 Hello there. I'm Ron from the Chrome team, and I'm going to tell you about Privacy Sandbox for the web. Specifically, I want to talk about the pros and cons of third-party content on the web today. Then I want to show you the privacy model behind the Privacy Sandbox proposals that addresses these issues by partitioning identity by first party, while still retaining the functionality we need. And then we can go into detail on how this model applies to cookies so that you can see what you may need to do on your site. So first, let's talk about the functionality that we want to keep. When you build on the web, you never have to start with a blank canvas. There are clues right there in the name, the web, the internet. It's all about connections between different sites, composable building blocks to create amazing things. Now this spans all the way from a basic link or including an image from another site up to pulling an entire JavaScript library or embedding cross-site content within the iframe. And because this is all built on a foundation of open standards, it's resulted in an incredibly rich and varied ecosystem that's not owned by any one entity and is open for anyone to participate. When you have your own site, it's entirely your choice what you do with it, whether that's just sharing amazing cat pictures or running an entire cat care business as your day job. The thing is, inviting a service onto your home page is a lot like inviting someone into your own home. You're giving them a level of access and visibility, and that requires a level of trust. For example, pulling in third-party JavaScript gives them access to the content on your page. And that's expected because generally you actually want that JavaScript to do something. Now, there are a number of things you can already do to secure your page. I'm not covering them in this session, but you can check out our guides for more details. And that's because what I want to cover is how this access by third parties can leak out beyond the confines of your own site. Now, that third-party service may be setting a cookie as part of its functionality. If it's a map widget, that cookie might store something simple like a color theme preference or perhaps a favorite store location. And that's what we call a third-party cookie. Now, there's nothing inherently bad or scary about it. It's functionality that I want as a user. But if we throw another site into the mix that's using the same widget, then now, when I browse both these sites, it's the same cookie being sent. And that opens up some implementation issues for the service. If the cookie is for a color scheme, that's probably OK. I'll get the same look on each site. But if it's for a favorite store, though, that might not make sense across different sites. Or the third party may be explicitly setting a unique identifier that means they can directly link my activity on site A and my activity on site B. And this is what we mean by cross-site tracking. Our aim with Privacy Sandbox is to remove this ability from the web platform. However, when I say remove this ability from the web and that we're going to phase out support for third-party cookies, I don't mean we just straight block them. You can already try this in your browser today by blocking third-party cookies and browsing around. All that functionality, like state and embedded widgets, shared commenting, iframes embedding other protected documents, either breaks, or developers are finding creative hacks and holes to try and work around what the browser and the user is trying to prevent. So we have a problem where the same web functionality that delivers valuable third-party experiences also enables cross-site tracking. So let's go with some motivations and principles before we talk about exactly what happens on cookies. This is the balance to try and strike. As both a user and a developer, I want third-party services to be something I can easily and safely include as part of my browsing and coding. Now, at the same time, I want to ensure that cross-site tracking is hard. As a user, I don't want to worry that my activity on one site will leak into another. And as a developer, I want to reduce the risk that data between my different client sites might start conflicting. Our aim with Privacy Sandbox is to try and tackle this at the level of the platform, the level of web standards. Because that's where the challenge exists. Each of the proposals I'm going to talk about are proposals for new or updated standards with the intent that we can find solutions that work across browsers. Now, that's not something we can just decide on our own, though. We need feedback and input from developers like you to work through the process of progressing from a proposal to a standard that has support for broad adoption. Now, with Privacy Sandbox, we're proposing to move to a model of the web that is partitioned by first party. Let's see what that means and how that would work. One, identity is partitioned by first party site. Now here, identity just means that my browsing activity on the blue site is separate and distinct from my browsing on the green site. By partitioning these identities, we're creating a privacy boundary around them. We want to stop information that could allow these identities being joined from leaking through that boundary. Now, that spans explicit identifiers like a value in a cookie or passive properties like comparing a visitor's user agent string or IP address. The default location for the partition is at the site level, providing a roughly equivalent mapping of the first party to what you see in the browser's location bar. OK, number two, third parties can be allowed to access a partitioned first party identity. This is where we allow a third party to work within our privacy boundary. So my embedded map widget from before can save my favorite store, but that preference stays within the partition. When I visit the second site, it's a clean slate. No crossover or conflict with my activity on the previous site. And finally, three, only small amounts of first party identity can be shared across site. The key here is that the information shared across the privacy boundary cannot be enough to join those two identities. And there's an important distinction here. A person might choose to explicitly join their identity across sites. For example, shared commenting service, where I comment as the same user across multiple sites. But we don't want to get all forms of cross-site interaction behind a login. Several of the privacy sandbox proposals provide this link that lets you get value from a wider third party service without enabling cross-site tracking. Now, I want to show you how that works by using the new topics API. And then we'll get back into cookies. There's a bit more to topics than I'm covering because I want to focus on the flow of information. If you want to learn more about it, we have the documentation up here and the API is available for testing feedback now. The intent of the topics API is to help with interest-based advertising use cases by providing topics of interest for the user based on the sites that they visit. But vitally, without sharing that activity in a way that would allow for cross-site tracking. Okay, let's say you want to provide me with an ad tailored to my interests using topics API. Each time I visit a site that uses your service, you would call the browsing topics method to observe the site's inferred topic. On one site, I might be looking at new plants and that site may have the home and garden topic. And that gets recorded in my browser as the topic your service is seen. Now later, I'm back looking at cats again. So on the site, on that site, the pets and animals topic is registered. And then when I'm visiting a site where you want to show an appropriate ad for me, along with recording that your service has seen the given topic for the site, the browsing topics method also returns a selection of relevant topics for me. And your service can use that to help select a useful ad for me. We can see our third principle being applied here. Only small amounts of first-party identity may be shared across site. And remember, identity here means those aspects of identifying information that could allow the third party to join my browsing activity across sites. Instead of getting visibility into the exact page that I visited, the information is distilled down to just the topic associated with the site. Instead of a third party needing to take all that raw data to get the answer, we can provide a purpose-built API that still provides the end result. I can get my tailored cat content, but without that third party learning about the specific cat-related sites that I visited. Topics is also available for testing now, along with several other Privacy Sandbox proposals. Now, if you provide third-party services around content personalization, advertising, fraud protection, identity, or similar, then you should be taking a look for opportunities to test, and we would love to hear your feedback on this as well. Okay, with that, let's get back into how we apply the Privacy Model to cookies. We already started this journey back in 2019 by making first-party access the default for cookies by changing the default for the same site attribute. Now, previously, if you've set a cookie like this on your own site, you may have been surprised to discover that that same cookie would be sent in cross-site contexts. So, in a way, every single cookie could be a third-party cookie unless you said otherwise. So, we changed the default value to be equivalent to same-site equals lax. And what that means is that by default, cookies are restricted to first-party contexts only. And if you really did want to provide a third-party cookie, then you needed to explicitly opt in by adding the same-site equals none and secure attributes. Now, what this also means is that now, you have an explicit list of your third-party cookies, as in anywhere without your setting that same-site equals none attribute. You will need to review these cookies to take appropriate action before the full phase out. We have two proposals that you can apply here, chips and first-party sets. We're gonna start with chips to see how it applies the partitioned approach from our privacy model. So, again, here's the current situation. Setting same-site equals none on a cookie means that same cookie is sent in all these different cross-site contexts. And that's iframes or a sub-resource requests. Now, if we label up our sites, then we see that the reason for this is because we have just one cookie jar for site C, and that's regardless of context. So what's the missing ingredient here? Well, instead of lumping everything together, we want cookies having independent partitioned state, which gives us the convenient and totally natural acronym of chips. Now, by setting the partitioned attribute on the cookie, you opt into a cookie jar that's partitioned by top-level site. That means there's no more overlapping cookies from site C when they're accessed on site A or site B. So if site C had a favorite store cookie, then I'm going to keep separate values for that across those sites. Partitioned also requires that you set the path equal to slash and do not set the domain attribute. That means the cookie won't be sent to sub-domains. This is generally a good practice anyway, as it's another reduction in scope for the cookie and less for you to worry about. You can also use the host prefix on your cookie name here, which is a convenient convention to enforce those rules. So if your use case for a third-party cookie fits into this one-to-one embedded model, such as providing separate widgets or APIs per client, then chips and this partitioned cookie represents a clear improvement for you in terms of reducing complexity and reducing the risk of cross-site data leaks. You can also try this right now. For your own testing, we have the partitioned cookies flag that you can enable to try the attribute. And if you're watching this during I.O., then we are currently running an origin trial from Chrome 100 through to the end of Chrome 103 or up until about the beginning of August. Now, origin trials mean you can try chips on your own site with production traffic. This is absolutely critical for us because origin trials are a key route for us to get real-world developer feedback on proposals to ensure that we're building something that is going to meet your needs. Again, full instructions up on this blog post and we're around on Twitter and GitHub to hear your feedback. Okay, the other proposal is first-party sets and the same party attribute, which allows you to define a larger privacy boundary than just one site. If we go back into our earlier setup and our model, where we said identity is partitioned by first-party site, site is just a convenient default. There are several situations where the same party can own multiple sites and wants to treat them differently from sites that are owned by someone else. For example, you may have different country-level versions of your service, or you may have separate sites to provide separate functions provided under the same banner. The challenge is that currently, if I want to share a cookie among my own sites, I need to set same site equals none. And if I do that, then the cookie will be sent on any cross-site request, which gives me additional security risks that I need to try and address. Now, I don't want to use chips in this situation because while it would protect my cookie from being shared with the malicious site, it also puts all my sites into a separate container. If I'm trying to do something like single sign-on or a shared shopping cart, this doesn't work. First-party sets provides a method where we can define that set of sites that we own as in the sites that are first-party to each other, and then we can mark our cookie to only be shared among those sites. This involves two bits of configuration. First, we define the first-party set, which has one on a site and a list of member sites. Then we can update our cookie with the same-party attribute to enforce only sending the cookie within our defined same-party context of that set. You can see I'm also using same-site lax here. Now, normally, this would restrict the cookie to just a single-site context. But again, because we've used the first-party set to expand our privacy boundary, I can still set the lax value and only have that cookie sent inside of my set. First-party sets are also available for developer testing behind a flag. We have previously run an origin trial on this, and we're continuing to update based on the feedback that we've been receiving, figuring out things like what makes the right policy for a valid set. So if you think this may apply to your situation, got all the details up on the developer site for you to get testing. With that, I hope you've got a better understanding of the model behind the privacy sandbox proposals, and I want to leave you with a little recap on what you need to do to prepare for the third-party cookie phaseout. First, make sure you review and have a list of your own cross-site cookies. This is anywhere that you are currently setting the same-site equals none attribute. These are the cookies where you may need to take some kind of action. Next, if your use case for that cookie is in some kind of one-to-one or wholly embedded situation, like a self-contained component in another site, then look into chips. You can add the partitioned attribute, and with the current origin trial, you can test on actual production site too. If your cookie is used across multiple sites, but only across sites that you own, then you should investigate first-party sets. There are flags available for testing, and you can also use that to check how this would behave on a set of sites that you can define. Now, if neither of these proposals meet your needs, then you will need to investigate the wider set of privacy sandbox proposals for APIs, such as topics, where we are replacing the need for a cross-site cookie with a purpose-built API for the use case. So with that, thank you for dropping by. I hope you've got that better understanding of the model and applying it to your cookies. You can find all this material and more up on our developer site, and the team and I are always happy to hear your questions over on Twitter, on GitHub. So I'll see you there.