Fingerprinting
Date: 2026-08-17
Identifying a browser from the characteristics it exposes, without storing anything on the device. It survives cookie deletion, private browsing and storage partitioning — which is exactly why browsers are actively reducing the surface, and why using it deliberately for tracking is both technically fragile and a regulatory problem.
Browser fingerprinting is identifying a browser by combining attributes it exposes — user agent, screen, fonts, rendering quirks — into a value stable enough to recognise it across visits.
How it works
No single signal identifies anyone. The combination does.
signal rough entropy
user agent string ~10 bits
screen resolution + colour depth ~5
timezone ~3
language + locale list ~5
installed fonts ~15 ← historically the richest
canvas rendering hash ~10 ← GPU and driver differences
audio processing hash ~6
hardware concurrency ~3
platform, touch support ~3
─────
~60 bits combined
In plain terms: around 33 bits of entropy is enough to single out one person among roughly 8 billion. A naive combination of common browser signals used to exceed that comfortably — which is the entire problem.
Canvas fingerprinting is the classic technique: draw text and shapes to an off-screen canvas, read the pixels back, hash them. Tiny differences in GPU, driver, font rasterisation and anti-aliasing make the hash stable per device and different across devices.
What browsers are doing about it
The reduction programme runs in three directions:
FREEZE / REDUCE user agent strings frozen or trimmed
platform details generalised
Browser Privacy Restrictions
RANDOMISE canvas and audio readback noised per site
per session, so the hash isn't stable
GATE font enumeration restricted to system fonts
some APIs behind permission or user gesture
— Permissions and User Gestures
Gating in particular now leans on the same activation model as any other privileged API — Permissions and User Gestures.
Entropy has fallen substantially and unevenly. Safari and Firefox have been most aggressive; Chromium reduces some surfaces and preserves others via negotiated APIs like client hints.
[CHECK: which specific protections are active per browser, and their current scope — this has changed repeatedly and any claim about today’s state needs verifying against vendor documentation.]
Passive versus active
A distinction worth having, because they carry different risk:
PASSIVE information sent anyway with every request
user agent, Accept headers, IP address, TLS characteristics
← you cannot avoid receiving these
ACTIVE information you must run code to collect
canvas hashing, font enumeration, audio context,
hardware probing
← this is what "fingerprinting" means in a
regulatory context
Receiving a user agent string isn’t fingerprinting. Combining twelve signals into a stable identifier is. The line is intent and combination, not any individual data point.
The legitimate uses
Fingerprinting-adjacent techniques have genuine defensive applications, and it’s worth being precise about which:
- Fraud and bot detection. Recognising that 400 “different” customers share one device signature is a real signal, and it’s the main defensible use — Bot and Internal Traffic
- Account takeover detection — flagging a login from a device profile never seen on that account
- Rate limiting where IP is inadequate — though this is weak, and easily wrong behind corporate networks — Rate Limiting
- Bot filtering in analytics, at a coarse level — Sample Pollution
All of these are risk signals, not identifiers. The defensible version scores a session; the indefensible version builds a persistent profile.
The compliance position
This is where it gets sharp, and the distinction most people miss:
Fingerprinting requires consent under PECR — the Privacy and Electronic Communications Regulations — on the same basis as cookies. The regulation covers storing or accessing information on a user’s device, and reading device characteristics to build an identifier is accessing information. You cannot avoid the consent requirement by not setting a cookie, which is precisely the reason some vendors present fingerprinting as a “cookieless” alternative — and that framing is wrong — UK GDPR and PECR for Analytics, Legitimate Interest vs Consent.
The strictly-necessary exemption plausibly covers fraud prevention on a payment flow. It does not cover analytics or advertising.
A resulting fingerprint is personal data. It identifies a person, so it carries a lawful basis requirement, a retention period, and subject access and deletion rights — with the practical difficulty that a fingerprint has no straightforward way to be looked up or erased on request — Pseudonymisation and Anonymisation.
Why it’s a bad foundation regardless
Even setting the compliance question aside, it’s a poor engineering bet:
- Unstable. A browser update, a new monitor, a driver change or an OS font update changes the fingerprint. Match rates degrade continuously
- Actively targeted. Every browser vendor is working to break it, so anything built on it needs perpetual maintenance against people trying to defeat it
- Collides. Corporate fleets with identical hardware and locked-down configuration produce identical fingerprints across thousands of users — so it both over-identifies and under-identifies, in the same dataset
- Undetectable when wrong, which makes debugging an attribution or fraud problem built on it very hard
For measurement, the durable answers are first-party identity where consented, and aggregate or experimental methods where not — Privacy-Preserving Measurement, Incrementality Testing, Marketing Mix Modelling.
Where it interacts
- Browser Privacy Restrictions — the programme reducing this surface
- Storage Partitioning — closing the storage route is what pushed tracking towards fingerprinting, and why browsers moved on both
- Cross-Device Tracking — probabilistic matching leans on these signals, and degrades for the same reasons
- Common Vulnerabilities — the fraud-detection use, where the same techniques are defensive