Have you tried patchright and compared against your project ?

[Greatz08]

I did recently tried patchright and it was a good experience for me personally and so i did researched about similar projects and got to know about this one. I did see that your approach is directly patching chromium instead of playwright lib which is pretty good ( i guess inspired from camoufox ? ) , but i was wondering if both can pass alot of modern security checks then did you ever feel the need for seperate project because of which you created this one or it was a hobby project for you to work on and have an alternate way of passing all security checks in chromium environement. I am just curious to know the reason behind the development of this project :-)) .

I also want to say thank you very much for this project ( wish i could see the patches but i know you did hide/not shared those for a reason and i understand this tough/sad reality of open source , which is that if you showcase those patches then it will be painful if they get patched and you have to spend much more time in finding new or might face different challenges, but if you dont open source then community wont be able to trust and try confidently but still i respect your work )

[Cloak-HQ]

Thanks for the thoughtful question, and for the kind words about the project.

On Patchright specifically — yes, we've tested it extensively. In fact, when we first launched CloakBrowser, Patchright was our default backend because our binary didn't yet cover all the CDP-level leaks it addresses. Over the past couple of months we've added C++ patches that handle those signals directly, and after testing against 50+ detection systems we haven't found a single case where Patchright makes a measurable difference on top of our current patches. It also introduces real downsides — it breaks proxy authentication and addInitScript(), which a lot of our users rely on. We're actually considering removing Patchright support entirely (context in #121).

On why a separate project — Patchright and CloakBrowser operate at different layers, and that's the key:

• Patchright is a runtime patch of Playwright itself. It suppresses CDP automation artifacts (Runtime.enable traces, console API leaks, etc.) at the JavaScript/automation layer.
• CloakBrowser patches Chromium at the C++ source level. Fingerprint signals (GPU, WebGL, canvas, audio, fonts, screen, timezone/locale, hardware) are spoofed before any JavaScript can observe the "true" values.

The two approaches overlap but aren't equivalent. Modern anti-bot systems (DataDome, Arkose, FingerprintJS, Akamai, Kasada) don't check individual signals in isolation — they cross-reference GPU with WebGL, canvas with audio, screen with platform, locale with timezone, etc. A single inconsistency flags the session. Runtime JS patches struggle with this because they're observable from the same layer the detection script runs in. Binary-level patches produce a coherent hardware profile that looks identical to a real browser because, from the page's perspective, it is one.

Other things that came out of building at the binary level and don't exist in Patchright:

• CDP input stealth — input events from automation protocols normally leave detectable traces. We patch those at C++ level so they look identical to real user input.
• humanize=True — one flag replaces Playwright's mouse/keyboard/scroll with Bézier curves, per-character typing, realistic scroll patterns. Behavioral detection is a whole separate layer.
• Working headless — no Xvfb workarounds needed for most sites.
• Zero-config stealth — the binary auto-generates a coherent random fingerprint at startup with no flags required.

More detail on the comparison with other patched-Chromium projects is in #75 if you're curious.

On the patches being closed — you've already understood the tradeoff perfectly and we really appreciate that. The short version: anti-bot companies actively reverse-engineer open-source stealth projects. DataDome published a breakdown of how they dismantled puppeteer-stealth, and they now flag ~40M requests/week from that plugin alone. Camoufox's own README says the same: "Anti-bot providers test Camoufox over and over again to find even 1 unique inconsistency, then they immediately update their background scripts to test for it." The pattern has been consistent across every open-source stealth tool. Publishing the patches would hurt every CloakBrowser user, not just us.

The wrapper (Python + JS) is fully open source under MIT, so you can see exactly what's being launched. For the binary, we publish VirusTotal scans, signed Docker images (Cosign/Sigstore), and GitHub artifact attestation. Full trust discussion is in #50 and #105 if you want the deeper version.

Let us know if this works for you, and thanks again for taking the time to ask.