Large-Scale Measurement and Real-World Mitigation of Web Browser Fingerprinting in the Wild

Web browser fingerprinting has become a key tracking mechanism on
the modern web, yet its real-world effectiveness and which of the
existing mitigations offer value at scale remain insufficiently
understood.

In this paper, we present a large-scale study of browser
fingerprinting based on real-world telemetry from almost 25 million
Firefox release users. This dataset enables us to quantify user
uniqueness at population scale and identify which characteristics
contribute most to this uniqueness.

Our analysis shows fingerprintability is largely driven by a small
set of high-impact characteristics and their combinations, rather
than the accumulation of many independent measurements. Building on
these insights, we propose and evaluate fingerprinting protections
based on their impact on uniqueness and cohort structure, and design
data-driven mitigations.

These protections, shipped in Firefox 143, reduce the fraction of
uniquely identifiable users from 75% to 46% while maintaining web
compatibility, demonstrating that practical reductions in
fingerprintability are achievable in a mainstream browser.

Here’s what we want to present to you with this paper and the
broader scope of our work.

Uniqueness is caused by a small number of metrics – not one or
thirty

Fingerprinting test sites have a seemingly endless list of
measurements they can pull from your browser. If a user has a
unique fingerprint, it is typically not because of a single
measurement, but it is also not because of 20 or 30
measurements. It is a small number of metrics that make
users unique.

In fact, it’s very close to the
80/20
rule. Specifically, of all the users seen as unique by
Fingerprint Pro (the most discerning fingerprinter we model) –
80% of them are unique after only 8 metrics – while the
fingerprinter collects a total of over 50 metrics. Signifyd
collects more metrics, but identifies fewer users as unique:
80% of the users it sees as unique will be identified after 9
metrics despite collecting over 80.

The numbers only mean anything per operating system

Whenever someone cites a single percentage when describing “How
many users are unique” – you should be suspicious. Because
this collapses multiple different populations that
behave very differently.

Firstly, as a baseline, your operating system is always going
to be exposed to a fingerprinter. We are always working within
the constraint of web compatibility, and lying about the
user’s operating system breaks shortcut keys and gives
you the wrong downloads among other problems. So if
we know the website is going to learn your real OS
anyway, we can use it to segment the population and analyze it
separately.

And when you do you see that each operating system behaves
differently because they have different important metrics.
Admittedly, it’s very difficult to give a concise summary of
work and also provide four sets of numbers – so even we fall
prey to the trap of providing a single number, as we did in
the prior paragraph. But every time we have a single
percentage, somewhere we have that number broken down by
operating system, and in doing so, you will see that each
behaves differently.

Entropy is not the measurement you want

It’s so, so easy to take all the results for a metric and just
calculate Shannon entropy – it’s a standard yardstick in this
literature. But as we show – a high Shannon entropy does not
reliably predict fingerprinting impact.

Cohort size, not just uniqueness

Previous analyses calculated how many people were unique, but
they did not analyze the other people – the ones who
weren’t. All those other people might be 1 million users who
share one fingerprint or 500,000 distinct fingerprints shared by
2 people each – that’s quite the difference.

We use the
Simpson
Index (aka the
Herfindahl–Hirschman
Index) to quantify that difference and compare different
sets of cohorts (shared fingerprints). This lets us compare
how effective different fingerprinting defenses are based not
just on how much uniqueness they eliminate but how much they
collapse groups of users into each other.

For example, two different protections can each lower the share
of unique users by about 2.1 percentage points. But one improves
the cohort score by 56%, while another raises it by only 13%.
Judged on uniqueness alone, two defenses can look equally
effective; while the cohort improvement varies significantly.

The same protection performs very differently per platform

Protections are not uniformly impactful, and the variation is
not small. As an example, clamping the available screen
resolution takes 25.3 percentage points off cumulative macOS
uniqueness but between 0 and 3 points off the other three
platforms. Averaged across all users, that 25-point drop
shrinks to 3.5 – a protection that matters enormously to one
platform can look marginal in the aggregate.

This is yet another reason why it’s so important to segment and
analyze data on a per-operating-system basis.

Standardization and randomization go hand-in-hand

Making users report the same values makes them look more alike,
but it never makes everyone look the same. Some users will still
stand out, and that gets worse on websites with small visitor
populations. Standardization improves the situation, but it
should still be paired with randomization. Randomization is very
strong when it works, but can always be detected and bypassed.
Neither can carry the burden of providing privacy on its
own.

The data shows why values differ, not just that they do

Correlating fingerprinting values with users’ hardware and other
characteristics let us identify why certain measurements differed
between users. Knowing the root cause lets us build
protections that reach much further, and protect small groups of
users who would otherwise stand out as a minority.

Addressing these differences has already produced more consistent
outputs for
image
rendering,
Web
Audio, and
mathematical
operations on Android, with more root causes being investigated.

Users don’t connect website breakage to the setting

Breakage from a strict mode is delayed, and the delay hides the cause.
Turning on a stricter mode is a one-time act – but the broken website
arrives later and nothing connects the two. From the user’s
perspective, this website doesn’t work in Firefox and they have
no idea why and are frustrated. Report after report we see
people posting for help, confused – despite having taken
specific action to enable a hidden setting opting them into
strict fingerprinting protections.

Protections that ship have to keep the web working

Users don’t realize that a setting they changed caused the breakage,
and don’t know how to fix it – so a protection that breaks the web
breaks the browser along with it.
We selected and tuned mitigations on both measured impact
and compatibility. For a default, compatibility
isn’t a trade-off against privacy – it’s a precondition for it.

The hard part is finding what breaks

The web is vast, and even the most innocuous change is likely to break
something somewhere. Some breakage can be anticipated, which helps
design, testing, and detection. The other breakage gets fixed only if a
chain of luck holds: someone has to recognize the breakage, report it,
reproduce it on the right hardware, and get it to the right
person.

We are deliberately not publishing everything we could

Commercial fingerprinters evolve continuously, and they borrow
openly from the community that studies them. Sites built to
teach people about fingerprinting – CreepJS among them – get
picked up and used outright by fingerprinting products.

So we have been deliberately conservative. There are analyses
this dataset would support that we have not run, data we could
have released that we have not, and offensive angles on this
work that we have not pursued. That is a choice rather than an
oversight: we would rather leave a question open than make it
easier to build a better fingerprinter.

This interactive test re-implements individual measurements as close
as possible to how Firefox’s own collection code performed them,
runs in your browser, and compares each result against the published
aggregate data. For every characteristic you can see your value and how many
of the ~25 million measured browsers share it – overall and within
your operating system.

If the test, or anything else on this site, looks wrong, please
report it as an issue on GitHub.
For a problem with the test, include the diagnostics from its
Copy diagnostics button, or, if you would rather
not post your measured values publicly, email them to
[email protected].

The extended version of the paper is available as a PDF.

The paper’s appendices contain a wealth of data locked behind a
reasonable page limit and PDF formatting. This full data page
carries all of it – every rank for every operating system and
all three modeled services, the complete protection chains,
and the paper’s figures regenerated at print resolution.

Our measurements come from Firefox telemetry, specifically the
user-characteristics ping, a dedicated telemetry ping.
Unlike normal telemetry pings that are sent regularly, this ping
must be explicitly enabled (which has happened twice, once in 2025
and once in 2026), and sends one data report before becoming dormant
again.

This ping carries no client ID, only a UUID unique to the ping used
to de-duplicate users. It cannot be keyed to any other telemetry
submissions. It is submitted over Oblivious HTTP
(OHTTP): a relay operated independently of Mozilla forwards the
encrypted submission, so the relay can see the sender’s IP address but
not the contents, and Mozilla receives the contents but not the IP
address. Access to the collected data was restricted to four authorized
Mozilla employees. The data was retained for 90 days and has since been deleted.

We release four types of data:

1. A list of fingerprints generated for different phases of protections, per modeled fingerprinter, with the user’s OS and locale unmasked.
2. Aggregate tables of the frequency of value per metric, split by OS
3. Aggregate tables of the frequency of value per metric, correlated by other metrics’ values, again split by OS
4. A detailed analysis of rendered canvas images that allows comparison

In the fingerprint lists, the fingerprints cannot be recreated from
a website measuring user characteristics, due to the way the telemetry
was collected. After being generated, the files were shuffled to a new ordering,
and any locale occurring fewer than 100 times was anonymized.

In the aggregate tables, any value observed fewer
than 100 times within a single per-OS population is withheld – so
the published data describes cohorts, never individuals.

In the canvas comparison, raw canvas renderings are provided, but they
are devoid of any connection to other user data. Any unique canvas rendering
is not provided; only the hash.

For verification and exploration, the code used to process the data and
perform different analyses is available for review. It additionally contains
the specific fingerprinting scripts captured, reverse engineered, and
modeled for the paper.

Far more can be asked of this dataset than we have asked. Some of it
we chose not to pursue, some of it we simply did not think of, and
some of it is a better fit for someone who is not us.

There is a discussion board for proposing follow-up analyses. Two
kinds are worth posting:

• Answerable from the published aggregate data.
  Anyone can run these – the per-operating-system
  distributions are released, and the analysis toolkit is open. Post
  the question anyway, so the work is not duplicated and so the
  result lands somewhere others can find it.
• Needs the raw data. These we would have to run
  ourselves, since the underlying ping data is not something we can
  ever release. Describe what you want to know and why! To be clear,
  we do not have the raw data anymore but it is possible we
  will perform a re-collection in the future which we could analyze.
  We cannot promise to run everything, and some questions we will
  decline because we do not wish to help build a better fingerprinter.