Federated Learning of Cohorts, or FLoC, was Google’s proposed privacy-preserving advertising model that grouped users by similar browsing behaviour instead of tracking individuals directly. The idea was to support interest-based advertising while reducing reliance on person-level identifiers, but the proposal was later replaced during the Privacy Sandbox redesign.
What FLoC Was Trying to Do
federated learning of Cohorts was an attempt to preserve some interest-based advertising value while reducing direct tracking of individual users. Instead of building a per-person profile, browsers would place users into coarse behavioural cohorts so advertisers could target groups rather than named identities.
The core idea was not anonymity, but less granular tracking. That distinction matters because cohorting can still reveal a user’s interests, browsing patterns, and likely sensitive traits if the grouping is too specific or if it is combined with other signals.
How Cohort-Based Advertising Differs from User Tracking
FLoC changed the advertising model by shifting from individual identifiers to shared behavioural buckets. In practice, that meant the browser, not the ad network, would compute cohort membership locally and expose a cohort signal for ad selection.
This kind of design sits between direct tracking and full privacy protection. It can reduce the obvious use of cookies or person-level IDs, but it does not eliminate profiling, inference, or the possibility that cohort labels become a stable proxy for a user over time.
Because the signal is still behavioural, the privacy question is whether grouping is broad enough to avoid singling people out while still being useful for ad targeting. The more specific the cohort, the more the system starts to resemble disguised individual profiling.
Why FLoC Drew Privacy Scrutiny
FLoC was controversial because privacy-preserving language can obscure the fact that group membership itself can be sensitive. If a cohort is small, persistent, or correlated with unusual browsing habits, it can expose interests that users did not expect to reveal.
It also raised ecosystem concerns about consent, transparency, and unintended secondary use. A cohort signal can be combined with other data points, which means the privacy benefit depends heavily on how the surrounding advertising stack is designed and governed.
OpenID Connect Core 1.0 is a useful contrast here because it shows how a standards-based identity layer can be explicit about what is being asserted, while FLoC relied on a browsing-derived grouping signal rather than a user-authenticated identity claim.
Why FLoC Was Replaced
FLoC did not become the long-term answer for the Privacy Sandbox because the privacy and ecosystem trade-offs were difficult to settle. The broader shift toward replacement proposals reflected the need for ad-targeting approaches that were easier to explain, easier to govern, and less likely to create new forms of user fingerprinting or inference.
Workforce Identity Security Guide, IAM and IGA Basics, and OAuth 2.0 and OpenID Connect Guide for Identity Teams are useful references for the broader trust and governance patterns that help explain why systems relying on signals, assertions, and delegated behaviour need clear boundaries and reviewable controls.
Risk and Threat Considerations
FLoC’s main risk was not classic account compromise, but privacy leakage through inference. A cohort signal can still reveal sensitive browsing interests, and an attacker or data broker may use repeated cohort observation to infer behaviour, interest categories, or stability of identity over time.
Failure mechanism: Cohort membership can become a persistent behavioural marker, especially when it is combined with other browser, device, or ad-tech signals. Small or stable cohorts can make it easier to correlate activity back to a specific person or narrow group.
Impact: The result can be profiling, re-identification risk, unwanted behavioural targeting, and loss of user trust in the privacy model. Even when individual identifiers are suppressed, a weak cohort design can still create a meaningful privacy exposure.
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 ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Cohort-based tracking contrasts with user-authenticated identity assertions. |
| PT-3 — PII Processing and Transparency | FLoC is a privacy design topic where transparency and data-use notice materially matter. | |
| RA-3 — Risk Assessment | The proposal's value depends on assessing privacy leakage and re-identification risk. | |
| Recommendation — Separate authenticated identity from behavioural targeting signals and limit cross-context correlation. Document what behavioural signals are collected, how they are grouped, and how they are used. Assess whether cohorting meaningfully reduces privacy risk or simply changes the shape of it. | ||
| NIST CSF 2.0 | PR.AA-05 — Roles, responsibilities, and access permissions are established and managed | Highlights governance over who or what may act on user-linked signals and data. |
| Recommendation — Define governance for cohort-like signals and restrict use to approved purposes. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Cohort-based advertising raises privacy protection obligations around behavioural data. |
| Recommendation — Treat behavioural grouping signals as privacy-sensitive data and apply protection controls. | ||
Practitioner Guidance
Common misunderstanding: Grouping users does not automatically equal privacy protection. Practitioners should treat cohort-style designs as data minimisation mechanisms that still require testing for re-identification, sensitivity leakage, and compatibility with the broader ad-tech ecosystem.
Practitioner takeaway: If a privacy-preserving targeting model can be stable, narrow, or linkable enough to follow a person across contexts, it needs the same kind of scrutiny you would apply to any other persistent tracking signal.
Related resources from NHI Mgmt Group
- How should security teams reduce communication overhead in privacy-preserving vertical federated learning without weakening differential privacy?
- Why does frequent client-server communication create risk in vertical federated learning deployments?
- What should practitioners watch for when vertical federated learning is too communication-heavy?
- What can client weights reveal in vertical federated learning models?
