An IMC 2024 study turned detection into a reproducible online experiment: instead of trusting what a browser claims to be, it counted properties on underlying objects and compared them with the declared version. The method is more instructive than the conclusion.
There are many claims about whether browser fingerprints can be detected, and most stop at the conclusion. Rather than arguing over who wins, it is more useful to see how researchers turned the question into a reproducible experiment and what metrics they used to make a judgment.
A study published at the ACM Internet Measurement Conference (IMC) 2024, titled Browser Polygraph, was conducted by researchers from Arizona State University, Boston University, and Amazon; its DOI is 10.1145/3646547.3688455. Instead of running simulated data in a lab, the study was deployed in the real production environment of a large financial company for 4.5 months, covering 205,000 real user sessions. Ten common environment-masquerading solutions were tested, with normal user traffic used as the control.
How the experiment was set up
Three design choices made it possible to deploy detection across all traffic without disrupting the business.
The features had to be cheap. The detector only reads a fixed set of properties, with per-run overhead measured in milliseconds and KB, so it can run on all traffic without sampling and without a noticeable effect on users.
The features had to be stable. Instead of parameters users can change, it selected underlying structures fixed by the browser itself. Each browser version ships with a different JavaScript engine, and there are subtle version-to-version differences in how many APIs exist and how many properties are attached to each object. The study used the Chrome 110 to Chrome 114 range for comparison: the detector counted the number of properties on 28 key objects and compared the result with the browser's claimed version. A mismatch means the declaration and actual behavior do not come from the same stack.
The labels had to be trustworthy. Each tested environment was connected to the same production traffic and judged by the same rules, while the control group consisted of normal behavior from real users. The result is therefore not a subjective measure of whether something “looks real,” but whether that traffic can be distinguished under the same rules.
Metrics for judging whether the simulation is real
The measurements used in the study can be grouped into four categories.
- Consistency: whether the browser's claimed version matches the structure of its underlying objects. This is the central metric and the hardest to fake, because changing a string does not also change the number of objects and properties in the engine.
- Detection rate: the study ran detailed experiments on four of the products, with detection rates ranging from 67% to 84%.
- Deviation from real devices: under the same decision rules, normal browsers received a risk score of 0, while the tested products averaged between 8.85 and 11.66. The score reflects distance from the real distribution rather than a subjective impression of similarity.
- Distinguishability: whether the tested traffic can be separated from normal traffic. A class that cannot be separated indicates no behavioral gap from real browsers under this method.
Among the four metrics, the first is the cause; the other three are consequences of it.
Where the four result categories break down
The study divided the tested solutions into four categories based on their underlying implementation.
In the first category, the low-level features do not match any known real browser version, meaning there is no corresponding engine. A simple scan exposes the mismatch.
In the second category, the environment contains real fingerprint features, but when the identity is switched only the surface-level declaration changes while the underlying engine stays the same. This was the most common pattern in the study. As an analogy, the business card shows a new version, but the accent still sounds old. The problem is not whether individual parameters are tuned well; it is the gap between declaration and behavior, and that gap accounts for most of the detections.
In the third category, the underlying engine switches along with the identity. If the environment claims a particular version, it runs the engine corresponding to that version, so consistency holds and the traffic was not distinguished by this detector. The paper also notes that identifying this category would require more sophisticated detection methods.
The fourth category leaves the browser itself unchanged: it runs a real browser inside a virtual machine and then loads the target configuration. Because the browser is genuinely real, the detector cannot distinguish it, but the operational cost is high and difficult to scale.
The difference among the four categories is not the number of parameters, but whether the declaration and the behavior come from the same stack.
Practical guidance for choosing an environment solution
The focus of detection has shifted from reading declarations to validating behavior, so editable surface-level parameters provide less and less advantage. In practical evaluation:
- Ask about the underlying layer, not the parameter list. When the declared version changes, does the underlying layer change with it? Are fingerprints automatically generated as real combinations, or manually assembled values?
- Compare environments with one another. If multiple environments return highly similar low-level features, isolation is incomplete.
- Prioritize consistency before differentiation. The more internally contradictory features are tuned, the larger the exposure surface becomes.
- Passing a generic detection page does not mean a platform will accept the environment. The final check should still use a small amount of real traffic for your own validation.
The core problem at the environment-isolation layer is to make each environment internally self-consistent and independent. That is what PurpleMark is designed to address. Detection and anti-detection should both be used within compliance boundaries; the real value of this research is that it gives evaluation an evidence-based method rather than a ranking of which product is good or bad.
