Preparing for a more private web | Session

Key Takeaways

[Music] 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 crosstalk 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-eye 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 the body 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 using a cross iframe well then you have a cookie that's always used in 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 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 hosts 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 requests 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 sub domains for example next up we have http only and this adds 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 stale 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 sensei lex and with this the cookie is only sent in requests that match the top level set 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 lags became the default in modern browsers but it's good practice to specify it anyway another change we introduced was skinful 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 site 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 in 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 it's third party here so first party sets and the same party cookie attribute or proposals to define just that relationship grouping together sites 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 fuel 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 when sites experiment with these new apis in the wild in chrome this is called an origin trial because as a developer you can you know 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 and box page and this is your entry point really to find which apis are relevant to you and are available for experiments 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 could 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 sites either in the meta tag 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 um 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 reduce 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 by a 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's site and look at some work 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 previous and box trials by using this one toggle and when it's sung 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 plan hints or advertising apis it is relevant to your organization and most importantly share your feedback with us thanks for watching you can find me as mood nels on twitter and enjoy the rest of google i o [Music] you