How CloakBrowser is different from playwright-stealth
The 2026 fact every stealth scraper has to internalise: anti-bots run Function.prototype.toString.call(fn) on every patched native function. If the result is anything other than [native code], the patch itself becomes the bot signal. This breaks playwright-stealth against Kasada, recent Akamai versions, and DataDome — every override leaves a JS source signature visible to toString.
CloakBrowser patches the same things (canvas hash, WebGL renderer, AudioContext, navigator quirks, Battery API, CDP input handling) at the C++ build level. The functions still return [native code] because they are native code. There is no JS injection, so toString() finds nothing.
The 60-extension probe and real extensions
Akamai's sensor.js fetches 60 known chrome-extension://[id]/manifest.json URLs. Real Chrome users have at least a few extensions installed (uBlock Origin, LastPass, Bitwarden, 1Password). A headless browser returns net::ERR_FAILED on all 60 simultaneously — a statistically impossible result for a real user.
CloakBrowser ships with profiles that have real extensions installed. Some probes return real manifest data; the response pattern matches a real Chrome user. This is the single Chromium-side feature that Camoufox does not address as natively (Firefox does not have the chrome-extension protocol at all).
When to choose CloakBrowser vs Camoufox
CloakBrowser: Chromium-only sites, Akamai targets with active sensor.js scoring (extension probes matter), sites that score browser market share (~65% of users are Chromium-family). Higher memory cost.
Camoufox: Cloudflare (reported 100% pass rate Mar 2026), sites where CDP detection is the gate (Camoufox uses Mozilla's Juggler protocol, not CDP). Lower memory cost.
Both: use real residential or ISP IPs, use geoip-style alignment, run with humanize=True equivalent, never run more than ~10 instances per machine.
Is the closed-source binary safe? (security analysis)
CloakBrowser's control library is open source, but the stealth value lives in a pre-built, closed-source Chromium binary you download and run with full local privileges. That is a real supply-chain concern: a patched browser binary could in principle read your .ssh keys, harvest environment secrets, or phone home, and you cannot audit the C++ source to rule it out.
An independent behavioural audit — github.com/pim97/cloakbrowser-analyze — ran nine runtime tests against the binary and reported no malicious behaviour observed: 2.9M extracted strings contained no suspicious URLs, hardcoded credentials, or exfiltration keywords; packet capture showed only the expected PyPI/GitHub traffic from the wrapper; the process never touched .ssh, .aws, or planted decoy secrets; and every spawned process was a standard Chromium component.
The same write-up is explicit about the limit of that evidence: passing behavioural tests is not the same as being provably safe. A closed binary can still hide time-delayed or conditionally-triggered behaviour that runtime observation will not catch. If your threat model cannot tolerate an unauditable binary — corporate machines, anything near credentials or production infrastructure — prefer a fully open-source stack like Camoufox or PatchRight, or sandbox CloakBrowser in a disposable container with no access to host secrets.