On 12/9/24 3:39 PM, 'Sam LeDoux' via blink-dev wrote:
Contact emails
sled...@google.com <mailto:sled...@google.com>, johann...@chromium.org
<mailto:johann...@chromium.org>, cfred...@chromium.org
<mailto:cfred...@chromium.org>
Explainer
https://github.com/privacycg/storage-access-headers
<https://github.com/privacycg/storage-access-headers>
Specification
https://privacycg.github.io/storage-access-headers
<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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI>
Search tags
storage access api
<https://chromestatus.com/features#tags:storage%20access%20api>,
storage access headers
<https://chromestatus.com/features#tags:storage%20access%20headers>
TAG review
Not needed, per https://github.com/w3ctag/design-reviews/issues/982
<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
<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
<https://github.com/WebKit/standards-positions/issues/412>)
Web developers: Positive
(https://github.com/privacycg/storage-access/issues/130
<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/170>*
https://github.com/privacycg/storage-access/issues/189
<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
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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
Flag name on chrome://flags
#storage-access-headers
Requires code in //chrome?
Yes
Tracking bug
https://issues.chromium.org/issues/332335089
<https://issues.chromium.org/issues/332335089>
Launch bug
https://launch.corp.google.com/launch/4309903
<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
<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
<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
<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
<https://chromestatus.com/>.
--
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+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXxhJJVGame57-BhbW5r_XX2DgRaVcmo1fDu740S7b_hbg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5d90c94e-830d-4f5f-b7fb-85955b758c9c%40chromium.org.
