Intent to Ship: requestStorageAccessFor (for First-Party Sets)
Johann Hofmann
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
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
--
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
Mike Taylor
LGTM2
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4gsMixxu7f6pGGtEQ-8cUcYw35fJMZqN%3DmphF2MdkSAkg%40mail.gmail.com.
