Intent to Experiment: Storage Access Headers

242 views
Skip to first unread message

Sam LeDoux

unread,
Oct 3, 2024, 4:05:32 PM10/3/24
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 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

Blink>StorageAccessAPI


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.


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


Mike Taylor

unread,
Oct 4, 2024, 10:58:12 AM10/4/24
to Sam LeDoux, blin...@chromium.org

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

Blink>StorageAccessAPI


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.

Hey Sam, could you expand on the compat risk here? What might this break, and why?
--
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.

Sam LeDoux

unread,
Oct 4, 2024, 4:13:01 PM10/4/24
to blink-dev, Mike Taylor, Sam LeDoux
Hey, happy to give some more information on the compatibility risk. 

As part of the Storage Access Header implementation, we found that, for security purposes, it was necessary to send the `Origin` header in certain cross-site requests that would not previously have had the header. We've seen some breakage occur on servers when they receive an `Origin` header that they weren't expecting, which is the compatibility risk we're anticipating. To mitigate this, we are limiting the inclusion of the "new" Origin headers to requests where we include the `Sec-Fetch-Storage-Access` header with the `inactive` value. Our hope is that since the `inactive` value primarily covers cases where a storage access permission grant exists (with the exception of ABA cases), the impact of this change in `Origin` headers will be limited to "new" servers who are less likely experience breakage when they see the header in requests they weren't previously expecting. This thread provides some more context on the risk and decisions surrounding it: https://github.com/privacycg/storage-access-headers/issues/7#issuecomment-2089764041

Domenic Denicola

unread,
Oct 7, 2024, 12:49:22 AM10/7/24
to Sam LeDoux, blin...@chromium.org
LGTM to experiment, with a few notes inline.

On Fri, Oct 4, 2024 at 5:05 AM 'Sam LeDoux' via blink-dev <blin...@chromium.org> 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

Blink>StorageAccessAPI


TAG review

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


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?
 

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


Will this eventually be testable, before shipping?
 

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


Sam LeDoux

unread,
Oct 7, 2024, 12:02:31 PM10/7/24
to Domenic Denicola, blin...@chromium.org
Thank you Domenic. 

To address your notes:

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?

Just filed those concerns as issues (here and here). We will bring those up for discussion with the PrivacyCG as well.

Will this eventually be testable, before shipping?

Yes, we will be writing Web Platform Tests before we ship.

Best,
Sam
Reply all
Reply to author
Forward
0 new messages