Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Ship: Storage Access Headers

364 views
Skip to first unread message

Chris Fredrickson

unread,
Jan 2, 2025, 1:36:17 PMJan 2
to blink-dev
Contact emails

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


Explainer

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


Specification

https://privacycg.github.io/storage-access-headers


Summary

Storage Access Headers offer an alternate way for authenticated embeds to opt in to unpartitioned cookies. These headers indicate whether embedded resources should load with permission they have already been granted, reducing loads and latency overall for these use cases.



Blink component

Blink>StorageAccessAPI


Search tags

storage access api, storage access headers


TAG review

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


TAG review status

Satisfied in early design review. TAG didn’t expect to have major input on the spec and invited us to proceed without their spec review. 


Chromium Trial Name

StorageAccessHeader


Origin Trial documentation link

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


Risks

Interoperability and Compatibility

This feature poses a minor compatibility risk, since the Origin header is now included on requests that include the "Sec-Fetch-Storage-Access: inactive" header - and some servers do not yet properly handle the Origin header.


However, this risk is low, because:

* The "inactive" header is only included on clients that already block third-party cookies.

* The presence of the "inactive" header implies that the request is cross-site, and that the site in question already uses the Storage Access API (which is relatively new to the web platform) or that the context is an "A > B > A" embedding scenario.

* This feature omits the Origin header from requests whose `credentials` mode is not "include".



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1084)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/412)


Web developers: Positive (https://github.com/privacycg/storage-access/issues/130) Other feature requests: * https://github.com/privacycg/storage-access/issues/170 * https://github.com/privacycg/storage-access/issues/189


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

This is debuggable via DevTools and via chrome://net-export.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

The Storage Access API itself is not yet supported on Android WebView.



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

Yes


DevTrial instructions

https://developers.google.com/privacy-sandbox/blog/storage-access-api-headers-logic


Flag name on chrome://flags

storage-access-headers


Finch feature name

StorageAccessHeaders


Requires code in //chrome?

False


Tracking bug

https://b.corp.google.com/issues/329698698


Launch bug

https://launch.corp.google.com/launch/4309903


Measurement

We've written metrics to track the usages of the "load" and "retry" response headers, and to measure the incidences of each variant of the request header.


Sample links

https://storage-access-headers-demo.glitch.me


Estimated milestones

Origin trial desktop first


130


Origin trial desktop last


135


Origin trial Android first


130


Origin trial Android last


135



Anticipated spec changes

Open questions about a feature may be a source of future web compatibility or interoperability issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None


Anticipated implementation changes

We decided not to separately integrate the “Activate-Storage-Access” header with the SAA Permissions Policy in this initial version. The follow-up work to figure out the integration is tracked in https://crbug.com/382291442. Because of how SAH works this header already “benefits” from the SAA PP by default (SAH won’t work if there’s no SAA permission grant), and we haven’t seen developer demand for being able to prevent just the header, but not SAA itself. The implementation carries a surprising amount of architectural complexity, but we do plan to follow up with this for completeness. Most importantly, adding this later is unlikely to cause compat risks because SAA has a “*” default allow-list, so we won't be changing default behavior.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6146353156849664?gate=6138146145435648


Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXyMJzMmpQkZMwQUFGK8-f%3DEerhR2VQbTZephdmE22W%2ByA%40mail.gmail.com

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXyYbxwh%3DPdnigTW80d9jez_835R1SV1bQPDjvk1ra5G4g%40mail.gmail.com



This intent message was generated by Chrome Platform Status.


Yoav Weiss (@Shopify)

unread,
Jan 2, 2025, 10:53:50 PMJan 2
to Chris Fredrickson, blink-dev
On Thu, Jan 2, 2025 at 7:36 PM Chris Fredrickson <cfre...@chromium.org> wrote:
Contact emails

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


Explainer

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


Do I understand correctly and the extra RTT imposed by the "retry" is required for security reasons?
 

Specification

https://privacycg.github.io/storage-access-headers


Summary

Storage Access Headers offer an alternate way for authenticated embeds to opt in to unpartitioned cookies. These headers indicate whether embedded resources should load with permission they have already been granted, reducing loads and latency overall for these use cases.



Blink component

Blink>StorageAccessAPI


Search tags

storage access api, storage access headers


TAG review

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


TAG review status

Satisfied in early design review. TAG didn’t expect to have major input on the spec and invited us to proceed without their spec review. 


Chromium Trial Name

StorageAccessHeader


Origin Trial documentation link

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


Risks

Interoperability and Compatibility

This feature poses a minor compatibility risk, since the Origin header is now included on requests that include the "Sec-Fetch-Storage-Access: inactive" header - and some servers do not yet properly handle the Origin header.


However, this risk is low, because:

* The "inactive" header is only included on clients that already block third-party cookies.

* The presence of the "inactive" header implies that the request is cross-site, and that the site in question already uses the Storage Access API (which is relatively new to the web platform) or that the context is an "A > B > A" embedding scenario.

* This feature omits the Origin header from requests whose `credentials` mode is not "include".


Hmm, so we'd start sending the Origin header on no-CORS requests?
Have we tried to quantify that risk? Finch it in some way?
 
--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1bbe492c-8722-4dbf-8342-82f59fbb0bd2n%40chromium.org.

Chris Fredrickson

unread,
Jan 3, 2025, 10:58:19 AMJan 3
to blink-dev, Yoav Weiss, blink-dev, Chris Fredrickson
On Thursday, January 2, 2025 at 10:53:50 PM UTC-5 Yoav Weiss wrote:
On Thu, Jan 2, 2025 at 7:36 PM Chris Fredrickson <cfre...@chromium.org> wrote:
Contact emails

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


Explainer

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


Do I understand correctly and the extra RTT imposed by the "retry" is required for security reasons?

Yes, the additional round trip is necessary for security. (We recognize that an extra round trip is not ideal, and we're working on a way to "reuse" the security signal provided by one round trip for subsequent requests.)
 
 

Specification

https://privacycg.github.io/storage-access-headers


Summary

Storage Access Headers offer an alternate way for authenticated embeds to opt in to unpartitioned cookies. These headers indicate whether embedded resources should load with permission they have already been granted, reducing loads and latency overall for these use cases.



Blink component

Blink>StorageAccessAPI


Search tags

storage access api, storage access headers


TAG review

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


TAG review status

Satisfied in early design review. TAG didn’t expect to have major input on the spec and invited us to proceed without their spec review. 


Chromium Trial Name

StorageAccessHeader


Origin Trial documentation link

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


Risks

Interoperability and Compatibility

This feature poses a minor compatibility risk, since the Origin header is now included on requests that include the "Sec-Fetch-Storage-Access: inactive" header - and some servers do not yet properly handle the Origin header.


However, this risk is low, because:

* The "inactive" header is only included on clients that already block third-party cookies.

* The presence of the "inactive" header implies that the request is cross-site, and that the site in question already uses the Storage Access API (which is relatively new to the web platform) or that the context is an "A > B > A" embedding scenario.

* This feature omits the Origin header from requests whose `credentials` mode is not "include".


Hmm, so we'd start sending the Origin header on no-CORS requests?

That's correct - but only if the recipient site has already been granted the "storage-access" permission (or the request context is an A>B>A embed, so no explicit permission grant is needed) and the request's credentials mode is "include". I.e., only if the value of the Sec-Fetch-Storage-Access header is "inactive".
 
Have we tried to quantify that risk? Finch it in some way? 

We have UMA metrics on Dev that can help upper-bound the risk. On Windows clients that have manually enabled this feature, 6k out of 88M cross-site requests (about 0.00007%) included the Sec-Fetch-Storage-Access header and set its value to "inactive". (On Mac, Linux, and Android, these numbers are 0.0001%, 0.0004%, and 0.0005%, respectively.) These numbers are an overestimate of the expected breakage, since they only count cross-site requests, and presumably some of those requests were to servers that handle the Origin header properly.

Those metrics are a limited sample and are certainly biased since they come from Dev clients that have manually enabled the feature. But those fractions are small enough to make me feel more comfortable launching this. (Anecdotally, I've been running Chrome with this feature enabled for months on my corp and personal profiles, and haven't run into any noticeable breakage.)
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss (@Shopify)

unread,
Jan 3, 2025, 11:44:35 AMJan 3
to Chris Fredrickson, blink-dev
LGTM1

This seems like a reasonable optimization, and I like plans to optimize this further. The immediate compat risk does indeed seem tiny. (but please keep the flag around just in case) 

Peter Pakkenberg

unread,
Jan 6, 2025, 10:08:53 AMJan 6
to blink-dev, Yoav Weiss, blink-dev, Chris Fredrickson

Hi Chris, 


> The Storage Access API itself is not yet supported on Android WebView.


WebView does support the Storage Access JS methods, but lacks a way to grant permission, which we are currently working on adding. Once that work is done, the already exposed JS interfaces will be usable by web content.


I also don’t see any code to explicitly disable the kStorageAccessHeaders flag on WebView, so if the feature flag is flipped to enabled by default, then this feature will be launched on WebView.


Is there any reason why the header feature should not be supported by WebView?


Chris Fredrickson

unread,
Jan 6, 2025, 10:28:53 AMJan 6
to blink-dev, Peter Pakkenberg, Yoav Weiss, blink-dev, Chris Fredrickson
On Monday, January 6, 2025 at 10:08:53 AM UTC-5 Peter Pakkenberg wrote:

Hi Chris, 


> The Storage Access API itself is not yet supported on Android WebView.


WebView does support the Storage Access JS methods, but lacks a way to grant permission, which we are currently working on adding. Once that work is done, the already exposed JS interfaces will be usable by web content.


Thanks for the clarification, I was a bit imprecise there.
 

I also don’t see any code to explicitly disable the kStorageAccessHeaders flag on WebView, so if the feature flag is flipped to enabled by default, then this feature will be launched on WebView.


That's correct; my plan was to disable the feature on WebView using AwFieldTrials::RegisterFeatureOverrides in the same CL that default-enables the feature.
 

Is there any reason why the header feature should not be supported by WebView?


There's no reason why WebView shouldn't support this feature. I'm not opposed to including WebView when this feature ships, given what you said above!

Chris Fredrickson

unread,
Jan 7, 2025, 4:31:09 PMJan 7
to blink-dev, Chris Fredrickson, Peter Pakkenberg, Yoav Weiss, blink-dev
Minor updates:

Mike Taylor previously noted a possible concern about naming. Ben VanderSloot (Mozilla) indicated that they're not concerned about the names, so this concern has been resolved.

I also started a thread in blink-api-owners-discuss about whether we can also ship on WebView (given the earlier discussion), though I think it's still waiting for approval from a moderator.

Yoav Weiss (@Shopify)

unread,
Jan 7, 2025, 10:36:05 PMJan 7
to Chris Fredrickson, blink-dev, Peter Pakkenberg
On Tue, Jan 7, 2025 at 10:31 PM Chris Fredrickson <cfre...@chromium.org> wrote:
Minor updates:

Mike Taylor previously noted a possible concern about naming. Ben VanderSloot (Mozilla) indicated that they're not concerned about the names, so this concern has been resolved.

I also started a thread in blink-api-owners-discuss about whether we can also ship on WebView (given the earlier discussion), though I think it's still waiting for approval from a moderator.

FWIW, my LGTM still stands if we're expanding scope to cover WebView. 

Mike Taylor

unread,
Jan 8, 2025, 9:29:02 AMJan 8
to Yoav Weiss (@Shopify), Chris Fredrickson, blink-dev, Peter Pakkenberg

Thanks for the updates Chris. LGTM2.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BUjZy0vax%2B_u31q-WTHCrRo5%2B9%2BP6W6yF8LH%3DgdJJy1A%40mail.gmail.com.

Rick Byers

unread,
Jan 8, 2025, 10:26:01 AMJan 8
to Mike Taylor, Yoav Weiss (@Shopify), Chris Fredrickson, blink-dev, Peter Pakkenberg

Chris Fredrickson

unread,
Jan 9, 2025, 10:15:28 AMJan 9
to blink-dev, Rick Byers, Yoav Weiss, Chris Fredrickson, blink-dev, Peter Pakkenberg, Mike Taylor
Thanks all. We will proceed to launch on all Blink platforms.

--
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+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages