 Topics is a mechanism to enable a web browser to share information about a user's interests, but without revealing anything more about the user's browsing activity. The topics of interest shared by the API can be used to help select advertising that's relevant for people based on their interests. So for example, show an ad for tennis shoes to a person who's interested in tennis. Now that's known as interest-based advertising. Historically, the webbers relied on third-party cookies and other tracking mechanisms to support ad selection along with fraud detection and a variety of other use cases. Now many people are concerned about the privacy implications of ad selection by third-party user tracking and third-party cookies are being deprecated. Topics is part of the Privacy Sandbox, a set of technologies to satisfy a variety of use cases but without using third-party cookies or other tracking mechanisms. So I'm Sam Dutton, a developer advocate with the Google Chrome team and in this video I'll provide an overview of how topics works. Now I won't go very deep technically, but if you prefer something more straightforward check out our resources at PrivacySandbox.com. So this video is about topics for the web. Now to find out more about topics for Android, take a look at the Topics API Developer Guide. So let's go through topics step by step. Now the core requirement for topics is to support interest-based ad selection. To do this, topics needs to provide ad tech platforms with topics of interests for a user based on their browsing activity. Topics does not use third-party cookies, instead topics shares non-sensitive topics related to your interests. It must be simple for a user to block specific topics or to turn off topics entirely. And in addition, websites must be able to opt out of topics calculating user interests on their pages. So to meet those requirements, topics has several components. First of all, topics uses a list of categories for the topics of interest associated with browsing activity such as tennis or gardening. Now that list is known as a taxonomy. The topics taxonomy looks like this, a publicly maintained human readable hierarchy that avoids sensitive topics. The taxonomy is likely to change and develop over time in consultation with the web ecosystem, meaning people like you. And you can provide feedback by filing an issue on the topics taxonomy on GitHub. So topics needs to record topics of interest for a user based on their browsing activity and to securely store these topics in the browser on the user's device. Topics works out topics of interest for a user by looking at the host's name of pages the user visits. So if a user looks at pages on the site tennis dot example, topics returned for the user might be sports or tennis. Now in Chrome's implementation, topics for the top 50,000 most popular sites are provided in a manually curated override list. In other words, if you visit pages on one of the top 50,000 sites, the topics recorded by the browser will be from the override list. For other sites, not in the top 50,000. Chrome uses a machine learning classifier to work out topics based on host names. You can try out the classifier for yourself from the Chrome topics internals page. Tennis dot example gets the topics sports and tennis. Gardening dot example gets the topic gardening. For instructions on how to view the top 50,000 override list and to try out the machine learning model used by the classifier. Take a look at our documentation on developer.chrome.com. As with the taxonomy itself, the approach used by the topics classifier will develop with time. You know, determining topics of interest for a user needs to get the balance rights. Sharing too much detail about a user's browsing activity is bad for privacy, but too little granularity means the API isn't useful. And if the API isn't useful enough, sites and services may opt for alternatives that are worse for user privacy. So just to recap, topics works out topics of interest for a user based on the host names of pages they visit. And these topics are stored by the browser on the user's device. The browser must also provide simple mechanisms to give the user control. And Chrome provides settings to view topics, block individual topics or turn off the API completely. And this is better for privacy than the current situation where cookies and other mechanisms are used by third parties to track user activity across sites. And user data is stored on third party servers without user control. Now, having recorded the topics of interest for a user, topics needs to provide access to them to third parties. But without revealing anything else about the user's browsing activity. A third party that wants to know the topics of interest for a user such as an ad tech platform is known as a caller, since this is the party that calls the API. For a caller, there are two stages to using topics as the user navigates the web. The caller observes topics and then accesses them. So first, the caller needs a way to tell the browser that they wish to mark a topic as observed for the current user. Topics chooses only from observed topics when it selects which topics to share when the caller uses the API to access topics. So a caller is identified by the ETLD plus one from which they observe and access topics. In case you're wondering about ETLD plus one, well, that's the top level domain plus the subdomain that precedes it. For example, adtech.example or adtech.example.com.au. So a site like tennis.example that I mentioned earlier might include JavaScript to embed an iframe from a caller such as an ad tech platform, say ad tech platform A. Subsequently, the caller needs to be able to access topics that they've observed for a user. In this example, adtech platform A using topics as a signal to select relevant ads. Now, a caller can only access topics that they themselves have observed for a user and not topics observed by other callers. For example, if adtech platform A has a presence on tennis.example, they would observe topics like sports and tennis for a user who visits that site. Now, if adtech platform B has a presence on gardening.example, they might observe the topic gardening. Now, each of these two adtech platforms will only get topics for a user that they have observed. In this example, adtech A won't get gardening and adtech B won't get tennis. In other words, callers such as adtech platforms only get topics for pages where they have a presence. The point is that callers should learn no more than they could have using third-party cookies. Topics provides two ways for a caller to observe and access topics. In other words, two ways for the caller to signify to the browser that they've observed a topic for a user and two ways to get access to topics that were observed for the user. The caller can either use the topic's JavaScript API or the caller can use the topic's request and response headers on a fetch request or for an iframe. So first up, a caller can signal to the browser that it has observed topics for a user by calling document.browsingtopics from an iframe embedded on pages the user visits. In other words, the caller has an iframe embedded on multiple client sites and the iframe includes code that calls document.browsingtopics to mark topics as observed for the current user. Now in this example, tennis.example includes JavaScript from adtech A that embeds an iframe in their pages and that iframe calls the topic's API. Now this means that the browser will record that adtech A has observed topics such as tennis for pages on tennis.example for the current user. Now and later, that caller can use the same document.browsingtopics method from the same ETLD plus one as the iframe to access topics it has observed for the current user. Now by the way, if document.browsingtopics is called with a skip observation true parameter, topics will be returned but the browser won't record that the topics were observed for the current page by the caller. Now the reason this method needs an iframe is that the context for observing topics must be the same as the context for accessing topics. In other words, the ETLD plus one of the calls to document.browsingtopics must be the same. In this example, that ETLD plus one is adtech A.example. Now a more efficient way to observe and access topics is to use request and response headers. If a fetch request includes browsing topics true in the options parameter or an iframe element has a browsing topics attribute, then the request from the browser will include a sec browsing topics header that lists topics for the current page. And the header value looks like this, kind of three, two, eight, V equals Chrome, one, two, four, then P equals P, zero, zero, zero, and so on. Now this example shows that topic three, two, eight has been observed, which is sports tennis. The V parameter provides the taxonomy version and the P value provides padding so all header values are the same length. Without the padding, an attacker could learn the number of topics for a different origin via the header length. If the response to the request includes an observe browsing topics header with the value question mark one, that signals to the browser to record that the caller has observed the topics that were provided in the request header. So how does the browser decide which of the user's topics to share with the caller? Well, there's a bit more detail to understand about how many topics the caller gets and how these are selected. As I've said, a caller only gets topics for pages where they have a presence and where the caller has signified to the browser that it wants topics for that page to be marked as observed by them for the user. Now bear in mind that a caller won't get topics that are blocked by the user in Chrome settings and no caller will get any topics if the user has turned off topics in settings. Chrome Enterprise administrators can also set policies to control settings for topics and other privacy sandbox APIs. And a site can opt out of topics calculation for all users on a page by including the permissions policy, browsing topics equals empty brackets, permission policy, response header. Alternatively, a site can control which third parties have access to topics on a specific page. Now, this example disables use of the Topics API within all browsing contexts except for the site's origin and adtech.a.example. The Topics API has to make sure the topics that it shares with callers are up to date. And Topics does this by periodically refreshing the topics for a user that it returns to the caller. Topics are calculated based on the user's browsing activity during a period of time known as an epoch. And currently in Chrome, an epoch is one week. But bear in mind that epoch start time is different for each user. The API returns up to three topics, one from each of the preceding three epochs in random order. In other words, one for each of the last three weeks. Topics, of course, are only returned to a caller if they've been observed for them for the current user. Now, this means that the caller will get less than three topics if they haven't observed the topics for all three epochs. The topic returned to the caller for each epoch is randomly selected from the user's top five topics for that timeframe. If fewer than five topics were observed for a user during an epoch, then random topics are included to make up the top topics. And to further enhance privacy and to make sure that all topics from the taxonomy may be represented, there is a 5% chance that the topic for an epoch is randomly selected from all possible topics in the taxonomy. Topics for a user are recalculated for a caller depending on the top level sites. So for example, if AdTech A has a presence on news one dot example, news two dot example and news three dot example, topics returned to AdTech A for the current user will be recalculated on each site. And this means that a caller is highly likely to get different topics for a user on different top level sites. And that makes it harder for a caller to identify a user by their topics since these will be different across top level sites. So to sum up everything, topics are provided per caller, per user, per epoch. The Topics API only returns topics a caller has observed and up to three topics are returned by the API. One for each of the previous three weeks of browsing activity, randomly selected from the top five for that week. The topics for a user that are returned to a caller are recalculated for each top level site. So that's the Topics API. To find out more about topics, check out our article on developer.chrome.com. Chrome engineers have built what's called a co-lab for topics. This is a data analysis tool that combines code, output and descriptive text into a collaborative document. And you can load the TF Lite model file used by topics into the co-lab and then use that for experimentation. We have two demos for topics, one that calls document.browsing topics from an iframe and ones that shows how to use request and response headers with fetch. If you have comments about the API design file and issue on the explainer and if you have feedback or questions about this video or any questions about using the API file and issue on our Privacy Sandbox Dev Support repo. To find out more about Privacy Sandbox on Android, take a look at the SDK and API documentation. So thanks for watching and be sure to check out the other videos in our Privacy Sandbox series.