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 <https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_field_trials.cc;drc=57e439af5bc1022525302dc8c3e25f8c7c10e445;l=86> 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! On Friday, January 3, 2025 at 4:44:35 PM UTC Yoav Weiss wrote: 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) On Fri, Jan 3, 2025 at 4:58 PM Chris Fredrickson <cfred...@chromium.org> wrote: 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 <cfred...@chromium.org> wrote: Contact emails sled...@google.com, johann...@chromium.org, cfred...@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 <https://github.com/privacycg/storage-access-headers?tab=readme-ov-file#opt-in-signal> ? 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 <https://github.com/privacycg/storage-access-headers/pull/22>" 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 <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". 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.) 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-a ccess-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/ch romium.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/ch romium.org/d/msgid/blink-dev/1bbe492c-8722-4dbf-8342-82f59fb b0bd2n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1bbe492c-8722-4dbf-8342-82f59fbb0bd2n%40chromium.org?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/f3f4be61-67dd-4747-849f-7eabbe465017n%40chromium.org.
