 Hello there. My name is Rowan and I'm on the Chrome Developer Relations Team for Security Privacy Payments and Identity. Now, hopefully you're here because you watched our Chrome Dev Summit stream and you would like to learn more about our progress on the work under the Privacy Sandbox banner. Now, if you haven't watched them, then don't worry, I'll pop some links around and I will be right here when you get back. And it's not just me either, Maude has come over from her video to help me explore this. Hi again. Let's jump straight in with a bit of previously in the Privacy Sandbox because since the original announcement back in May 2019, we have made a fair bit of progress. First up, and I'll be quick on this one because if I've done my job, then everyone is bored of hearing me say this by now, we have fully rolled out the same side cookie changes. But just to recap, because I have practiced it a lot, if a cookie does not have a same side attribute, then it will be treated as if it's specified same side equals lax, meaning restricted to first party only. Now, if a site does want a third party cookie, then it needs to be set with both same side equals none and secure. And you said that we fully rolled out the same side cookie changes, which is a big milestone, but there's more to comrades. That's right. Yes. So I still get to keep talking about this. Specifically, the definition of same site is expanding to include the scheme as well. So we're calling this scheme full same site. And what that means is that requests from HTTPS example.com to HTTP example.com now count as cross site. Now, use cases on your site that I think might be affected here, where you have a form on your plain HTTP site that is posting to the HTTPS version of your site, that is going to count as a cross site post request. So same site equals lax or strict cookies will not be included. However, I don't think that what you should be doing is setting all of your cookies to same site equals none. Instead, you should be trying to make sure that the original page is already on HTTPS. And in fact, that's an immediate pattern. Migrating to HTTPS automatically removes a whole bunch of headaches and not just a cookie related things. Now, scheme full same site is available to test from Chrome 86. And we're planning on rolling out to stable in mid January or so. As always, dropping some links below with all the details in there for you. Now, speaking of things we've launched, though, I should probably ask you about refer and refer policy. How did that go? Yeah, so that's another change that's gone out. And the summary here is that Chrome's previous default refer policy was no refer went down great. And what that meant is that for HTTP requests going from site A to site B, so both server source and navigation requests, site B would see the full URL of the requesting page in the refer header, except if it's a downgraded request. So the request going from HTTPS to HTTP. In this case, there would be no refer header sent at all. Now, Chrome moved to a new different default policy, strict origin when cross origin. And what this means is that this time in requests going from site A to site B, the value of the refer header is that sent to site B is only the origin of site A. So for example, site A, that example, there is no more path information. And in the case where it's downgraded request going from HTTPS to HTTP, well, there is still no refer sent, so no change here. And the important thing about this change is that it's a change of the default behavior, which means that if you're site A, you can still send the full URL if you need to. But now you need to state this explicitly. For example, by setting a less strict policy, like no refer when downgrade on specific elements, when you need to. Okay, so that's immediately another pattern. And that's the one of needing to ask for permission to get these additional capabilities. Yes, there is. And maybe before we go into that, we could explain a little bit why such changes are not just a simple flip of a switch in Chrome. Yes, yeah, right. So like many things this year, it has not been smooth sailing. Do you want to talk about some of your problems and then I can talk about some of mine? Yeah, I can do that. So one interesting case we had with the refer was with the cloud run button, which is a little snippet of markdown that you can put into the the read me of a Git repository. And this generates a button. And then if you click the button, this sends you over to the cloud run site, checks the with the Docker file and spins up a container. Before Chrome's change, this could work with that with a static with a simple static link. Because for example, when you went from the site that's hosting the Git repository to the cloud run sites, the refer header value by default would be the full URL, which would be pretty easy to transform into a link to the repository. And that would be the case if the sites that's hosting the repo didn't have a refer policy explicitly set, which is often the case. Lots of sites rely on the on the browser, the browser's default policy. But with the new default in Chrome, this meant that the refer would only be the top level origin and no more repo link. Okay, so what was the solution then? It's more that there were a few a few options. So the first option would be for the site to simply set a policy of no refer went downgrade to get the old behavior back. But what this means is that you're losing the privacy benefits of the of this change at the site at the site level. So at the global sites level, that's option one, option two is a little more granular. And this is about the site hosting the Git repository, setting a specific policy of no refer, no refer went downgrade, sorry, it's long and hard to say, only on specific pages. For example, on the read me pages, you know, which are the pages we're interested in. So option one, option two, or more on the hosting site, site. And then we have other options, such as option three, which would be for the button to specify a certain referral policy in an HTML attribute, because it's something you can do. And this way, the full URL would only be sent for that specific link. And this works pretty well if the link is in HTML. But most sites with user generated markdown actually sanitize the output in order to remove the attributes they want to, which is very sensible, but it means in our case that the attribute, the referral policy attribute would get lost. And so option three actually doesn't work. So it's out and then option four would be for developers. So users of this cloud run button to explicitly specify the repository URL, for example, in a config file also, which is the most robust solution. But it also means that when you fork a repo, which has such a button, you would need in your fork to edit this config file and change the URL, which is a little more cumbersome. Okay, so this is a good example, or maybe even another pattern of a totally valid use case is not doing anything to try and compromise privacy. But it does need to change if we want the web platform as a whole to move to these more private defaults. Yeah, that's the challenge. They are not just in this instance. But in general, there are use cases that rely on the on the browser sending some kind of information on cross site requests by default. And this approach, which is, you know, opens and everything by default is not how we would design this behavior if we did it today. But now it's here and it needs to change. And what this means as a result is that there are some use cases that cannot be supported exactly in the same way they used to be supported. Okay, that was for the refer example. But I'm sure you have interesting stories as well. So tell me about the problems you run into. Yeah, okay. So in my case, it was the same pattern again, relying on browser defaults to include stuff in cross site contexts. Now, this time it was the checkout process for card payments on sites. So there's this system called 3d secure for card payments, that when you're doing checkout, it will take you over to your cards player site to do some verification, like asking you for a pin code or sending you an SMS. And then when it's verified you, sends you back to the merchant site with the result. Now, that's all fine. 3d secure does not rely on cookies at all. However, most sites are using cookies to maintain the user's session, or like they're cut checkout. And at the end of the 3d secure process, it's often a cross site post request back to the merchant site. And so that means no cookies. Right. Yeah. So if the site was expecting to link their session on that request, while some sites saw it like a brand new visitor, other sites saw it as an error. Now, much like the referral issue, you could just set same site equals none on all of your cookies to go back to the old behavior. But like I said earlier, I don't think that's a good idea. Because you're going to lose all of the cross site request forgery benefits. And if we're talking about card payments, I kind of want you focused on doing what is going to be most secure. So again, there are a couple of solutions here. One of which is to just not just not rely on a cookie on that request. So make sure that you have all the necessary information in the payload. And another is to follow the post redirect get pattern, which basically means you process the initial post request, extract the information you need out of it, and then do a same site redirect to something like a success page and read the cookies off of that request. And back to something you said earlier, another reason to not set a safe site known on all of your session cookies, apart from the security benefits, is that once we no longer support third party cookies, sorry, then this won't work at all, right? Yeah, very true. So you said this in your session, we're heading towards third party cookies being phased out. So we should really start thinking about them as legacy code. But that was also a good reminder about legacy code in general. So I saw this good tweet from Ryan Florence last year calling it revenue code. In other words, it's code you wrote a while back. You know that there's stuff that you should be cleaning up in there. But it is running critical parts of your business. And those parts of your business need to keep running. Yeah, so it's about finding the finding the balance. And that's one of the other things I talked about is finding the sweet spot between privacy on the one hand and capabilities on the other hand. For example, it's the same for third party cookies, we can just immediately turn off third party cookies first because it's not the only avenue for cross-site tracking. So people who want to do it could still do it. And on top of that, there are lots of valid use cases that are right now today addressed by third party cookies. So it means that either we need to find alternatives now for this use case or we need to propose new APIs to cover these use cases. Okay, so this is basically where we tie in the longer term proposal or privacy budget to the work that we've done so far and as a way to measure what we want to do in the future. Yeah, and you mentioned earlier that other pattern of having to explicitly ask for additional capabilities. And one of the important steps in this journey in the context of the privacy budget is to eventually to move from surfaces. There are passive sources of entropy identity entropy to active ones. I feel like this is where we are throwing a lot of new terms at developers. So I did watch your video. But when you say entropy, I'm still thinking about like my physics lessons from school. Yes. In this case, we mean more entropy in the information theory sense. It's really about how a much identifying information is exposed by a specific surface. And actually, I think you may have encountered this because we can illustrate it with the user engine stream compared with the user agent client hints. Yes. Yeah. Okay. Okay. So I do get it a bit. But I think that the nuance is still tricky. So I understand the problem with the user agent string. There are so many different values that can be in there like exact browser version and the device. And that creates a pretty identifying signature. Yes. So this means then it's a high entropy surface. And the problem is that the user agent string on top of that is sent on every request without even a site needing to ask for it, which means it's passive. And you can't because it's passive, you can't even know if the site is using that information. Okay. So that's where the cross site tracking comes in. Because when I visit site A and site B, they both get the same fingerprint. And they can use that as a key to join my identity across those sites. Yeah, exactly. And now with this, you see how user agent client hints actually can help. Right. Gotcha. Okay. So this because the default passive information sent is a lot less granular, a lot less identifying. It's just the browser name, the major version and this indicator of whether I'm on a mobile device. Right. And one more thing is we can also briefly mention the the effect that Greece has on that specific on that default value you mentioned. Yeah. Yeah. Okay. I love that acronym. So that is generate random extensions and sustain extensibility. So basically it's saying that it's, it's not actually a single default value instead of just a static string saying I am browser X instead is returning this dynamic set of values that is saying I'm compatible with browsers A, B, and C. Yeah. And the idea behind this is to actually just create specific, so just wait sites from just checking the for specific browsers and then blocking browsers that don't recognize because they just don't support them. Right. That makes sense. Okay. So it's the same pattern we've been talking about sites trying to identify the exact browser on the site by getting this raw data and mapping it to an answer. In this case, we're saying, assuming that progressive enhancement or feature detection haven't worked for you. What you should do is take this list, compare it to your supported browser list. And if you get one or more matches, then you're seeing the browser is compatible. Okay. So that was a brief sidetrack. We'll pull it back to privacy budget now. The passive entropy has been reduced and for higher entropy values, I will need to specifically request them for user agent client hints. That's either via header or in JavaScript, it's this get high entropy values call. Yeah. Get high entropy values where we can find the entropy term again. Yes. Yeah. Okay. So this is our real hook into the privacy budget. Now as a developer, I have a choice about accessing a source that is going to give me some of this higher entropy information. But that also means that the browser has an opportunity to observe it. Yeah. So you as a developer, you can you choose how to spend your site's budget, your site's privacy budget. But from the browser perspective, this budget can be measured and because it can be measured, then it can be enforced as well. Okay. So this is some pretty significant progress in the privacy sandbox journey then. We've landed some of the restrictions on cross-site tracking. We're working towards being able to quantify entropy exposed across the web platform. And we've got some origin trials running for the new APIs. Yeah. And I think we can talk a little bit about these origin trials and maybe for those who are watching, just for clarity. Origin trials are a way to test new or experimental web features and to give early feedback. So really what we mean when we say origin trials, we mean new APIs that you as a developer can already experiment with. Yes. And you've been working with Charlie on the conversion measurement proposal. So what are your lessons from his session? So I think the first thing is the best thing to do is to go and watch Charlie's session for all of the details. But I think from our perspective, what we can do is we can extract a few patterns from it. And the first one would be really switching away from the idea of needing some kind of shared identifier because that's what cookies do. They give you an identifier so that you can follow a user from the athlete to the purchase, for example. What this API does instead is it focuses on what data is needed to address this use case. What you need is data about the ad that's being showed, about the athlete, and you need to know that an athlete resulted in a purchase, which is the conversion, but you don't actually need the ability to link the individual person on their journey. And the point is to let you measure the effectiveness of the advertising but not to track a single person. That's the first one. And the second pattern that's related is that the conversion measurement API is a browser API. So all of the work of linking an ad click to a conversion is this is all happening on the user's device. And what the browser does is it processes this data upfront and it only delivers the needed answer instead of all of the raw data. Nice. Okay. So this is also kind of a link back to our web.dev live session about this really being the time to reexamine how your site is working, check where you're relying on cross-site communication, figure out if that's really the way you need to be doing it, or if you can actually go about getting that answer in a different way. Yeah. And back in that talk, we shared a few simple rules that still hold true. So I think we can maybe take a look at them here. Right. Yes. So I'm always saying we should repeat the message. So I should repeat the message. And that was number one, do I need this data? Number two, is there an alternative? And number three, have I secured it correctly? And I think the key piece here is that we're saying it's anywhere that you're attempting to join information on something I did on site A with something I did on site B, that is a vector for cross-site tracking. And if it's a vector, then we're likely going to address it under the Privacy Sandbox proposals. But as a developer, you should look for opportunities to get ahead of that anyway, as in good privacy practice should just be good engineering practice. Right. And this was for the conversion measurement API. And we have another origin trial to talk about where I think we'll find the same concepts and the same patterns again. We do. Yeah, trust tokens. So do you want to give us the intro for that one as well? Yeah, sure. So maybe I can start with the problem we're trying to solve here. And there are these use cases where a system set up ways to recognize users across sites in order to answer a question. For example, to track an ad conversion, they create a cross-site identifier. We discussed this earlier with the conversion measurement API. And with trust tokens, the question, can I trust this user, can be answered without actually tracking the users? And basically, the idea is that a site can share that it trusts a visitor by issuing tokens to them. And these tokens are stored in the browser. And later on, they can be redeemed to verify that claim. For example, by another site that for some reason needs a signal that the user is authentic. Okay, so let me try walking this through an example then. I've got an account on a social networking site. I've had it for years. They've got a history there. So they're pretty sure that I'm a real person. So now they can issue tokens to my browser that indicate their trust that I'm a real person. So I've got my pool of tokens. And now I go over to a blog that I've never visited before, read an article, and I want to leave a comment. The blog wants to protect against bots and spam, which is pretty sensible. So before I can comment, they're going to ask for a token from a source that they trust. And I'm going to give them my social site token. They're going to take that and go over to social site to redeem it. Social site says it's genuine. And then boom, I can make my comment. I guess a concern here, though, is what does the blog site learn about me and vice versa? Because clearly there's some cross-site communication going on here. Yeah, and this is where cryptography actually comes in. It builds on privacy pass, which is an IETF standard that was originally developed by Cloudflare to enable a similar behavior for users of the Tor network. And the way this works is that the tokens are assigned using blind signing, which is a special technique that makes it so that you can prove that the tokens are authentic, but you can't link issuing to redeeming. And the blog, back to your example, the blog knows you had a social site token, but it's just like a coin that says social site on it. There is nothing that actually links it to your social site account. And then when the blog goes to social site to redeem the trust token, social site, what social site can do is it can verify that the token is authentic, but they have no way to actually link this to you. And one more thing is that the social site has been issuing tokens to you, but they should track this because if your account is asking for a huge number of tokens, this should look suspicious. Ah, yeah. Okay. Yeah. So this does make sense. So this is the same set of privacy focus patterns. Again, there is some form of cross-site communication, but it is not done by joining my identity across these sites. Instead, it is just the data I need to answer this specific question. And on top of that, the site has to actively request it. They don't just passively receive it. Right. And now we're saying just words, but we actually have a demo for this, but we are only going to link to it here because the thing about origin trials is they can change pretty fast, which means that for those of you watching in the future, the demo might look a little bit different, but it should still be working. Yes. Okay. So speaking of things that are going to change, this is kind of a good place to wrap things up and talk about where people can go to find out more. So thanks for the chat. I feel pretty good about the stuff that the whole team has delivered here. Yeah. Thank you too. Me too. And it's been a lot. There's a lot going on right now, and there's a lot more to come. Right. So we'll be making sure the web.dev and the chromium.org pages are kept up to date. But what we really need from developers, from you, is to test out this stuff early on. Check out the new restrictions and deprecations to see if your site is affected in some way. And if you work with any of the use cases that we've mentioned that are supported by the origin trials, then get them there and try them out or chat to your providers to see if they're actively tracking the proposals. The key thing is to really let us know what's going on because we are not going to drop these things on you. We want to work together to make sure that we get the right solutions out there. So thank you again and look forward to chatting soon.