My feed

When I added mobile personas to a browser that already had desktop ones working, I assumed the work was mostly string substitution: swap the user agent, set touch points to 5, shrink the viewport, done. That assumption survived about a day.

Mobile fingerprints aren’t a variant of desktop fingerprints. They’re a different set of constraints, and most of the desktop toolkit either doesn’t apply or actively gives you away. Here’s what I ran into, in the order it hurt.

Two test suites can have exactly the same average runtime and still create completely different development workflows. I modeled 300 code → test → fix cycles while keeping mean feedback latency close to ten seconds and changing only its variance. One runner behaved predictably. The other was usually fast but occasionally became extremely slow. The average stayed almost the same. The cost of waiting did not.

Modern software can become surprisingly difficult to run after only a few years. Dependencies disappear, package managers change, APIs get deprecated, runtimes stop supporting old versions, and sometimes the build instructions become archaeology before the actual code does. So I tried the opposite approach: write a small useful program in 2026 while treating 2056 as a real deployment target. The result turned out to be less about choosing the perfect language and more about removing assumptions that normally feel completely harmless.

I needed 100 disposable Linux machines for a test environment, so cloning one prepared VM looked like the fastest option. The clones received different MAC addresses, IP addresses and hostnames, booted normally and appeared as separate hosts in monitoring.

Then I started checking the identities stored inside the operating system itself. Across the whole fleet I found the same system machine ID, the same SSH host key, the same filesystem UUID, inherited cloud‑init state and the same WireGuard identity. What looked like 100 independent VMs from the outside was still one machine copied 100 times at several lower layers.

Finding a misconfiguration and proving an attack path are different tasks. ADhammer is an open-source Rust toolkit built around that distinction.

The workflow is simple:

Collect → Graph → Validate → Report

Collection first

The collector reads directory objects, ACLs, trusts, delegation, GPO signals, privileged principals, and certificate-template data. The result is an observation of the directory state—not an automatic compromise claim.

Graph context

AD relationships become typed edges: membership, control, delegation, enrollment, trust, and privilege. This makes a finding reviewable. A reader can ask which object creates the edge, which control is missing, and whether the route reaches a Tier 0 target.

Validation with a boundary

Validation is optional and intended for an authorized lab. When a supported workflow captures the expected proof, the finding records that validation state. Unsupported routes stay marked as potential instead of being promoted to confirmed exploits.

Evidence in the report

A useful finding keeps the affected objects, impact, remediation, commands, and proof metadata together. ADhammer exports JSON for automation, Markdown and HTML for human review, and graph-oriented data for existing identity-analysis workflows.

Why this matters

A report should let another operator understand what was observed, what was tested, and what remains unconfirmed. That makes remediation easier to prioritize and makes technical criticism productive.

ADhammer is still early software. It does not claim universal exploitability or replace operator judgment. The project is intended for authorized assessments and research environments, and technical review is welcome.

My Go API benchmark once showed an almost 7x throughput improvement after I moved a read-heavy endpoint from PostgreSQL to a local in-memory cache. The result looked obvious: PostgreSQL was the bottleneck, the cache removed it, and the API became much faster. Later I realized that this interpretation was too simple. ApacheBench had measured an entire request path consisting of HTTP handling, connection management, pgxpool waiting, SQL execution, decoding, serialization, and response writing. I decided to decompose that path and understand what the 7x result actually meant.

Daily tracking of job openings across 1,500+ tech companies reveals an emerging upward trend in AI testing roles.

Self-hosted Sentry means 65 containers, 16-32 GB of RAM, and a dedicated engineer just to keep it alive. All that - to catch stack traces. We dig into why the industry treats this as normal, compare the alternatives (GlitchTip, BugSink, Hawk), and take a look at Metric - a Sentry-compatible monitoring platform written in Rust that runs on 1 GB of RAM and two containers. Migration is a single-line DSN change.

Two months ago I gave an agent a simple job: log into a vendor portal, download last month’s invoice PDF, rename it, drop it in a folder. It worked on my laptop. It failed on the server, silently, in a way that took me a full day to understand — the page loaded, the DOM was there, the login form was there, and the credentials were rejected with a generic error. No CAPTCHA. No block page. Just “something went wrong.”

Everyone loves security — until they have to configure it. The first version of our audit extension felt like a nuclear power plant control panel: infinitely flexible, but impossible to operate without a manual. We admitted defeat, listened to DBA complaints, and shipped version 2.0 — with event classes and configuration logic designed for humans, not just compilers.

This article tells the story of fixing our own mistakes and turning a “shelf-ware” product into a tool people actually use.

A test taking 20 seconds does not necessarily cost a developer only 20 seconds. At some point during the wait, staying in the IDE becomes less attractive than opening a browser, checking documentation, reading a message, or starting another small task. I built a simulation of 300 code → test → fix cycles to estimate what happens when test latency begins to trigger context switching, and why cutting a test from 20 seconds to 10 may be much more valuable than cutting it from 5 seconds to 1.

There is a question quietly buried inside every task handed to a language model, and it rarely gets asked out loud. Do you trust one model? Do you go looking for the best model? Do you run several models side by side and keep whatever each of them happens to catch? Or — one turn further still — do you hand that whole pile of partial answers to yet another model and ask it to combine them into one? Each answer sounds reasonable on its own. Each is also, on its own, incomplete.

The goal here is to actually run that experiment rather than assume how it comes out. A single broken bash script, with seven distinct bugs of varying severity, is the test case, and the research runs in two rounds.

Round one: one model, unaided. Four models — Sonnet 5, HY3, Qwen3-Max, DeepSeek-V4-Flash — each fix the script working alone, with no knowledge of what the other three are doing. That's the first framing: one model, fixing only what it personally notices.

Best of the four. Once all four independent attempts exist side by side, the next question follows on its own: if you had to ship just one of these four scripts, which is best? Table 1 works that out below — though "best" here will turn out to mean "most complete," not "complete." Even the strongest single script among the four leaves real bugs unresolved.

Round two: each model selects the best from all four. That incompleteness is why a second round exists at all. Seven more models — ling-3.0-flash, Mistral-Medium-3.5, Nemotron-3-Super-120B, Qwen3-Max, DeepSeek-V4-Flash, Gemini Pro, dots-studio-3-note — are each shown the same four fixed scripts from round one and given the same job: pick out whichever fix, from whichever of the four sources, is genuinely the best solution to each bug, and assemble those choices into a single script.

Who actually combined best. All seven believe they've picked the best pieces. That's exactly the open question this round is built to test: does the model whose combination is objectively the strongest also turn out to be the one whose combination reads as the strongest — or does a different one of the seven, working from the exact same four inputs, put together something better than the obvious pick? Table 2 is where that gets settled, not here.

In an era where every company has its own app, UX design plays a vital role in representing the brand and building trust around the product. A well-designed app can accelerate your company’s growth, while a product with a poor user experience can ruin the company's image and lead to increased audience churn. To build an app that fulfills its mission and contributes to the company's success, you need a professional design team with the relevant experience, deep understanding of the subject and the right culture fit. Let's discuss a few key factors you should consider as a client before hiring a UX design team for your project.

In spring 2026, researchers at the Positive Technologies Expert Security Center (PT ESC) identified an unusual campaign targeting users in Saudi Arabia. The campaign used a previously unknown APK named Chrome.apk. The sample immediately stood out. Behind a benign-looking Google Chrome update screen and an unexpected request to enable Accessibility Services, we found a heavily protected execution chain that ultimately deployed Android spyware.

Codex CLI sessions are easy to manage when only one task is active. The workflow becomes less predictable when several sessions operate in different repositories or terminal tabs. A task may be blocked on an approval while another is still running and a third is ready for review.

In the first half of 2026, we discovered activity by the East Asian threat group FamousSparrow. Its attacks targeted several countries in South Asia and Europe. In these attacks, the threat actor used its own malware: a heavily reworked variant of the modular SparrowDoor backdoor and a new backdoor that we named SquawkDoor.

FamousSparrow, also known as Salt Typhoon and Earth Estries, is an East Asian threat group that has been active since 2019. The group is known for using its proprietary SparrowDoor backdoor and initially focused on attacks against hotels worldwide, as well as government and international organizations. Later, FamousSparrow began actively targeting telecommunications companies and internet service providers, apparently seeking long-term access to lawful communications intercept systems.

In these attacks, the threat actor used both malicious LNK files and a website compromise vector involving malicious JavaScript. The injected script displayed a fake error message when a user visited the page and prompted them to download a new certificate. In reality, the download was a malicious executable that led to backdoor infection. The attacks were tailored to specific countries: the JavaScript samples and payloads contained text customized for the target country.

For several weeks, I logged every moment when understanding our system required asking another person instead of reading code, documentation, dashboards, or configuration. What started as a small experiment turned into a surprisingly useful map of hidden knowledge dependencies. The biggest risk was not missing documentation. It was that some parts of the system effectively existed inside one engineer's head.

Due to recent rapid progress in the field of large language models (LLMs), many have speculated about artificial general intelligence (AGI). This paper addresses the keystone question: Are LLMs capable of transitioning to AGI? The paper presents a framework for estimating the logical limits of cognitive systems, which highlights the conflicting design requirement, namely, being able to proficiently execute both strict and loose logic. LLMs are gravitating towards loose logic and that inhibits their ability to grasp the essence of complex topics.

I write about the point where software abstractions meet irreversible authority, with an emphasis on threat models, negative tests, and systems that fail closed.

DeepSeek Harness is often described as an open-source coding agent. That description is correct, but incomplete. The more interesting part is its architecture. DeepSeek Harness is a configurable runtime for constructing agents from model adapters, tools, session services, execution backends, permission policies, interfaces, and agent loops.