How Google’s FLoC Failed and What Topics API Means for Privacy
Google’s attempt to replace third-party cookies followed a familiar pattern: identify a serious privacy problem, design a technical workaround, and present the workaround as a healthier foundation for online advertising. The proposal was called Federated Learning of Cohorts, or FLoC. It promised to hide individuals inside groups while preserving the behavioral signals advertisers considered valuable.
FLoC never became a permanent part of Chrome. It encountered criticism from privacy researchers, advertisers, publishers, regulators, and competing browsers before Google abandoned it in 2022. Its replacement, the Topics API, takes a less ambitious approach. Instead of placing people into behavior-based cohorts, the browser chooses broad subjects associated with their recent browsing.
That change matters, but it does not transform targeted advertising into anonymous advertising. Topics API reduces some of the risks associated with FLoC while leaving the commercial infrastructure of cross-site profiling largely intact. Understanding the difference requires looking beyond Google’s privacy language and examining who receives information, how often they receive it, and what they can combine it with.
Why FLoC Looked Attractive
Third-party cookies allowed advertising networks to recognize a browser across many unrelated websites. That recognition supported retargeting, audience measurement, attribution, and detailed behavioral profiles. As browsers began blocking third-party cookies, advertisers feared losing the ability to reach relevant audiences. Google wanted to offer an alternative that kept much of the advertising economy inside Chrome while presenting the browser as a privacy-preserving intermediary.
FLoC attempted to replace individual tracking with group membership. The browser would examine a person’s browsing history locally and assign the browser to a “cohort” containing thousands of users with supposedly similar interests. Websites and advertisers could request the cohort identifier rather than receiving a record of the individual sites visited.
The concept sounded simple: personal browsing history would stay on the device, while advertisers would receive only a crowd-level label. A user who visited technology websites, cooking blogs, and travel services might belong to a cohort associated with a broad pattern of interests. Advertising systems could target the cohort instead of storing a unique cookie-based trail.
This design appealed to Google because it moved the center of power from many independent trackers toward the browser itself. Chrome would make the classification, control the disclosure process, and mediate access to audiences. That could reduce certain forms of uncontrolled tracking while giving Google a strategically important role in the future of online advertising.
Where FLoC Went Wrong
The core problem was that a cohort identifier could become a new tracking signal. A website might not know a visitor’s full browsing history, but it could combine the FLoC value with IP addresses, login details, browser characteristics, and existing first-party data. The proposed replacement for third-party cookies could therefore become another ingredient in a more elaborate fingerprint.
FLoC also risked exposing sensitive interests. Browsing behavior can reveal health concerns, religious beliefs, political activity, sexuality, financial difficulty, or membership in vulnerable communities. Even if a cohort contained thousands of people, its label could still indicate that a browser belonged to a group connected with a sensitive subject. The browser’s classification process could produce an inference that users never explicitly chose to disclose.
Civil society organizations raised a deeper objection: privacy is not guaranteed simply because information is shared with a crowd. A group can be large and still be revealing when combined with other attributes. Cohort changes over time could also provide a signal about a person’s recent behavior. The system shifted the form of surveillance without clearly removing the incentives behind it.
There were practical problems as well. Publishers and advertisers did not necessarily trust Google to define the taxonomy or decide which cohorts were acceptable. Other browsers declined to implement FLoC, making it difficult to establish a common web standard. WordPress and privacy-focused tools discussed blocking it, while DuckDuckGo and Brave criticized the proposal. In January 2022, Google announced that it would stop developing FLoC and pursue the Topics API instead.
How Topics API Changes The Model
Topics API does not create a persistent cohort identifier. Chrome observes the broad categories associated with a user’s recent visits, using the hostnames of sites rather than analyzing the full text of pages. At regular intervals, the browser selects a topic from a taxonomy of advertising-relevant interests. When an eligible site or advertising provider calls the API, Chrome can return a small number of recent topics.
The system is designed to limit access. A caller generally needs to have observed a topic on a site where the user visited, and the browser can add randomization so that returned information is not perfectly predictable. Users can review or disable the feature through Chrome settings, and sites can use permissions mechanisms to control access. Google also removed categories it considered particularly sensitive from the public taxonomy.
These safeguards make Topics API less directly identifying than FLoC. A site does not receive a cohort label that follows the browser across the web, and the available subjects are intended to be broad. The browser can also provide a topic that is unrelated to a particular user’s actual interest, creating some uncertainty for anyone trying to build a precise profile.
Yet the API still has a clear purpose: to help advertising systems select audiences based on browsing activity. It does not stop a company from using login data, first-party identifiers, IP addresses, device fingerprints, or information purchased from data brokers. Topics API is therefore best understood as a reduction in one tracking channel, rather than a complete privacy architecture.
| Feature | FLoC | Topics API |
|---|---|---|
| Main signal | A behavior-based cohort identifier | Broad interest categories |
| How it is created | Browser groups similar browsing patterns | Browser derives topics from visited site hostnames |
| Persistence | Cohort value could be observed over time | Topics rotate across recent time periods |
| Potential privacy risk | Cohort could reveal sensitive behavior or aid fingerprinting | Topics can still expose interests and support profiling |
| Information available to sites | A label representing a large behavioral group | A limited selection of recent topics |
| User control | Proposed controls were unclear and implementation-dependent | Chrome offers settings to review or disable the feature |
| Effect on advertising | Preserved audience targeting through group membership | Preserved contextual and interest-based targeting |
What The Browser Still Reveals
Topics API narrows the information available to advertisers, but “narrow” does not mean “harmless.” A sequence of broad topics can become meaningful when associated with a stable account or device. Someone who receives topics related to chronic illness, debt advice, divorce services, or political organizations may become easier to classify even if no single topic identifies them.
The taxonomy itself is a policy decision. Deciding which subjects exist, how they are grouped, and which categories count as sensitive determines what the browser can infer. A broad label may hide detail from one advertiser while still exposing an important personal association. Categories can also be inaccurate, especially when a person visits a website for research, work, education, or someone else’s needs.
Access controls provide useful friction, but they do not eliminate the wider advertising ecosystem. A large platform can connect browser-provided topics with information from its search engine, account services, advertising relationships, and analytics products. Smaller companies can combine topics with their own customer records or other tracking techniques. The resulting profile may be more approximate than a cookie history, but approximation can still influence prices, content, political messaging, and access to opportunities.
The distinction between contextual advertising and behavioral advertising also deserves attention. Contextual advertising places an ad based on the page currently being viewed. Topics API adds a historical layer: what the browser thinks the person has been interested in recently. That is less invasive than silently transmitting a complete browsing history, but it remains behaviorally informed targeting.
The Privacy Trade-Off Beyond Chrome
Google’s proposal should be judged against real alternatives, not against an imaginary world where every other advertising method disappears. Replacing third-party cookies with a browser-mediated signal could reduce uncontrolled data leakage, especially on browsers that previously permitted extensive tracking. It may also make it easier to explain and manage some forms of interest-based advertising.
The danger is that a privacy label can create false confidence. A person may believe that their browsing history stays private because Topics API uses broad categories, while advertisers continue identifying them through account logins, fingerprinting, email-based identifiers, mobile advertising IDs, and server-side data sharing. The new API can become one component in a layered surveillance system.
This is part of a wider tension between convenience and control. Cloud services, for example, can centralize personal documents in exchange for seamless access, but the real cost of cloud storage includes dependence on providers and uncertainty about how data is processed. Advertising APIs present a similar bargain: less visible tracking in exchange for allowing a dominant platform to define the privacy boundary.
Regulation also changes the calculation. Under the GDPR and comparable laws, companies may need a lawful basis, meaningful transparency, data minimization, and safeguards around profiling. A browser API does not automatically make downstream processing compliant. Advertisers and publishers remain responsible for explaining their practices, honoring user rights, and avoiding discriminatory or unfair uses of inferred interests.
Practical Ways To Reduce Profiling
Users do not need to wait for a perfect replacement for surveillance advertising. Browser settings, privacy tools, and purchasing choices can reduce the amount of data available to platforms, although each measure has limits. The most effective approach is layered: prevent unnecessary collection, separate identities, and avoid granting every service a permanent view of personal activity.
The following steps are useful starting points:
- Review Chrome’s Privacy and Advertising settings, disable Topics-related personalization if preferred, and periodically clear browsing data and site permissions.
- Use a browser with strong anti-tracking defaults, block unnecessary third-party scripts, and limit extensions to tools from developers whose privacy practices are clear.
- Separate sensitive activities from advertising-linked accounts where practical, especially searches involving health, finances, legal matters, or political participation.
- Prefer services that collect less data and support end-to-end encryption; the case for encrypted SMS messages illustrates why provider access matters even when communications feel ordinary.
- Treat “free” digital services as data arrangements, read consent prompts critically, and reject optional advertising personalization when it is not necessary for access.
These actions cannot prevent every inference. Websites can still see information needed to deliver content, and first-party services can still build profiles from direct interactions. The goal is to reduce unnecessary exposure and make tracking less durable, less comprehensive, and less profitable.
A Better Standard For Privacy
FLoC failed because it tried to preserve behavioral advertising while changing the shape of the identifier. Its cohort model made group membership look anonymous, but groups can reveal sensitive traits and can be combined with other signals. The proposal also concentrated decision-making in Chrome, leaving the public to trust Google’s taxonomy, implementation, and incentives.
Topics API is a more restrained design. It avoids a single cohort label, limits the number of topics shared, introduces some randomness, and gives users a clearer opt-out path. Those are meaningful improvements. They should receive credit without being mistaken for the end of surveillance advertising.
A stronger privacy standard would ask whether a person can be tracked across unrelated contexts, whether sensitive inferences can be made, whether participation is genuinely voluntary, and whether the system remains useful when a user declines profiling. It would also consider the power of the company operating the browser, rather than evaluating only the technical details of one interface.
Privacy-conscious readers can put that standard into practice by checking browser controls, supporting services that minimize data collection, and questioning advertising systems that turn ordinary browsing into a marketable behavioral record. The future of online privacy will be shaped by those everyday choices as well as by browser code and legislation.