the fields a real identity matcher keys on are reported together

Measured against a deployed identity matcher, only a handful of fields broke an identity match when changed on their own: colour depth, device memory, touch support, colour gamut, the audio digest, and two engine intrinsics. Everything expensive did not.

Both canvas digests, all seven WebGL digests, the unmasked renderer strings, the detected font list and its per-family metrics, the screen box, the user agent, the locale and the timezone were all changed SIMULTANEOUSLY on one device and still resolved to the same visitor; adding two more hardware scalars on top was what finally broke it. That inverts the priority order most fingerprint work assumes.

The fields that make good bucket keys are the small, quantised, machine-lifetime ones — a tiny value set, hard to change without changing machine, and mostly not things a user-agent string can lie about — not the high-entropy digests that get the attention. This row exists to state that, because every other check in this audit asks whether the browser is internally consistent and none of them says which fields a matcher actually keys on.

Two members of the set cannot be moved at all: eval.toString().length and navigator.vendor are engine intrinsics, so a Chromium build reports 33 and a Google vendor string no matter what identity it presents — which puts a hard ceiling on any persona claiming a different engine family.

The row stays informational because judging whether a COMBINATION is one a real population produces needs population data, and that judgement is only worth making on a corpus clean enough to carry it.