Google Reversed Its Fingerprinting Ban: What Developers Need to Know
In February 2025, Google lifted its own ban on device fingerprinting. Here is what changed, why regulators are alarmed, and what it means for your analytics stack.
In February 2025, Google quietly updated its advertising policies to allow device fingerprinting — the same technique it had publicly condemned as "wrong" in 2019. The change took effect on February 16, 2025, and has significant consequences for anyone building analytics, running a web property, or relying on Google's ad infrastructure.
What fingerprinting actually is
Device fingerprinting is the practice of combining multiple passive signals from a browser or device to construct a persistent identifier. No cookie is set. No localStorage entry is written. The user is never prompted. The signals used include:
- IP address and network metadata
- Operating system and browser version
- Screen resolution and color depth
- Installed fonts and available codecs
- Language, time zone, and battery status
Individually, none of these is a unique identifier. Combined, they produce a fingerprint accurate enough to re-identify the same device across sessions, even after cookies are cleared and even in private browsing mode. Unlike cookies, there is no mechanism for a user to delete a fingerprint.
What Google's policy said — and what changed
Google's 2019 position was explicit: fingerprinting "subverts user choice and is wrong" because it operates outside standard browser privacy controls. The policy prohibited advertisers from using fingerprinting in Google ad products.
The February 2025 update removed that prohibition. Google's framing was procedural — the update was described as a routine policy revision — but the substance was a reversal. Advertisers may now use device-level identifiers including IP address, screen size, time zone, battery status, and user agent strings for targeting and measurement without any requirement to obtain user consent or disclose the practice.
The regulatory reaction
The UK's Information Commissioner's Office responded immediately. Stephen Almond, the ICO's executive director of regulatory risk, called the move "irresponsible" and made the regulatory position clear: fingerprinting is subject to the same consent requirements as cookies under PECR (the Privacy and Electronic Communications Regulations).
The ICO's reasoning is technically precise. PECR defines a consent trigger as "storing information, or accessing information stored, on a device." Fingerprinting accesses information from the device — it reads values from the browser environment — which means the consent requirement applies regardless of whether a cookie file is written. The mechanism of access is what matters, not the persistence format.
Under GDPR, the same data subjects who can request erasure of a cookie-based profile have no comparable mechanism for a fingerprint-derived profile. You cannot delete a fingerprint from a server you don't control. This creates an asymmetry that regulators in the EU and UK are actively examining.
Why this matters for your analytics stack
If your site loads Google's advertising tags — including GA4's gtag.js when connected to Google Ads — your visitors are now subject to fingerprinting under a policy that does not require their consent. The GA4 tag itself is approximately 45 KB and makes multiple outbound requests; with the fingerprinting change, those requests can now carry persistent device-derived identifiers to Google's infrastructure.
For developers operating under GDPR, the practical consequence is that deploying Google's tags without a consent mechanism is increasingly difficult to defend. The ICO has stated that fingerprinting "presents a high bar to meet" under existing frameworks — a signal that enforcement actions against publishers enabling fingerprinting-based tracking are a realistic near-term risk.
There is a second, subtler consequence: data quality. Fingerprinting injects non-consented identifiers into analytics pipelines. If you're using Google's measurement stack, some fraction of your attribution data is now derived from passive device signals rather than consented events. The two populations — consented and fingerprinted — are not equivalent, and mixing them without labeling them degrades the reliability of your metrics.
The contrast with fingerprint-free data collection
An analytics approach that does not fingerprint at all sidesteps these problems structurally. The Monoid tracker sends a single POST to /collect with no device-level signals beyond a coarse browser family and device type derived server-side from the ordinary request User-Agent. No IP is stored. No font enumeration. No screen resolution. No cross-session identifier.
The daily visitor hash — SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD) — uses the IP and user agent only in memory, discards them immediately, and produces a value that resets every 24 hours. This is the opposite of a fingerprint: it cannot persist across sessions, cannot be correlated across days, and cannot be used to re-identify a specific device.
Under the ICO's analysis, this approach does not trigger PECR consent requirements, because it does not access information stored on the device and does not produce a persistent identifier. The legal and technical case for this approach has only strengthened since February 2025.
What to audit now
If you are running analytics or advertising tags on your site, three questions are worth answering immediately:
1. Does this tag access device-level signals (fonts, battery, screen resolution)?
2. Does it send those signals to a third-party server?
3. Do you have a legal basis — consent or legitimate interest — documented for that transfer?
Google's policy change does not change your legal obligations; it changes what Google permits its advertisers to do. GDPR and PECR still require a lawful basis for processing, transparency in your privacy notice, and — where the basis is consent — a mechanism for users to withhold and withdraw it.
The simplest path through this is to not collect fingerprinting-derived data in the first place. A tool that never touches device-level signals has no exposure to the regulatory uncertainty surrounding fingerprinting, regardless of how Google's policies evolve.