On Tue, Jan 7, 2025 at 10:31 PM Chris Fredrickson <cfred...@chromium.org> wrote:
> Minor updates: > > Mike Taylor previously noted > <https://groups.google.com/a/chromium.org/g/blink-dev/c/5-SQmyp95U0/m/ibM_3pbcAAAJ> > a possible concern about naming. Ben VanderSloot (Mozilla) indicated > <https://github.com/mozilla/standards-positions/issues/1084> 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. > FWIW, my LGTM still stands if we're expanding scope to cover WebView. > On Monday, January 6, 2025 at 10:28:53 AM UTC-5 Chris Fredrickson wrote: > >> 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/sta >> ndards-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/ch >> romium.org/d/msgid/blink-dev/CABa1CXyMJzMmpQkZMwQUFGK8-f%3DE >> erhR2VQbTZephdmE22W%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/CAOmohS%2BUjZy0vax%2B_u31q-WTHCrRo5%2B9%2BP6W6yF8LH%3DgdJJy1A%40mail.gmail.com.
