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? 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- >> 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 >> <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/a1664f67-0c3e-42c1-9357-def2bc02fdben%40chromium.org.
