LGTM3 On Wed, Jan 8, 2025 at 9:29 AM Mike Taylor <miketa...@chromium.org> wrote:
> Thanks for the updates Chris. LGTM2. > On 1/7/25 10:35 PM, Yoav Weiss (@Shopify) wrote: > > > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BUjZy0vax%2B_u31q-WTHCrRo5%2B9%2BP6W6yF8LH%3DgdJJy1A%40mail.gmail.com?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/e1b34c1a-ae7a-40d1-80f7-6b0ac2c58c4a%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1b34c1a-ae7a-40d1-80f7-6b0ac2c58c4a%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/CAFUtAY8WSfPYqT1KV3anvDuqbZjZ7uaZhC51%3D5gHs0jQUxT3QQ%40mail.gmail.com.
