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

227 views
Skip to first unread message

Johann Hofmann

unread,
Mar 20, 2023, 5:35:10 PM3/20/23
to blink-dev, mreic...@chromium.org, kaust...@chromium.org

Contact emails

joha...@chromium.org, mreic...@chromium.org, kaust...@chromium.org


Explainer

https://github.com/privacycg/requestStorageAccessForOrigin

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


Specification

https://privacycg.github.io/requestStorageAccessForOrigin


Summary

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

Blink>StorageAccessAPI


TAG review

https://github.com/w3ctag/design-reviews/issues/808


TAG review status

Pending


Risks



Interoperability and Compatibility


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/736)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/125)


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.


Ergonomics

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?

No



Debuggability



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, https://wpt.fyi/results/top-level-storage-access-api. Note that while tests are passing locally in Chrome, they’re not yet showing up on wpt.fyi because the feature wasn’t included in the experimental web platform features flag.


Flag name

StorageAccessAPIForOriginExtension


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

https://chromestatus.com/feature/5122534152863744


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGg35awh2_aqmFtWgOdo40vYVnWf%2BkEv3o7jxZ8DLbWq0eC3eQ%40mail.gmail.com



This intent message was generated by Chrome Platform Status.


Yoav Weiss

unread,
Mar 29, 2023, 5:39:55 AM3/29/23
to Johann Hofmann, blink-dev, mreic...@chromium.org, kaust...@chromium.org
LGTM1

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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4g87zWDtnn00w1%2BVD%2BYwr9oP0TjOfemX97VrBe96kby3A%40mail.gmail.com.

Johann Hofmann

unread,
Mar 29, 2023, 10:45:39 AM3/29/23
to Yoav Weiss, blink-dev, mreic...@chromium.org, kaust...@chromium.org
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 https://github.com/privacycg/requestStorageAccessFor and https://privacycg.github.io/requestStorageAccessFor/, respectively. (apologies to those who hit a 404 on the spec link)

Mike Taylor

unread,
Apr 6, 2023, 12:26:28 PM4/6/23
to Johann Hofmann, Yoav Weiss, blink-dev, mreic...@chromium.org, kaust...@chromium.org

Eli Grey

unread,
Apr 8, 2023, 9:34:23 PM4/8/23
to blink-dev, mike...@chromium.org, blink-dev, mreic...@chromium.org, kaust...@chromium.org, Johann Hofmann, yoav...@chromium.org
Are you planning to ship both the plural and singular APIs or just one of the two?

Elijah Grey

unread,
Apr 10, 2023, 9:10:40 AM4/10/23
to blink-dev, Mike Taylor, blink-dev, mreic...@chromium.org, kaust...@chromium.org, 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

unread,
Apr 10, 2023, 9:23:28 AM4/10/23
to blink-dev, Elijah Grey, Mike Taylor, blink-dev, mreic...@chromium.org, 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.

Chris

Reply all
Reply to author
Forward
0 new messages