Why now

On 2026-11-10 the Mozilla Security Blog published "Open research, stronger privacy: Making Firefox users harder to fingerprint," alongside the CCS 2026 paper (Nov 15–19, The Hague) "Large-Scale Measurement and Real-World Mitigation of Web Browser Fingerprinting in the Wild" and a companion site, fingerprinting.study, with the data, analysis code and a browser test. Using measurements from almost 25 million Firefox release users, and simulating the scripts of three commercial fingerprinters (Fingerprint Pro, Signifyd and Akamai), the authors show that data-driven protections cut the share of uniquely identifiable users from 75% to 46%.

On HN (178 points, 69 comments) and on Lobsters, the discussion kept coming back to an old question: is it stronger to give everyone the same value (standardize) or a different value every time (randomize)? Brave has led with randomization ("farbling") since 2020, while Tor Browser has pursued uniformity, making everyone look the same. What's new here is that the paper answers the question with numbers from a population of 25 million: standardize as the main strategy, then layer randomization and targeted blocking on top. And it reaches straight into the return values of APIs web developers touch every day: navigator.hardwareConcurrency, screen.availHeight, navigator.storage.estimate(), canvas readback, and time zone names.

The problem

Fingerprinting re-identifies a user without any stored identifier like a cookie, by combining properties of the browser and device: fonts, screen size, GPU, CPU core count, language, time zone, canvas rendering output and so on. Each value is ordinary on its own, but together they become "the combination only I have." State partitioning such as Total Cookie Protection doesn't stop it.

Defenders work under two constraints:

• Web compatibility: lie about a value and some sites break. As examples from Resist Fingerprinting (RFP) mode, the paper cites calendars breaking when the time zone is pinned to UTC, image cropping breaking when readback of rendered output is disabled, and HTML5 games failing after clock precision changes. And the breakage shows up after the setting was changed, so users don't connect the two.
• The OS can't be hidden: lying about the operating system breaks keyboard shortcuts and serves the wrong downloads, so the design assumes the site always sees the real OS.

Within those constraints, the question is which values to change, and how, to blend as many people as possible into the crowd. There are three broad tools:

1. Standardization: round or pin the returned value to a small set of representative values.
2. Randomization: add small noise so values don't match across sites or sessions.
3. Targeted disruption: stop known fingerprinting scripts with URL blocklists or heuristics, or add noise only to those scripts.

How it works

Uniqueness isn't enough: cohorts and the Simpson Index

Earlier work usually talked about the share of unique users and the Shannon entropy of each feature. The paper argues those two aren't enough.

• It matters enormously whether the non-unique users are "one million people sharing one fingerprint" or "500,000 pairs." A pair can be separated with just a little extra signal, such as an IP address.
• So the paper also uses the Simpson Index (the same thing as the Herfindahl–Hirschman Index) as a "cohort score": the probability that two randomly chosen users share a fingerprint. The more people are pooled into large cohorts, the higher it goes.
• For example, two protections that each lower uniqueness by about 2.1 percentage points can differ sharply on cohort score: one improves it by 56%, the other by only 13%.
• A feature with high Shannon entropy also doesn't necessarily contribute much to uniqueness, because it may be correlated with other features and therefore redundant. The paper's principle: select targets by how much uniqueness drops when you remove them, not by entropy.

A few features decide most of it