Federated Learning of Cohorts, or FLoC, was a browser-based advertising proposal that grouped users into interest cohorts instead of exposing individual browsing histories. The aim was to support targeting with less direct identity sharing, but it still raised questions about profiling, consent, and re-identification risk.
What FLoC Was Trying to Change
FLoC, or Federated Learning of Cohorts, was an attempt to replace individual browser-level advertising identifiers with cohort-based targeting. The design goal was to reduce direct identity exposure while still giving advertisers a usable interest signal.
That distinction matters because the privacy trade-off was not “tracking versus no tracking,” but “less explicit individual disclosure versus a new form of group-based profiling.” Cohorts can still be used to infer sensitive interests, especially when combined with other browser or site data.
How Cohort-Based Advertising Works
FLoC grouped browsers into interest cohorts computed locally by the browser rather than publishing a full browsing history. In principle, that moved some profiling logic away from the ad ecosystem and into the client.
From a security and privacy perspective, the important feature was not the label itself but the inference surface it created. If a cohort is stable enough to be useful for targeting, it can also become a persistent signal for classification, correlation, and repeated observation across sites.
Why FLoC Drew Privacy Concern
FLoC was controversial because it tried to preserve ad targeting while weakening direct user-level visibility. EU General Data Protection Regulation (GDPR) is a useful reference point for understanding why grouping users for profiling can still trigger consent, transparency, and purpose-limitation concerns when personal data is involved.
Browser-based cohorting also raised re-identification and linkage concerns. A cohort is not the same as anonymity: if the cohort is narrow, stable, or combinable with other attributes, it can still contribute to a profile that meaningfully points back to an individual or small group.
Why the Proposal Mattered in Browser and Ad-Tech Governance
FLoC became an important case study in how privacy-preserving language can still leave strong profiling capability intact. It highlighted a governance question that still matters for browsers, ad tech, and privacy engineering: whether the control objective is to reduce identification, reduce tracking, or reduce profiling altogether.
That same question applies when evaluating any replacement for third-party cookies. A system may be less invasive than legacy tracking, yet still create a durable audience classification layer that deserves privacy review, transparency testing, and careful defaults.
Risk and Threat Considerations
FLoC-style cohorting can expose users to inference risk even when individual browsing history is not directly shared. The main concern is that a cohort identifier can become a reusable profiling handle, especially when websites, ad networks, or data brokers combine it with other signals.
Failure mechanism: A browser-generated cohort can be stable enough to support cross-site correlation, and small or distinctive cohorts can reduce the distance between a coarse group label and an individual profile. That makes the system vulnerable to linkage, re-identification, and unintended disclosure of interests.
Impact: The practical result is broader privacy exposure, weaker user control over profiling, and a higher chance that supposedly aggregated targeting still reveals sensitive behavioural patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Processing principles | FLoC profiles users through cohorting, which engages lawful, transparent, purpose-limited processing. |
| Art.25 — Data protection by design and by default | FLoC is a browser design choice that should minimise profiling and identity exposure by default. | |
| Art.35 — Data protection impact assessment | Cohort-based targeting can create profiling and re-identification risk that warrants formal impact review. | |
| Recommendation — Apply Art.5 principles to limit cohort-based profiling and ensure transparent, purpose-bound use. Build privacy-preserving defaults that reduce cohort granularity and unnecessary user profiling. Run a DPIA before deploying cohorting or other large-scale behavioural profiling systems. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The proposal’s privacy goal is to reduce unnecessary exposure of individual-level browsing data. |
| Recommendation — Limit collection and sharing paths so individual browsing data is not exposed beyond what is needed. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Cohort and browsing data still need protection because they can reveal sensitive user behaviour. |
| Recommendation — Protect stored cohorting and browsing data with controls that reduce disclosure risk. | ||
Practitioner Guidance
What to watch for: Treat any cohorting, fingerprint-adjacent signal, or interest grouping as a privacy mechanism that needs the same scrutiny as a tracking primitive. The key question is not whether the system names a person directly, but whether it creates a durable and meaningful profile.
Practitioner takeaway: If a browser or ad-tech design still enables reliable classification of users, it should be evaluated for profiling risk, consent expectations, and re-identification pathways before deployment.
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
