Our own stealth browser

TL;DR

• On Fidelity (Akamai) and Zillow (PerimeterX), our stealth browser Kestrel loaded 12 of 12 pages; stock headless Chromium loaded 0 of 12, on the same proxy exits.
• Kestrel builds one consistent identity (user agent, client hints, navigator, GPU) and takes its time zone and language from the proxy exit.
• Stock headless leaked our server’s real IP through WebRTC; Kestrel shows a page only the proxy.
• We drive it over raw Chrome DevTools Protocol, without the Runtime.enable call most automation libraries leave behind.
• Limits, measured: where a site blocks the IP (Redfin, Google), a better browser changes nothing, and neither browser gets past an interactive Cloudflare check.

Our agents browse real websites for real people. When a stock headless browser hits a bot wall, the agent fails, and the person gets no answer. So we built our own stealth browser, Kestrel, and a bench that measures it against stock headless Chromium on the same proxy exits.

The results, on live sites, 2026-10-06:

Source: the bench below.¹²

This post is about the engineering: what a browser has to get right to be believed, how Kestrel is put together, how we drive it, and how we measured it. Kestrel is ours and is not available online. We describe its design, not its origins.

The problem: a browser that tells two stories

The usual fix for a blocked headless browser is a fake User-Agent. Our research agent did exactly that: a Windows Chrome 138 UA, the AutomationControlled blink feature off, and --lang=en-US.³ It was added for a good reason. With the default HeadlessChrome UA, cnn.com served 164 bytes and zap.co.il answered “Request Rejected”.

But a UA flag changes one string. Chrome also sends UA client hints (Sec-CH-UA, Sec-CH-UA-Platform) and exposes them to scripts through navigator.userAgentData.⁴ Those come from the real binary, and Playwright’s headless mode runs a separate headless-shell build, Chromium 140 in our install.⁵⁶⁷ So the patched browser said this about itself, on a US exit:

Source: httpbin.org/headers and an in-page probe, US exit, try 1.¹

Every bold cell contradicts the first row. The patched browser claims Windows and then reports Linux three times. It claims Chrome and names itself HeadlessChrome. It sends no Accept-Language at all, which real Chrome always does.⁸ The last three rows are not lies, but they describe a server, not a desktop in New York. A bot wall needs only one contradiction.

That table is the design brief. Patching signals one at a time does not work, because every patch is a new place for two signals to disagree.

How Kestrel is put together

Kestrel has four layers. Each one exists because of a row in that table.

1. One identity, generated as a whole

Kestrel does not randomise values one by one. It builds a single, consistent profile and derives every surface from it: the UA string, the client-hint brands and platform, the navigator fields, the screen, the GPU and the locale. A profile that says “Chrome 152 on Windows” says it in the header, in the hints, in navigator.platform, in userAgentData and in the WebGL renderer, because all of them read from the same source.

The engine reports itself as Chrome 152.0.7977.64, and 152 is the version in every string, so the version a page reads matches the version its JavaScript runs on.⁷

2. The network decides the locale

A Windows desktop on a New Jersey exit with a UTC clock and no language header is not a person. Kestrel takes the time zone and the language from the proxy exit it is started with. On our first smoke test the exit was in Spain, and Kestrel chose es-ES and Europe/Madrid without being told to.⁹ On the bench we asked for en-US explicitly, and the Virginia exit gave America/New_York.¹

3. WebRTC cannot go around the proxy

A proxy hides the address a page connects from. It does not hide the address WebRTC reports. In stock headless, the STUN candidate on CreepJS, BrowserScan and Pixelscan was our server’s own public IP, in a different country from the proxy exit, shown on the same page as the proxy’s IP.² A “proxied” session was telling the site where it really ran. In Kestrel, non-proxied WebRTC is blocked, and the pages saw only the proxy.²

4. A service, a fresh profile per session, and a raw-CDP driver

Kestrel runs as a service. A client creates a profile (an OS family and the languages it wants), starts that profile with a proxy, and gets back a Chrome DevTools Protocol endpoint. When the session ends, the profile is deleted. Nothing carries over from one session to the next: no cookies, no storage, no history.¹⁰

We drive it over raw CDP, not through Playwright. That is a deliberate choice, for two reasons:

• Playwright’s high-level calls hang on it. Page title, screenshots and selectors never return. Plain navigation and evaluation work.
• Automation libraries leave their own fingerprint. Most of them call Runtime.enable on every page so they can track execution contexts, and that call is a widely discussed automation tell.¹¹ Our driver never calls it.

The driver is small. It attaches to the page target in flattened mode (Target.attachToTarget with flatten), enables the Page domain, enables Network only to block media with Network.setBlockedURLs, and runs its probes with Runtime.evaluate, which works without Runtime.enable.¹⁰ Screenshots come straight from Page.captureScreenshot.

The cost is integration. Our eval harness is built on Playwright, so moving a workload to Kestrel is a driver change, not a flag.

The bench

A stealth claim without a controlled comparison is marketing. The bench is built so that only one thing differs between the two arms: the browser.

Same exit, both browsers. Each try uses one datacenter exit from our basic proxy system, and both browsers use that exit. We used three US exits, A, B and C, in Virginia, Texas and New Jersey.⁷ This is what lets us tell a browser block from an IP block (see “What the IP decides”).

Success is decided before the run. Each site has a predicate in the bench’s judge function, written before any result was seen:

Source: the bench’s success predicates, fixed before the first run.¹⁰

Timing starts just before navigation and stops when the predicate first passes, polled every 500 ms. A page that never passes is a failure at 60 s. At most 3 tries per cell, one per exit.¹⁰

Small on purpose. Fewer than 150 fetches in total, $0.00 of model spend (no model is called), proxy bandwidth only.⁷

Results

Source: 54 matrix loads, 12 challenge loads and 2 redo loads.¹¹²¹³

† On exit A, stock headless’s first Redfin and Google tries died with a network error on our side (ERR_NETWORK_CHANGED), not a site block. We re-ran those two cells once on exit A. Redfin then passed in 2.6 s, and Google got a 429.¹³ The same error also hit two of stock headless’s nine Fidelity tries (both on exit C), which we did not re-run. The other seven failed with Akamai-style protocol errors and stalls. A bare Playwright launch with no flags at all (navigator.webdriver true) was blocked on Zillow and timed out on the fund page too, in a single try.¹¹⁴

Akamai tends to stall a suspect client rather than serve a block page. We saw ERR_HTTP2_PROTOCOL_ERROR, ERR_EMPTY_RESPONSE and plain timeouts, and there was never a page to read. Kestrel, on the same exits, loaded the FBALX fund page (the Fidelity Balanced Fund) every time.¹

This started with one eval run. An agent asked about Fidelity mutual funds, and our headless browser timed out at 60 s on both Fidelity pages it tried. On the same proxy type, Kestrel loaded the screener in 20.6 s and the fund page, 7.8k characters of it, in 9.9 s. The matrix above is that anecdote turned into a measurement.

What the IP decides

Redfin and Google did not care which browser we used:

Source: ¹¹³.

Sometimes it is the IP. These datacenter exits are on Redfin’s and Google’s lists in a pattern of their own, and a better browser changes nothing there. The bench can say so only because both browsers shared each exit. With a different exit per browser, Redfin would have looked like a browser result.

On Zillow and Fidelity the exit was held fixed and the browser decided the outcome. Kestrel differs from stock headless in many signals at once, so the matrix does not say which single signal each site keys on. It says that a browser whose signals agree got in, on the same exits where one whose signals disagree did not.

What the “is it a bot?” pages say

Public fingerprint pages are a quick, free second opinion. We loaded ten of them in both browsers on 2026-10-08, on the same Virginia exit, one load each.¹⁵ One pair tells the story; the table below has the rest.

A verdict in one line. deviceandbrowserinfo.com calls stock headless a bot and Kestrel a human. Its raw details name why: for stock headless, isAutomatedWithCDP, hasInconsistentChromeObject and hasHighHardwareConcurrency are all true. For Kestrel every check is false.¹⁵ The first of those points at the automation driver, not the profile, which is why Kestrel is driven over raw CDP.

The WebRTC leak. BrowserScan’s IP panel, same exit. Stock headless shows the proxy in the USA, and then, through WebRTC and STUN, our server’s own addresses, located in Germany. Kestrel reports WebRTC as disabled, so the only address the page learns is the proxy’s.¹⁵

The classic checklist. bot.sannysoft.com’s first table. Stock headless fails five rows: no window.chrome, the permissions check, zero plugins, a plugin list of the wrong type, and a SwiftShader software renderer. Kestrel passes all eleven, with 5 plugins and a desktop GPU under Direct3D 11.¹⁵

The strictest page. CreepJS rates stock headless 94% “like headless” and Kestrel 31%. The same view shows why the locale layer exists: stock headless is on UTC behind a US exit, and Kestrel is on Eastern Daylight Time.¹⁵

The pages do not agree with each other, and Kestrel does not pass all of them:

Source: 2026-10-08 fingerprint run.¹⁵

Pixelscan still calls Kestrel inconsistent, because it recognises the datacenter exit as a proxy. That is the IP, not the browser, the same split as Redfin and Google above. BrowserScan’s dedicated bot page passes both browsers, so a single green page proves little. BrowserScan’s own deductions for Kestrel were a WebGL exception and an audio exception, 5% each.¹⁵ Those are what the fingerprint-noise work below is for.

A lesson about our own test: the Turnstile demo

Our first matrix included Cloudflare’s Turnstile demo at demo.turnstile.workers.dev. Both browsers “passed” it, stock headless included.¹ That demo uses a Cloudflare test sitekey, which always passes. It measures nothing. We replaced it with a page that uses a real sitekey in non-interactive mode. Both browsers still got a token, on all three exits.¹²

The nopecha.com Cloudflare demo showed the interactive “Verify you are human” checkbox to both browsers on all three exits: 6 cells, 6 × 403 and the checkbox.¹² Our bench does not click checkboxes or solve challenges, on purpose (see “Ethics”). This row says that neither browser skips the interactive step without a click, and nothing about what happens after one.

How to bypass Cloudflare Turnstile with ease

Sorry, we can’t write all the details here.

However, we did extensive work on Cloudflare and other anti-bot systems, and we really do mean extensive.

What is next

• Kestrel in our research agent. That needs a CDP driver for the agent’s harness first, and then a rerun of the Fidelity task that started this.
• Residential and mobile exits. Every exit here was a datacenter address from our basic proxy system. On an advanced proxy system (residential exits), Redfin and Google might not split by exit.
• Fingerprint noise. Per-site noise options, in the style of Brave’s randomisation, are in progress and were not part of this run.
• WebRTC in our headless workloads. Turn off non-proxied WebRTC there too.

The proxy is chosen per site, separately from the browser. Kestrel pairs with the basic proxy system by default, and government sites always take a separate, dedicated route.

Ethics

We built Kestrel for research and agent reliability. Our agents act on behalf of real users, who ask them to read pages a person could read in their own browser. A browser that is consistent about being Chrome is part of that.

What we did in this bench, and what we do not do:

• We loaded public pages only. No accounts, no logins, no paywalls bypassed.
• We solved no CAPTCHAs and clicked no challenge. Where a site asked for an interaction, we recorded that as the result.
• We kept volume small: fewer than 150 fetches, at most 3 tries per page, and a 60 s ceiling.⁷
• Every live fetch went through a proxy provider, not our servers’ own IPs. Government sites take a separate, dedicated route.
• We do not use Kestrel for account farming, fraud, ad fraud, scalping, or getting around a ban placed on a user.

Nothing in this post says that any site’s terms of service allow automated access. Whether they do is a question for each site and each use.