Topics API notes and links

Users

Topics API rewards deceptive sites and traffic sourcing practices. Topics API leaks valuable audience data from one site to another. As I wrote on AdExchanger, this is a problem that it shares with third-party cookies—enabling the monetization of low-value sites of little interest to users. As the proposal currently stands, any site that a user can be tricked into visiting, or that their device can be manipulated into visiting, is in a position to collect ad revenue based on Topics API data that the browser supplies.

Topics API gives people an additional incentive to create deceptive sites and drive traffic to them by deceptive or harmful means. Operators of deceptive sites will see users as Topics piñatas—hit them with something like email spam or a deceptive link, get them to drop valuable Topics, profit. Technically this is no worse than third-party cookies, but third-party cookies are on the way out for a reason, and Topics API is positioned as a longer-term thing.

A new Topics API feature makes it even more friendly to monetizing problem sites. Adtech intermediaries can now obtain valuable topic data on illegal and/or low-reputation sites without allowing the browser to see those sites’ topics. See #92 (comment)

Topics API will enable price discrimination. Topics API would help retail, travel, and other sites identify more or less price-sensitive users based on their interests. And Topics API is more likely to be used for personalized pricing than other data sources, because it looks safer.

Many existing sources of data, such as geolocation or device info, might be correlated with membership in legally protected groups of people. However, Topics API is carefully intended not to be tied to sensitive information, which lowers the perceived risks of using the API for personalized pricing. (see #34)

Topics API discrimination does have some public sector uses that might be acceptable in some jurisdictions but not others. Users in the USA might accept the TSA using Topics API to optimize passenger screening, the IRS using it to select taxpayers for audits, or the CDC using it for public health data collection. (Update 13 Mar 2025) No, wait, they would probably freak out. But some other countries might use it for purposes that are not acceptable to some users there.

Some uses of Topics API outside the conventional publisher/advertiser use cases would be more or less acceptable to users, even if Topics API is successful in removing the ability of a caller to detect a sensitive user characteristic. And some jurisdictions might require use of a public-sector caller by sites—so not all callers are necessarily chosen or approved by the first party.

• HMOs or public health services classifying patients by healthy/unhealthy habits

• LMSs classifying diligent and distracted students

• Tax authorities classifying likely big-spending users for tax audits

More on non-advertising use cases: #216

Topics API could reveal sensitive information or identify individuals in combination with other data. Some privacy concerns for users are covered in a blog post from DuckDuckGo. There are some users who prefer personalized advertising, but a future personalize my ads feature would need to be designed to avoid user harms that would affect both personalizers and non-personalizers.

Inferring Users’ Demographics and Sensitive Interests Using the Topics API by Athicha Srivirote, Muhammad Abu Bakar Aziz, Jeffrey Gleason, Desheng Hu, and Christo Wilson. 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 ques- tion, 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.

Topics API enables machine learning systems to build profiles of users over time. Private Browsing 2.0 covers why Apple WebKit does not implement this API. You haven’t told any website with access to your email address anything that’s been going on in your family life. But the data broker has been able to read your shifting interests and store them in their permanent profile of you — while you were reading the news. Now imagine what advanced machine learning and artificial intelligence can deduce about you based on various combinations of interest signals. What patterns will emerge when data brokers and trackers can compare and contrast across large portions of the population? Remember that they can combine the output of the Topics API with any other data points they have available, and it’s the analysis of all of it together that feeds the algorithms that try to draw conclusions about you. Apple Safari doesn’t have this specific feature but you still need to turn off advertising measurement

Topics API enables advertisers to discriminate against legally protected groups without an incriminating paper trail. Consider a hiring manager who discriminates against job applicants who have a particular disability. This is illegal in the USA, and an online advertising service that offers advertisers the ability to explicitly discriminate by disability would face consequences.Facebook had to eliminate some targeting features over explicit discrimination—but biased advertisers still exist, and will tend to seek out systems that facilitate discrimination where available. And users who are searching for a job would likely choose not to share information on their disability with web sites.

Topics API will allow a biased advertiser to bypass both legal and user choice protections. A Topics API caller can feed the topics received from a user into a machine learning (ML) system that is simply optimized to get conversions, which in this case are hiring decisions by the biased manager. Using the presence or absence of particular topics for a user, the ML system learns to identify people whose disability would stop them from being hired if they clicked on the ad, applied, and got an interview. And no particular topic would appear sensitive to the user, so even if the user did decide to manually filter their Topics API list, they might not be aware of how the ML system uses apparently non-sensitive topics (or the absence of them) to determine that they should not receive a job ad from a particular company.

In this case the hiring manager does not expect to be able to track any one user individually, or even to receive no applicants with a disability—but is willing to pay extra for an opportunity to advertise in a way that results in reaching fewer applicants with the disability. And the only record of a discriminatory ad placement on either the advertiser or Topics API caller side is inside the ML system, which can be prohibitively difficult to interpret. (More on this problem: browser topics tracking and the prejudiced landlord problem) Related: #221

Martin et el. Respondents did not judge the privacy solution proposed—to have a browser collect data, keep the data on the local device, create inferences for use in advertising —to be a privacy solution over third-party tracking and the use of data brokers in advertising.

Topics API is misrepresented to users. How Google describes Topics API to users: Not disclosed is the fact that it’s an experimental system with unknown discrimination risks. See Google’s own 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.

Update: The misrepresentation problem is the subject of a complaint with the Austrian data protection agency from noyb.eu. Google’s internal browser tracking was introduced to users via a pop-up that said “turn on ad privacy feature” after opening the Chrome browser. In the European Union, users are given the choice to either “Turn it on” or to say “No thanks”, so to refuse consent. In a letter to noyb, Google argued that choosing to click on “Turn it on” would indeed be considered consent to tracking under Article 6(1)(a) of the GDPR. In reality, the company concealed the fact that selecting this option would turn on first-party tracking. Full complaint (PDF)

Update: it seems like regulators are on to this one. A recent CMA report recommends a redesign and says, Surface the Topics dialogue box periodically and consider approaches, based on user research, to remind or prompt users to revisit other Privacy Sandbox settings. In a subsequent report, the CMA states:

We are concerned that the Topics consent user interface may not adequately inform users about how their personal data is used or how the topics generated may be used for purposes wider than interest-based advertising (e.g. as determined by organisations that decide to use the API). To address this concern, Google has agreed to update the Topics API consent interface and to strengthen developer guidance to highlight the requirement to obtain purpose-specific consent prior to calling the API. We are awaiting the results of these updates

Topics API does not provide the same privacy guarantees to all users. Beugin and McDaniel: We find that 46%, 55%, and 60% of the 1207 users in the dataset are uniquely re-identified across websites after only 1, 2, and 3 observations of their topics by advertisers, respectively. More literature:

• On the Robustness of Topics API to a Re-Identification Attack

• A Privacy Analysis of Google’s Topics Proposal

Web page authors

Topics API enables leakage of audience information across sites. The main beneficiaries of Topics API audience data leakage would be sites that advertisers would not choose to support, along with the adtech intermediaries that enable them. Ad revenue that goes to sanctioned, copyright-infringing, brand-unsafe or other problem sites is not available to the authors of legit web pages (and a waste for advertisers, but they’re not on the list of constituencies that I’m using). (More on the persistent problem of ads on copyright-infringing sites)

Topics API is designed to allow Google to continue to transfer valuable audience info from legit sites to confidential sites like this one, which accept less ad money because they use other people’s content. (URL and logo blurred because it’s confidential. Their ads.txt is one line, and their Google ad account id is a multiple of 19.)

Cross-site data leakage is a problem for users because of the incentives covered above, but also a problem for legit web sites because of revenue. (And yes, it is better for users when ad revenue goes to sites they like, and not sites they got tricked into clicking through to.)

Users and legit ad-supported sites share an interest in having advertising pay for the largest possible value in ad-supported content. Meanwhile, Google wants to maximize ad revenue while minimizing the amount paid for content. Topics API is part of a set of projects to help Google come off ahead in this contest. The other parts are a Google service called Performance Max that hides information about what site an ad appeared on from the advertiser, and Google’s decision to run a large number of ads on confidential infringing or brand-unsafe sites without disclosing the domains on an industry-standard file called sellers.json. (IMHO it’s impossible to understand Topics API outside the context of Performance Max and confidential crap sites, but we won’t see the slide that has all three on it until it comes out in discovery in an antitrust case, or gets leaked.)

Topics API is biased in favor of large, general-interest sites. Topics API assigns only one or a few topics to each domain. A niche site that covers one or a few topics would provide significant commercially valuable data to the system, while a large site such as YouTube, that covers every topic, would provide no usable information. This is a pretty obvious problem for competition policy, so I’m kind of surprised they left it in. (See #206 and #224.)

Topics API encourages consolidation of third party services. The more sites that a third-party service runs on, the more useful information it can collect from Topics API. Since an individual site can’t get usable information out of Topics API, sites will have to A/B test different combinations of third-party iframes as callers. Sites will keep callers that provide more good Topics, and drop others. After repeated cycles of A/B tests, where callers that get dropped by one site start providing worse data to other sites and get dropped there too, we would be left with one domain doing all the Topics API calls. (see #82) This is also a pretty glaring antitrust issue.

See also a Google comment on the W3C TAG review: Note that the number of sites that can both call the API, and receive an unfiltered response, is quite small. This is because the caller would have to have observed the user on a site about that topic in the past to get through the filter. The vast majority of sites that can call the API will actually receive an empty list. Topics API is noisy enough to be much more useful for a large third-party caller than for a smaller one. (Is the noise level deliberately tuned to be too noisy to be useful for companies much smaller than Google, but usable at Google’s size?) More discussion of Topics API as a driver of consolidation and centralization in issue #73 Toward an oligopoly of “Topic providers”?.

The Topics API README states that,

One of (Interest-based advertising)’s benefits is that it allows sites that are useful to the user, but perhaps could not be easily monetized via contextual advertising, to display more relevant ads to the user than they otherwise could, helping to fund the sites that the user visits.

This goal can be achieved without the extensive leakage of site audience data made possible by Topics API. (Alternatives moved to a separate section, below.) Web authors and publishers might be able to ameliorate some of the effects of Topics API by, for example, opting out their signed-in users, or opting out of Topics API data collection entirely until YouTube channels are treated as separate areas with their own topic sets, on an equal footing with domains (see #17).

Topics API is designed to be difficult to A/B test. Ad-supported web publishers, and ad services that manage ads for them, generally make a practice of testing the revenue impact of turning different data sources on and off. Unlike other data sources, Topics API is controlled only by a Permissions-Policy HTTP header, which means that turning it off can only be done at page load time, and only with access to the web server or CMS code or configuration. In theory a publisher could choose not to load a script that only called Topics API, but Topics API so far has been combined with other third-party functionality, so needs its own A/B testing control. (#208).

Update 31 Jan 2023: The SEO problem is fixed. (Opting Out Of Google’s Topics API Won’t Affect Search)

User agent implementors

User agent implementors have limited developer and tester time available to implement and support new features. All software projects must leave some good ideas un-implemented in order to devote time to the features they decide to do. And as the feature set of a browser grows, so does the required ongoing maintenance. Choosing to implement and support Topics API, even for a large company, would mean failing to do a useful feature. Some Google Chrome features are good, and out ahead of other browsers. It would be a waste to keep putting time into this one.

Alternatives

There are two alternatives to Topics API that also support the proposal’s intended functionality, that might be wanted by the users who prefer personalized ads.

• Seller-defined audiences (SDA)

• FLEDGE interest groups

The main difference is that SDA and FLEDGE both give a gatekeeper role to a party with an incentive to avoid problematic ad placements and data leakage. With SDA, one publisher can control use of data to place ads on other publishers’ sites (audience extension). Depending on how the final version of FLEDGE comes out, a variety of parties could be interest group owners. None of these proposals are complete or perfect, but Topics API appears to be too friendly to good ad/bad site placements to keep pursuing.

What do do about it

How to protect yourself—and also protect desktop users you support and visitors to your web site: Google Chrome ad features checklist

Related

browser topics tracking and the prejudiced landlord problem

From WebKit standards positions: The Topics API · Issue #111

A Privacy Analysis of Google’s Topics Proposal by Martin Thomson at Mozilla

W3C TAG review

Alert: No Google Topics in Vivaldi Browser

Porn, Piracy, Fraud: What Lurks Inside Google’s Black Box Ad Empire by Craig Silverman and Ruth Talbot

realistically get rid of third-party cookies