Contact emails sled...@google.com, johann...@chromium.org, cfred...@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 <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 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <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/1bbe492c-8722-4dbf-8342-82f59fbb0bd2n%40chromium.org.
