A burst of history updates is rate-limited, as Chrome's IPC flooding protection does
On a Chromium engine, fewer than all 300 replaceState calls in a burst take effect (genuine Chrome: 200). N/A on other engines and when the browser throws or ignores the updates (severity: warn).
What a detector infers
Every history.pushState or replaceState call sends a message from the page to the browser process. To keep a page from flooding that channel, Chrome counts them per frame and silently ignores further calls once a frame has made 200 within 10 seconds (it logs a 'Throttling navigation' warning in the console). The switch --disable-ipc-flooding-protection turns that limit off, and the common automation drivers pass it by default.
So a page can make 300 replaceState calls in a row, each storing its own number in history.state, and read which one stuck: in Chrome the state stops at 200, with the switch it reaches 300. The audit does this in a throwaway frame so the page's own history and address bar are never touched, and the frame's limit is its own. Other engines handle the burst differently: Firefox throws an exception at call 201 and Safari at call 101.
A thrown error or an unreadable state is therefore reported as inconclusive, never as a failure.
How to resolve it
Launch without --disable-ipc-flooding-protection. Remove it from the driver's default arguments; nothing an ordinary page does depends on it.
Nearby checks in Automation surface
- history.replaceState to another origin throws SecurityError
history-replacestate-cross-origin-throwshistory.replaceState may change the URL shown for a document only within its own origin; the HTML standard requires a SecurityError for any… - No automation extension has written its marker into the page
automation-extension-markupSome automation tools announce themselves in the pages they control. - No interface stable Chrome keeps behind a developer switch is exposed
flag-only-surfaces-absentStable Chrome keeps unfinished web platform features behind developer switches, and some of them add global interfaces as soon as the switch… - A Cast reconnect to an unknown route fails with Chrome's message
presentation-cast-reconnect-errorChrome's Presentation API hands Cast requests to the media router in the browser process. - No debugger client attached to this tab after it loaded
console-replay-trapV8 keeps the console messages a page logs, which is why DevTools can show messages logged before it was opened. - navigator.webdriver does not assert WebDriver control
webdriver-offThis check is intentionally one-way. The WebDriver specification defines navigator.webdriver as the browser's assertion that it is under… - navigator.webdriver is a native prototype getter returning false
webdriver-descriptor-integrityRather than reading the value, this check inspects the property's shape: it requires a getter on Navigator.prototype whose… - No Selenium / Puppeteer / Playwright globals
automation-globalsThis check tests a fixed list of roughly two dozen known names against both window and document (Selenium's __webdriver_evaluate /…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Automation surface checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Automation surface — the family history-updates-rate-limited belongs to.