a build claiming Chrome carries the Privacy Sandbox surface Chrome ships
Check id privacy-sandbox-vs-chrome-claim
What an ordinary browser yields
A Chrome-branded desktop build at 115+ exposing Topics, Protected Audience, Shared Storage and Fenced Frames. N/A for Brave, for Chromium-branded builds, for mobile, for pre-115 claims, and outside a secure context (severity: warn).
What a detector infers
Topics, Protected Audience, Shared Storage and Fenced Frames all shipped to Chrome stable in 115 and are present by default on desktop. So a build that presents a Google Chrome brand at 115 or later while exposing none of them is claiming to be software it does not have the surface of - the same argument as the device-API family row, one level up: that one asks whether a family is internally consistent, this asks whether a family Chrome SHIPS is present in something calling itself Chrome. THE OBJECTION THAT DECIDES THIS ROW, AND THE MEASUREMENT THAT ANSWERS IT. A privacy-conscious visitor turns these off in chrome://settings/adPrivacy, and a row that fired on them would convict exactly the people who care most - the same failure as scoring a keyboard-activated click as synthetic. Tested on a throwaway profile against stock Chrome 150: at defaults all four are present; with privacy_sandbox.m1.topics_enabled, fledge_enabled and ad_measurement_enabled all set false - which is what the settings UI writes - all four are STILL present, byte-identical to defaults; only --disable-features=BrowsingTopics,BrowsingTopicsDocumentAPI,Fledge,InterestGroupStorage,SharedStorageAPI,FencedFrames removes them. The toggles change what the APIs RETURN, not whether they exist, so presence is a build/launch property and the objection is answered by measurement rather than merely acknowledged. Brave is exempted outright, as it is in the device-API row, because it strips Privacy Sandbox as a stock privacy feature and would otherwise fail for being itself; a Chromium-branded build is exempt too, since it never claimed Chrome's surface. The residual caveat is enterprise policy, which can also disable these and which is a legitimate reason for a managed device to be missing them - that is why this is warn, and why the row reports what it measured instead of naming a cause.
How to resolve it
If the goal is not to participate in ad-tech, leave the interfaces in place and refuse at the call - that is exactly what the settings toggles a real user has do, and it produces a browser indistinguishable from any other Chrome with the feature turned off. Removing the interfaces with --disable-features instead produces a shape no released Chrome has, which makes it the rarer and more identifying signal: the opposite of the intent. Note the asymmetry that makes this worth getting right - a browser that keeps the API and returns nothing is common, while one that lacks the API entirely is not.
Nearby checks in Capability surfaces
- the device-API family is present or absent as a unit
device-api-family-coherenceWeb Bluetooth, WebUSB, WebSerial and WebHID are one family on Chromium desktop - the same secure-context gating, the same desktop platforms… - Firefox resistFingerprinting announces itself when enabled
firefox-resist-fingerprinting-identifiableFirefox's privacy.resistFingerprinting substitutes CONSTANTS rather than randomness, and a constant is itself a fingerprint. - the CSS feature surface is identical in a fresh realm
css-surface-vs-realmWhich CSS properties, values and selectors an engine understands is decided when the browser is compiled. - device-level media features are identical in a fresh realm
media-surface-vs-realmMedia features are answered by the layout engine rather than by the JavaScript properties that describe the same machine, which is what… - the codec matrix is identical in a fresh realm
codec-surface-vs-realmcanPlayType answers come from the media stack compiled into the browser, and the shape of that matrix is genuinely informative: branded… - supported <input> types are identical in a fresh realm
input-surface-vs-realmAssigning an unrecognised type to an <input> element does not throw — the element silently falls back to reporting type "text". - emoji advance widths are identical in a fresh realm
emoji-surface-vs-realmEmoji do not render from the page's fonts but from a platform font supplied by the operating system — Segoe UI Emoji on Windows, Apple Color… - the Web Animations surface is identical in a fresh realm
animation-surface-vs-realmThe Web Animations API exposes a small, precisely specified surface: whether Element.animate exists, whether the timeline and KeyframeEffect…
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 privacy-sandbox-vs-chrome-claim belongs to.