Patterns for privacy

Key Takeaways

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 mod 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 size attribute then it will be treated as if it specified same-sex equals lacks 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 site 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 for 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 lacks 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 size equals 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 to cookie related things now scheme for 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 yes so that's another change that's uh that's gone out uh and the summary here is that chrome's previous default reference policy was no refer when done great and what that meant is that for http requests going from site a to site b so both subresource 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 request going from site a 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 a downgraded request going from https to http well there is still nowhere for a cent so no change here and the important thing about this change is is that it's a change of the default behavior which means that if you say a you can still send the full url if you need to but now you need to state this explicitly for example for example by setting a less strict policy like no referral and downgrade on specific elements when when you need to ah okay so that's immediately another pattern and that's the one of needing to ask for permission to 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 uh 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 referee was with the cloud run button which is a little snippet of markdown that you can put into the the readme of the 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 reads the docker file and spins up a container before chromes change this could work without 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 range 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 hosting the repo didn't have a referral policy explicitly set which is often the case lots of sites realize on rely on the on the browser 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 was the solution then it's small that there were a few a few options so the first option would be for the site to simply set a policy of no referral and downgrade to get the old behavior back but what this means is that you're losing the privacy benefits of the ch of this change at the sites at the site level so at the global size 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 referral no referral when downgrade sorry it's long and hard to say only on specific pages for example on the readme pages you know which are the pages we're interested in so option one and shoot on two or more on the hosting side side 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 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 refer policy attribute would get lost and so option three actually doesn't work so it's out and then option four uh would be for developers um so users of this uh cloudgram button to explicitly specify the repository url uh 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 you know 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 uh it's not doing anything to try and compromise privacy but it does need to change if we want the 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 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 referee example but i'm sure you have interesting stories as well so tell me about the the problems you run into yeah okay so in my case it was the same pattern again uh 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 uh it will take you over to your card suppliers 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 3d secure does not rely on cookies at all however most sites are using cookies to maintain the user's session or like their their cut at 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 well some sites saw like a brand new visitor other sites saw it as an error now much like the referrer issue you could just set same psi 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 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 third part supports our party cookies sorry then this won't work at all right yeah very true so you said this in your session where 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 uh 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 um 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 you know explicitly ask for additional capabilities and one of the important steps um in this journey in the context of the privacy budget is to eventually uh to 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 i did watch a video um but when you say entropy i'm still thinking about like my physics lessons from school yes um in this case we mean more entropy in the in the information theory sense it's really uh about how a much identifying information is exposed by a specific surface and actually i think you you may have encountered this because we can illustrate it with the user agent stream um compared with the user agent client hints yes yeah okay okay so i do get it a bit um but i think that the 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 the site needing to ask for it which means um it's passive and you can't because it's passive you can't even know if the you can't even know if the site is using that information ah okay so that's where the 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 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 the one more thing is we can also briefly mention the the effect that greece has on that specific on that default value you mentioned uh 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 uh instead it's returning this dynamic set of values that is saying i'm compatible with browsers a b and c yeah and and the idea behind this is to actually dissuade specific uh also displayed sites from just checking the 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 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 assume the browser is compatible okay so that was a brief side track we'll pull it back to privacy budget now um 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 uh the entropy term again yes uh yeah okay so this is uh this is our real hook into the privacy budget um now as a developer i have a choice about accessing a source that is going to give me some of this higher entry information but that also means that the browser has an opportunity to observe it yes so you as a developer you can you choose how to spend your site's budget your size 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 so this is some pretty significant progress in the privacy sandbox journey then we've landed some of the restrictions on quest 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 um 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 api 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 the best thing to do is to go and watch charlie's session for all of the details um but i think from our perspective what we can do is we can extract a few patterns uh from from it uh and the first one would be uh really switching away from the idea of needing some kind of shared identifier because that's what cookies do they give you and add any fire 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 you need data about the ad that's being showed about the ad click and you need to know that an eye 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 the second pattern and that's related is that the conversion measurement api is a browser api so all of the work of linking a nightclick 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 this is also kind of a link back to our web.dev live session um 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 uh the way you need to be doing it or if you can actually go about getting the 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 and i think the key piece here is that we're saying it's anywhere that you are 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 management api and we have another origin trial to talk about where i think we'll follow the same 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 are 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 reason it's a signal that the user is authentic okay so let me try walking this through uh an example then um 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 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 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 through 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 choice token social sites uh what social side can do is it can't verify that the token is authentic but they have uh no way to actually link this to you and one more thing is that the you know a 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 uh yeah okay yeah so this does make sense uh so this is the the same set of privacy focused 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 trails 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 uh yeah okay so speaking of things that are gonna 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 to me too and it's been 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 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 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 [Music]