the reported colour gamut is carryable by the reported colour depth
A display advertising a P3 or Rec.2020 gamut also reports at least 24-bit colour. sRGB at 24-bit is the ordinary case and is not questioned.
What a detector infers
screen.colorDepth and the colour-gamut media query are two readings of one panel, and a measured sweep of a deployed identity matcher found that each of them, changed alone, was enough to break an identity match — while canvas, every WebGL digest, the font list, the screen box and the user agent, changed together, were not. That inverts the usual priority order.
The fields worth being careful with are not the expensive digests but the small, low-cardinality hardware scalars, precisely because they make good bucket keys: a tiny value set, stable for the life of the machine, and hard to change without changing machine. Two of them describing one display is exactly where a persona that edits values independently leaves a contradiction.
The assertion is one-directional on purpose: a wide gamut needs depth to carry it, so P3 or Rec.2020 at fewer than 24 bits is incoherent. The converse is not asserted, because a 24-bit sRGB display is the most ordinary configuration on the web and reading it as a fault would convict most of the population.
How to resolve it
Derive the gamut and the colour depth from one display description rather than setting them independently. Both are values a real matcher buckets on individually, so neither is a safe place to approximate.
Nearby checks in Screen & display
- devicePixelRatio matches matchMedia resolution
dpr-matchmediaThe check compares window.devicePixelRatio against the layout engine's own answer, querying matchMedia with a min-resolution/max-resolution… - screen dimensions are a plausible physical size
screen-plausibleA pure sanity range on screen.width and screen.height: both must be at least 200px and no more than 16384px. - the available screen area fits inside the screen
screen-avail-within-boundsThe available screen area is a subset of the screen by definition: availWidth and availHeight describe what is left of width and height… - screen.colorDepth decomposes into the CSS color media feature
color-depth-vs-media-colorscreen.colorDepth and the CSS color media feature describe one display in two different units: total bits per pixel, and bits per colour… - screen has an OS chrome inset (avail < screen on either axis)
taskbar-presentscreen.availWidth/availHeight describe the area left over after the OS reserves space for its own chrome — a Windows taskbar, a macOS dock… - the outer window fits within the screen
window-boundsThe check asserts only the zoom-invariant bound: window.outerWidth/outerHeight must be non-zero and must fit within the screen. - a non-touch desktop has a fine pointer + hover
pointer-hover-desktopThis check applies only when the UA identifies a desktop platform (Windows, Macintosh, Mac OS X, X11, Linux, CrOS, and not Android/Mobile)… - maxTouchPoints coheres with pointer media
touch-pointer-coherenceA one-directional coherence test: if navigator.maxTouchPoints is greater than zero, matchMedia("(any-pointer: coarse)") is expected to…
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 Screen & display 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 Screen & display — the family colour-gamut-vs-colour-depth belongs to.