navigator.cookieEnabled agrees with whether a cookie can actually be stored
navigator.cookieEnabled and the actual write agree: true with the cookie reading back, or false with it not reading back. Either pairing is coherent — it is the disagreement that is informative.
What a detector infers
navigator.cookieEnabled is a claim; writing a cookie and reading it back is a measurement. They are supposed to be two views of one fact, which makes the disagreement a free coherence check requiring no reference value and no knowledge of the host. The reason it earns a row of its own is that the failure has a consequence far beyond fingerprinting.
A de-Googled or privacy-hardened Chromium base can ship cookie restrictions the boolean does not reflect, and a stealth browser built on such a base traced a total, unexplained failure of reCAPTCHA v3 tokens to exactly this: the reputation cookie those challenges depend on could never be stored, so every token scored as a stranger. Nothing in a fingerprint report points at that.
The browser looks coherent, the identity looks plausible, and the challenge fails anyway — which is the most expensive class of bug in this field, because it sends people hunting through canvas noise for a problem that lives in the cookie jar. The probe writes a first-party cookie and removes it immediately, so it leaves no state behind.
How to resolve it
Make the property and the storage layer agree. If cookie restrictions come from a de-Googled or privacy-hardened base, decide deliberately whether to keep them rather than inheriting them by accident: reputation-scored challenges depend on a first-party cookie surviving, and a build that silently drops it fails those challenges for a reason no fingerprint report will ever surface.
Read in the wild by
CloakBrowser issues
A stealth-browser tracker traces complete reCAPTCHA v3 token rejection to third-party cookie blocking inherited from its de-Googled base, and the vendor subsequently shipped a switch to allow them.
CloakHQ/CloakBrowser #388, #409, #418 (cookie policy vs challenge scoring)
CloakHQ/CloakBrowser#388Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Capability surfaces
- the platform theme resolves the CSS system colours coherently
system-colors-vs-platformThe CSS system-colour keywords — Highlight, HighlightText, Canvas, CanvasText, ButtonFace, ButtonText, GrayText and their newer siblings… - the user-agent stylesheet resolves identically in a fresh realm
default-style-values-vs-realmEvery browser ships a user-agent stylesheet: the rules that make a heading bold and a button look like a button before any site CSS exists. - the permission descriptors this build accepts are the platform's, not a lookup table's
permission-name-support-setThe Permissions specification deliberately fixes no list of names. - form-factor-gated APIs match the form factor the client hints claim
platform-gated-apis-vs-form-factorSome Web APIs are not compiled for every platform, so their presence is a fact about the binary rather than about the user agent. - Web Bluetooth is present or absent as the claimed desktop platform requires
bluetooth-availability-vs-platformnavigator.bluetooth is part of Chrome's desktop surface on Windows, macOS and Linux, and it is provided by the platform layer rather than by… - the WebAuthn surface is as complete as the claimed platform's browser ships it
webauthn-surface-vs-platformWebAuthn reaches further down the stack than most web APIs: PublicKeyCredential is not a self-contained JavaScript object but the front door… - the deprecated and modern storage-quota APIs report the same origin quota
legacy-quota-surface-agreementnavigator.webkitTemporaryStorage.queryUsageAndQuota and navigator.storage.estimate() describe the same thing — this origin's storage quota… - the Storage Buckets API reports the same origin quota as navigator.storage
storage-buckets-quota-agreementThere are three ways to ask this origin how much storage it may use, and they all describe one number. navigator.storage.estimate() is the…
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 Capability surfaces 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 Capability surfaces — the family cookie-enabled-vs-actual-write belongs to.
