Intent to Extend Experiment: Storage Access Headers

[Sam LeDoux]

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 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

Search tags

storage access api, storage access headers

TAG review

Not needed, per https://github.com/w3ctag/design-reviews/issues/982.

TAG review status

Not applicable

Origin Trial Name

Storage Access Headers

Chromium Trial Name

StorageAccessHeader

Origin Trial documentation link

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

WebFeature UseCounter name

kStorageAccessAPI_requestStorageAccess_Method

Risks

Interoperability and Compatibility

This feature poses 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 (which are not expected to be common).

* 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

None

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. 

Reason this experiment is being extended

We are currently targeting M133 for the stable launch of Storage Access Headers; therefore, we would like to extend the Origin Trial to last through M132, as partners have expressed a desire to continue experimenting with the Storage Access Headers feature up until it begins launching to stable.

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?

Yes

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

Shipping on desktop	133
Origin trial desktop first	130
Origin trial desktop last	131
Origin trial extension 1 end milestone	132
DevTrial on desktop	130
Shipping on Android	133
Origin trial Android first	130
Origin trial Android last	131
DevTrial on Android	130

Link to entry on the Chrome Platform Status

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

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.

[Mike Taylor]

On 12/9/24 3:39 PM, 'Sam LeDoux' via blink-dev wrote:

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 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

Search tags

storage access api, storage access headers

TAG review

Not needed, per https://github.com/w3ctag/design-reviews/issues/982.

TAG review status

Not applicable

(This should probably be changed to Resolution: satisfied, per the above link)

Origin Trial Name

Storage Access Headers

Chromium Trial Name

StorageAccessHeader

Origin Trial documentation link

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

WebFeature UseCounter name

kStorageAccessAPI_requestStorageAccess_Method

Risks

Interoperability and Compatibility

This feature poses 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 (which are not expected to be common).

* 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)

This is trending positive, but https://github.com/mozilla/standards-positions/issues/1084#issuecomment-2471319900 some possible renaming. Can we try to sort that out with Mozilla before shipping?

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

None

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.

What feedback have you received so far from participants?

Reason this experiment is being extended

We are currently targeting M133 for the stable launch of Storage Access Headers; therefore, we would like to extend the Origin Trial to last through M132, as partners have expressed a desire to continue experimenting with the Storage Access Headers feature up until it begins launching to stable.

This rationale sounds like using the OT as a soft-launch, which isn't great. Do you think your partners will learn something in the requested extra 4 weeks such that you might meaningfully incorporate the feedback ahead of a launch? (I think the answer is probably no, but I'd love to hear your perspective).

Can you also comment on substantial progress for the following (as relevant), since the original OT?

• Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)
• TAG review (see exceptions)
• bit.ly/blink-signals requests
• Outreach for feedback from the spec community
• WPT tests

--
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/CABa1CXxhJJVGame57-BhbW5r_XX2DgRaVcmo1fDu740S7b_hbg%40mail.gmail.com.

[Sam LeDoux]

Mike,

Thank you for the response. To address your comments:

This is trending positive, but https://github.com/mozilla/standards-positions/issues/1084#issuecomment-2471319900 some possible renaming. Can we try to sort that out with Mozilla before shipping?

Thank you for pointing this out, we will discuss the naming with Mozilla again. 

 

What feedback have you received so far from participants?

 

One piece of feedback we received was that the SAH retry behavior with cross-site redirects was unintuitive, which led us to create this issue, and update the behavior in chromium accordingly.

This rationale sounds like using the OT as a soft-launch, which isn't great. Do you think your partners will learn something in the requested extra 4 weeks such that you might meaningfully incorporate the feedback ahead of a launch? (I think the answer is probably no, but I'd love to hear your perspective).

 One of our main motivators for extending the origin trial was feedback from a partner that they have not had a chance to begin experimenting and would appreciate having an additional milestone to do so. An extra 4 weeks may not be much time, but having any additional feedback from this partner experimenting would be helpful ahead of the launch.

Can you also comment on substantial progress for the following (as relevant), since the original OT?

• Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)

We have published a spec since the original OT, here. A link can also be found in the platform status entry.

• WPT tests

We have written a suite of WPTs for Storage Access Headers that were recently merged into the wpt repo. 

Best,

Sam LeDoux

[Alex Russell]

Hey Sam,

Thanks for the updates.

We discussed this at this morning's API OWNERS meeting, and given that there's some renaming risk, it sounds like there's support to extend you past the 1 extra milestone you're asking for under the caveat that breaking changes (e.g., a renaming) be implemented ASAP. Is there much traffic under the current OT?

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Sam LeDoux]

Alex,

Thank you for the context, and that caveat sounds fair. 

To answer your question, we have not seen much traffic under the current OT. 

Best,

Sam LeDoux

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.