sle...@chromium.org, cfre...@chromium.org, joha...@chromium.org
https://github.com/cfredric/storage-access-headers
None
Storage Access Headers offer an alternate way for authenticated embeds to opt in for unpartitioned cookies. These headers indicate whether embedded resources would like to load with permission they have already been granted, reducing loads and latency overall for these use cases.
https://github.com/w3ctag/design-reviews/issues/982
Completed
There is a small compatibility risk as this feature involves sending the Origin header in new contexts. We're working to limit the new Origin headers to be included only on "inactive" requests, in order to minimize compat impact.
Not available on WebView
This experiment would allow us to receive and incorporate feedback on the browser's application of the `Sec-Fetch-Storage-Access` request header, as well as the browser's handling of the `Activate-Storage-Access` header before the feature is fully launched.
Experiment behavior
This experiment would rely on an Origin Trial (OT) to test the Storage Access Header feature. Once the OT is active for an origin, requests to the same context that it was enabled on will include the `Sec-Fetch-Storage-Access` header, and the browser will handle responses with the `Activate-Storage-Access` header in accordance with the feature’s description.
This experiment relies on the use of a persistent OT. Developers opting into the use of Storage Access Headers should not expect the `Sec-Fetch-Storage-Access` request header to be included on initial navigations to their origin as the feature will only be active after receiving its first OT token. Additionally, all subsequent navigations to an opted-in origin should include the token, otherwise the browser will take this as a signal that the origin is no longer participating in the trial.
None
Currently best debugged via chrome://net-export logs, as Chrome DevTools does not show the full chain of network events. We may add improved debugging capabilities in the future.
No.
Supported for Mac, Windows, Linux, Chrome OS, and Android.
No
#storage-access-headers
Yes
https://issues.chromium.org/issues/332335089
https://launch.corp.google.com/launch/4309903
Experiment desktop first 130
https://chromestatus.com/feature/6146353156849664
Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/yfxV-jLMqNg/m/NJFVBEAyAQAJ
On 10/3/24 4:05 PM, 'Sam LeDoux' via blink-dev wrote:
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 offer an alternate way for authenticated embeds to opt in for unpartitioned cookies. These headers indicate whether embedded resources would like to load with permission they have already been granted, reducing loads and latency overall for these use cases.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/982
TAG review status
Completed
Risks
Interoperability and Compatibility
There is a small compatibility risk as this feature involves sending the Origin header in new contexts. We're working to limit the new Origin headers to be included only on "inactive" requests, in order to minimize compat impact.
--
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/CABa1CXyYbxwh%3DPdnigTW80d9jez_835R1SV1bQPDjvk1ra5G4g%40mail.gmail.com.
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 offer an alternate way for authenticated embeds to opt in for unpartitioned cookies. These headers indicate whether embedded resources would like to load with permission they have already been granted, reducing loads and latency overall for these use cases.
Blink component
TAG review
TAG review status
Completed
Risks
Interoperability and Compatibility
There is a small compatibility risk as this feature involves sending the Origin header in new contexts. We're working to limit the new Origin headers to be included only on "inactive" requests, in order to minimize compat impact.
WebView application risks
Not available on WebView
Goals for experimentation
This experiment would allow us to receive and incorporate feedback on the browser's application of the `Sec-Fetch-Storage-Access` request header, as well as the browser's handling of the `Activate-Storage-Access` header before the feature is fully launched.
Experiment behavior
This experiment would rely on an Origin Trial (OT) to test the Storage Access Header feature. Once the OT is active for an origin, requests to the same context that it was enabled on will include the `Sec-Fetch-Storage-Access` header, and the browser will handle responses with the `Activate-Storage-Access` header in accordance with the feature’s description.
This experiment relies on the use of a persistent OT. Developers opting into the use of Storage Access Headers should not expect the `Sec-Fetch-Storage-Access` request header to be included on initial navigations to their origin as the feature will only be active after receiving its first OT token. Additionally, all subsequent navigations to an opted-in origin should include the token, otherwise the browser will take this as a signal that the origin is no longer participating in the trial.
Ongoing technical constraints
None
Debuggability
Currently best debugged via chrome://net-export logs, as Chrome DevTools does not show the full chain of network events. We may add improved debugging capabilities in the future.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No.
Supported for Mac, Windows, Linux, Chrome OS, and Android.
Is this feature fully tested by web-platform-tests?
No
Flag name on chrome://flags
#storage-access-headers
Requires code in //chrome?
Yes
Tracking bug
https://issues.chromium.org/issues/332335089
Launch bug
https://launch.corp.google.com/launch/4309903
Estimated milestones
Experiment desktop first 130
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6146353156849664
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/yfxV-jLMqNg/m/NJFVBEAyAQAJ
The TAG identified a few smaller issues in their review. Can you re-file those as issues on https://github.com/privacycg/storage-access-headers/issues and make sure they get a fair discussion via the PrivacyCG?
Will this eventually be testable, before shipping?