A patched Chromium setup changes some part of the browser automation stack to make automated sessions look more like ordinary browser sessions. The changed part may be the Chromium binary, a driver, an automation framework, a launch configuration, or code injected into the page.
That distinction matters. A product described as “patched Chromium” is not necessarily a custom browser build, and two tools using the label may leave different evidence.
What a patched browser changes
Browser automation has several layers:
| Layer | Examples | What can change |
|---|---|---|
| Browser binary | A maintained Chromium fork | Browser-exposed properties, command-line behavior, or protocol handling |
| Driver | ChromeDriver tooling | Driver artifacts and browser launch configuration |
| Automation framework | Playwright or Puppeteer modifications | Which protocol domains and execution contexts the framework uses |
| Page script | Init scripts or stealth plugins | JavaScript-visible values after a document starts |
| Operating environment | Container, display, fonts, network | The context around the browser rather than the browser code itself |
“Patched” should therefore be treated as a description to investigate, not a fingerprint. Ask which layer changed, which upstream version it tracks, and which observations the change is meant to affect.
Start with the standards
The WebDriver specification defines a webdriver-active flag that is true when the user agent is under remote control. navigator.webdriver exposes the state of that flag.
That makes the property useful evidence in its defined context. It does not make false proof of a human user. Automation that does not create a standards-conforming WebDriver session may not set the flag, and modified tooling may try to alter what the page observes.
The same restraint applies to headless mode. Chrome's headless documentation says modern headless Chrome uses the regular Chrome code and creates platform windows without displaying them. Headless is an execution mode, not an automation verdict. Legitimate testing and rendering systems use it, while automation can also run with a visible interface.
Understand the protocol surface
Many Chromium automation tools communicate through the Chrome DevTools Protocol (CDP). The protocol exposes domains for inspecting and controlling the browser. For example, Runtime.evaluate evaluates an expression on the global object, while the Page domain can create an isolated world for a frame.
The fact that CDP has a documented method does not mean a page can reliably infer every use of that method. An observation may depend on a particular Chromium version, framework sequence, execution context, or serialization path. A browser update can change the observation even when the protocol method still exists.
This is why a technique should be recorded with its prerequisites:
- browser and operating-system version;
- automation tool and version;
- launch arguments and extensions;
- page lifecycle stage;
- expected observation and known counterexamples.
Without those details, “detects CDP” is not a reproducible result.
Read tool claims at the right confidence level
Projects describe their own goals and techniques. Those descriptions are useful for forming tests, but they are not independent proof of bypass or detection performance.
For example, the rebrowser-patches repository describes changes intended to avoid specific automation leaks associated with the CDP Runtime domain. That is a project-maintainer claim. Treat it as a hypothesis until you reproduce the behavior against named browser and framework versions.
The same rule applies to driver patchers, Playwright forks, hosted browsers, and custom Chromium builds:
- Record what the maintainer says is changed.
- Pin the artifact and upstream browser versions.
- Reproduce the claimed observation in an isolated lab.
- Test ordinary browsers using the same environment.
- Re-run after either side updates.
Do not turn a passing demo into a universal statement about all sessions from that tool.
Why static checks age quickly
A static check asks whether one property or object has an expected value. These checks are cheap and can still contribute evidence, but they have narrow scope.
A changed browser can normalize a property. An ordinary browser can also produce an unusual value because of enterprise policy, privacy software, accessibility tooling, an extension, hardware, or an unsupported platform. Treating either case as conclusive raises false positive and false negative risk.
Version drift adds another problem. Chromium, drivers, and automation frameworks ship independently. A check observed on one combination may disappear, invert, or become common in legitimate traffic on another.
No single browser property establishes that a session is automated. The useful question is whether several independent observations support the same bounded conclusion.
Build a layered test
Start with a matrix, not a single proof-of-concept.
| Cohort | Purpose |
|---|---|
| Ordinary supported browsers | Measure the normal range and false positive rate |
| Supported browsers with common privacy or accessibility changes | Find legitimate edge cases |
| Stock automation with pinned versions | Confirm the test can observe known automation |
| Patched or configured automation with pinned versions | Measure which observations changed |
| New browser or framework release | Detect drift before rollout |
For each cohort, collect evidence from layers that fail differently:
- Runtime consistency: related browser values, APIs, permissions, and lifecycle observations.
- Protocol and network consistency: whether the browser claim agrees with transport and request behavior visible at your integration point.
- Interaction sequence: navigation, timing, input, and retry patterns across the session.
- Application context: whether the sequence resembles the abusive workflow you are protecting, such as repeated login attempts or high-cost search requests.
Then remove one evidence family at a time and measure the effect. This shows whether the model is genuinely layered or merely repeats the same assumption under several feature names.
The browser automation detection guide contains a fuller evidence model and rollout process.
Set a bounded response
Detection and response are separate decisions. Weak or conflicting evidence may justify observation or a rate limit, not an immediate deny. Stronger corroborated evidence on a sensitive route may justify a challenge or block.
Define these before rollout:
- the protected resource and abuse case;
- the evidence required for each response;
- how legitimate automation is identified;
- what happens when collection fails;
- the maximum delay and data retained;
- an appeal or recovery path for affected users.
Roll out in observe mode first. Review false positives across supported browsers and important user flows. Use holdouts where practical so a drop in abuse is not confused with a drop in legitimate traffic.
Where Centinel fits
Centinel combines browser, network, session, and crawler evidence for route-specific automation decisions. It is designed to avoid making one JavaScript property carry the whole verdict.
Coverage still depends on deployment. Browser-side evidence is relevant only when the client runs it. Network and server-side evidence must be collected on the traffic path being evaluated. A buyer should test the actual integration against current ordinary and automated cohorts rather than rely on a generic detection claim.
See the bot management overview for the supported decision model and evaluation checklist.
Patched browsers change evidence. They do not remove the need to define the abuse case, reproduce observations, measure error, and keep the test current.