(gentle music) - Hello there, my name's 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, Maud 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 SameSite cookie changes, but just to recap because I have practiced it a lot. If a cookie does not have
a SameSite attribute, then it will be treated as if it's specified SameSite=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 SameSite=None and secure. - And you said that we fully rolled out the SameSite cookie changes which is a big milestone, but there's more to come, right? - That's right. Yes, so I still get to keep talking about this. Specifically, the definition of SameSite is expanding to include the scheme as well. So we’re calling this Schemeful SameSite. 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 are 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 SameSite=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 the SameSite=None. Instead, you should be trying to make sure that that 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 the cookie-related things. Now, Schemeful SameSite is available to test from Chrome 86, and we're planning on rolling out to stable in mid-January or so. As always I'll drop in 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 referrer and referrer 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 referrer policy was no-referrer-when-downgrade. And what that meant is that for HTTP requests going from site A to site B, so both server resource and navigation requests, site B received the full URL of the requesting page in the referrer header except if it's a downgraded request. So the requests going from HTTPS to HTTP, in this case, there would be no referrer 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 referrer header that's sent to side B is only the origin of site A, so for example, siteA.example. There is no more path information. And in the case where it's a downgraded request, going from HTTPS to HTTP, well, there is still no referrer 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 in 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-referrer-when-downgrade on specific elements when you need to. - Ah, okay, so that's immediately another pattern. 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, you're 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 referrer was with the Cloud Run Button which is a little snippet of markdown that you can put into the README on the Git repository and this generates a button. And then if you click the button, this sends you over to the Cloud Run site, reads the Docker file and spins up a container. Before Chrome's changed, this could work with a simple static link.
Because for example, when you went from the side that's hosting the Git repository to the Cloud Run sites, the referrer 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 referrer policy explicitly set, which is often the case. Lots of sites rely on the browser's default policy. But with the new default in Chrome, this meant that the referrer 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 options.
So the first option would be for the site to simply set a policy of no-referrer-when-downgrade to get the old behavior back. But what this means is that you’re losing the privacy benefits of this change 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-referrer-when-downgrade, sorry, it's long and hard to say, only on the on specific pages, for example, on the README pages, which are the pages we're interested in. So option one and option two are more on the hosting side site and then we have other options such as options three, which would be for the button to specify a certain referrer policy and then a 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 referrer policy attributes 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 the 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 edits this config file and change your 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 there are not just in this instance but in general there are use cases that rely on the browser sending some kind of information on pre-site requests by default and this approach, which as you know often send 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 referrer example but I'm sure you have interesting stories as well, so tell me about the problems we 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 3-D Secure for card payments, that when you're doing checkout, it will take you over to your card supplier site to do some verification, like asking you for a pin code or sending you an SMS. And then when it's verified you, it sends you back to the merchant site with the result. Now, that's all fine.
3-D Secure does not rely on cookies at all. However, most sites are using cookies to maintain the user's session or their cart at checkout. And at the end of the 3-D 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, well, some sites saw it like a brand new visitor, other sites saw it as an error. Now, much like the referrer issue, you could just set SameSite=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 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 SameSite 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 SameSite=None on all of your session cookies apart from the security benefits is that once we no longer support third-party cookies, 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 there 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 developed awhile 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 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't 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 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 that are passive sources of 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 in the information theory sense. It's really about how much identifying information is exposed by a specific service.
And actually, I think you may have encountered this because we can illustrate it with the User-Agent string compared with the User-Agent Client Hints. - Yes, yeah, 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. - Yeah, 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 the site needing to ask for it, which means it's passive. And because it's passive, you 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 a User-Agent Client Hints actually can help. - [Rowan] Right, got you. 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. - [Maud] Right, and the one more thing is we can also briefly mention the effect that GREASE has on that default value you mentioned. - Yeah, okay, I love that acronym. So that is: generate random extensions and sustain extensibility.
So basically it's saying that it's not actually a single default value instead of just a static string saying, I am browser X; instead, it's 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 dissuade sites from just checking for specific browsers and then blocking browsers they 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 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 assume 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, okay, so this is a 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 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 those restrictions on cross-site tracking, where 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 about this origin trials and maybe for those who are watching just for clarity. Origin trials are weighted as new or experimental features and to give oral 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 proposals. So what are your lessons from his session? - So I think 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 ad click 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, you need the data about the ad that's being shown, about the ad click, and you need to know that an ad click 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 and 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, this is all happening on the user's device. And what the browser does is it processes this data up-front 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 re-examine 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. - 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 sites 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 sites says it's genuine, and then, boom, I can make my comment. I guess the 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 paths which is an IETF standard that was originally developed by CloudFlare to enable similar behavior for users of the Tor network.
And the way this works is that the tokens are signed 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 blog, back to your example the blog knows you had the 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's account. And then when the blog goes to social site to redeem the trust token, 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. - 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're 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 this 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 that 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 down 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. (gentle music)
Meaning restricted to first party only. Now, if a site does want a third-party cookie, then it needs to be set with both SameSite=None and secure. - And you said that we fully rolled out the SameSite cookie changes which is a big milestone, but there's more to come, right? - That's right. Yes, so I still get to keep talking about this. Specifically, the definition of SameSite is expanding to include the scheme as well. So we’re calling this Schemeful SameSite. 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 are 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 SameSite=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 the SameSite=None. Instead, you should be trying to make sure that that 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 the cookie-related things. Now, Schemeful SameSite is available to test from Chrome 86, and we're planning on rolling out to stable in mid-January or so. As always I'll drop in 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 referrer and referrer 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 referrer policy was no-referrer-when-downgrade. And what that meant is that for HTTP requests going from site A to site B, so both server resource and navigation requests, site B received the full URL of the requesting page in the referrer header except if it's a downgraded request. So the requests going from HTTPS to HTTP, in this case, there would be no referrer 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 referrer header that's sent to side B is only the origin of site A, so for example, siteA.example. There is no more path information. And in the case where it's a downgraded request, going from HTTPS to HTTP, well, there is still no referrer 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 in 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-referrer-when-downgrade on specific elements when you need to. - Ah, okay, so that's immediately another pattern. 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, you're 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 referrer was with the Cloud Run Button which is a little snippet of markdown that you can put into the README on the Git repository and this generates a button. And then if you click the button, this sends you over to the Cloud Run site, reads the Docker file and spins up a container. Before Chrome's changed, this could work with a simple static link.
Because for example, when you went from the side that's hosting the Git repository to the Cloud Run sites, the referrer 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 referrer policy explicitly set, which is often the case. Lots of sites rely on the browser's default policy. But with the new default in Chrome, this meant that the referrer 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 options.
So the first option would be for the site to simply set a policy of no-referrer-when-downgrade to get the old behavior back. But what this means is that you’re losing the privacy benefits of this change 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-referrer-when-downgrade, sorry, it's long and hard to say, only on the on specific pages, for example, on the README pages, which are the pages we're interested in. So option one and option two are more on the hosting side site and then we have other options such as options three, which would be for the button to specify a certain referrer policy and then a 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 referrer policy attributes 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 the 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 edits this config file and change your 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 there are not just in this instance but in general there are use cases that rely on the browser sending some kind of information on pre-site requests by default and this approach, which as you know often send 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 referrer example but I'm sure you have interesting stories as well, so tell me about the problems we 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 3-D Secure for card payments, that when you're doing checkout, it will take you over to your card supplier site to do some verification, like asking you for a pin code or sending you an SMS. And then when it's verified you, it sends you back to the merchant site with the result. Now, that's all fine.
3-D Secure does not rely on cookies at all. However, most sites are using cookies to maintain the user's session or their cart at checkout. And at the end of the 3-D 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, well, some sites saw it like a brand new visitor, other sites saw it as an error. Now, much like the referrer issue, you could just set SameSite=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 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 SameSite 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 SameSite=None on all of your session cookies apart from the security benefits is that once we no longer support third-party cookies, 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 there 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 developed awhile 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 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't 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 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 that are passive sources of 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 in the information theory sense. It's really about how much identifying information is exposed by a specific service.
And actually, I think you may have encountered this because we can illustrate it with the User-Agent string compared with the User-Agent Client Hints. - Yes, yeah, 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. - Yeah, 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 the site needing to ask for it, which means it's passive. And because it's passive, you 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 a User-Agent Client Hints actually can help. - [Rowan] Right, got you. 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. - [Maud] Right, and the one more thing is we can also briefly mention the effect that GREASE has on that default value you mentioned. - Yeah, okay, I love that acronym. So that is: generate random extensions and sustain extensibility.
So basically it's saying that it's not actually a single default value instead of just a static string saying, I am browser X; instead, it's 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 dissuade sites from just checking for specific browsers and then blocking browsers they 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 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 assume 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, okay, so this is a 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 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 those restrictions on cross-site tracking, where 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 about this origin trials and maybe for those who are watching just for clarity. Origin trials are weighted as new or experimental features and to give oral 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 proposals. So what are your lessons from his session? - So I think 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 ad click 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, you need the data about the ad that's being shown, about the ad click, and you need to know that an ad click 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 and 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, this is all happening on the user's device. And what the browser does is it processes this data up-front 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 re-examine 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. - 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 sites 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 sites says it's genuine, and then, boom, I can make my comment. I guess the 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 paths which is an IETF standard that was originally developed by CloudFlare to enable similar behavior for users of the Tor network.
And the way this works is that the tokens are signed 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 blog, back to your example the blog knows you had the 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's account. And then when the blog goes to social site to redeem the trust token, 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. - 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're 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 this 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 that 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 down 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. (gentle music)