sle...@google.com, joha...@chromium.org, cfre...@chromium.org
https://github.com/privacycg/storage-access-headers
https://privacycg.github.io/storage-access-headers
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.
storage access api, storage access headers
https://github.com/w3ctag/design-reviews/issues/982.
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.
StorageAccessHeader
https://github.com/cfredric/storage-access-headers
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:
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
This is debuggable via DevTools and via chrome://net-export.
No
The Storage Access API itself is not yet supported on Android WebView.
Yes
https://developers.google.com/privacy-sandbox/blog/storage-access-api-headers-logic
storage-access-headers
StorageAccessHeaders
False
https://b.corp.google.com/issues/329698698
https://launch.corp.google.com/launch/4309903
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.
https://storage-access-headers-demo.glitch.me
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
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.
https://chromestatus.com/feature/6146353156849664?gate=6138146145435648
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.
Contact emailssle...@google.com, joha...@chromium.org, cfre...@chromium.org
Explainer
Specificationhttps://privacycg.github.io/storage-access-headers
SummaryStorage 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
Search tagsstorage access api, storage access headers
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/982.
TAG review statusSatisfied 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 NameStorageAccessHeader
Origin Trial documentation linkhttps://github.com/cfredric/storage-access-headers
Risks
Interoperability and CompatibilityThis 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".
--
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.
On Thu, Jan 2, 2025 at 7:36 PM Chris Fredrickson <cfre...@chromium.org> wrote:Contact emailssle...@google.com, joha...@chromium.org, cfre...@chromium.org
ExplainerDo I understand correctly and the extra RTT imposed by the "retry" is required for security reasons?
Specificationhttps://privacycg.github.io/storage-access-headers
SummaryStorage 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
Search tagsstorage access api, storage access headers
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/982.
TAG review statusSatisfied 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 NameStorageAccessHeader
Origin Trial documentation linkhttps://github.com/cfredric/storage-access-headers
Risks
Interoperability and CompatibilityThis 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?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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?
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?
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.
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.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1b34c1a-ae7a-40d1-80f7-6b0ac2c58c4a%40chromium.org.
--
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.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1b34c1a-ae7a-40d1-80f7-6b0ac2c58c4a%40chromium.org.