 Storage Access API provides a way for embedded cross-site content to check whether it currently has access to browser-based storage, such as cookies, and to request storage access if it doesn't. The API only enables embedded sites to access its own cookies, the same cookies it would have access to when users visited as a top-level site. In this video, I'll explain how it works, when you should use it, and what alternative solutions you should consider. Let's foresee why we need the Storage Access API. Third-party cookies are the main mechanism that enables cross-site tracking, and several major browsers have already placed restrictions on third-party cookies in some way. In 2024, Chrome is planning to phase out support for third-party cookies. We have already introduced new cookie functionality and purpose-built APIs to continue supporting legitimate use cases while preserving user privacy. At the start of January 2024, we will disable third-party cookies for 1% of Chrome users, which means you want to be sure that your site is ready. Third-party cookies also enable many valid use cases, such as managing state-in-embedded content or enabling user sessions across multiple sites. New APIs, like Chips, related website sets, and FedCM, will cover many of these use cases. Still, there are user experiences that rely on unpartitioned cookie access today that are not fully covered by those technologies. For example, authenticated cross-site embeds, such as commenting widgets or subscribed video services, often rely on cookies to authenticate users who are already logged in to their first-party services. When browsers block access to unpartitioned cookies by embedded sites loaded in a third-party context, Storage Access API can be used as a fallback to enable those user experiences. So, how does the Storage Access API work? Storage Access API has methods for sites to check whether they currently have access to unpartitioned cookies and, if not, to request it. Has Storage Access is used to check if the embedded site has access to unpartitioned cookies and other storage in the current context. It returns a promise with a Boolean result, indicating if the document has Storage Access or not. Request Storage Access is used to request access to unpartitioned cookies and storage for an embedded iframe document. It returns a promise that will resolve if access is available. If the request is unsuccessful, the promise will be rejected. There are a few requirements to using Storage Access API in Chrome. First, request Storage Access can only be called from within an iframe. Second, the user must have visited and interacted with the site that owns that iframe as a top-level document, not in an iframe. And third, the user must interact with the iframe before Request Storage Access can be called by, for example, clicking a button or a link. The request will present users with a prompt to either allow or deny access. As with many powerful features like camera or location access, we provide the user with the ability to grant or deny access. You need to consider this in your user flow. Make sure the steps to and reason for granting Storage Access are clear to your users. And of course, make sure you can gracefully deal with them denying the permission as well. Storage Access is an existing web platform API that is also supported in Firefox, Edge, and Safari. Recently, browsers have worked on specification improvements that address security considerations and added features such as permission API support. So if you have already implemented Storage Access API for cross-site cookie access in other browsers, make sure to test it in Chrome as well, which supports the latest version of the API. Storage Access isn't going to be the right solution for every cross-site cookie situation. If your third-party cookie is only being used in a one-to-one embedded context with the top-level site, for example, in third-party chant embeds, map embeds, or third-party payment embeds, consider using CHIPS, which stands for Cookies Having Independent Partition State. Adding the partitioned attribute to your cookies will allow cross-site access with a separate cookie jar used per site. If you're using Storage Access API across a small group of meaningfully linked sites, related website sets can offer a smoother user experience without prompts for sites within a set and additional functionality for the top-level site, not just the iframe, to grant Storage Access. There is also a wider set of purpose-built APIs that may allow you to migrate away from cross-site cookies entirely. For example, your identity provider may support FEDCM to let you handle signing without cookies. To learn more about these APIs, check out our videos and documentation. Now is the time 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. Thanks for watching.