Intent to Prototype: Storage Access API Headers

278 views
Skip to first unread message

Sam LeDoux

unread,
Apr 19, 2024, 10:23:01 AMApr 19
to blin...@chromium.org

Contact emails

sle...@chromium.org, cfre...@chromium.org, joha...@chromium.org


Explainer

https://github.com/cfredric/storage-access-headers


Specification

None


Summary

Storage Access Headers extends the Storage Access API to offer a way for non-iframe cross-site subresources to opt in for unpartitioned cookies, and a way for cross-site iframes to activate the `storage-access` permission during the frame's load. These headers leverage permissions that have already been granted to reduce loads and latency for authenticated embeds and unlock new embedded use cases.


Blink component

Blink>StorageAccessAPI


Motivation

The Storage Access API currently supports the ability of authenticated embeds to opt in for unpartitioned cookies by requiring them to call a JavaScript API. Iframes that load credentialed subresources may therefore load, then invoke document.requestStorageAccess(), then reload themselves to re-trigger the subresource fetches. This creates latency, as the process includes unnecessary network round trips and/or document loads, and it limits use cases by requiring the embedded resources to use an iframe.


Initial public proposal

https://github.com/privacycg/storage-access/issues/130


TAG review

None


TAG review status

Not yet requested. 


Risks


Interoperability and Compatibility

None



Gecko: Tentatively Positive (we will request a formal standards position as well)


WebKit: Tentatively Neutral (we will request a formal standards position as well)


Web developers: Positive (feature request, feature request, feature request


Other signals:


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?

None



Debuggability

None


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

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/u/0/issues/332335089


Estimated milestones

TBD


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6146353156849664


Antonio Sartori

unread,
Apr 23, 2024, 10:15:12 AMApr 23
to blink-dev, Sam LeDoux
Hi,

after discussing this in the OWP Security&Privacy reviews, we would like to have an allowlisting of the embedding origins as discussed in https://github.com/cfredric/storage-access-headers/issues/7, implementing arturjanc's proposal ("Require Activate-Storage-Access to specify not only permission, but also the origin that is meant to receive the ability to load the resource with credentials.")

Reading cfredric's response to that, it looks like there might be consensus around that.

Thanks!
Antonio

Johann Hofmann

unread,
Apr 23, 2024, 11:02:41 AMApr 23
to Antonio Sartori, blink-dev, Sam LeDoux
Thanks Antonio! As mentioned on the issue, I think this sounds like a reasonable idea, though we'll have to think through some of the details of it a bit more, and will update the explainer accordingly.

--
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/6441c492-b1d2-4897-909e-3c5fbbf5e459n%40chromium.org.
Reply all
Reply to author
Forward
0 new messages