 Hi, I'm Helen and I'm a Product Manager on Privacy Sandbox. Hi, I'm Goss Saba and I am an Engineering Manager focusing on private, general-purpose and anti-fraud technologies in Privacy Sandbox. Today, we're going to focus on the Privacy Sandbox for the web and share what you can do today to prepare your sites for the end of third-party cookies. The Privacy Sandbox is a suite of proposals to help tackle the problem of pervasive tracking and address the needs of the web and app ecosystem. As these changes are rolled out to Chrome and Android. As part of this effort, Chrome will soon be deprecating support for third-party cookies. Check out privacysandbox.com slash timeline for the latest information. We've already made some progress in removing tracking vectors in the web. HTTP cache partitioning shipped in Chrome 85. User agent string reduction, which we began via a phased approach in Chrome 92, will be complete in Chrome 113. Network state partitioning shipped in Chrome 108 and storage partitioning is also starting to roll out in Chrome 113. If your site has embeds that depend on storage such as index DB, local storage and session storage being accessible across multiple top-level sites, check out the link under storage partitioning for more information. This is great progress. We're excited about the changes we're bringing to Chrome to make sure users feel safe and protected against pervasive tracking on the web. To learn more about how the privacy sandbox tackles the issue of pervasive tracking and our web standards approach, make sure to check out last year's IOTalk too. As we get closer to the end of third-party cookies in Chrome, we want to make sure you're all set with the knowledge and the tools to prepare your sites. We're excited to share with you today that the tools that you need to migrate away from third-party cookies like first-party sets and chips which stands for cookies having independent partition state are now available to implement. Make sure to follow along with this video, especially if you're responsible for one or more sites since you're probably using cookies somewhere in your code to make sure your website is delivering a great experience to visitors. And some of these cookies might be third-party cookies. To begin, we're going to go over how to identify third-party cookies in your code and then review what you can do to replace the functionality they currently provide. Then, we're going to go over Chrome's web standards proposals for new cookie behavior, which we're shipping now in Chrome. We hope this will help you identify when to continue to rely on cookie behavior in Chrome and when to turn to third-party cookie alternatives like purpose-built APIs. Following the session is a great start. There's certainly no time like the present to start preparing for third-party cookie deprecation in Chrome, especially since first-party sets and chips are available to integrate with right now. To help you get a sense of how to begin preparing, we're going to review how to first identify third-party cookies in your code. Cookies can be first-party or third-party relative to the user's context, depending on which site the user is on at the time. This distinction between first-party and third-party contexts on the web isn't always obvious, and the effect it has on different resources can vary. Generally speaking, cookies that are sent in cross-site contexts, like iframes or sub-resource requests, are referred to as third-party cookies. One way you can identify how your site is using third-party cookies and what potential breakage this might impose is to block third-party cookies on your own machine and browse through your site. You can open DevTools here to help you investigate. First, to identify which cookies are blocked, navigate to the Network tab and load your site. You can filter down using the third-party request checkbox. Select a specific request and then click on the Cookies tab. Then click on the box to show filtered out request cookies to see what cookies have been blocked on the request and response. If you are blocking third-party cookies, you'll see the tooltip indicate user configuration as the reason for the cookies being blocked. We know that was a lot to follow, so we've put together instructions on how to navigate DevTools here. Make sure to check back in regularly since we'll be updating materials as we create more tools to help you. Another way to look for third-party cookies is to examine your code base. In 2019, Chrome changes cookie handling, restricting cookies to first-party access by default. This means that now you can identify any cookies used in third-party context today with the same-site-none attribute. Pro tip, using Ctrl-F same-site-none can probably help you here. Now that you have your list of third-party cookies, the next step is to investigate how or why they are being used on your site. Knowing this will help you consider whether cookie-based solution like chips and first-party sets or an alternative API is most appropriate for your use case. To help you with this task, we'll review the use cases we're aiming to solve with updated cookie functionality to replace default and passive access to third-party cookies. Thanks, Helen. As you might have guessed from how they're used in your code, while third-party cookies pose privacy challenges for users, they are also a critical component to functionality on the web. Third-party cookies enable the composability of content and services, which in turn enable the creation of engaging and helpful experiences for people around the world. Examples of services that rely on third-party cookies include embedded maps and chat service widgets on a retail website or shared login infrastructure across an organization's brands or country-specific website. Even as we take measures to protect users on the web, we want to make sure developers continue to have ways to create seamless and joyful experiences for users. Over the past few years, we've engaged with developers and other stakeholders in the World Wide Web Consortium, or the W3C, through public discussions on GitHub and at various conferences. Developers like you have helped us identify critical use cases and develop solutions that serve the ecosystem as a whole. We've addressed certain needs through purpose-built APIs like the Topics API and Federated Credential Management, or FedCM. For other use cases, we propose web standards to limit cookie usage to more secure and private mechanisms. A couple of the proposals we collaborated on are now shipping in Chrome, our chips and first-party sets. We'll now go over the two proposals, including the changes we've made to both based on feedback from web developers. One common set of use cases for third-party cookies is the use of third-party libraries or services. An example could be an embedded map showing store locations or a chat widget providing customer support. In this case, the vendor needs to maintain cookies or state, such as the user's preferred store location on a per-top-level website basis. This is where chips, an acronym for cookies having independent partition state, is useful. All you need to do is add an additional cookie attribute, partitioned. The nice thing is, since browsers simply ignore cookie attributes that they don't recognize, your cookies will continue to work as before on clients that don't yet support chips. By specifying this additional cookie attribute, your cross-site cookie automatically gets a different cookie jar on every top-level site it is embedded on, thus preventing the ability to track users across sites. Chips will allow you to ring your users a more private experience now. You don't have to wait until third-party cookies are phased out to migrate your website to using chips. If you've looked at chips before, you should know since the last time we introduced chips at I.O., we've made two changes that we hope make the feature easy to adopt for many applications that currently rely on third-party cookies. Both changes were made based on feedback provided to us by web developers like you during the incubation process in the W3C. First, we've removed the host prefix naming and host name boundedness requirement. While the original intent behind the requirement was to encourage security best practices, many developers told us that they currently reuse cookies across subdomains and that this requirement would place a significant adoption burden. Second, we've changed the previous cookie limit of 10 cookies per partition to a dynamic memory limit of 10 kilobytes per partition. This allows developers the flexibility of using a small number of large cookies or a large number of small cookies. Before we jump into first-party sets, here are some quick links to more resources on chips. Let's now talk about first-party sets and how the proposal facilitates cookie access to support user-impacting functionality across sites with a first-party relationship. If you've been following the progress we've made on Privacy Sandbox over the past year, you may recall that first-party sets has evolved to respond to feedback raised by developers, other browser vendors, and stakeholders in the web ecosystem. The change reflects our effort to meaningfully collaborate and listen for opportunities to improve the proposals we bring forward. For those who are relatively new to first-party sets and also those revisiting first-party sets after some time, we'll begin with a brief overview. The browser currently uses a site-level boundary to interpret first-party versus third-party. When Chrome deprecates third-party cookies, this interpretation can be limiting for organizations that rely on third-party cookies because their web architecture is designed to utilize multiple domains. For example, an organization may have one domain for their hiking block and another for their camping store and want to support user journeys across those sites. An organization may also maintain multiple country code domains with shared infrastructure for their web service. For cases like these, we set out to create a solution that's aligned with such organization's needs while preserving users' expectations for their privacy on the web. First-party sets is a framework for developers to declare relationships between domains. The browser can then make decisions regarding access based on the third-party domain's relationship to the first-party domain. A set may enjoy first-party benefits including continued access to their cookies when the top-level domain is in the same set. In this framework, there are three different purpose-built subsets to meet key use cases on the web. The first is for country code top-level domains like .ca or .de. If you maintain sites with different CCTLDs for localized experiences and these sites still require access to shared services and infrastructure, this subset may help retain functionality for you. The second is for service domains. For this subset, you can identify domains your organization relies on for security or performance purposes that require access to a user's identity to perform their functions. The third is for associated domains. Your organization might maintain multiple sites for different related brands or products and you may want to understand user journeys across related sites to better understand how your user base interacts with your sites or to remember a user's logged in state on a related site relying on the same login infrastructure. Sets are submitted by developers and to ensure integrity of the sets. There are subset-specific policy requirements, corresponding technical validation checks and specific browser handling behavior. You can check out the submission guidelines for more detail. For domains within a set, third-party cookie access will be facilitated by the Storage Access API a mechanism for a site to actively request access to its cookies while in a third-party context. In addition to the Storage Access API, we have also introduced the Request Storage Access for API to address some of the limitations of the Storage Access API identified by developers such as the fact that the API can only be invoked from an iframe. When the browser has received the request through the Storage Access API or the Request Storage Access for API, it will confirm that this third-party domain and first-party domain are in the same set and grant the access request. The Storage Access API is also shipping in other browsers like Safari and Firefox, so you will be able to leverage the implementation of the API for your site's functionality in other browsers. From the user's perspective, first-party sets will be referred to as related sites in a group. They'll be able to toggle on and off a control to allow Chrome to make access decisions based on the first-party set's list. They'll also be able to see whether a site they're visiting is in a first-party set and what other sites they've visited are in the same set. This in-browser user experience helped us maintain both seamless and private experiences on the web while giving users the opportunity to tune their privacy on the web according to their comfort. Remember, first-party sets is ready to adopt right now, so check it out and get ahead of the curve on preparing for third-party cookie deprecation. That was a lot, but we hope we've set you up with the information you need to prepare your sites for third-party cookie deprecation. You can always review this video at a later time and access these links to get the full details on using chips and first-party sets. As a recap, let's do a quick overview of what to do next. First, use DevTools or look for same-site non-cookies to identify whether your website relies on third-party cookies. Second, identify what the cookies are being used for and whether either first-party sets or chips are the right replacement solutions for you. For self-contained users of third-party cookies or where the third-party cookie only needs to be accessed in a single context, chips may be the right solution. For your cookies that are used in cross-site contexts but are on domains that you control, consider using first-party sets. As you're looking through your third-party cookies, if you encounter a use case that is not supported by chips and first-party sets, you can check out other Privacy Sandbox proposals where we are replacing the need for a cross-site cookie with a purpose-built API to fulfill the use case. Finally, if there is still an important capability that is missing, log the use case in our third-party cookie deprecation tracker. This will help the Privacy Sandbox team identify and help address broken flows on the web. For example, we've heard that the Storage Access API has been helpful in addressing cross-site cookie needs in other browsers, so Chrome is looking to support this API beyond its application of first-party sets to support authenticated third-party content. We want to hear about your use cases and are eager to help. Thanks for tuning into our talk. Remember to check out the additional resources linked in this video and also those linked below. If you have questions, don't hesitate to reach out and GitHub. Remember, chips and first-party sets are both ready to adopt right now, so it's a great time to start preparing for third-party cookie deprecation. We wish you luck on your journey to find the third-party cookies in your code. Thank you.