Browser fingerprinting has quietly replaced cookies as the default tracking method

Third-party cookies were supposed to die years ago. Apple's Safari blocked them by default back in 2019-2020 with Intelligent Tracking Prevention, Firefox's Enhanced Tracking Protection followed the same year, and Google spent from 2020 to 2024 promising to phase them out of Chrome entirely — before reversing course in July 2024 and announcing it would keep third-party cookies and instead offer users a choice prompt. None of this stopped cross-site tracking. It just moved the tracking to a technique that the legal frameworks built around cookies were never designed to catch: browser fingerprinting.

That's the quiet shift worth understanding: on roughly half the browser market — Safari and Firefox combined — cross-site cookie tracking has been dead for years, and tracking didn't stop, it migrated to reading signals the browser already exposes rather than writing an identifier to it. Consent frameworks built on "cookies require permission" don't map cleanly onto a technique that never stores anything on the device in the first place.

What fingerprinting actually reads

Canvas fingerprinting renders a hidden graphic using the browser's Canvas API and reads back the resulting pixels; tiny differences in GPU, driver, and font-rendering stacks produce a near-unique output hash across devices. WebGL fingerprinting does something similar by querying the GPU renderer string and supported extensions. AudioContext fingerprinting plays an inaudible tone through the Web Audio API and measures minute floating-point differences in the output waveform caused by hardware and OS differences.

None of these require storing anything. Combine canvas, WebGL, and audio signals with font enumeration, screen resolution, timezone, and installed browser extensions, and the EFF's Cover Your Tracks project (the successor to Panopticlick) has repeatedly found that the overwhelming majority of tested browsers produce a fingerprint unique or near-unique among everyone else tested — enough to track a user across sites without ever touching a cookie.

Ironically, Chrome's own privacy-motivated User-Agent reduction — replacing the old free-text User-Agent string with structured Client Hints — made some fingerprinting signals cleaner and more consistent to read, rather than messier. And network-level techniques compound the browser-level ones: CNAME cloaking disguises a third-party tracking request as a first-party subdomain request, slipping past tracker-blocklist tools that only check the visible domain.

The legal gray zone, explained

The EU's ePrivacy Directive, Article 5(3), requires consent for "storing or gaining access to information already stored" on a user's device. That language was written with cookies in mind — a cookie writes an identifier to storage, and that writing is the act requiring consent. Fingerprinting doesn't write anything; it reads signals the browser already exposes to any page that asks. For years, that created a genuine argument that fingerprinting sat outside the literal scope of cookie-consent law.

France's CNIL closed part of that gap in 2020 guidance, stating explicitly that fingerprinting falls under Article 5(3) because "gaining access to information" covers reading existing signals, not just writing new ones — so consent is required regardless. The UK's ICO has issued similar guidance. But stated legal scope and actual enforcement are different things: proving that a specific canvas or audio API call was used for tracking, as opposed to legitimate bot-detection or fraud-prevention, is a technical forensics problem regulators are not well equipped to solve at scale, and enforcement actions specifically targeting fingerprinting remain rare compared to cookie-consent-banner violations.

There's also a framing loophole that's arguably bigger than the legal gray zone: companies like Fingerprint (formerly FingerprintJS), Seon, Arkose Labs, and TransUnion's iovation market the exact same signal collection as "fraud prevention" rather than "tracking." Fraud-prevention framing sits closer to a legitimate-interest legal basis that doesn't require the same consent flow as advertising — even when a fingerprint originally computed for fraud scoring gets reused downstream for ad attribution.

What this means for cookie consent banners

The practical consequence is that cookie consent banners — the thing most users now associate with "privacy compliance" — do nothing against fingerprinting-based tracking. A site can run a fully compliant cookie banner, reject all non-essential cookies by default, and still fingerprint every visitor through canvas and audio signals that the banner never mentions, because the banner's entire legal and technical framing is cookie-specific.

Google's own attempted replacement — the Privacy Sandbox APIs (Topics API for interest-based ad targeting, Protected Audience for remarketing, Attribution Reporting for conversion measurement) — is a genuine attempt at a non-fingerprinting alternative, built around aggregated, on-device computation instead of raw signal collection. Adoption has been slow and contested by ad-tech companies who argue it favors Google's own ad business, and it only applies within Chrome in any case — it does nothing for Safari or Firefox users, and does nothing about non-advertising fingerprinting uses like fraud scoring.

What to actually do about it

If you run a website: know what your analytics, fraud-prevention, and ad-tech vendors are actually collecting. "We don't use tracking cookies" is not the same claim as "we don't fingerprint," and regulators increasingly expect you to be able to answer both. If a vendor's documentation doesn't explicitly address canvas, WebGL, or audio fingerprinting, ask them directly — CNIL's 2020 guidance means the answer has legal weight in the EU regardless of what your cookie banner says.

If you're a developer building anti-fraud tooling, disclose fingerprinting-based signals to users explicitly rather than relying on a generic cookie banner to cover it — the gap between "fraud prevention" framing and actual ad-tracking reuse of the same signal is exactly where enforcement is heading next.

If you're a privacy-conscious user, cookie settings alone do not protect you. Brave's "farbling" (randomizing fingerprint-relevant API outputs per site) and Tor Browser's letterboxing and canvas-randomization are the only consistent countermeasures currently available, because there is no consent toggle for a technique that doesn't require your permission to begin with.