The most technically sophisticated critique of Google’s FLoC proposal has now been published, and it lands hard enough that independent analysis of the Privacy Sandbox’s most prominent API can no longer be dismissed as industry self-interest dressed up as privacy concern.

The IAB Tech Lab published a detailed technical review of FLoC in late June, followed by additional critique in July. The Electronic Frontier Foundation, which operates Panopticlick/Cover Your Tracks — one of the leading browser fingerprinting research platforms — published its own analysis. Taken together, these critiques identify specific, testable problems with FLoC that are not obvious from Google’s published specification: the cohort ID mechanism creates a new fingerprinting surface that can be exploited in ways that may actually increase cross-site tracking risk compared to the current cookie-based system it replaces.

The Fingerprinting Problem Explained

Browser fingerprinting is the practice of identifying users across websites without cookies by combining multiple browser characteristics into a unique signature: screen resolution, installed fonts, browser version, time zone, language settings, and dozens of other stable attributes. Fingerprinting is difficult to block because it uses information the browser exposes for legitimate purposes, and it is already in widespread use by advertisers and adtech vendors seeking cookie-free tracking mechanisms.

FLoC introduces a new attribute that can be added to a browser fingerprint: the cohort ID. Every Chrome user is assigned to a FLoC cohort based on their browsing history — a number from a range of thousands of possible cohort IDs. This cohort ID is exposed to any website the user visits.

The fingerprinting problem is this: the cohort ID encodes information about the user’s browsing behavior that is not available in the other browser attributes that fingerprints use. Combined with those other attributes, the cohort ID increases fingerprint uniqueness — the statistical distinguishability of one user from all others.

The EFF’s research demonstrated that FLoC cohort IDs add meaningful entropy to browser fingerprints, making users more uniquely identifiable than they are without FLoC. The irony is precise: a privacy-preserving API that was designed to replace cookie-based tracking creates a new tracking surface that fingerprint-based trackers can exploit.

The IAB Tech Lab’s critique goes further, noting that cohort IDs can be combined across multiple FLoC-aware sites to build more precise user profiles over time. If a user’s cohort ID is logged at multiple third-party sites over days or weeks, and cohort membership changes with browsing behavior, the pattern of cohort ID changes can itself become a tracking signal.

The Cohort Design Critique

The IAB Tech Lab’s analysis also challenges whether FLoC cohorts provide sufficient audience resolution to support effective advertising, separate from the privacy concerns.

FLoC cohorts in the current design have approximately 2,000 users per cohort. The argument for large cohorts is privacy: a cohort of 2,000 users provides k-anonymity — any individual is indistinguishable from 1,999 others within the cohort. The consequence is precision loss: a cohort of 2,000 users is a broad population segment, not a targeted audience.

Behavioral audience targeting currently used in programmatic campaigns can achieve much finer segmentation than 2,000-user cohorts. DSPs using lookalike modeling and behavioral segments work with audience populations defined at the individual level and then statistically expanded — the signal is individual-level before it is aggregated for reach. FLoC’s floor of 2,000 users per cohort prevents this level of precision.

IAB Tech Lab’s analysis modeled expected advertising performance under FLoC cohort signals and concluded that conversion rates for cohort-targeted campaigns would be materially lower than for current behavioral targeting — not the 95 percent efficiency retention that Google’s own research suggested.

Why the Critiques Are Landing

Previous industry critiques of Privacy Sandbox proposals were easy to characterize as rent-seeking — companies whose business models depend on the cookie protesting its replacement. The current critiques are harder to dismiss because they come from organizations with credibility on both sides of the privacy debate.

The IAB Tech Lab’s critique is from an organization that represents publishers and technology providers who benefit from advertising effectiveness. But its technical review is detailed, reproducible, and specific — it identifies testable claims about cohort ID entropy and audience resolution that can be independently verified.

The EFF’s critique is from an organization with a long track record of opposing cross-site tracking and supporting user privacy. The EFF arguing that a privacy-focused Google API creates new privacy risks is not an industry interest argument. It is a technical analysis from a credible privacy-oriented source.

The CMA’s interim report, which we covered last month, expressed concerns about the privacy implications of FLoC as well as its anticompetitive potential. When a competition regulator and a privacy advocacy organization reach the same substantive concerns through different analytical frameworks, the overlap is worth taking seriously.

Can Privacy Sandbox Survive This Scrutiny?

The question is not whether Privacy Sandbox survives as a project — Google is committed to it. The question is whether FLoC specifically survives as the primary interest-based targeting API, or whether the critiques force a redesign substantial enough to constitute a new approach.

Google has already begun revising its terminology, renaming the underlying auction concept from TURTLEDOVE to FLEDGE and more recently to Protected Audience API. These renamings correspond to design changes, not just branding. Whether the design changes address the fingerprinting and cohort resolution problems is the substantive question.

The W3C Privacy Community Group — where these proposals are developed — is the formal venue for resolution. Google publishes proposals, critics publish analyses, Google publishes revised proposals. This process works slowly, and its outcomes are constrained by what Google ultimately implements in Chrome.

The more consequential forum may be the CMA. Google’s formal commitments to the CMA include providing test data and results from Privacy Sandbox origin trials. If that data demonstrates the fingerprinting risks the EFF and IAB Tech Lab have identified, the CMA has the authority to require design changes as a condition of the Privacy Sandbox’s UK deployment.

FAQ

What is k-anonymity and why does it matter for FLoC? K-anonymity is a privacy property that guarantees that any individual in a dataset is indistinguishable from at least k-1 others. FLoC uses k-anonymity as a privacy safeguard: cohorts must contain at least some minimum number of users (approximately 2,000 in current designs) so that no individual is uniquely identifiable by their cohort membership. The tradeoff is audience resolution: larger cohorts mean less precise targeting. The fingerprinting critique does not undermine k-anonymity directly — it argues that cohort IDs add entropy to external fingerprinting techniques, making user identification more effective through fingerprinting even if cohort membership alone provides k-anonymity.

Does the FLoC fingerprinting problem affect all browsers or just Chrome? The fingerprinting risk is specific to browsers that implement FLoC — currently only Chrome, and only in the percentage of users participating in FLoC origin trials. Firefox and Safari have explicitly declined to implement FLoC. Brave, the privacy-focused browser, announced it would not implement FLoC. Apple and Mozilla both published statements expressing concerns about FLoC’s privacy properties. The EFF documented that at least three Google properties received the FLoC cohort ID during origin trials, raising questions about how Google itself was using the cohort data.

If FLoC is problematic, what are the Privacy Sandbox alternatives for interest targeting? Google is developing other Privacy Sandbox APIs alongside FLoC, including FLEDGE/Protected Audience API (for remarketing without cross-site tracking) and the Topics API (a newer interest-based targeting proposal with different cohort mechanics). The Topics API, announced after the period covered by the IAB Tech Lab critique, uses a smaller set of broad topic categories rather than computed cohort IDs, which addresses some of the fingerprinting concerns. Whether Topics has its own privacy problems will become clear as its specification matures and critics examine it.

Should we be investing in FLoC-compatible campaign infrastructure given these critiques? Not production investment in FLoC specifically, no. The critiques suggest FLoC’s current design is unlikely to survive intact. The more durable investment is in understanding the general direction of browser-based interest targeting and building evaluation capabilities for whatever APIs Google ships that reach origin trial at scale. The Privacy Sandbox’s direction — interest targeting without individual identifiers, conversion measurement without cross-site tracking — is stable even if the specific APIs change.