 Welcome to the Chrome Enterprise Technical Community Hour. Today, we'll be discussing the Privacy Sandbox and the third-party cookie deprecation. My name is Rich, and I'll be your host for today's presentation. Joining me is Daniel Kane, who's a business development lead for Chrome Enterprise and Sam Dutton, a developer advocate for Privacy Sandbox. To start out today, I'll first provide a overview of the CER program and the Technical Community Hour. After that, I'll hand it over to Daniel and Sam, and they'll cover third-party cookies, deprecation timeline, what you can do to prepare, and additional information on chips and other alternative APIs. Today's Chrome Technical Community Hour is brought to you by the Chrome Enterprise Recommended Program, which is Google's partner program for third-party solutions that are optimized for Chrome OS or integrated with Chrome Browser. This webinar brings you the opportunity to engage with our team about new features and updates, enterprise development best practices, and our enterprise strategy. Now, without further ado, I'll hand it over to Daniel, and he'll kick us off. Daniel? As Rich mentioned, in this presentation, we're going to focus on third-party cookies. We'll quickly touch on what third-party cookies are, how they're used, and why the web is beginning to move away from this approach. Chrome has published a timeline for third-party cookie phase-out, and we'll share that and give a bit more context. And we'll then talk about the impact of these restrictions, some steps that you as a service provider can take to mitigate any impact that your users may experience, and then we'll look at some new and alternative web APIs and web standards that are available as alternatives to third-party cookies. So, as I'm sure many of you are aware, a third-party or a cross-site cookie is one that's set from a different origin to the top-level site that the user is visiting. These cookies might be set by a page that's embedded inside an iframe or potentially as a third-party script that's embedded onto that top-level site. So, some of the examples for where you could use a third-party cookie like this might be that you've got different top-level domains per country. So, for example, .code.uk and Anna.com, or that you are using a CDN or potentially another origin to host static content and even potentially single sign-on flows. But the key thing to note here is that third-party cookies are often used to provide crucial functionality to websites. Again, a few more examples shown here, and it's not just about advertising. And the reason that we're looking at restricting third-party cookie usage in Chrome is because cookies have proliferated across the web and they are being used for a lot of functionality that they were not originally intended. And this has led to potentially users' privacy being eroded and users being tracked across the web. So, as we mentioned, Google are making some changes here to restrict third-party cookies. But along with that, we're also launching new alternatives to cookies. And these new technologies are more privacy-preserving and Sam will get a bit deeper into some of these. But there are quite a few technologies been launched. Some are aimed primarily at ads and content type use cases. We've got some across measurement. We've got things for cross-site boundaries, which is where we'll focus the majority of this. And then there's some technologies that we're launching that are primarily focused at spam and fraud protection. And then just to touch on that timeline, so Chrome has already started to restrict some third-party cookie usage. So from the start of January 2024, Chrome has restricted usage for 1% of users across the web. And subject to addressing any remaining computation concerns that make them up from the UK's competition. And our Marcus Authority of Chrome's plan is to start to ramp up this third-party restriction through the end of 2024, Q3, Q4, 2024. So with that in mind, we're going to take a look at the steps that you can take to start to prepare for this phase out. And specifically, looking at ways that you can audit your usage of third-party cookies and test for breakage. And right now, the main thing is to see if you have breakage, how do you mitigate that, and then how do you start to look forward towards what types of solutions you can use to move away from cookies in the longer run. So the first step is to audit your usage of third-party cookies on your web apps and web properties. So the way that you would do this is you would be looking for cookies where you are setting same side equals none. So for example, this could be in a HTTP header, or potentially through JavaScript. So looking through your code base and trying to identify these cookies is a good place to start. And Chrome has also added some functionality to help with this. So in DevTools, any third-party cookies that have been set in this way will now throw an issue. So you will see that under Console, you will get these flagged issues, and then you'll be able to dig a bit deeper into each of them to see what the cookie is and how it's been set. And just recently, we have also launched the Privacy Sandbox Analysis Tool. Or PSAT. And this is a Chrome extension, which is open source. It's available on GitHub. It's also in the Chrome Web Store. And by adding this extension into Chrome, it gives you an easy way to analyze all of the cookies that have been set by your web pages. So as you can see in the screenshot, from the dropdown for the extension, you can see the first and third-party cookies that have been set. And it attempts to single out ones that are functional, ones that are marketing, ones that are based on analytics, and then any that it's not aware of it will book it as uncategorized. The PSAT also integrates with the DevTools. So if you have DevTools open, you'll get a new tab within your DevTools, and that will let you build down and get a lot more information on the cookies that you've got set. So once you've done some analysis and you know what cookies you're setting, the next step will be to check and see if these cookies are going to break functionality if they are disabled. And again, Chrome has some tooling for you for this. So there is a flag, which is test third-party cookie phase out, which you can set. This can be set either via the Chrome Flags page or via the command line when you're launching Chrome. And our guidance here will be to do parallel testing, to run tests with both third-party cookies enabled and third-party cookies disabled, and then to check for differences in your functionality. And if you do find that there is functional breakage from cookies, third-party cookies been blocked, you can report those breakages to Google at go.gle forward slash report dash three PC dash broken. This will open a bug. That our engineering team will create and then it will be able to provide some guidance to you as to what options you have there. Again, as part of our Chrome Enterprise Recommender Program, this is a key ask that we were asking that you go and you test for breakage and report anything that you find. So then once you find a breakage, right now there are a number of mitigations that you can take. And the first of those that we're going to look at is deprecation trials. So we've got two deprecation trials open at the minute. The primary one is our third-party deprecation trial and this is a deprecation trial that's available to service providers that embed into a third-party context. So if your solution is the one that's been presented within the iframe or it's your script that's been embedded onto other sites, then this is the correct deprecation trial for you. So essentially this lets you register with Google that there is a breakage with your product and with your service and then get access to this deprecation trial. Once you're on the deprecation trial, you'll be able to continue to set third-party cookies in a third-party context like this. There is currently a grace period open. So if you apply now for the deprecation trial, you have until April 1st where just being registered and being part of the trial will allow your cookies to continue to be set. For this to continue to work past April 1st of this year, you need to apply a deprecation token and again we'll provide links with more detail on that. But that's the standard process for deprecation trials and origin trials at Google. So if you've been part of an origin trial before, you should be aware of the trial tokens. There's also a second deprecation trial that we're running right now which is a first-party deprecation trial. So this is aimed at the top-level site. So if your use case is that you have other third-party setting cookies on your top-level site and it's not reasonable for all of those third-parties to go through the third-party deprecation trial, you can apply for a first-party deprecation trial. Again, this is the grace period that I mentioned in place. So from now until April 1st of 2024, just being part of the registration and being in the deprecation trial will allow those third-party cookies to continue to be served. And then if you need this functionality for longer, up until later in this year, you would need to apply the token as per with the third-party deprecation trial. There are also mitigations available to your enterprise customers. So again, this would be the users of your product. So those customers who are managing Chrome browser in their estates, they have a number of policies that they can use to continue to allow third-party cookies to persist. So the first one is called block third-party cookies. They can set this to false. And this is quite a wide ranging policy. It will continue to allow third-party cookies to be set across all domains. There's also a much more granular policy that they can use cookies for URLs, which allows them to specify URL patterns that you continue to have third-party cookies set. So again, this is primarily aimed at enterprise customers who are managing Chrome browser in their estates. But again, good for service providers if you're aware. And then you have the ability to provide that guidance to your customers. So with that, I'm going to hand over to Sam, who's going to go a bit deeper into chips. Brilliant. Thanks, Daniel. Yeah, I'll just take over presenting there and over to chips. If you haven't tried out chips, you should check them out. So cookies having independent partitioned state chips are cookies that are set with a partitioned attribute. Now, the partitioned attribute allows developers to opt a cookie in to partitioned storage. You know, it's as if each top-level site has a separate cookie jar. So for each domain that sets a cookie. And now that's good for privacy and use of privacy and security. But it also means a cookie won't be blocked by third-party cookie deprecation. So without cookie partitioning, a third-party can set a cookie from an embed on one side, like one top-level side, and then access that same cookie from an embed on another top-level site. Now, with cookie partitioning, a cookie is tied to the top-level site where it's initially set, and it cannot be accessed from anywhere else. So you can think of chips, kind of double-keying cookies, you know, keyed by the top-level site, a partition key, as it's called, as well as the domain setting the cookie, which is known as a host key. Anyway, just to warn that chips must also have the secure attribute set and is also recommended that you set a host prefix for the cookie name. And that binds the cookie to the host name and not just the registrable domain. Difficult to say that. You can find out more about support for chips from our documentation. Recommend you take a look at that. We'll share links with those later. So related website sets, if you haven't heard of these, it's a web platform mechanism to help browsers, kind of to understand the relationship between a collection of domains. You know, for example, you might have sites across different country domains, you know, say, or maybe with different brands from the same company. You might have, like, apps, service, sandbox domains, and so on. And related website sets allows you to declare domains as belonging to the same set in order to allow some limited cross-site cookie access for specific use cases. Now, to set up a related website set, you first need to provide a JSON file in the well-known directory on your websites that specifies the structure of your set. And then you submit your set to the related website sets repo on GitHub, which you can see here on the slide. And the repo maintains the canonical related website sets lists as a publicly viewable JSON file itself. So once you've ordered, you know, audited your sites for third-party cookies and tested for breakage when they're blocked and consider these other alternatives, you know, you really need to look to these technologies that are kind of built to meet your use cases in the absence of third-party cookies. We won't go into all the details here, but Privacy Sandbox provides a range of technologies that have built to handle all the use cases that are currently met by, you know, using third-party cookies for identity, for fraud protection, and ad relevance and measurement, and for cross-site storage. One thing in particular I'd recommend here is if you have ads on your site, speak to your ad tech providers and ask them how they're preparing for third-party cookie deprecation and if they're testing the Privacy Sandbox ads APIs. You'll learn more about all this from our cookie countdown resources. And yeah, one big thing here, you can also report breakage of your own site or other sites by creating an issue on the third-party cookie deprecation breakage repository. And you can do that by following the report 3PCD broken link that's shown here on the slide. Now, the repo helps developers understand where users are experiencing problems and how breakage is being fixed. And of course, it can also help us support you. Thanks, Sam. And Daniel, too. In closing, please visit the Chrome Enterprise Developer website. And on that website, there's more information on there to supplement your learning. This concludes today's webinar. Thank you for joining and enjoy your day.