Browser fingerprint detection research and sources

A deployed bytecode-VM anti-bot. Its payload script collects 427 browser probes per page load, and the published teardown enumerates every one of them — which makes it a ground-truth list of what a commercial detector actually reads.

Read from a public reverse-engineering writeup and the decompiled script it publishes. We have no access to Kasada's source or its server-side scoring.

A deployed collector. Its ev1/ev2 payloads carry 200+ fields under obfuscated keys; a public RE study decodes them against real captures, so each field can be traced to the browser API that produced it.

Read from a public reverse-engineering study and the deployed scripts it archives. Field keys cited in the findings are that study's decodings, not documentation from the vendor.

A deployed collector. A public RE project publishes a real captured payload — 232 fields under six-character obfuscated keys, with the values a live browser actually sent — so a field can be matched to the API that produced it by its own value. A companion project disassembles the bytecode VM that builds it.

Read from a public captured payload and a public VM disassembly. Field keys cited in the findings are our readings of that capture, not documentation from the vendor, and the keys are per-deployment rather than stable — a key quoted here identifies a signal, not a permanent name for it.

Bot Manager v2. A public analysis of its ~512KB sensor script inventories the signal categories it collects — browser fingerprint, hardware, behavioural, JavaScript environment, timing and network — which is why findings cite it for a category rather than a field key.

The weakest of the sources cited here, and worth saying so: it is a categorised inventory rather than a decoded payload, so it establishes that Akamai reads a signal without pinning the exact probe. Findings citing it say only what that inventory says.

An open-source fingerprint research tool, and the origin of the lie-detection method this whole page is built on: compare a browser against itself rather than against a population.

A research tool, not a commercial detector. Where a finding names CreepJS it means the technique is demonstrated there — not that anything is scoring you with it.

A scraping-API vendor that publishes detection research and a public browser-fingerprint tool. Their write-up of the Math.tanh OS oracle — V8 swapping to std::tanh in Chrome 148, exposing the host C library's rounding — is the source of this audit's OS check; their fingerprint tool's signal inventory (EME/DRM, WebGPU, media devices) confirms which surfaces a commercial detector reads.

An open-source patch set for Puppeteer and Playwright that documents how CDP-driven automation leaks — Runtime.enable exposing execution contexts, sourceURL traces, main-world execution — and patches each. Its write-ups are the source for this audit's CDP-leak checks, read as a catalogue of what those leaks look like from the detector's side.

A stealth-tooling project, not a detector. Where a finding names Rebrowser it means the leak is documented there; the check measures the leak, it does not use their patches.

Independent research into how Chrome's DevTools Protocol gives itself away. The published walkthrough follows a single console argument down through V8's inspector — the preview call in v8-console-message.cc, the two surface-only Proxy guards in value-mirror.cc and debug-property-iterator.cc, and the point in keys.cc where the ECMAScript spec leaves the engine no choice but to call back into page script — and demonstrates it against the author's own instrumented content_shell build. It is the source for this audit's prototype-chain Proxy check, and it also documents why the older Error.stack vector stopped working.

A technique writeup, not a detector and not a decoded payload. Where a finding cites it, the claim is that the signal exists and is reachable — verified here by reproducing the probe — not that any named system is scoring you with it. The V8 source it quotes is public and can be read against the commits it names.

Google's reCAPTCHA anti-bot. A public reverse-engineering project disassembles and emulates its “old” BotGuard bytecode VM until a token is produced, and ships the real loader script — which is where the one signal we take from it lives: the loader depends on Trusted Types producing a genuine, eval-able TrustedScript.

A token solver, not a signal payload, so it exposes only the surface its own loader touches rather than a field inventory. Cited by a single finding, on the strength of the loader's visible dependency, not a decoded probe list.

A fraud-detection vendor. Its client script forces relay-only WebRTC against its own TURN servers, tagging each attempt with a short-lived token so the backend can bind the UDP source address it observes to that specific page load, then closes the connection seconds later. That design is what the relay-egress check on this page reproduces — and reproducing it is how we confirmed the technique works: a real browser reports zero relay candidates to the page while the TURN operator records the true public address in the same second.

The weakest provenance on this page, and it should be read that way. We have NOT read Verisoul's script ourselves — the description comes from a user-supplied analysis of a session that was flagged. What we did verify independently is the MECHANISM, against our own TURN endpoint: that part is measured, not reported. Treat the attribution as credible-but-second-hand and the technique as demonstrated.

The public issue tracker of a stealth browser. Each bug report where a detector caught the browser is a detection signal stated from the wrong side — read inverted, the tracker is a catalogue of what real anti-bots check, confirmed against a shipping product.

A bug tracker, not a detector. A cited issue establishes that some real system caught this signal against CloakBrowser; it does not name which vendor, and the reporter's diagnosis is theirs, not ours.

The same stealth browser, but run here against this very page under a licensed Pro build and compared field-by-field with stock Chrome on the same machine. Where a finding cites this, the contradiction was observed directly rather than read about, and the value the browser actually reported is quoted in the evidence line.

One product, one machine — so it shows that a shipping browser can produce the contradiction, not in which versions or on which hosts. Where a finding is cited here it was reproduced across repeated launches and the rate is stated with it, because this browser randomises part of its profile per session and a contradiction seen once is not the same claim as one seen every time. Every baseline compared against was measured on stock Chrome on the same hardware.

The harvesting collector a stealth tool ships to capture real devices for REPLAY. It scores nothing and detects nothing, which is what makes it a different kind of artifact from the others here: its field list is a spoofer's own statement of which surfaces it believes have to be reproduced faithfully. Read in full. Most of what it collects this audit already checked; the surfaces it reads that nothing here did became the seven compiled-API-surface rows.

A spoofing tool's own collector, not a detector and not a decoded payload — the same weak class as a vendor changelog, and worth saying so. It establishes that a stealth tool considered a surface worth harvesting and replaying; it does not name any system that reads it, and neither do the findings that cite it.

The shipped release notes of the same stealth browser, which are a different artifact from its issue tracker and are cited separately for that reason. An issue is a bug a user hit; a release note is the vendor stating which surface it had to bring into line with a real Chrome install. Read as a list of what was worth fixing — the Chromium 150 build names speech and language profiles, and Windows system colors and selection rendering, in one clause.

A vendor's own changelog, not a detector and not a decoded payload — the weakest kind of source cited on this page, and worth saying so. It establishes that a shipping stealth browser considered a surface worth aligning; it does not name which system reads it, and neither do the findings that cite it.

The public issue tracker of a Firefox-based anti-detect browser. It is our one Gecko-focused source — where the others document Chromium tells, a Camoufox bug report reveals a Firefox-specific one: a Gecko surface that leaks the real host through a value the browser tried to spoof.

A bug tracker, not a detector. Because Camoufox is Firefox, each cited issue is a Gecko coherence tell that a real Firefox does not exhibit; it does not name which vendor caught it, and the reporter's diagnosis is theirs, not ours.

The same Firefox-based anti-detect browser, but run here against this page and driven to specific operating-system personas rather than read about. It is the only stealth build measured here that is not Chromium, which makes it the control for whether a check works on a non-Blink engine at all — several of this page's oracles turn out to be Chromium-only and say nothing against it.

One product on one host, and a defended surface rather than a failing one: where a finding cites this, the browser handled the vector correctly and the citation records that the vector is real and actively defended, not that this browser failed it. Forcing a persona with os= is not the same as the profile a user would draw at random, so treat the OS as chosen rather than representative.