Why per-surface randomization fails
The obvious-but-wrong approach is to randomize each fingerprint surface on its own — a random canvas hash here, a random WebGL string there, a random font list. The problem is that these signals are not independent in real life, so random combinations produce a device that could not exist: a macOS user-agent paired with a Linux font set, an NVIDIA GPU string on a Mac screen aspect ratio, an Asia/Tokyo timezone with US English. Anti-bot models, trained on millions of real users, know these pairings never occur and flag them instantly. The disguise becomes the giveaway.
Runtime spoofing vs engine-level patching
The same fix can live at two different layers, and where it lives decides how well it holds up:
| Runtime spoofing | Engine-level patching | |
|---|---|---|
| How it works | JS injected at page load overrides properties / methods | C++ source of Chromium / Firefox is patched and rebuilt |
| Examples | puppeteer-extra-stealth, undetected-chromedriver, selenium-stealth | Camoufox, CloakBrowser, PatchRight (patches at Playwright source) |
| Defeats toString check? | No — the patch is a JS function, visible via Function.prototype.toString() | Yes — the override happens below the JS layer, so toString still returns "[native code]" |
| Setup cost | npm install | Binary download (Camoufox/CloakBrowser) or pip install (PatchRight) |
| Maintenance | Plugin updates as detections change | Tied to upstream Chromium/Firefox releases; weeks-to-months lag |
Runtime spoofing means injecting JavaScript when the page loads to override the values a site reads. It is the cheap starting point and works fine against simpler vendors (Cloudflare Bot Fight Mode, Imperva, AWS WAF Common). Engine-level patching means editing and recompiling the browser's own C++ source so the fix sits below JavaScript, where detection scripts cannot see it. That deeper approach is what you need for Kasada, recent Akamai, Cloudflare Bot Management Enterprise, PerimeterX, and F5 Shape — see the vendor cheatsheet for which deployments fall in which category.
The real-profile-database approach
The hardest part of a consistent configuration isn't any individual signal — it's making them coherent, meaning they all fit together the way they would on one real machine. A browser claiming to be Chrome on Windows 11 with an NVIDIA renderer must also have the matching extension list, the matching AudioContext output for that OS, a timezone that matches the IP's location, and so on across dozens of signals. Spoofing each one by hand almost always produces a combination that doesn't add up.
The state-of-the-art fix is the real-profile database: collect tuples — bundles of values that belong together — of (UA, OS, GPU, audio, canvas, timezone, language, screen size, …) from real users at scale, then hand one whole tuple to each browser session. Camoufox bundles such a database (10k+ profiles); commercial anti-detect browsers like Multilogin and GoLogin maintain larger ones. Because each tuple was captured together from one real machine, every signal in it is automatically consistent.
The catch is novelty. Anti-bot vendors test against the same scraping tools and harvest their profile databases. A profile that's been published in Camoufox's corpus for six months may already be flagged. Refreshing the database is the real work — collecting profiles, rotating them out before they burn, and matching profile geography to proxy geography. This is why commercial anti-detect tools charge $50-200/month for the same idea Camoufox ships free: the operational cost of profile freshness, not the patching itself.
Whole-profile rotation
The right thing to rotate is a complete device profile, not one value at a time: a coherent set of (UA, fonts, GPU, screen, timezone, languages, TLS) that matches a real class of device. Tools like Camoufox ship with ready-made profile pools. If you build your own rotation, the generator has to respect which values go together — for example, a Windows + Chrome profile always carries the same set of installed fonts, the same TLS ciphersuite order (the fixed sequence of encryption options the browser offers), and the same audio context hash range.
What fingerprinting does not cover
A consistent static fingerprint is only one layer of how detection works. Behavioral signals — mouse movement, scroll velocity, how long you linger on a page — are judged separately. And IP reputation runs first: datacenter traffic is often handled differently before the page's JavaScript even loads. The static fingerprint is just one signal among several that systems weigh.