 Hey, I'm Mood. Hey, and I'm Ron. Now over the past couple of videos there's been a pattern where the changes we've been showing you have been to reduce cross-site data transfer by default and because some of these changes restrict existing behavior, you need to take action if your site relies on that cross-site functionality. So instead of just a list of features, we wanted to give you a little framework for thinking about them both for now and for the future. So we've brainstormed and finally distilled that down into three questions you can ask yourself and your team and we'll be running three examples, but first let's take a look at the raw questions. One, do I need this data? Now there's definitely a developer temptation to think just collect all the data. It might be valuable later, but that's not really the right attitude anymore. Right, and you're opening yourself up to more risk if that data leaks. You've got more regulations to follow and it's just more work. So the lazy option is just don't, don't collect it. No risk, no work. Hmm, so we can sum this up as more data, more problems? Yeah. Onto the next question. Question two then. Is there an alternative? There are so many options there, so it depends. Some things like side preferences might be better in client-side storage like index DB or local storage. So you can still sync them with the server, but maybe you don't need them on every single request. Yeah, and there might be places where the query parameters in the URL make more sense. If it's related to how the content displays, because then if I share a link with you, you get the same options that I have. Sometimes cookies are the right answer though, so question three, have I secured it correctly? Oh, I know this one. Watch my video from earlier. Yeah, yeah. Okay, Ron. Okay, but let's do a summary. So first party cookies should try using the host prefix so they're secure and single origin. They should use HTTP only to stop JavaScript access and they should set SAMHSA lacks to protect against cross-site request forgery. And if they do need to be third party, then try and do the same, but with SAMHSA equals none and secure. And that's it. Cool. I feel good about this. I think if you're asking these questions, you're headed down the right track. We should repeat these a few times though, like good scientists to see if it works with different topics. Good idea. I might even have a topic I could talk about right now. Yeah, me too. Okay, you go. Okay, first test drive of these questions then. We're going to take a look at the user agent string. Now, the original specification for this back in 1996 was pretty simple. It was basically browser version, library version, and so on. However, nearly a quarter of a century later, that string has grown a bit. If you want to successfully pass this, then you need a whole bunch of regular expressions or a library that hides them from you. On top of that, the information about your browser and device in that string can be pretty identifying. From my string here, which is being sent on every single request, you can see the exact build of Chrome, the phone I'm using, the version of Android it's running. Now, especially with less common devices, this could be enough to track someone. While we would eventually like to reduce the amount of data exposed there, those 25 years of growth have meant that there's a lot of genuine and valuable use cases out there for the user agent string. And maintaining backwards compatibility on the web is what means that your modern browser can still show you those 25-year-old sites successfully. Right, let's run the questions then and see if it helps us. Number one, do you need it? If you're using the string to try and determine feature support or capabilities, then it's far better to use feature detection, progressive enhancement, or responsive design to achieve those goals. That means you don't need to maintain a mapping between browser version and whatever feature you're checking for. It also means you're less likely to exclude less common browsers just because you couldn't match the string. Question two, is there an alternative? When I mentioned valid use cases before, some of those examples might be matching the user's OS so you can show appropriate downloads or match the UI conventions. You may also need to work around browser bugs, where the specific browser version is the key bit of information you need to know if it's been fixed or not. For this, I want to introduce you to client hints and specifically the new set of user agent client hints. Essentially, the idea is we could go from broadcasting all of this information by default to a model where the site asks the browser for each piece of info, and the browser decides what it wants to return. With user agent client hints, the default data shared on each request is the browser name, significant version, and the mobile indicator, which comes in on these sex CH headers. If you want something extra, like the OS platform, then your site needs to ask for it. It can do this by sending an accept CH header in its response, asking for platform. Then on subsequent requests, the browser will send a sex CH UA platform header back. You can also do this in JavaScript by calling get high entropy values on navigator dot user agent data and passing platform as a parameter. There's one of these user agent hints to cover each of the bits of data that you can get from the string. So, full browser version, platform version, device model, CPU architecture on top of the significant version and that mobile indicator. But wait, there's more. There are also existing client hints that can give you things like device memory or viewport width, because even if you're getting the data in the right way, it's easier to ask directly for the thing you want instead of using user agent as a proxy. Okay, third and final question, have you secured it correctly? For the user agent client hints, they are by default restricted to the same origin. If you have other cross origin or cross site requests on that page that need the client hints, let's say your downloads are hosted on a separate origin, so you want to send the platform hint there. You need to specify each of the hint and origin pairs in a feature policy to allow them through. Now, eventually we'd like to reduce the amount of information exposed by default in the user agent string. So ideally, if you can migrate to user agent client hints, then that should absolutely be your route. However, if you cannot, then try to be flexible in your detection. This kind of string passing is inherently fragile, so feel free to warn me that I might get issues with my browser, but don't block me just because my string didn't match your regex. And there we go. User agent 123 done. We've got a lot more info on web.dev, but let's keep this rolling and do another round. Maude, over to you. Thanks, Juan. Now let's look at our second test drive of these questions to see how they work using an example that's also an HTTP header. It's called the refer. You'll see it written with either one or two hours. Don't be surprised, this is due to an original misspelling in the spec. Imagine that a user is visiting a page on site one and to load an image, a request to site two is sent. In some cases, site two can see the full URL of site one the user is on in the request's refer header, which might be present in all types of requests, navigation or subresource. And this info is not just present in the header, it may be accessed on the destination via JavaScript. The refer can be insightful, for example, for analytics to know that 50% of visitors to site two were coming from socialnetwork.com. But full URLs can contain private data and even sensitive or identifying details, especially the path and query string. And requests sent from your website might include these details. So on to question one, do I need this data? First, incoming requests. Sometimes, like on this diagram, the refer is used to extract the origin to see where the request came from or whether it's the same origin. But the refer contains way more data than you need to answer these questions. If you're doing this, you're using it as a proxy to find answers, and this is more work for you. So we'll look at alternatives in a minute. Second, outgoing requests. If there's no compelling reason for your website to share full URLs cross-origin, then you shouldn't. We'll see how. Okay, on to question two, is there an alternative? Yes. First, incoming requests. Back to what we said. If what you need is just the origin, the origin header gives you exactly this, and it's available in post and course requests. And if what you need to know is whether the request is same origin, you can use the sec fetch site header. Also, side note, if you're using the refer as extra protection against CSRF, then replacing it with this or origin is great, but make sure that you're using CSRF tokens and maybe same site as a primary protection. Now, let's talk about outgoing requests. Is there an alternative to sending the full URL in all requests? Again, yes. Luckily, websites can control how much data is sent in the refer by sending a specific refer policy. And depending on the policy, either no refer at all, the origin only, or the full URL will be sent. Back to your websites. Suppose you want the full URL, for example, to understand how users are navigating within your website. This doesn't mean that you have to send the full URL in all requests. What you can do instead is set your refer policy to strict origin when cross origin. It shares the full URL for same origin requests, like here on this diagram, but only the origin in cross origin requests. Also, it's a safe policy, because if from your HTTPS website a request to an HTTP origin is sent, the refer will be stripped, which is good, because you don't want to leak your URLs on an encrypted connection since anyone on the network can see this, right? And quick segue. If you don't set a policy, the browser's default policy will be used. And to have your back, browsers have switched to or are experimenting with more privacy-preserving default policies, for example, strict origin when cross origin, the policy which is talked about. You can already try this out, so check the article in the video notes for details. Okay, on to question three. Have I secured it correctly? Strict origin when cross origin is good, but maybe you can't set this for your whole website because of some specific use case you might have. In this case, don't fall back to an unsafe policy altogether. What you can do instead is take a case-by-case approach. For example, set strict origin when cross origin as a general policy for your website, and a more lax policy on specific elements or requests, if need be. You need to pick a policy that fits the level of sensitivity of the data, and maybe you have a cookie recipes website, but maybe you have a healthcare web app, and the topic in the path is sensitive, or some of the URLs contain user-identifying information. On the whole, don't share the refer to a third party unless it's strictly necessary and transparent to your users. And one last thought, data that might not look sensitive or identifying can bring one more piece to the puzzle and be more revealing than you think. So that's it for the refer, and I think we're through. So, Rohan, you want to wrap up? Thanks, Maud. Yeah, okay, wow, that was a lot of topics in one session. As always, we've got the links included, so you can read more on this. To close then, when you're reviewing data usage, whether that's cookies, user agent, or refer or anything else, what are you going to ask yourself? One, do I need this data? Two, is there an alternative? And three, have I secured it correctly? Speaking of needing data, what have we got next? Oh, smooth transition. So, you definitely need data at sign up and sign in, so you've got to do these forms right. And Sam's going to explain how to improve sign in and sign up forms on your websites. And we'll see you around. Thank you.