 Hello. Chip stands for cookies having independent partition state and introduces new cookie behavior that improves user privacy and security. It allows developers to opt a cookie into partition storage with separate cookie jars per top level site. In this video, I'll explain how it works, why we need it, and when you should use it. Without partitioning, third-party cookies can enable services to track users and join their information from across many unrelated top-level sites. This is known as cross-site tracking. You can identify third-party cookies by their same-site-none value. Once Chrome starts limiting access to third-party cookies by default, any cookies that contain same-site-none will require updates. Chips related by website sets or storage access API will be the only way to read and write cookies from cross-site context, such as iframes when third-party cookies are blocked. So make sure to audit your use of cookies so your sites are prepared to run without third-party cookies. Let's see how chips works. Chips introduces a new cookie attribute, partitioned, to support cross-site cookies that are partitioned by top-level context. All partitioned cookies must also be set with secure attribute to ensure they are only set and sent over secure protocols. A partitioned third-party cookie is tied to the top-level site where it's initially set and cannot be accessed from elsewhere. This way, cookies set by a third-party service can only be read within the same embedded context of the top-level site where they were initially set. In this example, the cookie comes from storefinder.site, which hosts a map of stores that enables a user to save their favorite store. By using chips, when brand A.site embeds storefinder.site, the value of my favorite cookie store cookie is 1, 2, 3. Then, if brand B.site also embeds storefinder.site, they will set and send their own partitioned instance of my favorite store cookie. In this example, the cookie set by the storefinder on brand B.site has the value of 4, 5, 6. This means that embedded services can still save site but do not have shared cross-site storage that would allow cross-site tracking. Use cases for chips include third-party chat embeds, map embeds, or payment embeds, sub-resourced CDN load balancing, headless CMS providers, sandbox domains for serving untrusted user content, and more. Chips is easy to implement. It's just adding another attribute to cross-site cookies. So if you have a service that's embedded in a third-party context, check if chips satisfies your use case. If your site is embedding a third-party service like this, you don't need to make changes to any cookies, but do check with your service provider that your dependencies will continue working when third-party cookies are blocked. Chips is an important step to help services make a smooth transition to a future without third-party cookies. It is really the way cookies should work by default, but backwards compatibility is an important part of the web. By having an additional attribute, chips provides an opt-in to a more restrictive, more secure type of cookie behavior. To get ready for the future without cross-site tracking, audit your use of cookies and plan the actions needed if your site is impacted. For cross-site cookies which store data on a per-site basis, chips is likely the right solution. To learn more about chips, check out our documentation and demos. Thanks for watching.