Does undetectable automation need a kernel-level driver? No, and here is where detection actually happens

Why people assume a kernel driver is required

The intuition comes from a different threat model, and it is correct there. If the thing inspecting you runs on your machine — an anti-cheat, an endpoint agent, a proctoring tool, a DRM stack — then it can enumerate processes, read window handles, hook input, and see anything a user-space program does. Hiding from software with that vantage point genuinely does push you downward: a driver, a hypervisor, something with more privilege than the observer.

Bot detection on a website is not that. The detector does not run on your machine with privileges. It runs inside the page, as JavaScript, in the browser you handed it, plus some server-side signals about the connection that got there. It has exactly the vantage point of a web page: the DOM, the JavaScript APIs the browser exposes, the timing of your interactions, and the TLS and HTTP characteristics of the request. That is a small window compared to an endpoint agent, and it is a completely different one.

Where web bot detection really runs

A page that wants to know whether it is talking to a person or a program has a short list of things it can ask. The homepage's detection scanner is built from that list, and it is worth reading as prose:

• `navigator.webdriver` — a boolean the browser itself sets when it was launched in a way that announces automation. One line of JavaScript reads it.
• CDP leak globals — objects and properties some automation stacks leave on window, which a page can enumerate without any special permission.
• `navigator.plugins` — an empty or stub plugin array is a shape ordinary desktop Chrome does not usually have.
• WebGL vendor and renderer — a browser running without GPU access reports a software renderer, which is both unusual for a desktop user and trivially readable.
• Canvas fingerprinting — draw text or a gradient to an offscreen canvas and hash the pixels; different graphics stacks produce different hashes, so the result is a stable-ish identifier and an anomaly detector at the same time.
• User agent — inconsistent or stale UA strings, and mismatches between the UA and everything else the browser reports.
• `navigator.languages` — empty or default-only language lists where a real user's browser carries a populated list.

None of those requires privilege. All of them are answered by the browser you started. Which is exactly why the leverage is in how the browser is started, not in how deep the tool that started it sits.

What a user-space tool can address, and by what mechanism

The mechanism is unglamorous and specific. Before Chrome launches, the server filters the argument list and removes 30+ flags that would answer those questions badly — automation announcements like --enable-automation and --test-type that set navigator.webdriver=true, fingerprint leaks like --disable-gpu and --disable-webgl that show up in WebGL and canvas probes, and the default flag sets that identify Puppeteer and Playwright by signature. Every strip is reported back to the caller rather than done silently.

Then it launches the real browser that is already installed — Chrome, Chromium or Edge — rather than a patched headless build, and points it at a real profile with real cookies, real history and real logins carried over from previous sessions. A page asking the seven questions above gets the answers an ordinary installation gives, because it is one.

That is the entire claim. It is a claim about launch configuration and profile state, made at the only layer where those two things are decided. A kernel driver would not improve any of it, because none of it is being observed from the kernel. How bot detection works goes through the probes and the flag signatures one at a time.

What this explicitly cannot claim

Being precise here is what makes everything above worth believing, so it gets its own list rather than a hedge in a footnote.

• No kernel driver and no OS-level hooking. Nothing is installed below user space. There is no ring-0 component to audit, and equally none to rely on.
• No screen overlay and no assistant. It does not draw on your screen, read other applications, or sit invisibly above what you are doing. It drives a browser through a protocol.
• No hiding from software that inspects the machine. Anything enumerating processes or windows on your computer will see a Chrome process and a Python process, because that is what is running.
• No behavioural guarantee. Detection also scores interaction patterns — mouse paths, dwell times, request cadence. Clean launch flags say nothing about whether your automation acts like a person.
• No claim about vendors the project has not demonstrated against. The bypasses this project publishes are the ones it has on video, and it is careful not to extrapolate to the rest of the anti-bot industry.

So what does undetectable mean here

It means: the browser does not carry the specific tells that mark a session as automated, and the profile it uses is not a blank one. The demonstrated cases are Cloudflare's challenge and Turnstile, both recorded end to end and linked from the homepage. That is a concrete, checkable claim about two specific challenges, not a general immunity, and the distance between those two statements is where most marketing copy in this category goes wrong.

Detection is also adversarial and moving. A signal that is clean today is clean because of how this release starts a browser today; a vendor that adds a new probe tomorrow has added a new probe. Treat any static claim in this field — this one included — as a claim about a point in time.

• How bot detection works — the probes, the layers, and the flag signatures in detail.
• Stealth browser automation — the product this page is about, at full length.
• Install the MCP server — if you have decided the user-space answer is the one you wanted.
• `DESIGN.md` — the architecture invariants, including the ones this page is describing.