Intent to Ship: requestStorageAccessFor (for First-Party Sets)

Skip to first unread message

Johann Hofmann

Mar 20, 2023, 5:35:10 PMMar 20
to blink-dev,,

Contact emails,,


(note that we recently updated the name to remove “origin”, but not yet the repository name)



An extension to the Storage Access API that allows a top-level site to request access to unpartitioned ("first-party") cookies on behalf of embedded sites. Browsers will have discretion to grant or deny access, with mechanisms like First-Party Set membership as a potential signal. This allows for use of the Storage Access API by top-level sites.

For now, we intend to ship requestStorageAccessFor without user-facing prompts, instead relying on information from First-Party Sets to determine which sites should be granted storage access.

Blink component


TAG review

TAG review status



Interoperability and Compatibility

Gecko: No signal (

WebKit: No signal (

This has been discussed with other browser vendors outside of the standards-positions repositories. These browsers ship this functionality as a version that is only accessible to internal code (as an anti-cross-site-cookie-breakage measure), but haven’t exposed it to developers, primarily out of prompt relevance concerns. There have been mixed reactions to our proposal, with the primary feedback being on reputation concerns with potential prompts, and a desire to maintain the security benefits from cross-site cookie blocking to an even larger extent. We intend to work on these concerns in collaboration with other browsers (if possible).

Edge: No public signal. However, we’ve discussed this with Edge and they are supportive of this additional API surface and will work on enabling it (i.e. providing the prompts or FPS mechanisms to gate it) on Edge as well.

Web developers:

Positive. There has been developer feedback on SAA asking for this or similar functionality, as well as communication with partners that are trying out the API to utilize FPS.


Like requestStorageAccess, this API requires additional work from the developer compared to the old state of "passive" cross-site cookie access. This is an inherent, intentional property of the design.

For security reasons, this feature requires developers to use either CORS headers (for non-iframe subresources) or requestStorageAccess in iframes to be able to access cross-site cookies after a requestStorageAccessFor call.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. This will be supported on Windows, Mac, Linux, Chrome OS, and Android, but will not initially be supported on Android WebView.

Is this feature fully tested by web-platform-tests?

Yes, Note that while tests are passing locally in Chrome, they’re not yet showing up on because the feature wasn’t included in the experimental web platform features flag.

Flag name


Requires code in //chrome?

True, as we’re adding a new permission and integrating with FPS. As mentioned in the FPS I2S, Chromium-based browsers should be able to consume the list through component updater.

Estimated milestones

Shipping in M113.

Anticipated spec changes

Some details of this API are still being discussed in the Privacy CG and there may be backwards-incompatible changes in the future. As mentioned above, the primary feedback has been on reputation concerns with potential prompts, and a desire to maintain the security benefits from cross-site cookie blocking to an even larger extent.

We are confident in shipping the API in its current state to better understand and iterate on real-world developer needs, and accept the responsibility of supporting potential future breaking API changes. Since use of the API in Chrome is currently restricted to First-Party Sets, we think it allows us to leverage targeted developer outreach to minimize compatibility impact.  

Link to entry on the Chrome Platform Status

Links to previous Intent discussions

Intent to prototype:

This intent message was generated by Chrome Platform Status.

Yoav Weiss

Mar 29, 2023, 5:39:55 AMMar 29
to Johann Hofmann, blink-dev,,

I appreciate the reliance on this API on FPS as an internal concept (equivalent to the reliance of other browsers on entities.json) to significantly reduce its user friction as well as the risk that other vendors are concerned with (e.g. reputation concerns).

I think we've made significant strides towards eventual interoperability with this, without compromising on the use cases we care about, and without unnecessarily burdening users with privacy labour.

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Johann Hofmann

Mar 29, 2023, 10:45:39 AMMar 29
to Yoav Weiss, blink-dev,,
Thanks Yoav!

One minor note to the group that we successfully renamed the repository and so the explainer and spec can now be found at and, respectively. (apologies to those who hit a 404 on the spec link)

Mike Taylor

Apr 6, 2023, 12:26:28 PMApr 6
to Johann Hofmann, Yoav Weiss, blink-dev,,

Eli Grey

Apr 8, 2023, 9:34:23 PMApr 8
to blink-dev,, blink-dev,,, Johann Hofmann,
Are you planning to ship both the plural and singular APIs or just one of the two?

Elijah Grey

Apr 10, 2023, 9:10:40 AMApr 10
to blink-dev, Mike Taylor, blink-dev,,, Johann Hofmann, Yoav Weiss
It's not clear which version of the requestStorageAccessFor() API is being shipped. Are both the singular and plural APIs being shipped, or just one of them?
This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

Chris Fredrickson

Apr 10, 2023, 9:23:28 AMApr 10
to blink-dev, Elijah Grey, Mike Taylor, blink-dev,, Kaustubha Govind, Johann Hofmann, Yoav Weiss
Hi Elijah,

The specification describes the API shape and behavior. The design we're shipping is the "singular" one from the explainer. The discussion of the "plural" API in the explainer was just hypothetical, to explore the design space and motivate why the singular API is simpler.


Reply all
Reply to author
0 new messages