Thanks all. We will proceed to launch on all Blink platforms. On Wednesday, January 8, 2025 at 10:26:01 AM UTC-5 Rick Byers wrote:
> 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/st >>>> andards-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/e7c875b9-8f29-4478-bd48-bd8c2fe32721n%40chromium.org.
