Web Scraping APIs

What Is CloakBrowser?

By the Scrappey Research Team

What Is CloakBrowser? — conceptual illustration
On this page

CloakBrowser is a Chromium build with 49 C++ binary patches that give it a consistent browser configuration. The goal is for it to present like an ordinary browser. Most anti-fingerprinting tools, like playwright-stealth, inject JavaScript at runtime to change browser values — but that injection is detectable, because a site can ask a function to show its own source code with Function.toString() and notice the difference. CloakBrowser takes a different route: it edits the Chromium source code itself and recompiles it. The patched browser features return [native code] when inspected because they genuinely are native code — there is no injected JavaScript to catch. It is tuned for Chromium-only sites and for Akamai's 60-extension probe, and it reports a reCAPTCHA v3 score of 0.9 (a score close to 1.0 means the site is very confident you are human).

Quick facts

Base browserChromium (vs Camoufox's Firefox)
Patches49 C++ binary patches — Canvas, WebGL, AudioContext, Battery, CDP input
Distinct featureLoads real extensions (uBlock, 1Password) to pass Akamai's 60-extension probe
reCAPTCHA v3 score~0.9 (consistent, low-risk score)
Memory footprint~200+ MB per browser instance

How CloakBrowser is different from playwright-stealth

Here is the key fact every stealth scraper has to understand in 2026: anti-bot scripts run Function.prototype.toString.call(fn) on the browser functions a stealth tool usually overrides. That call returns a function's source code. If the result is anything other than [native code], the site knows the function was tampered with — so the patch itself becomes the giveaway. This is why playwright-stealth fails against Kasada, recent Akamai versions, and DataDome: each JavaScript override leaves a visible source signature.

CloakBrowser changes the same things (canvas hash, WebGL renderer, AudioContext, navigator quirks, Battery API, CDP input handling) but does it in the C++ code before the browser is even built. The functions still return [native code] because they are still native code. Nothing was injected at runtime, so toString() finds nothing to flag.

The 60-extension probe and real extensions

Akamai's sensor.js tries to load 60 known chrome-extension://[id]/manifest.json URLs — in effect, checking which browser extensions you have installed. Real Chrome users almost always have a few (uBlock Origin, LastPass, Bitwarden, 1Password), so at least some of these requests should succeed. A headless browser (a browser running with no visible window, typical of bots) has none, so all 60 requests fail at once with net::ERR_FAILED — a result that is statistically impossible for a real user.

CloakBrowser ships with profiles that have real extensions installed, so some probes return real manifest data and the overall response pattern looks like a genuine Chrome user. This is the one Chromium-side feature that Camoufox cannot match as naturally, because Firefox has no chrome-extension protocol at all.

When to choose CloakBrowser vs Camoufox

Pick CloakBrowser for: Chromium-only sites; Akamai targets where sensor.js actively scores you and the extension probe matters; and sites that weight browser market share, since about 65% of users run a Chromium-family browser. The trade-off is higher memory use.

Pick Camoufox for: Cloudflare (reported high compatibility in Mar 2026), and sites where CDP detection is the main barrier — Camoufox is built on Firefox and drives the browser with Mozilla's Juggler protocol instead of CDP (the Chrome DevTools Protocol that automation tools use and anti-bots watch for). It also uses less memory.

For both: use real residential or ISP IP addresses; align your timezone and locale to the IP with geoip-style settings; run with a consistent, rate-limited input mode (humanize=True or equivalent); and never run more than about 10 instances on one machine.

Is the closed-source binary safe? (security analysis)

CloakBrowser's control library is open source, but the part that actually does the stealth work is a pre-built, closed-source Chromium binary you download and run with full local privileges. That is a real supply-chain concern (the risk that software you install does something hidden): a patched browser binary could in principle read your .ssh keys, harvest environment secrets, or phone home, and because you cannot see the C++ source you cannot rule it out.

An independent behavioural audit — github.com/pim97/cloakbrowser-analyze — ran nine runtime tests against the binary (watching what it actually does while running) 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 process it spawned was a standard Chromium component.

The same write-up is clear about the limit of that evidence: passing behavioural tests is not the same as being provably safe. A closed binary can still hide behaviour that only triggers after a delay or under specific conditions, which runtime observation will not catch. If your threat model cannot tolerate an unauditable binary — corporate machines, or anything near credentials or production infrastructure — prefer a fully open-source stack like Camoufox or PatchRight, or run CloakBrowser inside a disposable container with no access to host secrets.

Code example

python
# CloakBrowser is configured similarly to Playwright but with C++ patches baked in.
# Note: real extension profiles are configured at install time, not at runtime.

from cloakbrowser import CloakBrowser

with CloakBrowser(
    profile="default_with_ublock_1password",   # real extensions for Akamai probe
    proxy={
        "server": "http://residential:port",
        "username": "user",
        "password": "pass",
    },
    headless=True,
    humanize=True,
) as browser:
    page = browser.new_page()
    page.goto("https://akamai-protected.com/")
    page.wait_for_load_state("networkidle")
    # _abck flips to ~0~ after sensor.js POST — accumulated trust visible
    listings = page.eval_on_selector_all(".listing", "els => els.map(el => el.innerText)")

Related terms

Concept map

How CloakBrowser connects

The terms most directly tied to this one. Hover a node to see its neighbours, click to preview, drag to rearrange.

0 terms · 0 connections
You are here · Web Scraping APIs
Building map…

Frequently asked questions

Why does CloakBrowser need 49 patches?

Each patch hides one specific way a browser can be fingerprinted (identified) — Canvas pixel noise injection, WebGL renderer string spoofing, AudioContext output randomisation, navigator quirks, Battery API, CDP input timing. Together they cover the checks in the modern Akamai sensor.js script. New patches are added as new detection methods are documented.

Can I install my own extensions in CloakBrowser?

Yes — the build accepts standard Chrome extension packages. The default profiles come with uBlock Origin and 1Password installed, because those are among the most common real-user extensions and they pass Akamai's probe well.

How is CloakBrowser distributed?

It comes as a pre-built Chromium binary plus a Python control library. You do not need to build it from source unless you want to add your own custom patches — the standard binary covers most stealth use cases.

Will my fingerprint be unique enough?

Yes. CloakBrowser adds per-profile random noise to canvas and audio output, so two CloakBrowser instances produce different fingerprints (the values sites use to recognise a browser). Combine that with different proxy IPs and lightly randomized navigator properties, and you can run many sessions in parallel without them looking like the same client.

Is CloakBrowser safe to run? It's a closed-source binary.

The wrapper library is open source, but the stealth comes from a pre-built, closed-source Chromium binary that runs with full local privileges — a genuine supply-chain risk (the chance that downloaded software does something hidden). An independent behavioural audit at github.com/pim97/cloakbrowser-analyze ran nine runtime tests (string analysis over 2.9M strings, network capture, file-system and process monitoring, planted decoy secrets) and found no malicious behaviour. That is reassuring but not proof: a closed binary can hide triggers that only fire after a delay or under certain conditions, which runtime observation misses. Read 'no malicious behaviour observed' as exactly that, not 'provably safe'.

How do I reduce the risk of running the binary?

Run it in a disposable container or virtual machine that has no access to your real secrets — no mounted SSH or AWS credentials, no real environment variables, a network allowlist limiting where it can connect, and a throwaway proxy account. That way, if the binary ever does something unexpected, the damage is contained. If you cannot accept running an unauditable binary at all, use a fully open-source alternative like Camoufox or PatchRight, where you can read every line.

Is CloakBrowser open source like Camoufox?

Only partly. The control/wrapper layer is open source, but the patched Chromium binary itself ships pre-built and closed — you cannot inspect or rebuild the C++ patches from source. Camoufox, by contrast, is fully open source: its Firefox patch set is public and you can compile it yourself. If full transparency is a hard requirement, that difference is the deciding factor.

Last updated: 2026-05-31