Exploring the Storage Access API

Join this channel to get access to perks:
/ @tech-forum
#browser #privacy #google #web #api #ad #adtech #dsp #ssp #3pc #conversion #cookies #sso #remarketing #marketing #chrome
github.com/techforum-repo/you...
chrome://flags/#test-third-party-cookie-phaseout
chrome://flags/#test-third-party-cookie-phaseout
developer.mozilla.org/en-US/d...
The Storage Access API is a web platform feature that allows websites to request and manage access to storage, including cookies and other web storage mechanisms, in a cross-site context. It provides a standardized way for websites to control how their content interacts with storage across different origins (domains) while considering user privacy and security.
This API is important for scenarios where embedded content (like iframes) from different websites needs to interact with and share storage data, such as cookies, in a secure and controlled manner. It helps prevent cross-site tracking and data leakage by giving websites more granular control over which third-party sites can access their storage.
Websites can use the Storage Access API to request access to storage on behalf of embedded content and receive permission from the user. This permission allows for more secure cross-site interactions while maintaining user trust and privacy.
Allowing a sandboxed iframe to use the API
If the iframe is sandboxed, the embedding website needs to add the allow-storage-access-by-user-activation sandbox token to allow Storage Access API requests to be successful, along with allow-scripts and allow-same-origin to allow it to execute a script to call the API and execute it in an origin that can have cookies
Check whether the API is supported - (if (document.hasStorageAccess) {}).
If the API is supported, we call document.hasStorageAccess().
If that call returns true, it means this iframe has already obtained access, and we can run our code that accesses cookies right away.
If that call returns false, we then call Permissions.query() to check whether permission to access third-party cookies has already been granted (i.e., to another same-site embed).
If the permission state is "granted", we immediately call document.requestStorageAccess(). This call will automatically resolve, saving the user some time, then we can run our code that accesses cookies.
If the permission state is "prompt", we call document.requestStorageAccess() after user interaction. This call may trigger a prompt to the user. If this call resolves, then we can run our code that accesses cookies.
If the permission state is "denied", the user has denied our requests to access third-party cookies, and our code cannot use them.
Depending on the browser, the user will be asked whether to grant access to the requesting embed in slightly different ways.
Safari shows prompts for all embedded content that has not previously received storage access.
Firefox only prompts users after an origin has requested storage access on more than a threshold number of sites.
Chrome shows prompts for all embedded content that has not previously received storage access. It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same related website set.
Access is granted or denied based on whether the content meets all the security requirements
Once access is granted, a permission key is stored in the browser with the structure (top-level site, embedded site).
Browser-specific variations:
Websites using the Storage Access API should expect differences in the level and extent of third-party cookie access they receive between different browsers, due to differences in their storage access policies.
Chrome
Cookies must have SameSite=None explicitly set on them, because the default value for Chrome is SameSite=Lax (SameSite=None is the default in Firefox and Safari).
Cookies must have the Secure attribute set on them.
The storage access grants are phased out after 30 days of browser usage passed without user interaction. Interaction with the embedded content extends this limit by another 30 days.
Firefox
If the embedded origin tracker.example has already obtained third-party cookie access on the top-level origin foo.example, and the user visits a page from foo.example embedding a page from tracker.example again in less than 30 days, the embedded origin will have third-party cookie access immediately when loading.
The storage access grants are phased out after 30 calendar days have passed.
Documentation for Firefox's new storage access policy for blocking tracking cookies includes a detailed description of the scope of storage access grants.
Safari
The storage access grants are phased out after 30 days of browser usage passed without user interaction. Successful use of the Storage Access API resets this counter.

[@rohan1000com]

Thanks for the detailed information.
I tried the same steps to access localstorage but it is not working, can you please provide some information on accessing localstorage with chrome phasing out third party storage access?

Can you provide the code repo, please?

[@Tech-Forum]

Please find the code here - github.com/techforum-repo/youttubedata/tree/master/Google-Privacy-Sandbox