Inferensys

Glossary

Federated Learning of Cohorts (FLoC)

Federated Learning of Cohorts (FLoC) was a deprecated Google Privacy Sandbox mechanism that enabled interest-based advertising by assigning users to large cohorts with similar browsing patterns, computed locally on the device to prevent individual tracking.
Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.
PRIVACY SANDBOX PROPOSAL

What is Federated Learning of Cohorts (FLoC)?

A deprecated browser-based targeting mechanism that grouped users into large interest-based cohorts on-device, aiming to enable interest-based advertising without exposing individual browsing history to third parties.

Federated Learning of Cohorts (FLoC) was a Google Privacy Sandbox proposal designed to replace third-party cookies by assigning users to large, interest-based cohorts using on-device machine learning. The browser analyzed local history to generate a cohort ID representing thousands of users with similar browsing patterns, which was then shared with advertisers for interest-based targeting without revealing individual site visits.

FLoC was deprecated in 2022 and replaced by the Topics API due to significant privacy concerns, including fingerprinting risks and the potential for cohorts to inadvertently reveal sensitive categories. Unlike FLoC's unsupervised clustering, the Topics API infers a limited set of high-level interest categories from recent history, providing a more transparent and privacy-preserving mechanism for post-cookie advertising.

ARCHITECTURAL DECOMPOSITION

Key Architectural Features of FLoC

Federated Learning of Cohorts (FLoC) was a Privacy Sandbox proposal designed to enable interest-based advertising without third-party cookies. The architecture shifted the processing of browsing history to the client device, grouping users into large cohorts to obscure individual identity. Although deprecated in favor of the Topics API, its architectural principles remain instructive for privacy-preserving computation.

01

On-Device Clustering

The core privacy innovation of FLoC was moving the clustering algorithm to the browser. Instead of a central server collecting raw browsing history, the SimHash algorithm ran locally. The browser computed a compact, lossy representation of the user's history and assigned a Cohort ID based on this hash. This ensured that granular URL-level data never left the device, adhering to the principle of data minimization.

02

SimHash Locality-Sensitive Hashing

FLoC relied on Locality-Sensitive Hashing (LSH) , specifically SimHash, to group similar browsing behaviors. Key properties include:

  • Dimensionality Reduction: High-dimensional browsing vectors were compressed into a low-bit fingerprint.
  • Cosine Similarity: The Hamming distance between two SimHash values approximated the cosine similarity of their original history vectors.
  • Fuzzy Matching: This allowed users with similar, but not identical, interests to land in the same cohort, creating the necessary anonymity set.
03

Cohort Assignment & k-Anonymity

A central server maintained a list of valid, public cohorts, but the browser made the final assignment decision. To prevent fingerprinting, the API enforced a k-anonymity constraint. A cohort was only exposed to advertisers if it contained a minimum threshold of distinct users (e.g., thousands). If a user's calculated cohort was too small, the browser would either suppress the ID or assign a more general, larger cohort, preventing the creation of micro-groups that could identify individuals.

04

Cohort Rotation & Temporal Decay

To prevent long-term tracking via a static ID, FLoC implemented strict temporal dynamics:

  • Weekly Recalculation: The browser recalculated the cohort assignment every 7 days based on the recent history window.
  • History Windowing: Only a sliding window of recent browsing data was used, preventing a user's entire lifetime history from defining their cohort.
  • Anti-Fingerprinting: The rotation logic ensured that a user's ID changed frequently enough to prevent it from becoming a persistent, stable identifier.
05

Sensitive Category Filtering

The browser applied a local sensitive category blocklist before calculating the SimHash. Domains associated with sensitive topics—such as medical conditions, religious beliefs, or sexual orientation—were automatically excluded from the clustering input. This was a critical architectural safeguard to ensure that cohort assignment did not inadvertently reveal protected characteristics, aligning with differential privacy goals and anti-discrimination regulations.

06

Deprecation & Transition to Topics API

FLoC was deprecated due to concerns over fingerprinting entropy and the potential for cohorts to be combined with other signals (like IP address) to re-identify individuals. It was replaced by the Topics API, which uses a fundamentally different architecture:

  • Taxonomy-Based: Instead of unsupervised clustering, Topics maps history to a fixed, human-curated taxonomy of ~350 interest categories.
  • Random Noise Injection: Topics introduces 5% random noise to provide plausible deniability.
  • On-Device Inference: A lightweight classifier runs locally, eliminating the need for a central cohort list.
FLoC & PRIVACY SANDBOX

Frequently Asked Questions

Clear, technical answers to the most common questions about Google's deprecated Federated Learning of Cohorts proposal and its implications for identity resolution and ad-tech.

Federated Learning of Cohorts (FLoC) was a Privacy Sandbox proposal designed to enable interest-based advertising without exposing individual browsing history. The mechanism operated entirely on-device within the Chrome browser. The browser would analyze a user's local web history and, using a clustering algorithm, assign them to a large cohort of thousands of users with similar browsing patterns. Only this high-level Cohort ID—a number representing a group interest, not an individual profile—was exposed to advertisers via an API. The core premise was to hide the individual 'in the crowd' by ensuring each cohort met a k-anonymity threshold, preventing the re-identification of single users while still allowing contextual and interest-based ad targeting without third-party cookies.

PRIVACY-PRESERVING AD TARGETING COMPARISON

FLoC vs. Topics API vs. Third-Party Cookies

A technical comparison of browser-based interest advertising mechanisms, contrasting Google's deprecated FLoC proposal, the current Topics API, and legacy third-party cookies across privacy, architecture, and utility dimensions.

FeatureFLoCTopics APIThird-Party Cookies

Current Status

Deprecated (2022)

Active (Chrome 115+)

Phasing Out (2024-2025)

Grouping Mechanism

Unsupervised clustering (SimHash)

Browser-inferred topic taxonomy

Cross-site tracking via unique ID

Granularity

Cohort ID (thousands of users)

Top 5 weekly topics per user

Individual browsing history

Data Processing Location

On-device only

On-device only

Third-party servers

k-Anonymity Guarantee

Fingerprinting Risk

Moderate (cohort entropy)

Low (limited bits of info)

High (persistent identifier)

Cross-Context Exposure

Cohort ID visible to all sites

Different topics per site (randomized)

Full tracking across all sites

User Opt-Out Mechanism

Privacy Sandbox toggle

Browser settings + per-site block

Cookie deletion + browser blocks

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.