 Hello there. Chrome is changing how it handles cookies, specifically, restricting them to first-party access by default and requiring you, as a web developer, to explicitly mark cookies for access in third-party contexts. Now, if you only want to watch the first 30 seconds of this video, then the detail is, from Chrome 80, all cookies without a same-site attribute will be treated as if they had same-site lack specified. In other words, they will be restricted to first-party only. If you need third-party cookies, then they must be marked with same-site equals none and secure. This also means that third-party cookies will only be sent over HTTPS connections. Let's dive into the details. Cookies are small pieces of text data that a site sends in its response. Your browser then stores these and sends them back to the associated site on eligible requests. If the site in your browser matches the site in the request, then that's what's referred to as a same-site request or a first-party cookie. Conversely, if the site in your browser does not match the site in your request, then you've got a cross-site or third-party cookie. The same cookie may be sent in both of these scenarios. So first, a third-party is about the context of the request, not a specific property of the cookie. Now we've classified our cookies. Let's talk about where you might be using these third-party ones. Requests for remote resources are the most common. So that's things like a script, a pixel, or a font that you're pulling from a different site. It also covers content embedded in an iframe. In fact, if you're watching this video embedded on another site, then I'm in an iframe right now. And the cookies that would enable you to like, comment, and subscribe are all in a third-party context. If users are sent to your site via something other than a normal get request, like a post request from a form submission, then the cookies on that request count as cross-site. You may have this as part of an authentication flow with an identity service. Additionally, it's important to test use cases outside of a standalone browser and a web page. You should check your cookie behavior if you work with Chrome extensions, web views, Electron apps, or other embedded browsers. Speaking of testing, let's see how you do that. You may want to toggle old and new behavior when checking your site. You can do this through the Chrome Flags interface. Search for same site, and the two flags you need are same site by default cookies, and cookies without same site must be secure. To be sure you've got the new behavior, set both of these to enabled. Now head over to the site you want to test. Open up DevTools and go to the Console tab. As the page loads, you can see a couple warnings. These messages will tell you whenever a cookie is blocked and why. If the listed site is one that you're responsible for, then you need to update the cookies. If it's a third-party service, then you should check with their support channels that they are doing the same. You can then use the Network panel to dig into the individual requests. If you pick one of the cross-site requests, then you can look at the Cookies tab in there. Now, that's a lot of yellow because I've deliberately baked some messed-up cookies. For each one, you can see both the same site and the secure attributes, and the tooltip will tell us why that cookie was blocked. With your cookies identified, let's see what you need to do. The same-site attribute in your cookie is what's telling the browser whether this can be sent in first or third-party contexts. The new default means that for unmarked cookies, they will be treated as if they specified same-site equals lax. That restricts them to just same-site or first-party requests. If that's all you need, you should explicitly add this to your cookie to get consistent behavior across browsers. Now, for your cookies where you do need them to be sent on cross-site requests, you need to mark them with both same-site equals none and secure. That way, you're explicitly saying you want this wider distribution. We are mandating secure connections for third-party cookies, so that means that any requests that need those cookies must be over HTTPS. That should be enough to get you cooking, but if you're hungry for more, you can check out our articles across the Chromium blog, web.dev, and chromium.org. You can also find us on Twitter, GitHub, and Stack Overflow for questions and examples. Thanks for watching.