08 Jul 2023 Search

(8 Sep 2023: added links, copy edit for clarity)

Here’s a little longer explanation of the prejudiced landlord use case from my notes on Google Topics API. First of all, yes, bias in rental and other decisions is still a thing. Business decision makers are not Econ 101 profit maximizers. They’re entire people, with human motivations, good and bad. So any ad platform that’s large enough is going to get a mix of advertisers who want to do good and bad stuff.

If a platform measures, in aggregate, how well the advertisers achieve their goals, the platform is going to measure both the success of money-seekers in getting money, and the success of people with other motivations in achieving their goals. From the ad platform point of view, it’s hard to tell a pure money-seeking landlord, looking for the tenant likely to earn them the most profit, apart from a prejudiced landlord, who is willing to give up on renting to an otherwise suitable tenant if it means they can keep someone from a certain group of people out of their building. Any automated ad platform, unless management makes a substantial positive effort to do otherwise, is going to end up optimizing for the needs of prejudiced advertisers along with the rest.

Automated social media advertising saw this problem in a big way. A big social media site can identify users by membership in a protected group and allow landlords to exclude certain people from seeing an ad. But that turned out to be easy to spot. So how can an ad platform, which because of its size is optimizing for the needs of advertisers with all kinds of motivations, manage to offer housing ads that discriminate against members of protected groups without leaving evidence? That’s where some software components and protocols come together.

  • Conversion tracking: an advertiser can report to the ad platform whether a sale was made to a particular user.

  • Topics-based ad placement: an ad platform can place an ad based on topics collected from user browsing history.

  • Machine learning: the ad platform can optimize the likelihood of conversion of a particular ad.

Now, the discrimination never has to be written down. It’s calculated on the fly by the machine learning system, and ML decisions are notoriously hard to figure out. So,

  • user membership in a protected group is correlated with browsing topics in some way (could be reflected in either presence or absence of particular topics)

  • browsing history is classified and mapped to topics, in a way that is correlated both with actual topics browsed and with a pattern of noise and errors introduced by the classifier

  • user passes browsing topics into an ML system. If the user does examine “their” topics, the user can identify the topics, but not the errors in how topics are assigned, or how those topics, with errors, are correlated with membership in one or more protected groups

  • advertiser passes conversion data into the ML system. In the case of housing, a “conversion” reflects whether the prejudiced landlord decided to rent the apartment

  • ML system optimizes for conversions, and “decides” to show fewer ads for the prejudiced landlord’s properties to members of the protected group. It’s nearly impossible to explain why the “decision” was made, so there’s no evidence of the crime.

Won’t members of protected groups just avoid discrimination by blocking certain topics from being shared, or turning off the topics tracking feature? Well, no, because people who don’t expect to be discriminated against will be less likely to take that action, and the ML system will learn to discriminate that way.

Google’s Topics API is intended to be a subset of third-party cookies, and of course all of this is possible with third-party cookies instead of topics tracking. And the problem is not that the company is choosing to offer services to enable prejudiced advertisers to achieve their goals, it’s that because of the need to serve advertisers at large scale, advertisers with discriminatory goals will be served along with the rest, in a hard-to-detect way. According to Google’s FAQ,

Chrome can and will take steps to avoid topics that might be sensitive (i.e. race, sexual orientation, religion, etc.). However, it is still possible that websites calling the API may combine or correlate topics with other signals to infer sensitive information, outside of intended use. Chrome will continue to investigate methods for reducing this risk.

While they’re working on that investigation, best to leave this feature turned off.

What to do about it

Most of the web ad revenue comes from a small fraction of the ads. (It varies depending on how you measure but the 80/20 rule is a good way to think about it.) If you’re in the 20% of people who either get the best ads, or would have gotten them if you hadn’t protected yourself, then you have more impact. And, in my humble opinion, an opportunity and responsibility to help protect others by taking your own valuable eyeballs off the market. After turning this stuff off—especially if you’re the kind of person who would get targeted for the good ads—the most important step is to either remove all third-party JavaScript and iframes, or set the Permissions-Policy header on your web site to protect your users. Simple list of what to configure: Google Chrome ad features checklist

2026 update

Someone did the research—not with a real Topics API browser, but with simulated results based on web history data. Srivirote et al., in Inferring Users’ Demographics and Sensitive Interests Using the Topics API | Proceedings of the ACM Web Conference 2026, found

Prior work has shown that the Topics API makes Chrome users vulnerable to cross-context reidentification attacks. In this work, we investigate whether the Topics API can be abused to implement a different privacy attack: accurate inferences of users’ demographics and sensitive interests. To answer this question, we use a real-world dataset of browsing histories—containing over 250,000 unique domains over a span of eight months—to train machine learning models that take topics from the Topics API as input. Of the 19 demographic traits and sensitive interests that we evaluate, we find that all but two show predictive signals. Our findings add to the growing body of evidence that the Topics API is privacy-revealing, not privacy-preserving.