 Hi, I'm Muth. It's good to be here. Thank you all for joining. I'm a developer relations engineer for web privacy and security, and I work together with Rohan within the Chrome organization. Now, in the previous session, Rohan talked about how you can engage in building a more private web. And together in this session, we'll take a closer look at what you need to know and do to prepare your sites and systems for this more private web. And this is valid whether or not you have anything advertising related in your stack. To quickly refresh on what Rohan introduced with the privacy model, we want to move from a join identity to a partition identity. And anti-tracking efforts help us do this, because they phase out or replace mechanisms that enable identity joining. And today, one primary mechanism that's used to join user identity across sites is third-party cookies. And this is why Chrome will be phasing out third-party cookies. So what does this mean for you? Before I get into this section, let me say that there's a wide variety of ways sites use cookies. So how you adapt your site to cookie changes depends on how your use case and constraints look like. So I'll only give you a high level view, but we'll share links to everything you need to know. So cookies are changing and how can you prepare for this? Well, first, if you do the following, you're on a good track. First, use HTTPS everywhere. And second, make your cookies look like this when you can. This is a good first-party cookie. And you can tweak this base recipe to fit your needs. But let's take a closer look at what this recipe does exactly. So host is a prefix. What this means is it works like an interface in the sense that it makes some attributes mandatory and forbids others. So with host, more specifically, the attribute secure and path slash must be in. And the attribute domain must be out, which is why you cannot see it here on this slide. I won't detail secure and HTTP only too much here, but they help protect cookies from being stolen, either on insecure networks or by malicious third parties. Now let's move on to path slash. Path goes hand in hand with an attribute that's called domain. And domain is not set here, as we've said. So it means that the cookie is accessible only at the domain that sets it. So the domain of the current document, not even in subdomains. If you need one session across subdomains, you can tweak this base recipe. And path slash means that the cookie is accessible in all pages for that origin. So with this, the cookie for example.com will go on every request to example.com, but in no request to images.example.com. Finally, same set lacks. So this restricts the cookie to only be sent in requests that match the top-level sites the user is currently visiting. Except for navigations. So with this, you're not sharing your cookie with third parties. And as you know, last year, same set lacks has become the default in modern browsers. But even though it's the default, it's still good practice to specify it anyways. So same set lacks by default actually has two main benefits. First, sites that won't state in cross-site requests must now opt in with same set none. So now third-party cookies are labeled as such. And this is one step towards phasing out third-party cookies. And the second benefit is improved protection by default. Again, cross-site request forgery attacks. So you see that cookie changes have both privacy and security benefits. And this is a pattern that you'll see across a lot of anti-tracking changes. Now, remember earlier, we said that the best option was for you to fully migrate to HTTPS. And another push towards HTTPS by default being your easiest option is skimful same site. So last year, after a same set lacks by default, it meant that cross-site cookies would be blocked by default. And now with skimful same site, what this means is that different schemes, so HTTP and HTTPS, now also count as cross-sites. So this further restricts cookies from being shared between HTTP and HTTPS. So long story short, if you migrate fully to HTTPS, you shouldn't have any issue here. Now one quick note on WebView and cookies, because I think we had questions on that. The cookie changes that we have just introduced kick in if you target Android 12 and newer. So existing apps will not be affected until they choose to target Android 12. So what you can do today is either try and target Android 12 and see how your cookies behave in the resulting build. Or if you can't target Android 12 just yet, if you cannot target Android 12, you can enable the new cookie behavior with this specific flag. Now back to our cookie recipe. It's nice, but there's a chance that it's not enough for your use case. For example, what if you have different country-level domains for your organization and you want to use cookies in those contexts? Well, since the same site changed last year, you would need to set same site none if you want the cookie to be sent in that case. And yeah, it's cross-site, but it doesn't really feel like it's third-party. It's more of a first-party relationship that's wider than just one site. So building up on last year's same-site changes, there is now a proposal to define exactly that relationship. And this proposal is first-party sets and the same-party cookie attributes. And to loop in the concepts Hane introduced earlier, if you have first-party relationships that are wider than just one site, it means that you're potentially an implementer for this API, first-party sets. Now it's at an early stage, so there are still open questions. But if those questions are interesting for you, an origin trail is available for first-party sets. Maybe, though, this is not enough and you actually need some information to be transmitted across parties. And if you're doing this today with third-party cookies, it means that you need to replace them with new alternatives. And this is where new purpose-built APIs come in. So new APIs are designed to fulfill use cases that show today's web, but they do so in a privacy-preserving way. Some of these new APIs are ads-focused, so focused on advertising use cases, and a lot of them are named after birds. In the previous session, Rohan introduced you to one of the rare ads-focused API that is not named after a bird, namely the Conversion Measurement API. Here in this session, I won't detail any ads APIs, but instead we can look at another new API that's under the Privacy Sandbox umbrella. And this API is Trust Tokens. So Trust Tokens allow a site to issue tokens to the browser, and these tokens include a small amount of information, like a signal that says if the site thinks the user is real or a bot. And then later on, other sites can redeem and verify these tokens, for example for fraud protection or spam protection. And Trust Tokens is interesting because it aligns with the privacy model in the way that the tokens cannot be linked with the individual user, but they still allow the bit of cross-site information that is needed for this specific use case. So new APIs like Trust Tokens and Ads APIs are helpful, but we also need restrictions on how a few APIs are working today. And we want to apply these restrictions while maintaining the usefulness and capabilities offered by these APIs. And balancing privacy and usefulness is another pattern that you'll recognize across Chrome's privacy efforts. Now first, let's look at some interesting headers. User agent client hints or UACH if you're in a hurry. So today, like on this slide, the UA string can be used to fingerprint users and join their identity across sites, which is why we're trying to walk away from with the new model, privacy model for the web. And what makes it worse is that the UA string, the user agent string, exposes all of the user information by default. With user agent client hints, UACH access is managed in an explicit way instead. So you do receive some broad values by default like browser name and others, but if you need more specific information, you would need to ask for it. And the way this works is the server asks client hints like platform or platform version by a header, and then the browser sends back only the requested headers. And UACH is an alternative to the user agent string, and also the first step to reducing the granularity of the user agent string. Benefit of UACH is that it also offers a better developer experience in the sense that you don't need regular expressions to go and extract the bit of information you need in an endless UA string, but you get just the data you need instead. And with this, we want you to be able to access the information you need in a privacy-preserving way, and we think user agent client hints does this. It should allow you to migrate from the user agent string, and it's already out. It's live in Chrome stable, but we're still using your input and feedback to adjust things, to adjust the API and make sure it addresses your use cases. So try it out, and if something is stopping you from migrating, let us know and share your feedback. One last bit we're almost through. So earlier today, you heard about Core Web Vitals, and maybe you're already doing performance budgeting. Well, Chrome also proposed introducing a privacy budget, and the idea is that sites should be still able to use powerful APIs, but not to uniquely identify users across sites. So here you find the same pattern, again, balancing privacy and capabilities. The privacy budget is at a very early stage, so you cannot try it yet, and it will not be enforced soon, but it's definitely a good idea to already try and reduce the amount of potentially identifiable information you're using. And for example, user agent client hints help you do just that, so it's a good way to prepare for what's coming. Right, that's all I have for this presentation. There's more, but it was already a lot for 15 minutes.