Browser Fingerprinting and Consent: A Publisher's Guide to a Tracking Technique Regulators Are Watching
For most of the cookie-era discussion of online tracking, the technical surface that mattered was the storage layer: cookies in the browser, localStorage entries, IndexedDB databases, the things a developer could see and a regulator could point at. Fingerprinting works differently. It does not ask the browser to store anything. Instead, it asks the browser questions — what fonts do you have installed, what does this canvas render look like, how does the audio context process this signal — and combines the answers into an identifier that persists across sessions, devices, and even private browsing windows. For publishers and ad-tech vendors, fingerprinting has been an attractive way around third-party cookie deprecation. For regulators, it has become one of the most aggressively pursued tracking techniques because, by design, it identifies users without their cooperation. The CNIL, the EDPB, the UK ICO, and the Italian Garante have all issued enforcement decisions or guidance specifically targeting fingerprinting in the last 24 months. This guide walks through what fingerprinting actually is, what counts as fingerprinting under the law, and how a publisher should handle it inside a consent management framework.
What Browser Fingerprinting Is
A browser fingerprint is a high-entropy identifier built from properties the browser exposes to any running JavaScript. The base techniques split into several families, each of which contributes entropy to the combined fingerprint.
Canvas fingerprinting
The HTML5 canvas element renders graphics in slightly different ways depending on the underlying GPU, driver, operating system, and font subsystem. Drawing a fixed string with a specific font, then hashing the resulting pixel data, produces an identifier that varies across devices but is stable across sessions on the same device. Canvas fingerprinting is the canonical example and the most cited technique in enforcement actions.
Audio fingerprinting
The AudioContext API processes audio signals through the same kind of hardware-and-software pipeline as graphics, and the resulting output varies in a way that creates entropy. Running a known oscillator through a compressor and hashing the result produces a stable per-device identifier.
Font enumeration
Different operating systems and user profiles have different sets of fonts installed. Probing for the presence or absence of fonts — by measuring text metrics for a list of candidate fonts — produces an identifier that is particularly distinguishing for users who have customized their font set.
WebGL fingerprinting
WebGL exposes GPU capabilities and rendering behavior. The combination of vendor string, renderer string, and rendering of a fixed scene produces another high-entropy identifier.
Network and device metadata
Beyond the active probing techniques, fingerprints typically incorporate passive metadata: User-Agent string, language preferences, timezone, screen resolution, color depth, available memory, available processors, battery state, and TLS fingerprint at the connection layer. Each item adds entropy on its own and combines multiplicatively with the others.
How Regulators Treat Fingerprinting
The legal analysis is straightforward in outline but harder in practice. Fingerprinting that identifies a user produces personal data under the GDPR's definition, and reading or accessing information already stored on a device falls under Article 5(3) of the ePrivacy Directive — the same provision that governs cookies. Both Article 5(3) and the GDPR require prior consent for non-essential tracking. Where the law moves beyond cookies is that ePrivacy 5(3) covers "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user" — language broad enough to cover the device-state probing that fingerprinting depends on.
The EDPB confirmed this reading in its 2023 guidelines on the application of Article 5(3) to non-cookie tracking, and the CNIL has been the most aggressive enforcer: a number of fines in 2024 cited fingerprinting libraries operating before consent as a primary violation. The UK ICO's 2024 statement on tracking is even more direct in framing canvas, audio, and similar fingerprints as requiring opt-in consent on equal footing with cookies.
The Gray Area: Fraud Prevention vs Tracking
The most contested fingerprinting use case is fraud prevention. Bot-detection, account-takeover defense, and payment-fraud screening all rely on device fingerprinting as a core signal. Regulators have acknowledged that some of this processing can be justified under legitimate interest rather than consent — but the bar is high and the scope is narrow. The CNIL's position, echoed by other DPAs, is that:
- Strictly necessary fraud prevention on first-party properties may proceed under legitimate interest, with appropriate documentation in a legitimate interest assessment (LIA).
- Behavioral or advertising use of the same fingerprint requires consent and cannot ride on the fraud-prevention basis.
- Sharing the fingerprint with third parties for any purpose typically falls outside the legitimate interest scope and requires consent.
- Persistent storage of the fingerprint beyond the immediate fraud check generally requires either consent or a very tightly drafted legitimate interest position.
The practical implication is that a publisher running both fraud-prevention fingerprinting and ad-tech fingerprinting cannot rely on the fraud basis to cover both. The two flows must be architecturally separate, with the ad-tech flow gated behind consent and the fraud-prevention flow constrained to its documented purpose.
How to Handle Fingerprinting in a CMP
The integration pattern for fingerprinting is similar to other tracking techniques but with additional care because the absence of obvious storage makes the consent boundary easier to miss.
1. Inventory the fingerprinting surface
Audit the site for any script that calls canvas toDataURL(), AudioContext-based processing, font probing through text-metric measurement, or WebGL renderer queries. These calls are often buried in third-party libraries — ad-tech SDKs, anti-fraud vendors, A/B testing tools — and not immediately visible.
2. Categorize each fingerprinting use
For each library that fingerprints, document whether it is (a) strictly necessary for the site to function, (b) a fraud-prevention measure under legitimate interest, or (c) for tracking, analytics, or advertising. Categories (a) and (b) may proceed without explicit consent under documented bases; category (c) requires opt-in.
3. Gate the tracking-purpose fingerprinting
For libraries falling under category (c), the CMP should treat them identically to marketing cookies: the script is in the DOM but inert until the visitor accepts the marketing category. Most modern CMPs already support this via the standard type="text/plain" + category-attribute pattern.
4. Document the legitimate interest basis for fraud-prevention fingerprinting
Where fingerprinting proceeds under legitimate interest, the LIA must be specific, current, and reflect the actual processing scope. Generic "fraud prevention" is not enough — the LIA needs to identify what data is processed, how long it is retained, what protections apply, and what the user's realistic expectations are.
5. Provide a meaningful opt-out for legitimate interest flows
Even where fraud-prevention fingerprinting proceeds without consent, the GDPR's Article 21 grants the user the right to object to legitimate-interest processing. The CMP must surface this right, and the technical implementation must actually stop the fingerprinting when the right is exercised — not just record the objection while continuing to fingerprint.
Audit Checklist
Six concrete questions to answer for any site potentially exposing fingerprinting surfaces.
1. Inventory completeness
Has the security team produced a current list of every library that performs canvas, audio, font, WebGL, or device-metadata probing? If the answer is "we are not sure", the audit cannot proceed.
2. Basis classification
For each library, is there a documented lawful basis (consent, legitimate interest with LIA, contractual necessity)? Undocumented bases are de facto absent under accountability.
3. Consent gating
Are tracking-purpose fingerprinting libraries gated behind the marketing consent category, with the script unable to run before acceptance?
4. LIA freshness
Are the legitimate interest assessments dated within the last 12 months, and do they reflect the actual current processing scope rather than legacy descriptions?
5. Opt-out enforcement
When a user exercises Article 21, does the system actually stop the legitimate-interest fingerprinting, or only record the objection?
6. Cross-vendor cleanup
If a fingerprint is shared with a third party (an ad network, an attribution provider, an identity vendor), is that sharing covered by a separate consent and disclosed in the privacy notice?
Where Fingerprinting Sits in the Future of Tracking
Browser vendors are actively working to reduce the entropy available to fingerprinting libraries. Apple's ITP, Firefox's built-in protection, and Google's Privacy Sandbox proposals all chip away at the underlying surface. None of those interventions remove the regulatory issue, however — even a fingerprint with reduced entropy is still personal data when it succeeds in identifying a user, and reducing the success rate does not change the legal analysis when it works. For publishers, the safer assumption is that fingerprinting will continue to be a real, audit-relevant technique for the next 24 months, that regulators will continue to view it as equivalent to cookies for consent purposes, and that the right operational answer is to treat fingerprinting like any other tracking surface: inventoried, categorized by purpose, gated by consent where required, and documented thoroughly where it proceeds under another basis.