Intent to prototype: Storage-Access-Headers

[Manuel Bucher]

Summary:
Storage-Access-Headers is a draft to ease using unpartitioned cookies after storage-access has been granted with the Storage-Access-API using HTTP headers. The "Sec-Fetch-Storage-Access" header is sent on cross-origin resources letting the server know whether storage-access was previously granted and whether the request uses or could use unpartitioned cookies. The "Activate-Storage-Access"-response header to allow (re)loading the resource with unpartitioned cookies.
The feature is currently enabled in Nightly for testing with Bug 1991688. I'm intending to let it ride the train with Fx147 if nothing blocking comes up.

Bug: https://bugzil.la/1968715
Specification: https://privacycg.github.io/storage-access-headers/
Documentation: -
Preference: dom.storage_access.headers.enabled
Link to standards-positions discussion: https://github.com/mozilla/standards-positions/issues/1084
Tests: https://wpt.fyi/results/storage-access-api/storage-access-headers.tentative.https.sub.window.html?label=experimental&label=master&aligned
The tests still show up as failing on wpt.fyi due to side effects from previous tests: https://bugzil.la/1985789
Platform coverage: All
Other browsers:
* Blink: Supported (https://chromestatus.com/feature/6146353156849664?gate=5788202676518912)
* WebKit: positive (https://github.com/WebKit/standards-positions/issues/412)

[Lindsay Hall]

Hi all - Lindsay from Google Workspace here! Does Mozilla intend to ship the Storage Access Headers ahead of (or concurrently with) changes to adopt the Strict Same-Origin policy for Storage Access API? There are Google flows which rely on the prior Storage Access API semantics, and it is our understanding that Storage Access Headers are the recommended workaround to allow same-site, cross-origin requests to contain cookies once storage access is granted.

Thanks!

-Lindsay obo Google Workspace