What a fingerprint test site actually reports, and how to read one

A uniqueness score compares your browser against the population that has visited that test site. That population is not the population of the internet. It is overwhelmingly made up of people who are interested in fingerprinting, which is a very unusual group of browsers, running very unusual configurations, for very unusual reasons.

Two consequences follow, and both are counterintuitive.

A high uniqueness score is not automatically bad. Every browser on a slightly unusual screen resolution is unique in that population. So is every browser with a recently updated graphics driver.

A low uniqueness score is not automatically good. Matching a large cluster on that site means matching a large cluster of people who were also testing their fingerprinting setup that week.

The score answers "how rare is this configuration among people who visit fingerprint test sites". Almost nobody wants to know that.

Open the same test on two of your own profiles and compare the reports against each other. That comparison is the measurement, and it is the one nobody sells you.

One: do the profiles differ from each other where you configured them to differ? User agent, platform, screen dimensions, core count, memory, timezone, locale, the WebGL vendor and renderer strings. If two profiles that are supposed to describe two different machines are reporting the same values, the configuration did not take, and you have found a real defect. This is the check that catches actual bugs.

Two: does the timezone agree with the address? The report will show both. A mismatch here is the cheapest contradiction a site can detect and it is entirely avoidable.

Three: is there any address of yours in the WebRTC section? Not the proxy's - yours. Every candidate an RTCPeerConnection gathers is listed. If your own local or public address appears while a proxy is attached, stop and fix that before looking at anything else on the page. It is the only finding on the whole report that is unambiguously a failure.

If you are running any tool that launches an unmodified browser and applies values from outside the page, expect the tests that look for tampering to notice.

That is the expected result, not a defect. A value applied over the DevTools Protocol leaves evidence, and it is worth being specific about what kind. A property that has been redefined has a different descriptor shape from one the engine provides. A replacement function stringifies as its own source rather than as native code, unless something goes to the trouble of intercepting that, and intercepting it is itself a thing to find. Prototype chains gain entries. Tests written to look for the override rather than at the value will find it.

The only way to remove that class of evidence is to patch the browser at the source level and ship the result - which is what a vendor is doing when it ships its own browser binary instead of driving a stock one. Where a vendor claims otherwise, the question worth asking is which binary you are running, and that is a question with a checkable answer.

So the report you should expect from two well-configured profiles is: consistent identities, no address leak, a timezone that matches, two clearly different machines, and some indication on the strictest tests that emulation is present.

Anybody who tells you the last item can be removed without patching the browser at the source level is describing a product that does not exist.

1. Chasing a green score. The score is a comparison against an unrepresentative population. Optimising for it is optimising for a metric nobody measures you on.
2. Testing once. A fingerprint is only useful to a site if it is stable. Run the same profile twice, on different days, and check that it reports the same thing. A profile whose identity drifts between sessions is worse than one that is merely distinctive.
3. Testing the wrong browser. The report describes the browser build it was loaded in. If you are evaluating a manager, load the test in a profile that manager launched, with the proxy attached, in the engine you intend to use.

Every value discussed above is downstream of the proxy. A residential address with a clean history beats every setting in every panel in this category, and a datacentre address shared by hundreds of people cannot be rescued by any of them.

That order of importance - proxy, then consistency over time, then real storage isolation, then behaviour, and only then fingerprint coherence - is the same order this site's documentation gives. It is unflattering to write it down on a page selling a fingerprint manager. It is also true, and a test report will not tell you.