the media-session counter runs forward and does not restart
Three sessions numbered in strictly increasing order, with the third — opened from a separate MediaKeys object — continuing the sequence rather than restarting it.
What a detector infers
A deployed commercial agent opens a ClearKey media session purely to read its identifier as a number — and then, if that number comes back below ten, opens as many as 2500 further sessions and reads it again. You do not inflate a counter unless you believe somebody else is going to read it, and that single detail is what makes this worth a row.
Measuring what the identifier actually is: a Chromium ClearKey session id is eight bytes shown as sixteen hex characters, the first four random and the last four a little-endian counter. It increments per session, it continues across independent MediaKeys objects, and it survives across separate script evaluations — observed running one through four, then five through seven in a later probe on the same page.
Its scope is the renderer PROCESS, not the document, the origin, or the object that created the session. So it is an odometer for the browser process. A browser launched to serve a single page load reads near one; a browser somebody has had open all afternoon reads high. No fingerprint value carries that information, no persona sets it, and clearing storage does not touch it — which is precisely why a collector would rather inflate it than read it honestly.
The absolute value is reported and never scored, because starting your browser recently is not a fault and scoring it would convict most of the people who run this page. What is scored is the invariant no real Chromium breaks: the counter runs strictly forward and does not restart when a new MediaKeys object is made.
A build that resets it per object is manufacturing freshness, which is an action rather than a state, and a far more distinctive one than the number it was trying to hide.
How to resolve it
Leave the counter alone. A low reading is not a defect; a counter that restarts is a claim no real build makes, and it stands out more than the high number it was concealing. If short-lived browser processes are the underlying concern, the answer is process lifetime, not the odometer.
Nearby checks in Automation surface
- window.external is shaped the way the engine generates it
window-external-shapeA deployed commercial agent lists the absence of this object among its own named failure messages, which means it treats window.external… - no notifications-permission headless bug
permissions-notification-bugTwo independent APIs describe the same underlying notification permission: navigator.permissions.query({name:'notifications'}) returns a… - permissions.query is native (arity throw + stack shape)
permissions-query-stackThis probe calls navigator.permissions.query() with exactly zero arguments and inspects the error the native arity check produces. - timer handles are a real per-realm counter
timer-id-sequencingThe number setTimeout hands back is not a token, it is an index into the realm's own timer table — so it carries structure that a fabricated… - the global object carries every platform global its claimed Chromium major carries
window-globals-vs-baselineThe list of names on the global object is not written by the page — it is installed by the engine when it sets up a realm, from a table… - the element prototype chain matches its claimed Chromium major's
element-surface-vs-baselineA for..in over the document element does not enumerate one object: it walks the whole prototype chain — HTMLElement, Element, Node… - document.hidden agrees with document.visibilityState
document-visibility-coherencedocument.hidden and document.visibilityState are two views of one piece of state, and the specification defines the first in terms of the… - navigator.plugins is a real IDL collection, not a JavaScript object
plugins-idl-index-wraparoundA real navigator.plugins is a PluginArray — a C++-backed IDL collection — and its indexed getter runs the Web IDL unsigned-long conversion…
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 eme-session-counter-monotonic belongs to.