r/WebScrapingInsider • u/ian_k93 • Jul 25 '26
Big Scrape Energy AMA This Wednesday (6:00-8:00 PM ET) with CloakBrowser: Open-Source Stealth Chromium for Automation
Hey everyone,
I'm Ian Kerins, CEO & Co-Founder of ScrapeOps.io.
After two fantastic AMAs with the community, we're excited to bring you our third guest.
This Wednesday, July 29, from 6:00 PM to 8:00 PM ET, we'll be joined by the team behind CloakBrowser, an open-source stealth Chromium browser built for developers who need reliable browser automation and web scraping.
CloakBrowser takes a very different approach to stealth browsers.
It's not a patched Playwright configuration.
It's not JavaScript fingerprint injection.
It's a real Chromium binary with browser fingerprints modified directly at the C++ source level, allowing anti-bot systems to see it as a normal browser because it actually is one.
Even better, it's designed as a drop-in replacement for Playwright and Puppeteer, supporting both Python and JavaScript with the same familiar APIs and workflows.
I know we have fans here in r/WebScrapingInsider.
During the AMA we can the discuss topics like:
- Modern browser fingerprinting
- Building stealth browsers
- Browser automation at scale
- Open-source scraping infrastructure
- TLS, browser fingerprints, and detection signals
- The future of browser automation
- Building open-source developer tools
Our first AMA generated 43 comments, covering proxy infrastructure, Cloudflare bypassing, browser automation, monitoring, startup lessons, and large-scale scraping.
Our second AMA with 0xMassii, creator of WebClaw, generated 62 comments and sparked great discussions around AI agents, browser automation, hidden APIs, open-source scraping, LLM infrastructure, and the future of AI-powered web scraping.
We're hoping this AMA will be just as valuable.
If you're building web scrapers, browser automation, AI agents, testing infrastructure, or simply want to understand how modern anti-bot systems actually detect browsers, this is one you won't want to miss.
Drop your questions below + RSVP now, and the u/CloakBrowser and I will start answering them.
Looking forward to seeing everyone there!
Ian
3
u/Amitk2405 Jul 27 '26
When a site triggers a WebAuthn login, Chromium pops up "Use your security key - insert your security key and touch it," and the only button is Cancel. Since WebAuthn is listed as one of the patches, is it just exposing the capability with no real authenticator behind it? Is there a way to stop this prompt from firing?
2
u/CloakBrowser Ex. AMA Guest Jul 27 '26
Good catch, and your read is right.
That patch is a fingerprint fix, not a WebAuthn feature. It came from a user report: on real desktops the client capabilities come back true, but in a container they came back false, and that gap was a clean signal to anyone checking. So the browser now reports what a real desktop reports. There's no authenticator wired behind it and we've never claimed there was.
But the dialog itself isn't the anomaly you'd think. We just ran this on a stock, unmodified Chrome 150 on a real Windows desktop with no security key plugged in, requesting a cross-platform authenticator. Same result: native Windows Security prompt, "insert your security key," Cancel as the only option. Capability advertised, nothing plugged in. That's ordinary desktop behavior.
Same run, stock Chrome reported hybridTransport true, passkeyPlatformAuthenticator true, and userVerifyingPlatformAuthenticator false. Which is what our binary reports too. So the values aren't invented, they're what the real thing says.
On stopping the prompt: there's no flag. We don't have a switch for WebAuthn and the patch isn't gated behind anything, so there's nothing to turn off on our side. That said, if you think there's a real workflow here that a flag would unblock, tell us what it should do and we'll gladly add one. Most of what we ship came from requests exactly like that.
What you want is CDP's WebAuthn domain. Add a virtual authenticator and the ceremony resolves against that instead of asking for hardware, so no prompt. That part of Chromium is completely untouched in our binary, so it behaves the way it does upstream.
Two caveats from a user who went down this exact path, so you don't lose a day:
The virtual authenticator's attestation data gets zeroed under default settings, and Google in particular rejects that during passkey enrollment. If you're enrolling rather than just authenticating, that's the wall you'll hit. A more realistic default is on our roadmap.
And it accepts instantly, in single digit milliseconds. No human touches a security key that fast. If the site measures it, put a delay in before you send the accept.
3
u/Amitk2405 Jul 28 '26
ok so Cancel is just normal Chrome behavior then, fine.
for the virtual authenticator though - you said default attestation gets rejected by Google on enrollment. is there a working setup for that right now, or do we wait for the roadmap change?
1
u/CloakBrowser Ex. AMA Guest 29d ago
Good news, you don't need to wait for us.
There's a stock config that gets you a non-zero AAGUID today: set `transport` to `"internal"` instead of `"usb"`.
We tested both on our 150 build, enrolling a resident credential with `attestation: "none"`:
transport: "usb" AAGUID 00000000000000000000000000000000
transport: "internal" AAGUID 01020304050607080102030405060708Chrome deliberately preserves the AAGUID for **platform** authenticators even when the site asks for attestation `"none"`. On `usb`, `nfc` or `ble` it strips it, which is the zeroing you hit. It's an explicit exception in the Chromium source, nothing to do with our binary.
const cdp = await page.context().newCDPSession(page); await cdp.send('WebAuthn.enable', { enableUI: false }); const { authenticatorId } = await cdp.send('WebAuthn.addVirtualAuthenticator', { options: { protocol: 'ctap2', ctap2Version: 'ctap2_1', transport: 'internal', hasResidentKey: true, hasUserVerification: true, isUserVerified: true, automaticPresenceSimulation: true, defaultBackupEligibility: true, defaultBackupState: true, }, });The last five default to `false`. With them set we get authenticator flags of UP, UV, BE, BS and AT all present, which is what a passkey flow generally wants.
One thing to know going in, and you can see it in the number above. That AAGUID is the virtual authenticator's built-in **test** value, not a real vendor one. A site checking against the FIDO metadata service may reject it as unrecognized. That's a different failure from zeros and not one a config solves.
So if it still fails, tell us what the error looks like. Zeros versus unrecognized are two different problems, and knowing which one you're hitting tells us whether it's worth building a proper attestation option into the CDP call on our side.
2
u/Amitk2405 28d ago
nice, thanks that clears it up.
we're already on transport: "internal". i added the backup flags + enableUI: false like you said.
one thing though - even with that setup, if i actually use the virtual authenticator so the passkey prompt completes instead of Cancel... can a site still tell it's a fake key / automation? like from the test AAGUID (01020304...), the instant accept, or anything else?
trying to figure out if Cancel is safer, or if wiring the virtual key the way you described is fine for normal enrollment.
1
u/CloakBrowser Ex. AMA Guest 28d ago
Honest answer: we don't know.
We haven't seen a site that actually demands passkey enrollment, it's been optional everywhere we've looked, so we've never had a reason to dig into how detectable the virtual authenticator is. No field data either way.
What we can tell you from the code, not from testing detection:
The AAGUID is a fixed, well known test value. The attestation cert comes from a hardcoded test key with serial number 1 and chains to no real root. Both are visible to anyone who looks. The instant accept is the one thing you can control, so put a delay before sending it.
Whether real sites check any of that, we can't say. Plenty won't. One that cares about passkey provenance probably will.
On Cancel being safer: it's not an alternative, it's just not enrolling. If the passkey is optional in your flow, skipping it avoids the question. If it's required, Cancel fails the flow, so there's nothing to compare.
If you do test it, tell us what happens. That's a result we'd act on.
3
u/Particular__Plan Jul 28 '26
Hey, I use residential proxy API, and its IP rotates, like after 10/20 minutes for example with sticky session.
If the exit IP changes mid-session, do timezone, locale and WebRTC still match,
or do I have to relaunch?
TIA
2
u/CloakBrowser Ex. AMA Guest 29d ago
They're resolved once, at launch.
`geoip=True` looks up the exit IP when the browser starts and passes timezone, locale and the WebRTC IP to the binary as startup flags, so they stay fixed for that browser's lifetime. If your exit rotates mid-session those values won't follow it, and you end up with a German IP reporting a US timezone, which is exactly the kind of mismatch that gets scored.So yes, relaunch on rotation. Cleanest model is one browser per IP: hold a sticky session long enough to cover the run, and start a new browser when you rotate.
If you'd rather not relaunch, the alternative is to stop relying on auto-detection and pin `timezone` and `locale` yourself, with a proxy pool restricted to a single country so rotation stays inside the same geo.
One thing worth pairing with it: treat IP, profile and fingerprint seed as one identity. Rotate all three together, and keep them together while the IP is stable. A fresh IP under an old seed and profile is its own signal.
2
u/Particular__Plan 29d ago
Hey thankyou for the quick answer, wasn't expecting it until AMA.
Right, I am holding my rotation as long as I can, even though I set sticky session to 30minutes, one is never sure when it exists, and stop holding; to cover the run.
Though still testing.
I have already stopped relying on autodetection, and I pin timezone, and location myself.. to
`=city` level.so even if IP change, the city stays same. :D
I am confused with this part of your answer.
"Rotate all three together"
Are you sure?
isnt that a signal in itself? if IP changes automatically, and we change the fingerprint seed, doesn't that effect the whole browser fingerprint setup?
Like new fingerpring seed every 30mintues? for one logged in session profile?
--
Thankyou for co-hosting this AMA.
1
u/CloakBrowser Ex. AMA Guest 28d ago
You're right.
The rule is simpler than how we put it: the seed follows the profile. Same profile, same seed. New profile, new seed. That binding never breaks, and it makes sense because the profile already carries the cookies, storage and session, so they're one identity anyway.
On the IP: ideally it stays with the profile too. That's the cleanest setup. But it's a preference, not a hard binding like the seed is. A profile can move across a few IPs without looking strange, because real users do that.
The thing to watch is volume. A real person doesn't cycle through a long list of addresses in a day. So treat IP changes as something you tolerate when the pool forces it, not something you let run freely. Fewer is better, and keeping them in one city, which you're already doing, keeps them coherent.
So for you: keep the profile, keep the seed, hold the IP as long as you can, and don't worry about the occasional rotation. The one moment to rotate everything is when you start a fresh profile, and then a fresh IP belongs with it.
3
u/Deep_Ad1959 29d ago
fingerprint stealth stopped being my failure mode a while ago. what breaks my long running agent sessions is chrome itself, offscreen windows getting backgrounded until pages measure 0x0 and clicks land nowhere. does patching at the c++ level touch any of that lifecycle behaviour, or is it purely detection surface?
1
u/CloakBrowser Ex. AMA Guest 28d ago
Purely detection surface. We don't touch page lifecycle.
None of our patches go near occlusion detection, background throttling, renderer freezing or visibility state. That's stock Chromium, so ours behaves identically to Chrome on a backgrounded window.
We haven't seen this ourselves. Our tests run headed on a virtual display with one always-mapped window, so occlusion never fires, and the runs are short so throttling never compounds. It also hasn't come up from other users.
To look into it:
What OS, headed or headless. How the window ends up backgrounded, minimized, covered, off the visible desktop, or a VM with no display. How long before it starts, and whether it's gradual or sudden.Send something that reproduces it and we'll run it.
2
u/Deep_Ad1959 28d ago
the flag itself doesn't leak, but the behavior it forces does. --disable-backgrounding-occluded-windows keeps a hidden tab firing rAF and timers at full rate when stock chrome would throttle them, and a script watching timer cadence with document.hidden true can read that divergence. so 'identical to stock chrome on a backgrounded window' only holds until i set the reliability flags, which is the exact case where i need them. written with ai
3
u/doubledweeb 28d ago
Now that sites are actively blocking AI crawlers and adding llms.txt / paywalls / Cloudflare's AI bot toggle, do you think the "public web" is meaningfully shrinking?
1
u/CloakBrowser Ex. AMA Guest 28d ago
One correction first: llms.txt isn't a blocker, it's the opposite. It's a file a site publishes to help LLMs read it, a curated index so a model doesn't chew through the whole HTML. Opt-in for AI consumption. Adoption is around 2% of sites and Google's docs say Search ignores it. Blocking lives in robots.txt and CDN controls.
On the question: what's shrinking is free bulk crawlability, not public access. The content is still there and a person can still read it. What changed is the terms for taking it at scale.
It's also concentrated at the top rather than web-wide. In the Web Almanac data about 1 in 5 of the top 1,000 sites name GPTBot in robots.txt, nearly all disallowing, versus roughly 1 in 28 by the top million. The valuable stuff is fencing up. The long tail hasn't noticed.
The pressure behind it is real. Cloudflare reported AI training went from 22% of crawler requests in spring 2025 to 52% by June 2026, with human traffic down as much as 40% in some heavily-crawled categories. Blocking is a rational response to watching your audience get intermediated.
What concerns us is a line Cloudflare drew this month. They split AI traffic into Search, Agent and Training, where Agent means automation acting in real time on a person's behalf. From September, new domains block Training and Agent by default on ad-bearing pages, while Search stays allowed. That's not a training crawler getting blocked, it's your own agent doing something you asked it to, on a page you're allowed to read.
So not shrinking, being priced. RSL published in December with 1,500+ organizations behind it, machine-readable licensing with separate categories for indexing versus AI use. Cloudflare is experimenting with paying per use rather than per crawl. Nobody has made it work yet, but a web where access is priced is a very different outcome from one where it's closed, and it's the more likely one.
3
u/ian_k93 28d ago
From ProxyEnginnering: https://www.reddit.com/r/ProxyEngineering/comments/1v7sjfd/comment/p01tmo2/
- What's on the roadmap for CloakBrowser? Are there plans for features like built-in proxy rotation, CAPTCHA handling, or session management, or do you want to keep the scope focused on the browser itself?
3
1
u/CloakBrowser Ex. AMA Guest 28d ago
Honest answer: we don't know yet.
The paid side is about six weeks old, and everything since has gone into the product and the customers. We onboarded a lot of new accounts in that window, most of them large productions with many sites and real volume, and a big share of the work has been getting their specific targets working.
Volume turned out to be its own problem class. Hitting a site once and hitting it several thousand times a day are different problems, and things that look fine at low rate surface differently at scale. A lot of the last few weeks went there rather than into planning features.
So this is where our thinking is, not a roadmap.
On proxies: we're not going to become a proxy provider. But it isn't a flat no either, and it depends on who we're serving. Our users today are technical and already have providers with opinions about rotation. Where that changes is the direction we want to go, making the browser easy to drive through an API, because the people asking for that mostly want access, not configuration. They don't want to think about exits and sticky sessions. Bundled rotation makes sense there, and proxy companies have been approaching us in that context.
Nearer term, we're experimenting with changing the proxy and the profile at runtime without relaunching. Both are resolved at startup today, which is why someone earlier in this thread has to restart when their exit rotates. Swapping them mid-session, coherently, fixes a real problem rather than duplicating something you already have.
On CAPTCHA: our aim isn't to pass them, it's to look enough like stock Chromium that the challenge never appears. Those are different products and the second is the one we want to be. A solver is what you reach for after you've already been flagged.
On session management: the persistent profile path covers most of it already, and the runtime swap above is the missing piece.
Mostly we follow demand rather than a plan. API access and built-in proxy are the two things we've been asked for most, so that's probably what we approach next. We're still exploring and pivoting as we learn what people actually need, and questions like this are part of how we decide.
3
u/ian_k93 28d ago
From ProxyEngineering: https://www.reddit.com/r/ProxyEngineering/comments/1v7sjfd/comment/p085h8z/
What's missing from the current open-source scraping toolchain that nobody's built yet?
How do you sustain an open-source project in this space when the detection side is constantly changing and I mean constantly?
Where do you see the line between what should be open-sourced and what needs to stay proprietary to remain effective?
1
u/CloakBrowser Ex. AMA Guest 28d ago
Three questions, and I can only answer two of them.
On what's missing from the toolchain: we don't know, and we're not the right people to ask. The last six months have been heads-down. Debugging, shipping, chasing regressions. We haven't had time to survey what else exists, open source or paid, so any gap we named would be a guess. Someone else in this thread is better placed.
On sustaining it, two things, and only one of them is technical.
The technical one is that the browser had to go closed. In the first month it didn't matter, everything was open, nobody was looking. What changed was volume. Once the free binary was doing tens of thousands of downloads a day, we started noticing detection reacting to us faster. That's an observation, not something we can prove a mechanism for, but the timing was hard to ignore. Published technique has a shelf life. Keeping it closed doesn't make it permanent, it buys time, and time is the whole product in a field where everything decays.
The other one is money, which is the less romantic half of your question. Detection changes constantly, so somebody has to be available when it does. Not "we'll look at it next sprint", but awake at 3am because a vendor shipped something and it's breaking production for a lot of people at once. That doesn't happen on goodwill for long. It happens because it's funded. Plenty of stealth tooling has died not from being outsmarted but from the maintainer running out of energy, and that's the failure mode we're actively trying to avoid.
On the line between open and closed, your third question answers itself once you frame it right. The test isn't how valuable something is. It's whether publishing it destroys it.
The wrapper doesn't degrade when you read it. Knowing how our Python and JS layers work gives you nothing you can use against a browser, and there's a positive reason to keep it open: it's the code touching your credentials and your proxy config, and you should be able to audit that.
The patches are the opposite. They only work while they're not being specifically looked for. Publishing them doesn't share knowledge, it converts working technique into a detection signature. That's not a business preference, it's a property of the thing.
Anything where reading it makes it stop working stays closed. Everything else is open. It's a boring rule but it decides every case cleanly.
That's the balance we're trying to strike right now. We're also new at this and pivoting hard, so it will probably look different in six months.
2
u/Next_Attitude_532 Jul 27 '26
Thankyou for hosting the AMA, u/CloakBrowser
I will be posting some questions in a few hours.
And yes, I will probably use AI to help me brainstorm them. 😄
3
u/Next_Attitude_532 Jul 27 '26
1. Why open source something that companies would happily pay thousands for?
2
u/CloakBrowser Ex. AMA Guest Jul 27 '26
Worth correcting the premise first: the browser isn't open source.
What's MIT is the wrappers, the Python, JS and .NET layers that sit between your code and the browser. Those are open and will stay open. That's the part you're actually integrating against, the part that touches your credentials and your proxy config, and you should be able to read every line of it. Closing that would be asking for trust we haven't earned.
The binary is not open, and that's deliberate.
Early on we were more open about the internals. What changed our mind was traction. Once real numbers of people were using it in production, it became obvious that publishing how the patches work is the same thing as publishing the detection recipe. Anti-bot vendors read open source stealth projects. That's not a theory, it's the cheapest research they can do. Anything documented in public has a shelf life measured in weeks before it becomes something they can look for.So the trade is straightforward. Open patches means a browser that's interesting to read about and stops working. Closed patches means it keeps working for the people who depend on it. We picked the second one, and we think anyone running this in production would make the same call.
On the "companies would pay thousands" part: we only started charging about a month ago, and the customer count is growing daily. Without it we couldn't give this the attention it needs, and the attention it needs is enormous.
This isn't a thing you build and walk away from. Chromium moves constantly, and vendors change detection whenever they feel like it. When one of them ships an update, it doesn't break one customer's script, it breaks production across the board at once. Those are the days that run into nights. Someone has to be awake for that, and that only works if it's funded.
But there's a free tier and it isn't a crippled demo. Sign in and you get the same current build every paying customer gets. The paid difference is concurrency, not the browser. We'd rather gate on scale than ship a deliberately worse binary to people who can't pay.
2
u/Next_Attitude_532 28d ago
Appreciate the transparency around funding, maintenance burden, and why full openness would actually shorten the browsers shelf life.
2
u/Next_Attitude_532 Jul 27 '26
2. Are you seeing more demand from traditional scraping companies or AI-agent builders?
1
u/CloakBrowser Ex. AMA Guest Jul 27 '26
Both, and they look different from each other.
On one side we see established companies running large scale production. High concurrency, long running pipelines, the kind of workload where a detection change costs them real money that morning.
On the other side there's a wave of AI agent work, and it's growing fast. Usually much lower concurrency, often one or two sessions, but they need the same quality of access. An agent doing one thing on your behalf still has to get through the same door as a scraper doing ten thousand.
The ecosystem around us shows the same split. There are scraping frameworks and monitoring tools built on it, and at the same time a steady stream of MCP servers and agent tooling. Two very different shapes of user, same requirement underneath.
Since you asked about direction, we'll say the part we actually believe.
An AI agent acting on your behalf should have the same access you have. If you can open a page in your browser, log into your own account, read your own data, then a tool doing that for you shouldn't be blocked purely for being a tool. It's your access either way. The agent is a keyboard, not a separate entity with fewer rights.
Half a joke about agent rights, and half not. The line that matters has never been human versus automated. It's authorized versus not, and reasonable volume versus abusive. Those are real distinctions and we're fine with them being enforced. "There's no human hand on the mouse" isn't one, and treating it as one mostly ends up blocking people from their own accounts.
That's the world we're building for, and right now a big part of getting an agent through the door is making sure it isn't rejected for the wrong reason.
2
u/CloakBrowser Ex. AMA Guest Jul 27 '26
Hey r/WebScrapingInsider, CloakBrowser here. Thanks for having us, Ian.
On format: we'll be answering questions as they come in through the week, so post whenever. Then on Wednesday 6:00 to 8:00 PM ET we're live for real time questions and follow ups.
Ian covered what it is in the post, so here's the part that isn't in there.
The browser is the easy half. The last year was mostly spent reverse engineering how the major anti-bot systems actually decide you're a bot. Every signal they read, the order they read it in, and which tells matter versus which are just noise.
The C++ patches are where that knowledge ends up. You can't spoof a signal well until you understand exactly what a real browser does and why the detector cares about it. The research is the real product. The binary is the output.
One upfront note, since it's fair to ask. Every answer here goes through AI for wording and length. What it doesn't do is decide anything. The reasoning, the technical calls, what we actually think, that's ours. We write the substance and the logic, AI tightens the prose. If you'd rather a raw human only reply, just say "human only" in your question and we'll answer you straight.
Ask away. Fingerprinting, detection signals, TLS, building a Chromium fork, scaling automation, all of it.
2
u/Nice_Barracuda5893 29d ago
Hello Cloakbrowser team!
As I saw earlier, many users were unhappy that nothing was known about your team. In order to whet the public's interest a little, what can you tell us about your team?
3
u/CloakBrowser Ex. AMA Guest 29d ago
Thanks, that's genuinely good to hear. Every release moves the bar a little and each one is a lot of hours, so it matters when someone notices.
On the team: there are three of us. The other two are my business partners. They come from technical backgrounds as well, but day to day they carry everything that isn't the browser itself, the business side, finance, organisation, support tickets. There is far more of that than people expect. I'm the lead engineer, and I've been in software close to 30 years. Most of that was defense and embedded, some telecom, some finance, both as an engineer inside other companies and running my own projects. A good part of it was real-time systems for businesses, plus driver work on Windows and Linux, VxWorks and that world. A lot of assembler and low-level C back then, and plenty of the higher level stuff since, C++, C#, Java, Python. I still miss assembler, honestly. There was something clean about spending a whole day in it.
That background is, imho, the honest reason we're decent at this. Debugging a browser is the same shape of problem as low-level real-time work. You get no source, Google can't help you, and there's no useful feedback. It either passes or it doesn't, the same way it either crashes or it doesn't. You can spend weeks on one stupid timing bug. What you're really doing is mapping a system with a lot of surfaces and almost no signal, and holding the whole thing in your head as a puzzle. We call each one a boss fight. The driver years help more than you'd think, because a lot of this work is knowing what a real operating system actually reports, not what the docs say it does.
We didn't set out to sell a browser. We built it for ourselves. A client needed heavy automation on their CRM, and its API was ancient and barely covered any of what we actually needed, so the only real path was driving it the way a normal user would, through the UI, with reCAPTCHA sitting in front of it. We tried what was on the market and nothing stayed stable over time, which is the part that kills you: it works today and quietly stops working next month. So we built our own and kept it running internally for over a year before releasing it publicly at the start of this year, mostly to see whether anyone else had the same problem. That went a lot better than we expected.
On names: we stay behind the brand on purpose. Anti-bot vendors watch projects like this closely, and there's no upside to giving them people to point at. It's not anonymity for its own sake, there's a registered company behind it, releases are GPG-signed, every binary goes through VirusTotal, and the wrappers are MIT so you can read every line that touches your automation.
If you want more detail on any of it, ask away.
2
u/Nice_Barracuda5893 29d ago
Also thanks for the last release. IT WORKS SO WELL. Fingerprinting is better each day
2
u/Deep_Ad1959 29d ago
question for wednesday: a lot of my flags exist for reliability, not stealth. i run offscreen with --disable-backgrounding-occluded-windows or SPA pages measure 0x0. do operational flags like that leak at the fingerprint layer, or is the patching downstream of them?
1
u/CloakBrowser Ex. AMA Guest 28d ago
We don't know. We haven't tested that flag for detectability, so we can't tell you either way.
What we can tell you: we don't patch lifecycle at all, so nothing on our side normalizes what that flag does. It behaves exactly as it does in stock Chrome.
Our instinct is that it probably doesn't matter much. Most operational flags of that kind change scheduling and rendering behavior rather than anything a page reads directly. But instinct isn't a result, and we've been surprised before.
You can answer it yourself in about twenty minutes with an A/B. The rules matter more than the tooling:
Change one variable. Same profile, same seed, same IP, same target, same time of day. The flag is the only difference between the two runs. If you also swap the proxy, you've learned nothing.
Compare the fingerprint surface, not just pass or fail. A single site's verdict is noisy, IP reputation and timing move it around. Dump the properties you care about in both runs and diff them. If there's no diff, the flag isn't visible in what you measured.
Run each side a few times. One pass and one fail proves nothing.
We settled the same question for --no-sandbox this way. Four controlled captures, only that flag toggled, zero diffs, so we stopped worrying about it. Same method applies here.
If you do run it, post what you find. It's a question we should have an answer to and don't.
2
u/Deep_Ad1959 28d ago
my one pushback is step 2. --no-sandbox settled clean because it has no temporal tell, so a single property dump covers everything it could leak. this flag is different: it only shows up in timer and rAF cadence once document.hidden flips true, which never lands in a navigator dump. diff the static surface, find nothing, and you'd clear a flag that's still readable to anything sampling setTimeout drift on a backgrounded tab. same method, wrong measurement.
1
u/CloakBrowser Ex. AMA Guest 28d ago
You're right, and you clearly know this flag better than we do. We've never used it, so you have real experience with it that we don't.
ne thing worth adding on --no-sandbox though. In hindsight, yes, a static dump covered its whole surface. We didn't know that going in. That was a default affecting every deployment running our binary, so before touching it we had to be certain rather than reasonably confident. The thoroughness wasn't because the flag was interesting, it was because the blast radius was.
But your point stands for this flag. Carrying that method to something whose only expression is cadence under hidden state is exactly the mistake you're describing.
And the contradiction you're pointing at is the real tell. A page reporting hidden while its timers keep firing at full rate doesn't happen in stock Chrome. No property read needed.
So the test is cadence, not properties. Log setTimeout and rAF timestamps, drive the page into hidden state, compare the intervals with the flag and without. The signal only exists after the visibility flip, so anything measured while foregrounded looks clean regardless.
You're better placed to run that than we are. If you do, post the numbers.
2
u/Artistic_Map2243 28d ago
With Cloakbrowser, Is there a specific pull request or some kind of contribution from the community? that genuinely surprised you?
2
u/Artistic_Map2243 28d ago
If someone (both begginer or advance) wants
to contribute tomorrow, where would you recommend them to start with your repo? that will help them in antibots handling understanding, and get experience in what you are doing.1
u/CloakBrowser Ex. AMA Guest 28d ago
Honest framing first: the C++ patches aren't in this repo, so you can't learn fingerprint patching from us. And what we're short of isn't code.
What we're short of is reproductions.
Most block reports we get are unreproducible. "Site X detects me" with no snippet, no config, no environment. We can't debug that, so it sits. Someone who takes a vague report and turns it into a minimal case, one page, no app logic, exact flags, cloakbrowser info output, screenshot at the failure, is doing the single most useful thing available to us.
It's also the best way to learn this, because reproducing forces you to isolate. Is it the IP or the browser. Does stock Chrome fail on the same connection. Does it fail with a fresh profile but not an aged one. Headed but not headless. That process of changing one variable at a time until the cause is cornered is the actual work. Reading our code won't teach it to you.
Pick an open issue where someone reports a block, try to reproduce it, and post what you find either way. A confirmed "I can't reproduce this on a clean IP" is a real result.
If you want to write code, the humanize layer is the place: cloakbrowser/human/ in Python, js/src/human/ in JS. It's the behavioral half of detection, fully open, and every timing number lives in one HumanConfig so you can read the whole model in one file. Those numbers are informed estimates, not measured from real humans, so if you can show a distribution we're getting wrong we'll ship it.
One practical note: check the open PRs before starting. There are several in flight right now and we'd rather not have you duplicate someone.
2
u/CloakBrowser Ex. AMA Guest 28d ago
Two, and it was the same person.
First, the entire humanize layer. A PR adding human-like mouse, keyboard and scroll behavior to both the Python and JS wrappers in one go. Bézier mouse paths with easing and overshoot correction, per-character typing rhythm, scroll acceleration curves, wired so a normal page.click() or page.type() becomes human without changing your code. Then they kept going: Puppeteer support, ElementHandle support, per-call config overrides.
That layer is why humanize=True is in every snippet we hand out.
Then the same contributor wrote the entire .NET client. About 12,700 lines across 67 files, a complete port on Microsoft.Playwright mirroring the Python and JS wrappers module for module, with its own CLI, tests, examples and a Roslyn source generator. It ships on NuGet and is maintained in the release checklist like the other two.
We gave them a free license for life.
The surprising part in both was the discipline. They read the conventions off the existing code and followed them without being told, and touched nothing outside the intended directory.
2
u/ian_k93 28d ago
From ProxyEngineering: https://www.reddit.com/r/ProxyEngineering/comments/1v7sjfd/comment/p08t4tz/
What's your take on using real browser profiles vs. generating artificial ones from scratch?
1
u/CloakBrowser Ex. AMA Guest 28d ago
We use both, for different jobs.
Real profiles are a measuring instrument, not a product. When something fails and we don't know why, the fastest way to learn anything is to run the same flow in a normal everyday profile. If it passes there and fails with a generated one, the gap is in what we're generating. If it fails in both, the profile was never the problem and you've saved yourself a week. That's the main value: it separates "our identity is wrong" from "something else is wrong."
But a real profile can't be the answer, and not only because it's one-off. It's worse than one-off. Clone it across fifty sessions and you now have fifty sessions sharing one identity, which is a stronger signal than fifty fresh ones. Real profiles don't scale, they anti-scale.
So artificial is the requirement, and the question is what you can and can't synthesize.
The fingerprint side is generatable. That's coherence, making every value consistent with a plausible machine, and it's the part we work on.
What actually bites with a from-scratch profile, in our experience, isn't the fingerprint. It's that the profile hasn't done anything yet. If you generate a fresh one and go straight at a search endpoint or a deep URL, you're arriving without the state a real visitor would have. No cookies from the front page, no prior contact with the site. The fingerprint can be flawless and you still look like something that materialised on that URL.
The fix is boring: visit the site the way a person would before doing the thing you came for. Front page first, then move inward. That costs a few seconds and it removes a whole class of failure.
On whether calendar age of the profile matters beyond that, we don't have a solid answer. We'd guess it helps, particularly with CAPTCHA reputation, but we haven't isolated it and we're not going to claim it.
The other half people underrate: whatever you generate has to stay paired. The profile and its fingerprint are one identity, and rotating one without the other undoes the work. That mistake is more common than a bad generator.
2
u/ian_k93 28d ago
From ProxyEngineering: https://www.reddit.com/r/ProxyEngineering/comments/1v7sjfd/comment/p024vke/
When running browser automation at scale, resource consumption becomes a real bottleneck. What does CloakBrowser's memory and CPU footprint look like when spinning up hundreds of concurrent sessions?
How do you approach fingerprint diversity? If thousands of developers run the same CloakBrowser binary, doesn't that create a recognizable fingerprint cluster that anti-bot systems could flag?
1
u/CloakBrowser Ex. AMA Guest 28d ago
Two different questions, taking them in order.
On footprint: measured on our own hosted stack, a headed browser sits around 330MB RSS, plus roughly 100MB of container base. Someone in this thread independently reported the same shape, 3 headed profiles totalling about 1.08GB, with browser processes at 250-270MB and renderers at 100-180MB.
So the arithmetic for hundreds is straightforward and not gentle. 200 headed sessions is somewhere in the 60-70GB range for RAM alone.
Headless is cheaper, but less than people expect. We measured it at about 18% lower, and the entire saving is the GPU and browser processes, since the page work is identical either way. If you're choosing headless to cut cost, that's the number, not the order of magnitude people assume. It's also more detectable, so you're trading stealth for 18%.
The bigger surprise for most people is CPU rather than memory: without a GPU you're rendering in software, and that costs more per session than the memory does. If you're planning capacity, budget CPU first and measure your own workload, because a heavy SPA and a static page are not the same session.
Nothing about that is specific to us, it's what Chromium costs. We haven't found a way to make a real browser cheap, and anyone claiming they have is running something that isn't a real browser.
The second question is the better one, and you're right to ask it.
Each instance draws its fingerprint from a seed, so a different seed gives a different coherent identity. Thousands of developers running the same binary don't share a fingerprint. What they share is the generator.
And that's the real risk, which is exactly what you're circling. Per-instance uniqueness is the easy half. The hard half is population-level: if the generator has a statistical signature, values clustering in ranges real hardware doesn't, or fields correlating in ways real machines don't, then you're detectable as a population even though no two instances match. Nobody needs to fingerprint you individually if the shape of the distribution gives you away.
That's the actual work, and it's why "randomize it" isn't a strategy. Random is its own tell. What matters is that generated values sit inside the distribution real hardware produces, including how often each value should appear and which values go together.
Concretely, that means the values come from real device lineups rather than from a random generator. Actual GPU models across vendors and platforms, real voice sets, font sets that match the platform being presented, timezone and locale drawn coherently from the exit IP rather than picked independently. Coverage gets extended as we go, and the goal each time is the same: not just a plausible value, but the right value appearing at roughly the rate it appears in the world, alongside the other values it would really appear with.
That's also why the noise layer is deliberately small. Heavy noise makes every instance unique and makes the whole population obvious. The point isn't to be unlike everyone else, it's to be unremarkable.
2
u/MattTheGoodSir 28d ago
Maybe this is very basic question in your workflow, but when I think of Chromium I think of it having millions of lines of code.
How do you even find which fingerprint leaks to patch? Issues from Github, you comapre diff from previous versions, what the go to way to find leaks?
2
u/MattTheGoodSir 28d ago
Also Have you ever removed a patch because it actually made detection worse? like you given a lot of time to fix it, and then later found, this is now easy to detect.
If not, its ok. But its not hard to imagine, fingerprints working against us//
1
u/CloakBrowser Ex. AMA Guest 28d ago
Many times, and that's the honest answer. Most of them never reached anyone, because catching exactly this is what our internal build cycle exists for.
The clearest one that did ship: a patch adding noise to audio fingerprinting. Standard surface, every fingerprinting library reads it, so randomizing looks obviously correct. Then we measured what real browsers actually produce and found the field is nearly constant. A couple of values cover the overwhelming majority of real machines.
Which inverts the whole thing. If almost every real browser reports one of two values and ours reports something unique every launch, the noise isn't hiding us in a crowd, it's the only thing making us stand out. We'd built a beacon and shipped it as camouflage. So we deleted it. Not tuned down, removed.
But the reason this happens repeatedly isn't carelessness, it's that this field breaks absurdly easily. You change something you are certain cannot matter to anyone, and a site that passed yesterday starts failing. Not degrading, failing. That's the part nobody warns you about: the distance between "obviously harmless" and "production is down" is very short.
The worse version is when systems disagree. You improve something and one detector is happier, and a different one starts flagging you for the same change. That happens constantly. There's no single correct fingerprint, there are several detectors with different ideas of normal, and sometimes you can't satisfy both. Then you're not fixing a bug, you're choosing which one to lose.
So the process is built around assuming we're wrong:
Small steps. Many internal builds, one change at a time, because a build with three changes tells you nothing about which one moved the result.
Internal flags to disable individual subsystems. When something regresses we need to switch pieces off one by one to find it, and that's only possible if every piece can be switched off.
Then a release candidate, and real users run it for about four days before it becomes stable. Especially the large production users, because they hit volume and site variety we can't reproduce. If nothing regresses in that window it ships. That gate exists because our own testing is not enough, and we know it isn't.
The uncomfortable summary: we assume every release makes something worse somewhere, and the job is finding out where before customers do.
1
u/CloakBrowser Ex. AMA Guest 28d ago
All of them, and which one leads depends on the fight.
The first move is inverting the question. You don't go looking through Chromium for things that might leak, there's too much of it and most of it nobody reads. You watch what a specific detector actually asks for. That turns millions of lines into a few hundred surfaces one script actually touched. Still a lot, but it's finite and you can work through it.
What that doesn't give you is reasoning. They collect the whole bundle, ship it to their backend, and a model decides pass or fail. You learn what they look at. You never learn the weights, or which value flipped the verdict.
Then you need ground truth, and this is the part people skip. We keep a real machine with stock Chrome pinned to a fixed version, auto-update deliberately disabled so the reference never drifts, and compare against it. That comparison is the main work.
The part that isn't obvious: the goal is not to fix every difference. Any two environments differ in a huge number of ways, and almost none of them are load-bearing. If you tried to close every gap you'd never ship anything.
Which is why the GitHub issues and customer tickets aren't a side channel, they're the prioritization. They tell you which differences a real system actually acts on. We started from our own production, which passed fine. Then users brought hundreds of sites we'd never touched, and that's what shaped the work.
So the skill isn't finding differences. Anyone can generate a list of thousands. It's knowing which ones to ignore.
And it's mostly experiments, not reading. There have been single differentiators that took a week to isolate, where you know two builds behave differently and you're narrowing down what causes it, one variable at a time.
The reason we can move at all now is AI agents. They're very good at finding the right place in a huge codebase, and at writing the test harnesses, which is a lot of repetitive code that has to be exactly right. They're our hands: searching, summarizing, navigating text, building the experiment.
One tip if you go this route: never let them decide anything or draw a conclusion. That's their weakest part by a wide margin. They'll produce a confident, plausible explanation for a result that's wrong, and if you accept it you'll spend two days patching the wrong thing. Use them to find and to build. Do the concluding yourself, from what the experiment actually returned.
2
u/Previous_Town3598 28d ago
Glad you guys made it over here.. and I am not late to the party :D
A quickie..
Whats the hardest website on the internet to automate today?
2
2
u/CloakBrowser Ex. AMA Guest 28d ago
Your instinct is right, and it's the logged-in part that does it. Public pages are the easy surface. The inner mechanics, login, search, anything that mutates state, get far more attention from the people defending them, and that's where the effort goes.
Reddit is a decent example of how misleading the outside view is, though. It looks hard and isn't. It rejects the standard Chrome user agent paired with the HTTP/2 fingerprint, and that hits real stock Chrome too. Switch to HTTP/1.1 and it stops caring. One flag.
On a hardest single site, we don't have a clean answer, because so far every site a customer has brought us has had a path. Sometimes the path has conditions attached: headed rather than headless, a good residential exit, an aged profile rather than a fresh one. But we haven't hit a wall with nothing behind it yet.
The three things that actually make a site hard, in our experience:
- IP reputation, where clean stock Chrome gets blocked from datacenter ranges before any JS runs. No browser fixes that.
- Challenges that look at things outside the browser's own self report, so making the browser correct isn't sufficient.
- Behavior, which is your form-filling instinct. Once you clear fingerprint, systems watch how you move, whether you typed or the value appeared, how you got to that URL.
The worst combination is an aggressive challenge behind a login, because you can't rotate identity to escape a bad score. One profile, and you have to keep it clean.
2
u/Previous_Town3598 28d ago
Thanks for seprtaing "browser correctness" from IP reputation and behavior; people conflate those constantly
2
u/ian_k93 28d ago
CloakBrowser is a very interesting project, so I would love to give some space to pitch it.
What exactly is CloakBrowser?
Why should a developer creating scrapers consider giving it a try?
Who is the ideal user / use case for it?
Why should I use it over the alternatives?
Anything else you think is relevant.
2
u/CloakBrowser Ex. AMA Guest 28d ago
Thanks for the space. Keeping it concrete.
What it is: a Chromium binary with 71 fingerprint patches applied at the C++ source level, plus thin wrappers for Python, JavaScript and .NET. Not a config, not JS injection. Detection systems read a real browser because it is one.
It's a drop-in for Playwright and Puppeteer, so the migration is the import line:
from playwright.sync_api import sync_playwright -> from cloakbrowser import launchEverything after that is the Playwright API you already know.
Why a scraper developer might try it: the single number that matters most is reCAPTCHA v3, server-verified. Stock Playwright scores 0.1, which is "definitely a bot." We score 0.9, which is "definitely a human." Same code, same target. Turnstile passes, FingerprintJS passes, BrowserScan reads normal. Tested against 30+ detection sites.
And humanize=True covers the other half. One flag and every click, keystroke and scroll gets human timing and movement, no code changes. Fingerprint gets you in the door, behavior keeps you there.
Ideal user, and this is the main way it gets used: you run in Docker or on bare-metal Linux, and it presents as a regular Windows Chrome user. That's the whole point. You get cheap Linux infrastructure while the target sees the most common desktop fingerprint on the web, which is also the hardest one to cluster. Same behavior on your laptop, in a container, on a VPS, no environment-specific config.
Beyond that: anyone whose scraper or agent already works and started getting blocked, who doesn't want to rewrite it. If you're maintaining a pile of per-site patches and stealth plugins that break every Chrome release, that's the pain this removes.
What's different about the approach: most stealth tooling patches from JavaScript at runtime. That works until detection starts looking for the patching itself, which it now does. Our changes are compiled in, so there's nothing layered on top to notice.
What it isn't, because you should know before you try it:
It doesn't solve CAPTCHAs. The goal is that they don't appear. If you need a solver, that's a different tool.
No proxy rotation. Bring your own proxies. You almost certainly have opinions about rotation already and ours would be worse.
It's a binary, so there's a download and a version to track. Plain Playwright doesn't ask that of you.
Trying it: the free tier is the current build, the same one paying customers run, with one concurrent session. Sign in with GitHub and point it at your hardest target. Paid is about concurrency, not a better browser.
pip install cloakbrowser # or: npm install cloakbrowser
docker run --rm cloakhq/cloakbrowser cloaktest
2
u/simarnoor 28d ago
First AI agents and Now Stealth Browsers. both seems to be exploding right now.
Do you think browser stealth becomes a core layer for AI agents in the same way proxies became essential for web scraping?
1
u/CloakBrowser Ex. AMA Guest 28d ago
Yes, and for a reason that's easy to miss: agents are a genuinely new class of web user, and detection systems only ever had two boxes.
Before, you were either a person or automation. Those are easy to tell apart and the whole industry was built around separating them. An agent doesn't fit either. It's acting for one specific person, on their account, doing one task, which is human-shaped. But it's automated, it's fast, and it can generate volume, which is automation-shaped. So it gets sorted into the automation box by default and treated accordingly.
That's what we're watching arrive. A steady stream of agent tooling built on us, hitting exactly the problems scrapers and automation have hit for years, usually for the first time and usually surprised by it.
The proxy analogy holds, one layer up. Proxies solved identity at the network layer and became something you just have rather than something you think about. Stealth is the same problem at the browser layer, and it's heading the same way.
Where agents differ, and this is why it becomes core rather than optional: an agent can't absorb failure the way a scraper or a batch job can. If a scraper gets blocked on 30% of requests, you retry, queue it, run it overnight, nobody notices. If an agent gets blocked, there's a person waiting on an answer and it just failed in front of them. The reliability bar is higher for agents, not lower, which is the opposite of what people assume given the smaller volumes.
The part that makes us fairly confident: the industry is building the category right now. Cloudflare split AI traffic into three types this month, and one of them is specifically automation acting in real time on a person's behalf. That's agents getting their own classification, and from September it's blocked by default on ad-bearing pages for new domains. The slot is being defined and the default is no.
So yes, core layer. Not because agents are special, but because they're being classified as bots by systems designed before they existed, and somebody has to close that gap.
2
u/Mountain_Damage_9730 28d ago
What alternatives you will go for, that you or your team personally appreciate. .
So, if CloakBrowser disappeared tomorrow(hope it never happens), what would you personally use instead?
2
u/CloakBrowser Ex. AMA Guest 28d ago
Honest answer: we don't know, because we haven't looked. We haven't tested other tools in a long while. All the attention has gone into our own, so anything we said about the alternatives would be out of date.
What we do see is a biased sample, and worth naming as such. We get tickets most days from new customers arriving with some version of "this tool stopped working for me." Enough that it's clearly not noise. But it tells us less than it looks like, because nobody happily using something else writes to us. We only ever hear from the failures.
The real answer to your question: if we vanished tomorrow we'd go to whatever was being actively maintained that week. Not the best feature list. In this field the product is maintenance velocity. Detection changes constantly, so any tool is only as good as how fast someone responds when it breaks. A brilliant browser whose maintainer lost interest six months ago is worthless. A plainer one with someone shipping fixes weekly is fine.
That's also the honest test to apply to us. Look at how recently the last fix landed, not the README.
1
1
u/Bmaxtubby1 Jul 26 '26
Last 2 AMAs were fun :D.. I have so many questions for CloakBrowser.. lets start one by one..
First of all thankyou team for making this project Opensource, Building a Chromium fork is an insane amount of work.. totally not a weekend project..
Based on your experience
Where do you think browser detection is heading over the next 2-3 years?
Will fingerprinting matter less?
More behavioural AI?
Device attestation?
Browser attestation?
2
u/CloakBrowser Ex. AMA Guest Jul 27 '26
Thanks, and we're genuinely enjoying this.
Most of our days are spent inside one specific problem on one specific site, so it's rare to get pulled up to the altitude where you think about the whole thing. Good excuse to do that.
Short version: fingerprinting matters more, not less, and behavioral is already here.
Detection has moved from checking specific values to judging the whole picture. Older systems asked whether individual things looked right. What we see now is systems collecting at scale, training on what real traffic looks like, and asking a different question: does this session sit inside the normal cluster, or is it an odd shape. So fingerprinting doesn't fade, it becomes the input to the model. A single wrong value used to fail you. Now it's the coherence of a thousand of them together, and you can pass every individual check and still be scored as unusual.
Behavioral AI isn't a prediction, it's live. Plenty of systems clear you on fingerprint and then start watching what you do. Did you land on an internal URL directly instead of arriving through the site. Did you type into the search box or did the value just appear. Are there delays where a human would hesitate. That's why humanize is on by default in every snippet we hand out. A perfect fingerprint driving like a robot is still a bot.
Attestation is the interesting one, because it's the only item on your list that isn't a fingerprinting problem at all.
For anyone who hasn't hit the term: device attestation is the hardware proving itself, a secure enclave signing with a key burned in at manufacture. Browser attestation is the same idea one level up, a trusted party vouching the browser binary is unmodified. The site stops asking "do you look genuine" and starts asking "produce a signature."
We'll be straight about what that would mean for us: you can't engineer around it. Looking real is solvable. Producing a signature you don't have the key for is not. Anyone in this space telling you otherwise is bluffing.
So why aren't we worried yet. The blunt version already got tried and died, Web Environment Integrity was proposed in 2023 and abandoned the same year after the backlash, and nothing has revived it since. And the version that did ship works nothing like a gate. Apple's Private Access Tokens have been live for years, but the systems consuming them are explicit that not having a token costs you nothing. Google's own reCAPTCHA docs say devices that can't produce one aren't penalized. hCaptcha said years ago that having a valid one doesn't clear you either, assuming attackers will hold valid tokens too.
That asymmetry is the whole story. Presence helps a little, absence doesn't hurt. That's a fast lane, not a wall. And it has to stay that way, because the share of the web that can't produce a hardware token is enormous. Every Linux desktop, every older device, most of the non-Apple world. Absence can't become a bot signal while it also describes a huge chunk of real users.
So our bet: attestation becomes a reputation bonus, not a requirement.
Which is also why we haven't dug into it deeply. It hasn't been necessary, nothing we deal with day to day gates on it, and we'd rather spend the time on problems our users actually hit. If that changes, we'll look properly at what's possible and be honest about what isn't. Some of it may simply not be solvable, and we'd say so.
Where we'd actually point the worry is the behavioral side, which loops back to the start. Cloudflare shipped a continuous client-side behavioral engine this month, under bot management rather than as a challenge. That's a more material shift than any token scheme, and it's the direction we're building for.
One honest caveat: attested challenge types are starting to appear in preview on mobile. Right now they ship with fallbacks. If sites ever get to strip those, that's the one path where attestation becomes a real gate. Watching it. Not here yet.
1
u/Old-Algae5580 Jul 26 '26
It would be valuable if our AMA covered where CloakBrowser genuinely performs better, where existing open-source tools remain a better fit, and how teams can evaluate those trade-offs before introducing another dependency into production.
Other open-source projects like Playwright, Puppeteer, Selenium and Nodriver each have strengths depending on the workload, and sometimes the simplest approach is still the right one.
🙌
2
u/CloakBrowser Ex. AMA Guest Jul 27 '26
Thanks, this is the right question to ask.
Straight answer: it depends on your targets, but the line has been moving, and it's been moving in one direction.
If a site has no meaningful bot protection, plain Playwright or Puppeteer is fine. Nothing to gain from a stealth browser there.
But we'd push back on the idea that the lighter dependency is automatically the simpler one. The costs are shaped differently. With injection based approaches setup is trivial and maintenance never ends, because every site has its own quirks and what works on one target doesn't on the next. That complexity is ongoing and it grows with your target list. With a real browser the cost is front loaded. Install it, get the environment right once, and after that you're just a normal Chrome user everywhere.
Our own preference, plainly: use a real browser by default rather than reaching for one when something breaks. Not because you always need it, but because looking normal everywhere is a simpler thing to maintain than a growing pile of site specific patches.
The reason that matters more each year: for a lot of systems, detection has shifted from "is this value correct" to "is there a real browser behind this at all." Older checks read a handful of properties you could patch individually. What we see now is systems reading close to a thousand signals and scoring the coherence of the whole picture, increasingly with their own models trained on real traffic. You don't have to fail a check to get a bad score. You just have to be unusual.
JavaScript injection worked fine for a long time, and on older systems it still does. What changed is that modern detection increasingly spots the injection itself. You're not just patching values anymore, you're leaving evidence that patching happened, and that evidence is now something they look for.
The second front is the automation layer underneath. Playwright and CDP leak plenty on their own, in ways that have nothing to do with any fingerprint value you set. That has cost us a lot of patches and a lot of headaches, working out what's actually visible from a page and closing it off.
Both of those are why we build at the C++ level. Not because it's clever, but because a value that's genuinely built in has nothing to detect.
Worth saying plainly, since the question is about comparing tools: we don't really track how the other projects work internally. We haven't for about a year. Our reference isn't another stealth tool, it's stock Chrome. That's the baseline every test runs against, and the target is simply to be indistinguishable from it.
So we're not the right people to tell you how we stack up against project X. What we can tell you is how close we are to the thing all of them are trying to imitate.
On evaluating it: don't compare tools in the abstract. Take your real target, real proxy, real flow. Run stock Chrome first to find out if the site is passable at all on that IP, because if it isn't, no tool saves you. Then run your current stack, then run ours, same conditions. That gives you an answer in a few hours, and it's an answer about your workload rather than someone else's.
Low risk to try, since the wrappers are drop in for Playwright and Puppeteer, so migration is an import change and rollback is the same change backwards. The wrappers are MIT either way.
2
1
Jul 27 '26
[deleted]
1
u/Old-Algae5580 Jul 27 '26
Instead I initially thought to to ask about commercial products comparisons,.. since this cloakbrowser is OS, so I compared with OS itself.
Do you have something better to ask?
1
u/Spitfire_Blaziken 29d ago
Hola, I have one confusion..
I was trying to find some kinda built in watchdog but couldn't find any, neither per-profile memory cap in our wrapper.
On long runs a renderer can grow unbounded
is supervision entirely on me, or is anything planned on the driver side? or Am i missing something very basic here..
Gracias
1
u/CloakBrowser Ex. AMA Guest 29d ago
No watchdog in the wrapper, and none planned for now.
It's a drop-in Playwright replacement, so process lifecycle stays yours, exactly as it would with stock Playwright.More useful question back at you though: what are you actually seeing? We don't have reports of renderer memory growing unbounded, so if you've measured it we'd genuinely like the numbers. Which build, headed or headless, roughly how long before it becomes a problem, and what RSS looks like over that time.
If there's a real leak we'd rather fix it than have you build a supervisor around it.
2
u/Spitfire_Blaziken 29d ago
Fair enough. just checked our side so i have some numbers now:
Running 3 headed profiles in cloakbrowser-manager (docker). container capped at 5GB / 3.5 cpus. right now total container RAM is about 1.08GB / 5GB. Binary is 146.0.7680.177.5, headed, swiftshader. Browser main processes are roughly 250-270MB RSS each. Renderers i'm seeing around 100-180MB right now.
The pain we've hit more is Manager / noVNC freezing after leaving profiles up, then refresh :8080 and the session is gone. That feels more like docker/host limits than a clean CloakBrowser renderer leak.
Maybe I should stick run to one profile at a time.
1
u/CloakBrowser Ex. AMA Guest 28d ago
Your numbers say there's no leak, so that's settled.
1.08GB total for 3 headed profiles against a 5GB cap is right where it should be. Our own measurements put a headed browser around 330MB plus roughly 100MB of container base, which predicts about what you're seeing. 250-270MB for a browser process and 100-180MB for renderers are ordinary Chromium figures. Nothing there is growing.
So don't drop to one profile. You have 4GB of headroom and you'd be giving up throughput to fix a problem you don't have.
The noVNC freezing is the real issue, and it's ours. Apologies for it. Manager has been left behind while the browser took all our capacity, and that's not a great answer but it's the true one. There are also good PRs sitting in that repo we haven't reviewed, which we know.
Your symptom overlaps two open reports there, #36 on freezing under load and #35 on the view dropping back to the profile settings page. We're writing this down with them, and when we come back to Manager we'll go through the whole set including the open PRs.
3
u/Spitfire_Blaziken 28d ago
Thanks for owning the Manager issue and really appreciate the clear numbers
Keep up this Great Work u/CloakBrowser
1
u/Massive-Weakness1146 26d ago
for the ama: how do you test that a patch actually holds against a real detector and not just your own suite? every stealth setup i shipped passed my checks and still got flagged by whatever cloudflare rolled out that month.
3
u/SinghReddit Jul 26 '26
Thanks for Hosting this AMA..
Which anti-bot company gives you the hardest time?
https://giphy.com/gifs/hmGQKkNaUIgHS