the platform theme resolves the CSS system colours coherently
Check id system-colors-vs-platform
What an ordinary browser yields
Every foreground/background system-colour pair resolves to two different, mutually legible colours in both the light and the dark scheme. The specific values are shown rather than judged; under OS high-contrast mode the row is not applicable.
What a detector infers
The CSS system-colour keywords — Highlight, HighlightText, Canvas, CanvasText, ButtonFace, ButtonText, GrayText and their newer siblings — are not resolved by JavaScript and not from a table inside the style engine. They come from the platform theme layer underneath the browser, which is why Windows, macOS and Linux answer them with different values and why the text-selection pair in particular is OS-characteristic: it is the one a user's accent colour flows into. A page can read the whole palette in a single getComputedStyle pass, from a layer nothing in the page reaches. What this check deliberately refuses to do is name the operating system from that palette, and the refusal is the most important thing about it. Naming an OS requires a per-OS reference table, and this page has already shipped one of those: a set of V8 heap constants that went stale and started telling people running a stock Chrome that their browser was implausible. A system-colour table would rot the same way and faster, because the values move with Chromium milestones AND with the user's own Settings. Measured on a stock Chrome 148 / Windows 11 while writing this: light-scheme Highlight is rgb(0,120,215), dark-scheme Highlight is rgb(25,103,210), and Highlight and SelectedItem are different colours from each other — three values a table would have to carry, and would get wrong the moment somebody picks another accent. So the palette is reported next to the claimed OS for you to read, and only STRUCTURE is asserted: a real theme layer resolves each foreground/background pair to two different, mutually legible colours (a contrast ratio of at least 3:1), in both colour schemes. That assertion needs no reference data and cannot go stale. Two more things came out of measuring rather than reasoning. AccentColor and AccentColorText do not parse at all on a current stock Chrome — CSS.supports('color','AccentColor') is false — and neither does -webkit-focus-ring-color as a colour value, so both are collected when present and never required; asserting on either would have failed a real browser. And GrayText is read but never paired against anything, because it is disabled-state text and is MEANT to be low contrast. The check declines outright under forced-colors, the OS high-contrast mode, which replaces the entire palette by design: that is an accessibility setting, not a tell. Pinning the probe element's own color-scheme to light and then to dark removes the other two legitimate sources of variation — the user's prefers-color-scheme and the page's own colour scheme — so the basis is stated rather than inherited.
How to resolve it
System colours are resolved by the platform theme layer beneath the browser rather than by CSS or by anything a page can set, so a stubbed or synthetic palette is visible the moment someone reads two of them together. Let the browser take its colours from the real desktop theme instead of pinning them to constants, and if a particular OS look is required, run on that OS rather than substituting values — a detector reads the whole palette in one pass and checks it against itself.
Read in the wild by
CloakBrowser Pro releases
The vendor's Chromium 150 stable release names Windows system colors and selection rendering explicitly as a surface it had to bring into line with a real Chrome install. A stealth browser publishing that in shipped release notes is what establishes the surface is read; the note does not say by whom, and neither do we.
Release "CloakBrowser Pro — Chromium 150.0.7871.114.3" (tag chromium-v150.0.7871.114.3-pro, published 18 Jul 2026), "What's changed in the binary": "Closer alignment with a real Chrome install across speech and language profiles, font handling, storage reporting, Windows system colors and selection rendering, and graphics parameters."
CloakHQ/CloakBrowser — chromium-v150.0.7871.114.3-proEvery attribution traces to a published artifact. See the sources and their limits.
Other 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 system-colors-vs-platform belongs to.