Measure The Web

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Browser Fingerprinting ======

//Browser fingerprinting// identifies a browser — and through it a device and a person — from the configuration it exposes to JavaScript and to HTTP: fonts, canvas rendering, audio processing, screen geometry, installed extensions, GPU behaviour. Unlike [[Privacy:Cookies|cookies]] it is **stateless**: nothing is written to the client, so nothing can be cleared, and there is no browser API a user can use to say no. That is what makes it the tracking technique that outlives every storage-based countermeasure, and the one a measurement study is least well equipped to observe.

The canonical entry point outside this wiki is Laperdrix et al.'s survey {[laperdrix2020_survey]}, which covers the attribute space, the entropy literature and the defence taxonomy in a way this page does not attempt to duplicate. What this page adds is the **measurement methodology**: how the 83 papers in our corpus actually detected fingerprinting, why their prevalence numbers cannot be compared with one another, and what you have to instrument to produce a number of your own.

<WRAP important>
**Before you search the literature for "fingerprinting", know that the word names at least eight unrelated research areas.** In our corpus of seven security and privacy venues, 280 papers describe detecting something they call a fingerprint. Only 83 of them are about browsers. The largest single group — 105 papers — is **website fingerprinting**, an encrypted-traffic-analysis problem about inferring which page a victim loaded over Tor or a VPN. It shares the word and almost nothing else. See [[#What the Word Means in the Literature]].
</WRAP>

===== The Mechanism =====

A fingerprint is a vector of attributes, each cheap to read and none identifying on its own. Three properties decide whether it works as an identifier, and every empirical paper on this page is measuring one of them:

  - **Entropy** — how much the attribute varies across the population. Eckersley's original study {[eckersley2010_unique]} framed this as an information-theoretic question and it has stayed that way.
  - **Stability** — whether the same browser yields the same vector next week. A high-entropy attribute that changes daily is useless for tracking and is why linking algorithms exist at all.
  - **Reachability** — whether the attribute is readable from an ordinary third-party script, without permission and without user-visible effect.

==== The attribute families ====

^ Family ^ Example signals ^ Why it is high-entropy ^ Reachable by a third party? ^
| Canvas / WebGL | Text and geometry rendered to an offscreen ''%%<canvas>%%'', then hashed | GPU, driver, font rasteriser and anti-aliasing all leak into the pixels | Yes, silently |
| Fonts | Which font families resolve; text metrics per font | Installed font set reflects OS, locale, and installed software | Yes, via measurement, no enumeration API needed |
| Audio | ''AudioContext'' / ''OfflineAudioContext'' output of a fixed oscillator | Floating-point behaviour of the audio stack differs by build | Yes |
| Display | ''screen.width/height'', ''devicePixelRatio'', available viewport | Monitor and zoom combinations are diverse | Yes |
| Extensions | Web-accessible resources, injected style sheets, DOM side effects, ''postMessage'' behaviour, page-visibility timing | The //set// of installed extensions is close to unique | Yes — this is a research area of its own, below |
| Platform strings | User-Agent, ''navigator'' properties, plugin list | Cheap and passive, but deliberately degraded by browsers since 2022 | Yes |
| Hardware channels | GPU timing, clock skew, motion-sensor calibration | Manufacturing variation between physically identical units | Sometimes — often needs a permission or a long observation |

The extension surface is worth separating out, because it is the one that grew fastest in the corpus and the one where the browser vendor has least control. Carnus {[karami2020_carnus]} enumerated four independent channels (web-accessible resources, DOM changes, intra-extension messaging, and outgoing HTTP requests); style-sheet injection {[laperdrix2021_fingerprinting]} and page-visibility timing {[agarwal2024_peeking]} added more. Two of these papers make the same uncomfortable point: extensions installed //for privacy// are themselves fingerprintable, and one study found that 82.5% of the extensions it detected remained detectable after their next update {[laperdrix2021_fingerprinting]}.

===== What the Word Means in the Literature =====

This section is the reason to read this page before doing a literature search. Every figure below comes from a structured extraction over **5,859 full-text papers** from CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, in which each paper contributes one record with a verbatim evidence quote per claim. The 2025 and 2026 venue-years are provisional — CCS and IMC 2026 have not been held and two more 2026 venue-years are incompletely selected — so read any row that reaches them as a floor. The population here is the **280 papers whose ''detection.phenomenon'' field names a fingerprint** — not the whole corpus, and not the 5,655 papers that detected //something//.

Those 280 papers produce **459 distinct free-text descriptions**. That is the whole problem: the field is not a vocabulary, and no exact-string aggregation over it means anything. After folding (method at the end of this section):

^ What was actually being fingerprinted ^ Papers ^ Share of 280 ^ Distinct strings ^
| **Website / traffic fingerprinting** — which page or site a victim loaded, from encrypted traffic | 105 | 37.5% | 136 |
| **Browser fingerprinting** — the subject of this page | 83 | 29.6% | 156 |
| Remote host & network-stack ID — TLS, OS, server, middlebox, DPI | 38 | 13.6% | 53 |
| Physical-object & hardware forensics — PRNU, paper speckle, clock skew, phone sensors, flash and USB timing | 28 | 10.0% | 54 |
| Human biometrics — actual fingers | 16 | 5.7% | 24 |
| Off-web device identification — BLE/IoT, MAC randomisation, LTE handsets, mobile SDKs | 13 | 4.6% | 18 |
| Media content identification — Shazam-style | 8 | 2.9% | 11 |
| Analysis-environment evasion — malware fingerprinting the sandbox | 2 | 0.7% | 4 |
| **LLM / model identification** — which model serves an endpoint //(new in 2025)// | 1 | 0.4% | 4 |
| //unmapped// | 6 | 2.1% | 7 |

Eighteen papers (6.4%) fall in more than one family, so shares exceed 100%. The practical consequences:

  * **Only about 30% of the papers that detect "a fingerprint" are about browsers** (83 of 280). That is the precision of a //structured extraction// that has already identified a detected phenomenon; a raw full-text keyword search hits many more papers and is worse. If you are building a related-work section, "website fingerprinting" is the false-friend that will dominate your results.
  * **Website fingerprinting is the larger literature, and browser fingerprinting has been flat since 2018.** Per 1,000 corpus papers, browser fingerprinting goes 5.9 → 13.0 → 16.0 → 14.8 → 15.2 across 2010–2013, 2014–2017, 2018–2021, 2022–2024 and the provisional 2025–2026 — it grew until 2021 and has sat near 15 since. Website fingerprinting goes 13.7 → 14.3 → 17.4 → 17.9 → 22.8. Neither is displacing the other, and in the last window traffic fingerprinting pulls ahead — on two incomplete venue-years, so do not lean on it.
  * **They do not share methods.** One drives instrumented browsers over crawls; the other trains classifiers on packet traces, so almost nothing transfers between them but the word. Whether the two literatures cite each other is a question about a citation graph, which this extraction does not contain and this page therefore does not answer.

==== Where the browser papers are ====

^ Venue ^ Corpus papers ^ Browser-FP papers ^ Share of venue ^
| TheWebConf | 843 | 17 | 2.0% |
| PETS | 510 | 17 | 3.3% |
| USENIX Security | 1,410 | 14 | 1.0% |
| CCS | 990 | 11 | 1.1% |
| NDSS | 701 | 9 | 1.3% |
| IEEE S&P | 767 | 9 | 1.2% |
| IMC | 638 | 6 | 0.9% |

PETS is the densest venue by a factor of two to three, which matches where the community sits — but the absolute numbers are small everywhere. **This is an 83-paper literature across seventeen years and seven venues.** It is small enough to read in full, and this page's report script prints the list.

==== How the folding was done, and its residue ====

''detection.phenomenon'' is one of the three least reproducible fields in the extraction: two independent runs over identical text agree on roughly 20% of exact free-text strings. It can carry a ranking; it cannot carry a precise percentage. The fold used here is in ''scripts/fp_fold.mjs'' below and works in three passes:

  - **Strong patterns**, ordered, matching the //subject// of the fingerprint — a named web API, a Tor circuit, a biometric sensor, a TLS stack. First match wins, because the discriminating word is the qualifier and not the head noun: "website fingerprinting" and "canvas fingerprinting" share the noun and share nothing else. This resolved 441 of 544 tuples.
  - **Property-only strings, resolved by paper context.** 95 of the 544 strings name only a property — "fingerprint stability", "fingerprint uniqueness", "fingerprint comparison speed" — and are genuinely unresolvable in isolation: //"fingerprint comparison speed"// is a PGP key fingerprint, //"font fingerprint uniqueness"// is a browser. Such a tuple inherits the family of a strong tuple in the same paper. This resolved 76 more.
  - **Hand verification of what was left**, by reading each ''evidence.quote'' and the paper title. Nineteen assignments are recorded by hand in the script, each with its reason inline; seven tuples in six papers could not be assigned at all and are printed rather than dropped. All six are genuinely something else: malware feature hashing, textual PGP key-fingerprint representations, Tor relay identity keys, Zcash transaction values, and two memory side-channel papers that fingerprint which application is resident in a confidential VM.

The fold had to be extended for this corpus. On the 4,322-paper corpus the residue was 5 tuples in 4 papers; the 2025–2026 papers took it to **59 tuples in 31 papers** before the patterns were widened. What arrived was mostly new subject matter rather than new phrasing — DPI-device fingerprinting, ad-blocker and filter-list fingerprintability, LLM identification, AR/VR app inference, mobile fingerprinting SDKs. [[provenance:privacy:fingerprinting]] lists every string and where it went.

<WRAP info>
**Why the fold matters quantitatively.** Not folding does not just add noise, it changes answers. FingerprintJS appears in this 83-paper subset under **seven distinct spellings** (''fingerprintjs'', ''fingerprintjs2'', ''FingerprintJS2'', ''Fingerprint2'', ''FingerprintJS'', ''FPJS Pro'', ''Fingerprintjs2 (FPJS2)''), so an exact-string count reports the most-used fingerprinting library in the literature at a fraction of its real frequency. The same is true of the phenomenon field, where 83 papers generate 156 strings.
</WRAP>

===== Use in Publications =====

Population for everything in this section: the **83 browser-fingerprinting papers** identified above. Sentinel values (''not-stated'') are counted as what they are and never as answers.

==== What kind of papers these are ====

^ Property ^ Papers ^ Share of 83 ^
| Measured the web platform | 78 | 94.0% |
| Also measured mobile | 16 | 19.3% |
| Ran an automated web crawl | 57 | 68.7% |
| Empirical (measured the world as it is) | 82 | 98.8% |
| Proposes a system, attack or defence | 54 | 65.1% |
| Reanalyses an existing dataset | 36 | 43.4% |
| Recruited human participants | 19 | 22.9% |
| Assessed a law | 10 | 12.0% |
| Released an artifact link | 77 | 92.8% |

Two of these are worth pausing on. **65.1% also propose a system, attack or defence** — this is a literature where measuring and building are the same paper, so a "prevalence of fingerprinting" number is very often a by-product of evaluating a detector rather than the study's primary object. And **92.8% released an artifact link**, well above the corpus-wide rate (66.2% for 2024, 76.9% for 2025), which is the single best practical fact on this page: the detectors are almost all available.

==== Which surfaces and questions get measured ====

Ranked, not precise — searched across the phenomenon, technique, metric and prevalence text of each paper's fingerprint tuples, because a paper enumerating twenty APIs still writes only "browser fingerprinting" in a ten-word summary field.

^ Surface or question ^ Papers ^ Share of 83 ^
| Uniqueness / entropy / anonymity set | 34 | 41.0% |
| Fingerprinting **scripts** as the detection target | 33 | 39.8% |
| Canvas | 23 | 27.7% |
| Stability & evolution over time | 14 | 16.9% |
| Fonts | 11 | 13.3% |
| Audio (''AudioContext'' / Web Audio) {[chalise2022_webaudio]} | 10 | 12.0% |
| Browser extensions as a signal | 10 | 12.0% |
| Defences and their resistance | 9 | 10.8% |
| WebGL / GPU | 8 | 9.6% |
| ''navigator'' / User-Agent / plugins | 6 | 7.2% |
| WebRTC | 6 | 7.2% |
| Timing & clock | 4 | 4.8% |
| Screen & display | 3 | 3.6% |
| Device sensors (motion, battery) | 2 | 2.4% |

<WRAP important>
**That table ranks sixteen years of literature, so some of its rows are history.** Before you instrument a surface because papers measured it, check whether it still carries entropy:

  * **''navigator.plugins'' is dead as a signal.** The HTML standard now mandates a **fixed, hard-coded** plugin list — the same five PDF-viewer names in every browser — so the property that Nikiforakis et al. {[nikiforakis2013_cookieless]} mined in 2013 returns a constant today.((WHATWG HTML Standard, [[https://html.spec.whatwg.org/multipage/system-state.html#pdf-viewing-support|§ PDF viewing support]], which specifies the fixed ''PluginArray'' contents ("Chromium PDF Viewer", "WebKit built-in PDF", …). Read 2026-09-03.)) The User-Agent string is reduced in Chrome and frozen except for marketing version in Safari (sources in the defences table below).
  * **The Battery API is gone from Firefox** for web content and has been since Firefox 52 — the study that made it famous is measuring a surface Firefox users no longer expose.((Mozilla, [[https://bugzilla.mozilla.org/show_bug.cgi?id=1313580|Bug 1313580]] "Remove web content access to Battery API", VERIFIED FIXED, ''status-firefox52: verified''. Read 2026-09-03.)) Flash, which several early papers rely on for font enumeration, reached end of life at the end of 2020.
  * **Fonts are still live but narrowed.** Safari exposes only web fonts and OS-bundled fonts, not user-installed ones, so a font-based measurement now yields far less on WebKit than the 2013–2018 papers report.
  * **Canvas, WebGL, audio and screen remain the load-bearing surfaces**, which is why canvas is the one technique the single post-reversal measurement on this page chose to count.

Nothing here says the old papers were wrong. It says a prevalence figure is a measurement of a platform at a date, and four of the rows above are measurements of a platform that no longer exists.
</WRAP>

The top two rows are the structural finding, and on the extended corpus they have swapped: uniqueness/entropy is now marginally ahead of script detection, 34 papers to 33, where on the 4,322-paper corpus they were tied at 25. The point is unchanged. **One of the two most common things a browser-fingerprinting paper detects is not a fingerprint — it is a script that takes one.** That is a different measurement problem with a different failure mode: you are classifying JavaScript, so your ground truth is a filter list or a hand-labelled sample, and your recall is bounded by which scripts your crawler happened to load. It is why this page's tooling section is mostly about [[Privacy:JavaScript|JavaScript instrumentation]] and not about attribute collection.

==== Prevalence numbers are not comparable across papers ====

<WRAP important>
Do not build a time series from published fingerprinting-prevalence figures. Of the 83 papers, 81 state a headline number, and they are measuring different things with the same words.
</WRAP>

Four widely cited figures, each verbatim from the paper:

^ Paper ^ Number ^ What the denominator actually is ^
| Nikiforakis et al. 2013 {[nikiforakis2013_cookieless]} | 40 sites, **0.4%** | Sites in the Alexa top **10,000** using one of **three named commercial** fingerprinting providers |
| Acar et al. 2014 {[acar2014_never]} | 5,542 sites, **>5.5%** | Sites in the Alexa top **100,000** running a **canvas** fingerprinting script — 95% of them one provider, addthis.com |
| Englehardt & Narayanan 2016 {[englehardt2016online]} | 14,371 sites, **1.6%** | Sites in the top **1 million** running canvas fingerprinting; canvas-font is a separate 2.5% of the top 1,000 |
| Iqbal et al. 2021 {[iqbal2021_fingerprinting]} | **10.18%** | Top **100K** sites deploying fingerprinting under an **ML classifier's** definition, not a script allowlist |

Every axis moves between rows: the rank cut (10K / 100K / 1M), the unit (site, script, provider), and the definition of fingerprinting (three named vendors / one API / any of several APIs / a learned classifier). Rizzo et al. {[rizzo2021_unveiling]} report the same year as Iqbal et al. that "only 1.1% of scripts is classified as actual fingerprinting" — a number an order of magnitude apart from 10.18% and not in conflict with it, because one counts scripts and the other counts sites.

If you need a trend, the two studies that hold the method fixed and vary time are the ones to use: Lerner et al.'s archaeology of archived pages {[lerner2016_internet]} and FP-Radar's longitudinal API-graph analysis {[bahrami2022_radar]}. Both find growth; neither does it by comparing other people's percentages.

==== The entropy and uniqueness literature ====

Uniqueness is the field's headline claim and its most fragile one, because it is a property of //the population you sampled//, not of the technique. The two studies that bracket the question:

  * Eckersley's Panopticlick data {[eckersley2010_unique]} found the great majority of participating browsers unique — from a self-selected, privacy-interested visitor population.
  * Gulyás et al. {[gulyas2016_near]} formalised the other direction — given a budget of //k// attributes, which set identifies the most users — and reported that detecting just 10 fonts uniquely identified 13,155 users (30.13%) in their dataset.
  * Gómez-Boix et al. {[gomezboix2018_hiding]} re-ran the measurement on 2 million fingerprints from a **general-audience** French website and found **33.6% unique overall — 35.7% on desktop and 18.5% on mobile**. Mobile browsers are much more homogeneous: same OS build, same font set, no plugins.

That gap is a sampling artefact of the kind [[Statistics:Biases]] is about, and it is the reason a uniqueness figure without its recruitment description is not usable. Berke et al.'s PoPETs 2025 study {[berke2025_demographics]} extends the point to demographics, linking fingerprints to a consented US panel and showing that identifiability is not evenly distributed across users.

Stability closes the loop, because a unique fingerprint that changes is not an identifier. FP-Stalker {[vastel2018_stalker]} measured evolution directly: **50% of browser instances changed fingerprint in under 5 days, 80% in under 10 days** — and then showed that a linking algorithm recovers the identity anyway, tracking for a median of 54.48 days. Pugliese et al. {[pugliese2020_long]} ran the longest observation, over years and with a participant survey attached. DRAWN APART {[laor2022_drawn]} adds a hardware-level GPU signal specifically to attack the stability limit, raising median tracking time from 17.5 to 28 days when combined with FP-Stalker.

==== Detection in the wild versus defence ====

The 83 papers split into two research programmes that use the same instrumentation:

**Detecting fingerprinting** — the classifier lineage. Heuristic API-access counting (Acar et al., Englehardt & Narayanan) gave way to learned script classifiers: FP-Inspector {[iqbal2021_fingerprinting]} on syntactic and dynamic JS features, FP-Radar {[bahrami2022_radar]} on the co-occurrence graph of API accesses over time, automatic discovery of //emerging// techniques {[su2023_automatic]}, taint tracking with entropy thresholds in FP-Tracer {[boussaha2024_tracer]}, and federated detection without centralising crawl data in FP-Fed {[annamalai2024_fpfed]}. Rizzo et al. {[rizzo2021_unveiling]} come at it from code mining instead.

**Evaluating and building defences** — PriVaricator {[nikiforakis2015_privaricator]} introduced randomisation ("little white lies") as an alternative to uniformity, and reported breaking four named commercial fingerprinters. FP-Scanner {[vastel2018_scanner]} then attacked the defences: it detects //inconsistencies// introduced by spoofing extensions, reaching accuracy 1.0 on its test set — a browser lying badly about itself is more identifiable, not less. Datta et al. {[datta2019_evaluating]} evaluated anti-fingerprinting PETs side by side and found Tor Browser most effective, under 3 bits of entropy remaining.

Three papers measure fingerprinting where it is used //for security// rather than tracking, which is a framing this page's readers should not lose: on phishing pages {[sanchezrola2023_rods]}, in phishing-kit cloaking (96.52% of 2,933 kits used fingerprinting-based cloaking) {[zhang2022_spartacus]}, and in adversarial-versus-benign fingerprint populations at commercial scale, where only 1.6% of unique fingerprints were shared between the two {[wu2023_manyfaces]}.

==== The toolchain, folded ====

Tools each paper //used or produced// (''usedOrMentioned'' filtered, so a baseline someone compared against does not read as adoption), folded across spellings:

^ Tool family ^ Papers ^ Share of 83 ^
| EasyList / EasyPrivacy | 19 | 22.9% |
| OpenWPM | 15 | 18.1% |
| FingerprintJS | 14 | 16.9% |
| Disconnect list | 13 | 15.7% |
| Brave | 7 | 8.4% |
| DuckDuckGo Tracker Radar Collector | 6 | 7.2% |
| uBlock Origin | 6 | 7.2% |
| FP-Inspector | 4 | 4.8% |
| AmIUnique | 4 | 4.8% |
| Panopticlick / Cover Your Tracks | 2 | 2.4% |
| Tor Browser | 2 | 2.4% |
| puppeteer-extra-plugin-stealth | 2 | 2.4% |
| FP-Scanner / FP-Collect | 1 | 1.2% |
| FPMON | 1 | 1.2% |

<WRAP info>
**What that table leaves out.** It counts only names the fold recognises. The report script now also prints its **residue** — 398 tool names it could not place, 55 of them in two or more papers — and the residue is where the plumbing lives: Selenium (13 papers), Puppeteer (12), Chrome DevTools Protocol (5), VisibleV8 (5), Docker (5), mitmproxy (4), Playwright (3). Read the two lists together. The table tells you which //fingerprinting-specific// resources the field shares; the residue tells you what it drives them with, and it is mostly Chromium, not the Firefox-only instrument at the top of the table.
</WRAP>

Read the top of that table carefully. **The most-used resource in the browser-fingerprinting literature is an ad-blocking filter list**, and the same holds for ground truth: of the classification resources these papers name, EasyList/EasyPrivacy (17 papers) and Disconnect (13) outrank every purpose-built fingerprinting resource. But the two lists are not the same kind of ground truth, and papers routinely write "filter lists" as though they were:

  * **EasyList and EasyPrivacy have no fingerprinting category.** EasyPrivacy blocks trackers; fingerprinting scripts are a subset that overlaps it imperfectly. Using it as a fingerprinting label caps your measurable recall at the list's tracker coverage and imports its known bias against the long tail (see [[Privacy:Requests]] on why up to 90% of EasyList resource rules provide no benefit in common browsing).
  * **Disconnect does have one** — two, in fact: its blocklist carries ''FingerprintingInvasive'' and ''FingerprintingGeneral'' as top-level categories alongside ''Advertising'' and ''Analytics'', and Firefox's "known fingerprinters" protection is built from them.((''disconnect-blacklist.json'' in [[https://github.com/mozilla-services/shavar-prod-lists|mozilla-services/shavar-prod-lists]], the list Firefox actually ships. Read 2026-09-03: the ''categories'' object has 11 keys, including ''FingerprintingInvasive'' (281 entries) and ''FingerprintingGeneral'' (96).)) So a paper using Disconnect as fingerprinting ground truth is inheriting a **specific** editorial judgement about which domains are invasive fingerprinters — not a generic tracker list — and it should say **which category** it used. A paper that says only "Disconnect" has not specified its ground truth.

FingerprintJS at 16.9% is the mirror image: papers use the //attacker's// library as a positive control, checking whether a script contains its magic strings. OmniCrawl {[cassel2022_omnicrawl]} found that 277 of 1,444 fingerprinting-matching scripts (14%) contained all the fingerprintjs2 magic strings — good for precision, useless for anything the library does not do.

==== Crawl methodology, compared with the corpus ====

Of the 83 papers, 57 ran a crawl and all 57 recorded a configuration. They report their setup **better than the corpus average on every axis**:

^ ''crawlConfig'' field ^ States a value ^ Share of 57 ^ All 1,080 papers with a crawl configuration ^
| Statefulness (stateful vs. stateless) | 21 | 36.8% | 21.9% |
| Interaction depth | 52 | 91.2% | 77.9% |
| Consent action | 39 | 68.4% | 54.2% |
| Headless or headful | 10 | 17.5% | 13.0% |
| Authentication | 55 | 96.5% | 72.1% |
| Browser named | 44 | 77.2% | 49.0% |

<WRAP important>
**The headless row is the one that should worry you: 17.5%.** Headless Chrome differs from headful Chrome in exactly the attributes a fingerprinting script reads — ''navigator.webdriver'', missing plugin arrays, a different WebGL vendor string, no ''chrome'' runtime object, and different font rasterisation. A fingerprinting script can therefore detect your crawler, and a cloaking script can serve it different content. More than four in five of the 57 crawling papers do not say whether they ran headless at all — and saying so is only the first step, since a paper that reports "headful Chrome" still has not reported whether its crawler was detectable.

The corpus contains direct evidence that this is not hypothetical, and it has been measured twice. FP-Fed {[annamalai2024_fpfed]} ran a manual crawl of the Tranco top 300 imitating real user interaction — logging in, solving CAPTCHAs — and found it captured //"3 times more fingerprinting scripts than automated/centralized ones proposed in previous work"//. Annamalai et al. {[annamalai2025_beyond]} then scaled the comparison: of 471 fingerprinting websites found in real user sessions, an automated crawl of the same sites missed **211 (45%)**. PhishPrint {[acharya2021_phishprint]} and the phishing-page studies {[sanchezrola2023_rods]} show sites profiling the visitor precisely to decide what to serve a crawler; and 96.52% of phishing kits in one study used fingerprinting-based cloaking {[zhang2022_spartacus]}. If you crawl for fingerprinting, assume the sites you care about most are the ones checking.
</WRAP>

Browsers actually driven: Chrome/Chromium 29 papers, Firefox 17, then single papers using Internet Explorer, Opera, Brave, Tor Browser, DuckDuckGo, Ghostery, Android WebView and Spartacus. The privacy-browser tail is thin, which matters because a defence study needs the browser whose defence it is testing. Note also [[Programming:Stateful stateless]]: only 36.8% state statefulness, and for fingerprinting the choice is not neutral — a stateless crawl sees the script's first-visit behaviour only.

==== Legal framing is rare ====

Only **10 of 83** papers (12.0%) assess a law, against 6.9% corpus-wide (402 of 5,859) — so not quite twice the corpus rate, and still an outlier practice. Folded, the laws are GDPR (9 papers) and the ePrivacy Directive (4 papers, appearing under three different spellings including "European directives 2002/58/CE and 2009/136/CE"), then CCPA (3), plus one each of the UK Digital Economy Act, Brazil's LGPD, COPPA and the DSA. The papers that do it are the ones joining fingerprinting to consent: cookie respawning with fingerprinting {[fouad2022_cookie]}, and post-cookie tracking that bypasses a GDPR consent choice {[papadogiannakis2021_user]}.

This is a gap, not a finding about the law. Fingerprinting has no consent API, so the compliance question — can a technique that cannot be refused ever rest on consent? — is squarely open, and became sharper in 2025 (see below). See [[Privacy:Consent]] and [[Practices:Legal enforcement]].

==== Human subjects ====

19 papers (22.9%) recruited participants, which is how uniqueness gets measured at all: you cannot compute an anonymity set from a crawl. Recruitment is bimodal — Mechanical Turk and other crowd platforms for the attack-feasibility studies (n ≈ 1,000–2,300), professional networks and volunteer panels for the longitudinal ones (Pugliese et al. ran three waves of 2,315 / 1,275 / 243 {[pugliese2020_long]}), and one 52,000-user browser-telemetry study {[zeber2020representativeness]}. If you are planning a uniqueness measurement, read [[Design:User studies]] and [[Practices:Ethics]] first: you are collecting a device identifier from participants, which is personal data under GDPR regardless of your intent.

==== Reproducing these figures ====

The report script prints every number on this page with its denominator, the unmapped residue, and the full 83-paper list. The folding rules live in a separate module so they can be audited and reused. The block below is that module in full and verbatim — not a summary of it — so that running it reproduces the family table above exactly. The long alternations are the point: each family is a list of the literal phrasings the corpus actually uses, grown by hand as new ones appeared, and a shortened version of them silently reclassifies papers.

<file javascript fp_fold.mjs>
// Folding rules for the word "fingerprint" in `detection.phenomenon`.
//
// Why this file exists: the corpus is seven broad security venues, so a
// substring search for "fingerprint" pulls at least seven unrelated literatures
// into one bucket. `detection.phenomenon` is free text and ~20% stable
// run-to-run (data/extract/README.md), so it can never be aggregated by exact
// string — 280 papers produce 459 distinct strings.
//
// Three-pass design, because one regex cannot do it:
//
//   Pass 1 — STRONG. Ordered patterns naming the *subject* of the
//     fingerprint: a web API, a Tor circuit, a biometric sensor, a TLS stack.
//     First match wins; the qualifier discriminates, not the head noun
//     ("website fingerprinting" and "canvas fingerprinting" share the noun).
//
//   Pass 2 — GENERIC, resolved by paper context. A large minority of strings
//     name only a *property* of a fingerprint — "fingerprint stability",
//     "fingerprint uniqueness", "fingerprint comparison speed". Those are
//     unresolvable from the string alone: "fingerprint comparison speed" is a
//     PGP key fingerprint, "font fingerprint uniqueness" is a browser. Such a
//     tuple inherits the family of a STRONG tuple in the same paper, and if
//     the paper has none it stays `unmapped`.
//
//   Pass 3 — HAND. The small residue left by passes 1 and 2, resolved by
//     reading each `evidence.quote` and the paper title, keyed on
//     (slug, phenomenon) with the reason recorded inline. See `HAND` below.
//
// Everything still unmapped after all three passes is PRINTED by the report, so
// the part that could not be classified stays visible instead of vanishing.

export const STRONG = [
  // 1. Human biometrics. First, because "fingerprint sensor / template /
  //    image" is a finger, not a browser.
  [
    'biometric',
    /\b(biometric|minutia|finger position|fingerprint (sensor|template|image|sample|reader|recognition|acquisition|authentication|spoofing|brute-force|smoothness|and camera)|fake fingerprint|half-fingerprint|latent fingerprint|scrap fake|fingerprint-template|spi fingerprint|friction sound|fingerprint-pattern prediction|fingerprint-based authentication|poisoned-fingerprint|tee fingerprint|fingerprint key security|fingerprint extraction|fingerprint image recovery|fingerprint deactivation|mishandled fingerprint updates|fingerprint api misuse)/i,
  ],

  // 2. Physical-object and hardware forensics: identifying an object or its
  //    manufacturing noise. Includes phone sensors and clock skew, which are
  //    hardware channels even when reached from JavaScript.
  [
    'physical-forensic',
    /\b(prnu|paper speckle|speckle|crumpling|water soaking|printing or scribbling|3d printer|ecu |can bus|clock-skew|clock skew|clock-based|cpu clock|transmitter|wi-?fi ftm|fpga|optical fingerprint|driving-route|driver fingerprint|magnetometer|gyroscope|accelerometer|motion-sensor|sensor calibration|sensor fingerprint|acoustic|speaker, microphone|environmental fingerprint|remote gpu|gpu fingerprint|decoder fingerprint|model-specific image|camera fingerprint|paper|flash fingerprint|usb timing fingerprint|write-induced fingerprint|physical-layer fingerprint|temperature-induced fingerprint|peripheral timestamp|fingerprint temperature robustness|fingerprint aging)/i,
  ],

  // 3. Media content identification (Shazam-style).
  [
    'media-content',
    /\b(music-based|video fingerprint|song|content fingerprint)/i,
  ],

  // 4. Encrypted-traffic analysis — the *other* fingerprinting literature:
  //    inferring which page, site, or command a victim loaded.
  [
    'traffic-analysis',
    /\b(website|web site|web ?page|site-level fingerprintab|traffic|flow fingerprint|packet|netflow|sequence-number|ack fingerprint|connection-bucketing|keyword fingerprint|search-query|voice-command|streaming-command|alexa skill|command fingerprint|hidden.service|onion|\btor\b|relay fingerprint|openvpn|circumvention|cdnreaper|mobile-app fingerprinting over vpn|smart tv app|concurrent application|background activity|household fingerprintab|open-world|closed-world|defenseless|front-defended|domain-based|sensitive-site|phishing-site|google-resource|call-progress-tone|call-source|broadcast vulnerability|netflow-constrained|ip fingerprint|caching impact|encrypted mobile-app fingerprinting|ar\/vr standalone app fingerprinting|webxr app fingerprinting)/i,
  ],

  // 5. Off-web device and hardware identification: BLE/IoT devices, MAC
  //    randomisation, hardware tokens. Genuinely fingerprinting, genuinely not
  //    a browser.
  [
    'device-hardware',
    /\b(ble |bluetooth|iot|hardware fingerprint|device-signature|identical-model device|device tracking or fingerprinting|device and software fingerprint|mobile sensor|magnetic|wireless charging|dhcp|manufacturing batch|fingerprinting sdk|fingerprinting-signal exfiltration|permissionless android device fingerprinting|stable device fingerprinting)/i,
  ],

  // 6. Remote host and network-stack identification: TLS, OS, server,
  //    middlebox, censorship equipment. Adjacent to browser fingerprinting —
  //    a TLS fingerprint does identify a browser build — but the measurement
  //    target is a host, not a visitor.
  [
    'network-stack',
    /\b(tls|ja3|schannel|bsafe|rsa|rsalib|asn1|protocol fingerprint|middlebox|router|web-?server|libc|\bos fingerprint|operating-system fingerprint|remote os|http-response|tcp\/tls|tcp stack|malicious-server|server implementation|layered-server|multi-layer|ca side-channel|hidden-service server|dns software|filtering-tool|rp software|relying part|deep packet inspection|dpi behavioral fingerprint|dpi deployment fingerprint|dpi fingerprint|censorship injection fingerprint|honeypot fingerprint|tsc server-fingerprint|operator fingerprint|device and vendor fingerprint)/i,
  ],

  // 7. Malware/analysis-environment evasion: fingerprinting the sandbox.
  ['evasion-environment', /\b(sandbox|virtual machine|\bvm\b|analysis environment)/i],

  // 7b. LLM / model identification. New in 2025: identifying which model
  //     serves an endpoint. Its own family because it is a distinct literature
  //     that did not exist when this fold was written.
  ['llm-model', /\b(llm (version )?fingerprint|large language model|known-llm|left-out llm|fingerprinting query efficiency)/i],

  // 8. Browser / device fingerprinting on the web platform: the subject of
  //    privacy:fingerprinting. Named web APIs, or an explicit browser
  //    qualifier, or the fingerprinting *script* as the detection target.
  [
    'browser-device',
    /\b(canvas|webgl|audiocontext|web audio|audio api|font|screen|resolution|navigator|user-?agent|battery api|webrtc|css fingerprint|storage fingerprint|storage-side-effect|postmessage|global-variable|browser|fingerprintable api|fingerprintable? ?apis|api fingerprinting|api use by fingerprinter|javascript api|fingerprint-related api|fingerprinting api|fingerprinting script|fingerprinter|fingerprinting domains|entropy-based fingerprinting|fingerprinting detector|fingerprinting code reuse|fingerprinting obfuscation|fingerprinting-based cloaking|fingerprinting information sharing|collaborative fingerprinting|fingerprinting-generated cookies|tracking fingerprinting|commercial web fingerprinting|web fingerprint|fingerprinting-feature dependency|fingerprinting-enhanced cohort|cohort unicity|cloakx|bloat|extension|adblock|cross-browser|user-action-only|user perceptions of fingerprinting|fingerprinting intention|fingerprint trackability|filter-list fingerprinting|ad-blocker configuration fingerprinting|wallet fingerprinting|fingerprinting in local frames|fingerprinting-based ad tracking|fingerprinting-based http tracking|fingerprinting under privacy regulations|awareness of digital fingerprinting|acceptance of fingerprinting|concerns about fingerprinting|fingerprint attribute evasion|spatial fingerprint inconsistenc|temporal fingerprint inconsistenc|cloaking fingerprinting)/i,
  ],
];

// Property-only strings: a family cannot be read off them. Resolved by paper
// context in pass 2.
export const GENERIC =
  /^(?=.*fingerprint)(?!.*(?:website|canvas|browser|biometric)).*\b(stability|stable|uniqueness|unique|longevity|lifetime|persistence|survival|churn|evolution|change|over time|aging|robustness|fragility|discrimination|specificity|similarity|comparison|approximate|matching|collation|distribution|diversity|instability|degradation|reliability|errors|resistance|redundancy|correlation|attribute inference|randomi[sz]|defen[cs]e|blocked|harvest|cloak|cross-session|platform-specific|configuration-sensitive|cross-vendor|value fingerprinting|additive|identical|longitudinal|adversarial|harvest|sharing|leakage|churn)\b/i;

// Pass 3 — hand verification. Each entry was resolved by reading its
// `evidence.quote` and the paper title, and is keyed on (slug, phenomenon)
// with the reason. 14 entries were added on 2026-08-05 against the 4,322-paper
// corpus; 5 more on 2026-08-12 when the corpus grew to 5,859, for 19 in total.
// Anything still unresolved stays unmapped and is printed by the report. This
// table is the only place a human judgement overrides the rules, and it is
// deliberately small and enumerated.
export const HAND = new Map(
  [
    // → browser fingerprinting
    ['a-privacy-analysis-of-cross-device-tracking|device fingerprint uniqueness', ['browser-device', 'web+mobile browser fingerprints, entropy over browser attributes']],
    ['beyond-the-front-page-measuring-third-party-dynamics-in-the-field|device fingerprinting', ['browser-device', 'detected by searching for the Fingerprint2 JS library']],
    ['tales-of-favicons-and-caches-persistent-tracking-in-modern-browsers|fingerprint entropy', ['browser-device', 'entropy of immutable browser attributes, 16-24 bits']],
    ['your-drm-can-watch-you-too-exploring-the-privacy-implications-of-browsers-mis-im|Android Client ID fingerprint uniqueness', ['browser-device', 'browser DRM (Widevine) Client ID as a browser-reachable identifier']],
    ['your-drm-can-watch-you-too-exploring-the-privacy-implications-of-browsers-mis-im|Client ID fingerprint stability', ['browser-device', 'same identifier, longitudinal stability']],
    // → other families
    ['smudged-fingerprints-characterizing-and-improving-the-performance-of-web-applica|Real-world fingerprinting degradation', ['network-stack', 'identifies which web application software a remote host runs']],
    ['keeping-the-smart-home-private-with-smart-er-iot-traffic-shaping-sleeping-habits|Device fingerprinting', ['traffic-analysis', 'IoT devices identified from DNS queries and destination IPs']],
    ['voip-fraud-identifying-a-wolf-in-sheeps-clothing|Remote device fingerprinting', ['physical-forensic', 'clock skew estimated from SIP REGISTER timings']],
    ['flowprint-semi-supervised-mobile-app-fingerprinting-on-encrypted-network-traffic|longitudinal fingerprint robustness', ['traffic-analysis', 'mobile app identification from encrypted traffic']],
    ['flaw-label-exploiting-ipv6-flow-label|IPv6 flow-label device fingerprinting', ['network-stack', 'IPv6 stack implementation identified from flow-label behaviour']],
    ['ltrack-stealthy-tracking-of-mobile-phones-in-lte|phone fingerprinting', ['device-hardware', 'handset identified over the LTE radio link']],
    ['preventing-sim-box-fraud-using-device-model-fingerprinting|device-model fingerprint uniqueness', ['device-hardware', 'handset model identified from radio-layer configuration, no browser']],
    ['preventing-sim-box-fraud-using-device-model-fingerprinting|configuration-sensitive fingerprints', ['device-hardware', 'same paper, same radio-layer fingerprint']],
    ['evasion-attacks-and-defenses-on-smart-home-physical-event-verification|evasion-vulnerable physical fingerprints', ['physical-forensic', 'physical event signatures in a smart home']],
    // Added 2026-08-12 with the 2025–2026 corpus. Same rule as above: each was
    // resolved by reading the phenomenon against the paper title and quote.
    ['good-bot-bad-bot-characterizing-automated-browsing-activity|application fingerprinting', ['browser-device', 'identifies the browsing agent from its request behaviour — a browser-side fingerprint, not a server one']],
    ['device-fingerprinting-with-peripheral-timestamps|device fingerprinting', ['physical-forensic', 'clock-domain skew of USB/peripheral timestamps; hardware, reachable from JS but not a web API']],
    ['device-fingerprinting-with-peripheral-timestamps|user-device fingerprinting', ['physical-forensic', 'same paper, same hardware channel']],
    ['device-fingerprinting-with-peripheral-timestamps|fingerprint permanence', ['physical-forensic', 'same paper, longitudinal property of the same hardware channel']],
    ['mvpnalyzer-an-investigative-framework-for-auditing-the-security-privacy-of-mobile-vpns|tracking and fingerprinting', ['device-hardware', 'mobile VPN apps fingerprinting the handset; no browser involved']],
  ]
);

export function strongFamilyOf(phenomenon) {
  const s = String(phenomenon).toLowerCase();
  for (const [name, re] of STRONG) if (re.test(s)) return name;
  return null;
}

export function isGeneric(phenomenon) {
  return GENERIC.test(String(phenomenon));
}

// Classify every fingerprint-mentioning tuple of one paper. Returns an array of
// {phenomenon, family, resolvedBy} in tuple order.
export function classifyPaper(fpPhenomena, slug = '') {
  const first = fpPhenomena.map((s) => ({ phenomenon: s, family: strongFamilyOf(s) }));
  // Majority strong family in this paper wins the generics; ties broken by the
  // STRONG order above, which is the order of decreasing confidence.
  const votes = new Map();
  for (const t of first) if (t.family) votes.set(t.family, (votes.get(t.family) ?? 0) + 1);
  const order = STRONG.map(([n]) => n);
  const context =
    [...votes.entries()].sort((a, b) => b[1] - a[1] || order.indexOf(a[0]) - order.indexOf(b[0]))[0]?.[0] ?? null;
  return first.map((t) => {
    if (t.family) return { ...t, resolvedBy: 'string' };
    if (context) return { phenomenon: t.phenomenon, family: context, resolvedBy: 'paper-context' };
    const hand = HAND.get(`${slug}|${t.phenomenon}`);
    if (hand) return { phenomenon: t.phenomenon, family: hand[0], resolvedBy: 'hand', reason: hand[1] };
    return { phenomenon: t.phenomenon, family: 'unmapped', resolvedBy: 'none' };
  });
}

// Named-thing folding for fingerprinting tools and resources. Unlike
// name_fold.mjs (which canonicalises case and punctuation only) this merges
// synonyms and spellings. Ordered; first match wins.
export const TOOL_FAMILIES = [
  ['FingerprintJS', /fingerprint ?js|fingerprint ?2\b|fingerprintjs2|fp-?js|fpjs/i],
  ['FP-Inspector', /fp-?inspector/i],
  ['FPMON', /fp-?mon/i],
  ['FP-Scanner / FP-Collect', /fp-?scanner|fp-?collect/i],
  ['AmIUnique', /am ?i ?unique/i],
  ['Panopticlick / Cover Your Tracks', /panopticlick|cover ?your ?tracks/i],
  ['OpenWPM', /openwpm/i],
  ['Tracker Radar Collector', /tracker ?radar/i],
  ['Tor Browser', /tor browser/i],
  ['Brave', /^brave|brave browser|brave shields/i],
  ['Disconnect list', /disconnect/i],
  ['EasyList / EasyPrivacy', /easylist|easyprivacy/i],
  ['uBlock Origin', /ublock/i],
  ['Privacy Badger', /privacy ?badger/i],
  ['puppeteer-extra-plugin-stealth', /stealth/i],
];

export function toolFamilyOf(name) {
  const s = String(name);
  for (const [fam, re] of TOOL_FAMILIES) if (re.test(s)) return fam;
  return null;
}
</file>

The first section of that script's output, verbatim and unedited — the full run also prints the per-venue table, the crawl-configuration comparison and the 83-paper list:

<code>
corpus                                        5859 papers
detection fired at all                        5655 papers
phenomenon names a fingerprint                280 papers
only the technique does (excluded)             103 papers

## What "fingerprinting" means in this corpus

459 distinct free-text strings across 280 papers.

What was being fingerprinted               Papers  Share of 280  Distinct strings
-----------------------------------------  ------  ------------  ----------------
Website / traffic fingerprinting           105     37.5%         136
Browser fingerprinting (the web platform)  83      29.6%         156
Remote host & network-stack ID             38      13.6%         53
Physical-object & hardware forensics       28      10.0%         54
Human biometrics                           16      5.7%          24
Off-web device identification              13      4.6%          18
Media content identification               8       2.9%          11
unmapped                                   6       2.1%          7
Analysis-environment evasion               2       0.7%          4
LLM / model identification                 1       0.4%          4

Shares exceed 100%: 18 papers (6.4%) fall in more than one family.

Tuples: 544 total — 441 resolved by the string, 76 by paper context (property-only strings), 7 unresolved.
95 of 544 strings name only a property of a fingerprint, not its subject.

## Unmapped residue (printed in full)

7 tuples, 6 papers
  CCS/2011/bitshred-feature-hashing-malware-for-scalable-triage-and-semantic-analysis
      Fingerprint similarity approximation
  USENIX/2016/an-empirical-study-of-textual-key-fingerprint-representations
      Fingerprint comparison speed
  USENIX/2016/identifying-and-characterizing-sybils-in-the-tor-network
      Fingerprint changes
  CCS/2019/privacy-aspects-and-subliminal-channels-in-zcash
      value fingerprinting
  CCS/2019/privacy-aspects-and-subliminal-channels-in-zcash
      fingerprint survival
  USENIX/2025/shadows-in-cipher-spaces-exploiting-tweak-repetition-in-hardware-memory-encrypti
      Application page fingerprints
  NDSS/2026/snpeek-side-channel-analysis-for-privacy-applications-on-confidential-vms
      PHH fingerprinting leakage
</code>

==== Methodology and limitations of these figures ====

  * **Seven venues only**, 2010–2026, with 2025 and 2026 provisional. Which venues, which years, what each stage of the selection funnel costs and which venue-years are empty are on [[literature:corpus]] and are not restated here. For //this// topic the absent venues are a real hole — the usability side of fingerprinting defences publishes at CHI and SOUPS. Every claim here is a claim about those seven venues.
  * **One paper is double-counted.** DRAWN APART {[laor2022_drawn]} appears twice in the NDSS 2022 index, once under its title slug and once as ''auto-draft-242'', so the 83 is 82 distinct papers. Counts elsewhere on the page carry the same one-paper error. Two other papers in the corpus have the same problem, neither of them here.
  * **Silence is not absence.** "Does not state whether it ran headless" means the paper did not say. These are reporting figures, not practice figures.
  * **Field stability.** Enum fields (''platforms'', ''crawlConfig.*'', ''legal.law'') reproduce to within a few points on a repeat extraction and carry percentages here. ''detection.phenomenon'' does not, which is what the whole folding exercise is for — the family table is a set of rankings with an honest residue, not a measurement.
  * **The 83 is a floor.** A paper that studies fingerprinting without the extractor recording a fingerprint-named phenomenon is missing from it. 103 further papers name a fingerprint only in the ''technique'' field and were deliberately excluded, since "we detected X by fingerprinting the TLS stack" is a paper about X.
  * **Quotes were spot-checked.** ''%%scripts/quote_check.mjs --detection fingerprint%%'' verifies the evidence quotes behind this page in bulk against ''paper.cols.txt''; the results, and the ones that had to be read by hand, are on [[provenance:privacy:fingerprinting]]. The dataset's own "0.9% of quotes could not be located" figure was measured on the earlier 4,322-paper run and has not been re-measured.
  * **Every query behind this section, the report script and its unedited output** are on [[provenance:privacy:fingerprinting]]; corpus-level caveats are on [[literature:corpus]].

===== Defences, and What They Mean for Your Measurement =====

Browser defences matter here twice: as the object of study, and as a confound in your own crawl. There are only two strategies, and they are incompatible.

^ Browser ^ Strategy ^ What it actually does ^
| Tor Browser | **Uniformity** | Make every user identical. The design document is explicit that "striving for uniformity has generally proved to be a better strategy"; letterboxing rounds the content window to multiples of 200×100 px so screen size falls into buckets.((Tor Browser design document, [[https://2019.www.torproject.org/projects/torbrowser/design/|"Strategies for Defense: Randomization versus Uniformity"]]; current behaviour documented at [[https://support.torproject.org/anti-fingerprinting/|support.torproject.org/anti-fingerprinting]].)) |
| Brave | **Randomisation** ("farbling") | Slightly randomise semi-identifying API output, deterministically per **session per eTLD+1** — so one site sees a stable value within a session, different sites see different values, and next session everything moves.((Brave, [[https://brave.com/privacy-updates/4-fingerprinting-defenses-2.0/|"Fingerprinting Defenses 2.0"]].)) |
| Firefox | Both, separately | ''privacy.resistFingerprinting'' (RFP) is the older blanket Tor-Uplift approach, opt-in and site-breaking. Fingerprinting Protection (FPP, ''privacy.fingerprintingProtection'') is targeted per-API with granular overrides; Mozilla shipped it in Private Browsing and ETP Strict in 2025 and expanded it to Standard ETP in 2026.((Mozilla, [[https://blog.mozilla.org/en/firefox/fingerprinting-protections/|"Fingerprinting protections"]] (10 November 2025) and the [[https://www.firefox.com/en-US/firefox/153.0esr/releasenotes/|Firefox 153 ESR release notes]] (21 July 2026).)) |
| Safari / WebKit | Reduce the surface | WebKit's tracking-prevention policy treats fingerprinting as something to prevent or limit; concretely, only web fonts and OS-bundled fonts are exposed (not user-installed ones), plug-in support was removed, and the UA string changes only with marketing version.((WebKit, [[https://webkit.org/tracking-prevention-policy/|Tracking Prevention Policy]] and [[https://webkit.org/tracking-prevention/|Tracking Prevention]].)) |
| Chrome | Reduce the surface; entropy budget abandoned | User-Agent reduction and User-Agent Client Hints shipped from 2022: the UA string is frozen and detail is available only via an opt-in ''Accept-CH'' request. The **Privacy Budget** proposal — capping total entropy exposed per site — was never implemented and is archived.((Google, [[https://privacysandbox.google.com/protections/user-agent|User-Agent reduction]]; and [[https://privacysandbox.google.com/protections/privacy-budget|Privacy Budget]]: "The Privacy Budget proposal is no longer active and the following content has been archived.")) |

Two implications for a study design:

  - **Uniformity and randomisation are measured differently.** Against a uniformity defence you measure //how many users share a bucket//; against farbling you measure //whether values are linkable across sessions//. A protocol written for one gives a meaningless answer against the other, and this is a common flaw in defence comparisons.
  - **Your own crawler's browser is a defence configuration.** A 2026 Firefox with FPP on by default in Standard mode is not the browser that older papers measured with. State the browser, the version, and the fingerprinting-protection settings — the 21.9% of crawling papers in the corpus that state statefulness are ahead of the field, and fingerprinting-protection state is reported even less often than that.

==== The 2025 policy reversal ====

<WRAP important>
On 18 December 2024 Google notified users of its advertising products that **from 16 February 2025 it would no longer prohibit them from employing fingerprinting techniques**. The UK Information Commissioner's Office responded the next day: //"We think this change is irresponsible"//, quoting Google's own 2019 position on fingerprinting back at it — //"We think this subverts user choice and is wrong."//((UK Information Commissioner's Office, [[https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2024/12/our-response-to-google-s-policy-change-on-fingerprinting/|"Our response to Google's policy change on fingerprinting"]], 19 December 2024. Verified against the ICO page directly on 2026-08-05.))

For a measurement researcher this is arguably the most consequential change in the topic since GDPR. Prevalence figures from before February 2025 describe a web in which the largest ad platform contractually forbade the technique //to its own advertising customers//; anything you measure after it does not. The policy never bound the whole web, which is why the pre-reversal figures on this page are not a baseline of "fingerprinting while prohibited" — they are a baseline of the web as it was.

**The first post-reversal measurement in these seven venues has now landed.** Luo et al. {[luo2025_canvassing]} crawled the Tranco top 20K and a random tail sample **in May 2025**, three months after the change, and found canvas fingerprinting on **12.7% of 16,276 popular sites and 9.9% of 17,260 tail sites**. That is one technique on one crawl, and it is not a before/after comparison — nobody has run the same instrument on both sides of the date. But the page can no longer say the post-reversal web is unmeasured, and a pre/post study now has a published post-side baseline to work against.
</WRAP>

===== Practical Tooling =====

==== Detecting fingerprinting in a crawl ====

Pick by question, not by citation count. The table above ranks what the literature //used// over sixteen years; what follows is what each instrument is good for now.

  * **[[https://github.com/openwpm/OpenWPM|OpenWPM]]** — the most-cited instrumented crawler (15 of the 83 papers), and still the right default for **request- and cookie-level** work. Two caveats before you adopt it for fingerprinting specifically. It is **Firefox-only** and each release pins one unbranded Firefox build (v0.35.0, June 2026, ships Firefox 152), so its browser is neither a current Chrome nor whatever your reader runs — state the OpenWPM version //and// the Firefox version, because the pin is a default you can override. More important: ''js_instrument=True'' does not mean "instrument JavaScript", it means the fixed ''collection_fingerprinting'' list of 14 objects, whose contents have not changed since 2020 and which covers **neither ''WebGLRenderingContext'' nor ''document.fonts''**, and reads ''window.screen'' only for ''colorDepth'' and ''pixelDepth''. Three of the surfaces in this page's own table — WebGL, fonts, screen — leave no row by default. Write your own ''js_instrument_settings'' and say which APIs it covered. [[Programming:Crawler:OpenWPM]] has the version-to-Firefox map and the rest of the defaults.
  * **[[https://github.com/wspr-ncsu/visiblev8|VisibleV8]]** — a patched V8 that logs API accesses **from inside the JavaScript engine** — //"a custom variant of the V8 JavaScript engine that logs all JavaScript API calls and their arguments to a trace log"//, shipped as a patchset over Chromium((''README.md'' of [[https://github.com/wspr-ncsu/visiblev8|wspr-ncsu/visiblev8]], read 2026-09-03. Repository active (last push 2026-07-15); release tags name the Chromium version they patch, most recently the 138.x series.)) — so there is no in-page instrumentation for a script to detect or for a bundler to miss. It is the newest of the three lineages here and the only one still tracking Chrome releases (tags follow Chrome 138 as of 2026-07). It is invisible in the tool table above because the fold dropped it, yet **5 of the 83 papers use it** — more than FP-Inspector or AmIUnique — from extension fingerprinting in 2021, through the automatic discovery of emerging techniques {[su2023_automatic]}, to a 2026 NDSS mobile-tracking study. If your question is //which APIs did this script actually touch//, this is the current answer, and [[Programming:Crawler:PanoptiChrome]] builds taint tracking on top of it.
  * **[[https://github.com/uiowa-irl/FP-Inspector|FP-Inspector]]** {[iqbal2021_fingerprinting]} — the most-used purpose-built classifier in the corpus (4 papers). Treat it as a **research artifact frozen at its 2021 paper**, not a maintained tool: useful for its classifier, feature set and labelled script list; expect to port it.
  * **[[https://github.com/duckduckgo/tracker-radar-collector|DuckDuckGo Tracker Radar Collector]]** — a lighter Puppeteer-based collector with an API-access collector built in; 6 papers, and the instrument behind the one post-reversal measurement this page cites {[luo2025_canvassing]}. Chromium, so it is the natural pair to OpenWPM's Firefox. See [[Programming:Crawler:Tracker radar collector]].
  * **Filter lists** — EasyPrivacy and Disconnect are what most papers actually use for ground truth. Read the caveat above before you do the same, and see [[Privacy:Requests]] for how to apply them in post-processing rather than during the crawl.

==== Measuring your own browser (and your crawler) ====

Run these against your crawler before you trust it, not just against your laptop:

  * **[[https://coveryourtracks.eff.org/|EFF Cover Your Tracks]]** — the successor to Panopticlick; reports bits of identifying information per attribute and whether your browser has a unique fingerprint among its sample.
  * **[[https://amiunique.org/|AmIUnique]]** — the research platform behind several of the papers above (Univ. Lille); shows your attribute vector and its rarity in their dataset.
  * **[[https://browserleaks.com/|BrowserLeaks]]** — per-surface test pages (canvas, WebGL, fonts, WebRTC, TLS/JA3–JA4, IP). The most useful for isolating //which// surface changed after a configuration change.
  * **[[https://abrahamjuliot.github.io/creepjs/|CreepJS]]** — aggressive detection of lies and inconsistencies: it is the closest public analogue to FP-Scanner {[vastel2018_scanner]} and the fastest way to discover that your stealth plugin is making you //more// identifiable.
  * **[[https://fpmon.github.io/fingerprinting-monitor/|FPMON]]** — a browser extension that reports, in real time, which fingerprinting-relevant APIs the current page touched. Handy for a spot check on a site your pipeline flagged.
  * **[[https://github.com/fingerprintjs/fingerprintjs|FingerprintJS]]** — the open-source library, used as a positive control by 14 of the 83 papers. Licence history matters if you vendor it: MIT, then Business Source License 1.1 for the 4.x series, back to MIT from 5.0.0 (current npm release 5.2.0, MIT, checked 2026-08-05). The hosted **Fingerprint Pro** product is separate and proprietary.

==== Datasets you can start from ====

36 of the 83 papers (43.4%) reanalyse an existing dataset rather than crawling. These are the ones worth knowing about before you build a crawl:

  * **[[https://github.com/duckduckgo/tracker-radar|DuckDuckGo Tracker Radar]]** — the //dataset//, as distinct from the Collector above. One JSON file per third-party domain, carrying a ''fingerprinting'' likelihood score, the ''prevalence'' of the domain across crawled sites, and — per resource — an ''apis'' list of //"browser APIs accessed by this resource which are commonly used in fingerprinting"//. That last field is the useful one: it is a public, per-resource record of which fingerprinting surfaces a given script touched, which is exactly the ground truth most papers hand-build. CC BY-NC-SA 4.0, so check the licence against your use.((Field definitions from ''docs/DATA_MODEL.md'', licence from ''README.md'', both in [[https://github.com/duckduckgo/tracker-radar|duckduckgo/tracker-radar]], read 2026-09-03. Sampled values of ''fingerprinting'' on 2026-09-03: doubleclick.net 3, cloudflare.com 2, facebook.net 2, criteo.com 1.))
  * **Disconnect's fingerprinting categories** — ''FingerprintingInvasive'' (281 domains) and ''FingerprintingGeneral'' (96), in the same file Firefox ships. A domain-level label, not a script-level one, and an editorial judgement rather than a measurement — but it is the label 13 of these papers are implicitly using.
  * **FP-Inspector's labelled script list** {[iqbal2021_fingerprinting]} — the closest thing the field has to a published fingerprinting-script ground truth, frozen at 2021. Useful as a //seed// and as a comparison point; not usable as a current label set, because the scripts have moved.
  * **The papers' own artifacts.** 92.8% of the 83 released an artifact link — the highest-value fact on this page. Before you build a crawl, check whether the study you are extending published its script list, its API traces, or its classifier.

<WRAP tip>
None of these is a benchmark. There is no fixed site sample with hand-labelled fingerprinting ground truth that papers compete on, the way ad-blocking research has filter lists — which is why the prevalence figures above are incomparable, and why this is still an open problem rather than a solved one.
</WRAP>

==== A crawler self-check you should run ====

Anything that makes your crawler distinguishable from a browser also makes it a target for cloaking. Check at minimum:

  - ''navigator.webdriver'' — true under Selenium and plain Playwright/Puppeteer; a two-line tell.
  - Headless-specific values: empty ''navigator.plugins'', missing ''window.chrome'', ''HeadlessChrome'' in the UA string, a Google/SwiftShader WebGL vendor string instead of the host GPU's.
  - Font set and canvas hash from //inside// the container, which is usually a Docker image with a minimal font list and software rendering — a highly distinctive combination.
  - Whether the fingerprinting scripts you detected are the same set a **real user session** on the same page loads. Both measurements of this gap — FP-Fed's top-300 manual crawl {[annamalai2024_fpfed]} and Annamalai et al.'s 471-site comparison {[annamalai2025_beyond]} — vary interaction, login and consent together, not headless against headful, so they bound the gap without attributing it.

''puppeteer-extra-plugin-stealth'' patches many of the obvious tells and appears in two corpus papers. Do not treat it as a solution: CreepJS and FP-Scanner-style consistency checks defeat it, and a partially-patched browser occupies an anonymity set of one. If detectability matters to your result, **measure it and report it** rather than assuming it away.

===== Open Questions =====

<WRAP todo>
  * No **pre/post comparison** across Google's 16 February 2025 policy change. Luo et al. {[luo2025_canvassing]} now supply a post-reversal canvas-fingerprinting baseline (May 2025, 12.7% of the top 20K), so what is missing is the same instrument run on both sides of the date rather than any measurement at all. The pre-side baseline data (FP-Radar, FP-Inspector) is public.
  * **Partly answered since this page was written.** Annamalai et al. {[annamalai2025_beyond]} compared real user sessions against an automated crawl of the same sites and found the crawl missed **211 of 471 fingerprinting websites (45%)** — the first size for this gap //at scale//, after FP-Fed's top-300 pilot {[annamalai2024_fpfed]} put it at 3×. What is still open is the narrower question: how much of that 45% is //headless versus headful// as opposed to interaction depth, authentication and consent, which the paper attributes it to. Neither study varies one factor at a time, so nobody has isolated the cost of headlessness alone.
  * Prevalence figures are incomparable across papers because unit, rank cut and definition all vary. A shared benchmark — a fixed site sample with hand-labelled ground truth — does not exist for fingerprinting the way EasyList serves ad-blocking research.
  * Consent and fingerprinting: only 10 of 83 papers touch a law. The obvious experiment has **already been run** — Papadogiannakis et al. {[papadogiannakis2021_user]} crawled each CMP-bearing site three times, once per consent action, and of the **27,180 sites they reached successfully under all three**, 279 fingerprinted with no action taken, 285 after //Reject All// and 330 after //Accept All//, with 247 fingerprinting under all three conditions. Their conclusion is that //"the action of the user has no significant impact on the websites' fingerprinting operations"//. What is open is the **post-2025 repeat** of that design, and whether any signal a user can send — a CMP rejection, Global Privacy Control, an ePrivacy-style refusal — is honoured by fingerprinting scripts specifically. See [[Privacy:Consent]] for the CMP interaction half.
  * Usability of fingerprinting defences is **thin** here rather than absent: the 83 include a PETS 2026 study of public awareness and perception of fingerprinting and Berke et al.'s demographics work {[berke2025_demographics]}, but the venues where this subject mostly publishes — CHI and SOUPS — are outside the corpus. Someone with access should extend the [[#What the Word Means in the Literature]] analysis to those venues before concluding anything about how much of it exists.
</WRAP>

===== Related Pages =====

  * [[Privacy:Cookies]] — the stateful counterpart; fingerprinting and cookies are used together, and respawning links them directly {[fouad2022_cookie]}.
  * [[Privacy:JavaScript]] — classifying the scripts that 39.8% of these papers are actually detecting.
  * [[Privacy:Requests]] — the filter lists that most of this literature uses as ground truth, and why that is a compromise.
  * [[Privacy:Consent]] — the open compliance question: a technique with no refusal mechanism.
  * [[Design:Website classification]] — where fingerprinting sits in the wider classification taxonomy.
  * [[Programming:Crawler:OpenWPM]] and [[Programming:Crawler:Tracker radar collector]] — the two instrumented crawlers this page depends on.
  * [[Programming:Stateful stateless]] — only 36.8% of these papers state it, and for fingerprinting it changes what you see.
  * [[Design:Crawling location]] — the other axis a fingerprinting crawl is judged on.
  * [[Statistics:Biases]] — why a uniqueness percentage is a property of your sample.

====== References ======

/*
To insert citations:

  - Check the BibTeX entry exists in https://measuretheweb.org/literature/bibliography, add it there if not.
  - Use {[CitationKey]} in the text; it renders as a numbered reference.
  - Keep this section unchanged to print the bibliography.

If any step fails, a purple warning appears on the page.
*/

<bibtex bibliography></bibtex>


/* This enables discussion under this article. */
~~DISCUSSION~~