 Online tracking is a critical concern for web users. So the web is changing. It's becoming more private. My name is Mood. I'm a developer relations engineer. And together in this session, we'll look at how you can prepare for that future, but also contribute to it. And before we dive in, it's helpful to understand what's changing and why. Today, user identity can be joined across sites. This means users can be tracked across the web. And to address this, the goal is to partition identity across sites. That means your identity on site A is separate from user identity on site B, C, and so on. And this isn't just good for web users. It's good for us as developers too, because it's an opportunity to address the patterns and problems they have built up over the years. If you think about it, cookies are 25 years old now and it was a more innocent time on the web back then. If we fix these issues, so the default cross-site communication and fingerprinting, then that means fewer privacy concerns for you as a developer, which means more time to focus on your site. So how is the web changing to become more private? Well, first, third-party cookies are the main mechanism that enables cross-site tracking. So they're being blocked by default in several major browsers. And in Chrome, they will be phased out as viable alternatives become ready. And it's not the end state, because the goal is to prevent cross-site tracking. So therefore, workarounds like fingerprinting are being mitigated. But both third-party cookies and fingerprinting also support valid use cases, like embedding videos or maps, running analytics, single sign-on, advertising, fraud detection, and more. And this is all important functionality to preserve. So what we need are new APIs that support these valid use cases, but that do so in a privacy-preserving way. And these APIs should give you just the data you need to cover your use case. So these are the ways the web is changing. So let's look into each of these and what you can do to prepare for it. Let's start with third-party cookies being phased out. This is a big milestone, so I'll focus on what you need to do to prepare for this. Start with a question. Ask yourself, for the cookie you're setting, is it used across-site? If the answer is no, for example, if you set a cookie to manage the session on your site and it's never used in a cross-site iframe, well, then you have a cookie that's always used in a first-party context. So you won't have to do much to prepare for third-party cookies being phased out. Only when you set your cookie, make sure to use best practices and use what we call the good cookie recipe. This is the recipe for a good first-party cookie and you can tweak it to open it up for your own needs, but this is where you should start. So let's unpack it. Host is a prefix and it works like an interface in the sense that it makes some attributes mandatory and it forbids others. So it's helpful because it helps you stick to a certain set of rules. With host, secure must be in, domain here in red must be out and path must have a value of slash. Secure helps protect cookies from being stolen on an insecure network and with pass slash and no domain, this cookie, if it's set on example.com, it will go on every request to example.com but in no request to images.example.com. So it's kind of like making this cookie origin bound just like most modern APIs. You can tweak this if you need your cookie to be shared across subdomains, for example. Next up, we have HTTP only and this has some protection against malicious third-party scripts on your site by restricting JavaScript access. It's also helpful to set a max age because browser sessions can last a pretty long time and you don't want state cookies hanging around forever. So here we set a max age of 90 days which is a reasonable default but you may want to change this depending on your use case. Finally, we have same site lacks and with this, the cookie is only sent in requests that match the top level sites the user is currently visiting and this includes navigations which can be handy if you're sending someone a link and they need to be logged in to see it. So with this recipe, you're not allowing your cookie in cross-site or third-party contexts. Last year, same-set lacks became the default in modern browsers but it's good practice to specify it anyway. Another change we introduced was skimful same-sites and with this, HTTP and HTTPS count as cross-site and if you're running into issues because of this, the solution is to migrate fully to HTTPS and use that secure attribute we mentioned earlier. If you need something more restricted, you can also use same-sites strict but beware because it's probably not what you need for a session cookie. Now let's continue on our journey. What if your cookie is used across sites? Well, in this case, this cookie could be used to join user identity across sites so we need solutions here. We're entering the exploration zone. We don't have all the answers to this yet. So I'll tell you about some of the ideas we have in Chrome but the aim is for these to become part of the web platform and what this means is all of us working together to make sure we solve the issues for everyone. Okay, so let's dive in. Maybe your cookie is cross-site and it does need states but not state across multiple sites. For example, if it's used to save preferences for a widget or if it's used to share a session cookie for an API, also it's partitioned by top-level sites. So we're thinking of ways to enable this use case by giving you a way to opt-in to having your third-party cookie partitioned by top-level sites. And this way, you can use your cookie in a third-party context but third parties will see different cookies when the browser is on different top-level sites. So if this sounds like it would fit your use case, check out the partition cookie and partition attribute proposal. Next case, maybe your organization has multiple sites and you run your own SSO solution. Well, that means you would need to share the same session cookie across all of these sites. So currently you would need to set same site none because this is a cross-site cookie and you don't want partition cookie in this case because your users would have to sign in again on each site. But cross-site doesn't really feel like its third party here. So first-party sets and the same party cookie attribute are proposals to define just that relationship, grouping together a size you own and that need access to the same cookie. The policy and the process on how you would form first-party sets is under discussion but you can already try first-party sets. So check the linked page for details. Before we continue on our cookie exploration, a quick aside on tooling, you may already have noticed the issues tab in Chrome DevTools and what it does is it makes it easy for you to spot and fix issues on your site, including cookie issues. So make sure to check out the issues tab. And also in Chrome, you can enable new cookies functionalities for debugging purposes by toggling what we call flags. Back to our cookie exploration. Last case, maybe you're using your cookie really to share states across multiple different parties. So you're using a third-party cookie as a shared identifier. In this case, you need to switch to new APIs. New APIs, as we said earlier, are designed to fulfill use cases that show today's web but they do so in a privacy-preserving way. And some of these new APIs are focused on advertising but they really cover a wide variety of use cases across identity, fraud detection, and others. And Chrome is grouping those efforts under the project name of the Privacy Sandbox but these are really web platform efforts. So all these new APIs are being incubated through the web standards process where you have browser vendors, industry representatives and others who provide inputs and refine together these new web technologies. So some proposals like same-site lags are already adopted at scale but many are under exploration and a key step in this process is one site's experiment with these new APIs in the wild. In Chrome, this is called an origin trial because as a developer, you can always try these new APIs locally but running an experiment on your site is really the best way to ensure that these APIs cover your use case. Take parts in these experiments and tell us how these new APIs work for you. Do they address your use cases? Are they a good replacement for what you're doing with third-party cookies today? How is the developer experience? This is what we want to hear about. So head over to the Privacy Sandbox page and this is your entry point really to find which APIs are relevant to you and are available for experiment. Yahoo! Japan, for example, is already experimenting with the attribution reporting API which is a Privacy Sandbox API to measure ad conversions and Yahoo! Japan plans to analyze the data from this origin trial and provide feedback to the W3C. And this is exactly what you should do too if you have use cases that rely on third-party cookies. To make this a little bit more concrete, this is what setting up an experiment looks like. You would head over to the origin trial sites. You would find the origin trial you're interested in, click Register, fill in information about your experiment and you get back a token which is really a long string and you then add this token to your site either in the metadata or via HTTP header. And you're all set to start your experiment in real-life conditions with end users. You can also decide to apply your experiment only to a small percentage of users. What's important is that when you experiment with these new APIs, you're not on your own. You can ask questions, for example, on the GitHub repositories of the proposals and you also have tooling available. For example, some Privacy Sandbox APIs like trust tokens even have DevTool support. Now, let's take a look at how you can prepare for the third way the web is changing, that is fingerprinting mitigations. And one great example here is around the user agent string, which is so detailed that it can be used to fingerprint users and track them. And it's also exposed by default. So in the future, you can expect Chrome to readjust the amount of identifiable information that's exposed via the user agent string. And we hope to work with other browsers on future alignment. What you can do instead is use user agent client hints or UACH for short. So with UACH, you do receive some broad values by default, like the browser name, but if you need more specific information, you ask for it via header or via JavaScript and the browser sends back only what's requested, which is also a cleaner developer experience because you get just the data you need. It's live in Chrome, but your feedback is still used to make sure the API addresses your use case. So migrate to UACH and if something is stopping you, please let us know. Okay, so we've covered quite some ground on what you as a developer can do to prepare for the more private web. So before we wrap up, let's move on to the user site and look at some more of the Chrome privacy UX team has been doing. Chrome version 90 has introduced a control that's directly available from the main settings and upon clicking this control on this page, the privacy sandbox is explained in simple terms. Users can also decide to be included or not in the privacy sandbox trials by using this one toggle and when it's on, it means that sites you visit can use privacy sandbox APIs. This is just the beginning. The Chrome privacy UX team is working on more user facing features and friendly controls. And that's it. That was a lot I know. So let's recap this session. Use the good cookie recipe. Check the new proposals like partition cookie and try out the new APIs like user agent client hints or advertising APIs if these are relevant to your organization. And most importantly, share your feedback with us. Thanks for watching. You can find me as Modenals on Twitter and enjoy the rest of Google IO.