 Hey, my name is Jeremy Ney. I work in partnerships for Privacy Sandbox in Google Chrome, managing our anti-covert tracking initiatives. I'd like to walk you through some of the technologies that are part of the Privacy Sandbox, which help websites preserve important user-facing functionality and combating fraud. Today, we'll talk about solutions for anti-covert tracking and cross-site boundaries. I want to note that we are really putting use cases front and center here for a variety of industries, and we've outlined a few of the technologies that will be most impactful. This focus on real-world use cases is because in the Privacy Sandbox, we want to direct user and developer benefits to understand the right privacy versus utility trade-offs. My goal here is that by the end of this video, you will say to yourself, yes, this is what I need. We're excited about what we're building, so let's dive in. Let's start with CHIPS, which stands for Cookies Having Independent Partition States. CHIPS is definitely applicable across a wide range of circumstances and is largely for embedded use cases. Let's look at that in more detail. On the current version of the web with unpartition third-party cookies, SaaS providers can access cookies in many different contexts. Here, Embed C could be a mapping provider that sets my preferred store location on site A. But when I navigate to site B, that same mapping provider embedded there may know my location. Embed C needs to be able to store that information in cookies, but doing that today would allow C to track users across sites. With CHIPS, C is declaring that it's not trying to use cookies from that shared cookie jar on the left. Instead, as seen on the right, it now has partitioned or isolated cookie jars per top-level site. This is done via a double-key partition which creates cookie jar AC. C can continue to offer its functionality without being able to track users. So now that way, when a user navigates to site B, there's a new partition cookie jar BC. So if CHIPS is the thing you need, you can try it out now. The CHIPS team has shipped the feature and is available in Chrome version M110. There's also a spec draft if you're into reading those and if you want to give feedback, please do so on the CHIPS GitHub repository. Last, if you want to discuss the proposal, CHIPS is currently being incubated in the World Wide Web Consortium's Privacy Community Group, otherwise known as the W3C. And last, it's getting picked up by an IETF working group right now as well. Next, let's talk about first-party sets. First-party sets helps you when a user journey is spread across multiple websites that require deep integration through technologies like third-party cookies. As third-party cookies go away, Chrome is focused on making sure that users are not being tracked across sites. However, Chrome recognizes that there are many legitimate uses for sharing that information across the web. Obvious cases are country code top-level domains. So a British user of example.co.uk would want to be able to make use of the international example.com site without restrictions. Let's look at how that use case is enabled through first-party sets. At a very high level, first-party sets is a list of sites that browsers can use to make exceptions to privacy restrictions such as third-party cookie blocking. In a little more detail, site owners can list out their related domains in subsets of a larger first-party set. Subsets are key. They define use cases or the reasons for domains being in a specific set and being able to share state. I've already mentioned the country code top-level domain. Some of the other examples that we've defined so far are the service and the associated subsets. Each subset has different requirements with the goal of giving more flexibility for different types of domains. I won't discuss the requirements in details, but we would like to hear your thoughts on what use cases we need to support. I do want to note that we're still evaluating both what subsets we need to support and the rules that correspond to those subsets. We sincerely welcome feedback on this. The process of creating a first-party set is fairly straightforward. It begins with the set owner compiling the set of domains they want to add and submitting it to GitHub. Then there's a series of automatic checks that ensure that the submission rules for the subsets are followed. The most important part to note is the final stage which requires developers to use the Storage Access API. In Chrome, these calls would be automatically granted for same-set members without user prompts. Different subsets have different rules. First-party sets testing is available now by enabling feature flags. Sites can also test with submitting sets to begin evaluating how they might want to create their site boundaries. In the meantime, we would love to hear from you about your use cases and ideas around the current proposal. The third API I want to discuss is FedCM or Federated Credentials Management. FedCM has a great specific focus, Federated Identity. So what is Federated Identity? Federated Identity in short means having an identity provider that shares information about the user with one or more third-party websites called Relying Parties. In most cases, a user has an account at the identity provider and the information is then shared with the website for login. Some of the most common providers are Login with Facebook or Login with Google, Twitter, Apple, etc. This type of login is definitely something that helps users. It avoids the proliferation of usernames and passwords and it really should be part of the web. However, it's often built on technologies that enable tracking, like third-party cookies. It would be great if browsers had a way to distinguish valid Federated Identity flows. That's where FedCM comes in. FedCM mediates the exchange of information between the user, the site, and the IDP to ensure that the user is informed and has the opportunity to provide consent. This is what these prompts look like for FedCM. They're very similar to what users are used to seeing when they try to log in with Federated Services. However, with the new API, identity is Federated, so user identities can't be linked. While the mock shows Google as the IDP, any IDP, like a few I just mentioned and more, can be used as long as they implement the relevant endpoints required by the FedCM API. FedCM is live and has been available in Chrome since November, so you should be able to try it out now. While there's a first-version shipping, the team is also iterating on future improvements and would love to get your feedback in the Federated Identity Community Group of the W3C. Finally, let's talk about private-state tokens, which was previously called trust tokens. Private-state tokens don't have as much user contact as the previous three technologies that we've discussed, but they serve another really important purpose, combating fraud. Private-state tokens live in the context of the larger anti-fraud and anti-abuse work streams. Chrome wanted to make sure that as we are reducing certain values, like the user agent string, we were also creating trusted mechanisms to still help prevent fraud and abuse on the web. Private-state tokens allows third-party vendors to convey trust without fingerprinting them or storing identity. This is achieved in two parts, issuance and redemption. When a user visits Site A, that site runs its own analytics to validate the user and determine if they are a bot or not, for example. That Site A sends a token to the server for signature that encodes that information, basically a zero or a one. The browser securely stores that token, which can then be redeemed later. That's issuance. Now let's talk about redemption. If a user visits Site B, where it might be unclear if the user is trusted, that Site B can request to redeem the token which was issued from Site A. The issuer verifies the signature and issues a redemption record so Site B can see whether that value was a zero or a one. The Chrome team is continuing to develop private-state tokens and make it available for broader use. In the meantime, we welcome your discussion on private-state tokens in GitHub and in the W3C's anti-fraud community group. So let's recap some of the things we've talked about today. Chips helps you use embedded SaaS features by partitioning them on your site. First-party sets will allow you to declare use cases for related domains that need to share data with some important restrictions. FedCM ensures that federated login flows run smoothly in the future and private-state tokens can be used to convey trust in a user to combat fraud. However, the work of the Privacy Sandbox continues. I hope you did end up saying to yourself, yes, this is what I need, but you may not have heard about your exact use case for me today. This may be because it's covered by one of the ads APIs, but it's also quite possible that we just don't have the perfect answer for it yet. We're talking about other issues in different W3C and standards groups, and so we recognize that there are other use cases to work through. We definitely want to engage you and the web ecosystem further so we look forward to future conversations. We are incredibly excited about our work for improving privacy on the web, reducing covert tracking, and strengthening cross-site boundaries. There's more to come, and we know it will take strong web coordination to make it happen. Please come to PrivacySandbox.com to check out these proposals and more. We are really grateful for your support in that, and we can't wait to go down that path together. Thank you.