LGTM3 On Wed, Aug 6, 2025 at 8:06 AM Yoav Weiss (@Shopify) <yoavwe...@chromium.org> wrote:
> LGTM2 > > On Wednesday, August 6, 2025 at 5:06:29 PM UTC+2 Mike Taylor wrote: > >> LGTM1 (sorry for the delay) >> On 5/19/25 2:00 p.m., Chris Fredrickson wrote: >> >> Following up on this: >> >> Now that the new UseCounter >> <https://chromestatus.com/metrics/feature/timeline/popularity/5459> has >> made it out to Stable, the portion of pageloads that would be affected by >> this change is 0.000069%. >> >> The UseCounter >> <https://chromestatus.com/metrics/feature/timeline/popularity/3311> for >> `document.requestStorageAccess()` is currently at 0.075%. Same-site >> cross-origin SAA usage is a strict subset of this, which means 0.00092% of >> SAA usage would be affected in Chrome. >> >> Please LMK if those numbers look acceptable to you. >> On Friday, March 28, 2025 at 4:27:37 PM UTC-4 Chris Fredrickson wrote: >> >>> Thanks Alex (and Vlad), those concerns make sense. >>> >>> Re: next steps, I've improved <https://crrev.com/c/6373548> the >>> existing UMA, but more importantly, I added >>> <https://crrev.com/c/6397807> a UKM-based UseCounter that will >>> precisely measure the % of pageloads that would be affected by this change. >>> I will follow up once I have data from Stable (M136) from that, and know >>> which sites are most likely to experience breakage. >>> >>> I'm reluctant to do a finch'd rollout for this, since this change >>> affects web platform semantics; a finch rollout for this would make it very >>> hard for web developers to predict the user agent's behavior, IMO. So the >>> other options (improving metrics, including UKM to identify affected sites) >>> seem like the better option to me. >>> >>> Talk to you in a month or two (I hope), >>> Chris >>> >>> On Wednesday, March 26, 2025 at 11:27:05 AM UTC-4 Alex Russell wrote: >>> >>>> Thanks, Chris. >>>> >>>> We discussed briefly at today's API OWNERs, and Vlad and I are in the >>>> same boat (I think?), which is that we're glad that you were able to >>>> confirm our understanding of the situation, but the risk continues to look >>>> high in that light. >>>> >>>> There's generally a menu of options in these cases, ranging from adding >>>> more detailed metrics and waiting for analysis to roll in (which can take >>>> months), to working with developers and partners to characterise the >>>> potential for breakage, to spot checks of known-affected sites (or adding >>>> UKM to detect them), to finch'd rollout. We'd like to understand if any of >>>> these make sense for this case to reduce the risk profile here. >>>> >>>> WDYT? >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Friday, March 21, 2025 at 12:39:14 PM UTC-7 Chris Fredrickson wrote: >>>> >>>>> Mozilla standards position request: >>>>> https://github.com/mozilla/standards-positions/issues/1200 >>>>> WebKit standards position request: >>>>> https://github.com/WebKit/standards-positions/issues/476 >>>>> >>>>> On Wednesday, March 19, 2025 at 4:40:17 PM UTC-4 Chris Fredrickson >>>>> wrote: >>>>> >>>>>> Sorry for the delay, for some reason Alex's message didn't show up in >>>>>> my inbox! >>>>>> >>>>>> *Alex*: >>>>>> Up to 100% of Storage Access API (SAA) usage could be affected, if we >>>>>> assume that *every *usage of SAA later involves a cross-origin, >>>>>> same-site network request that is required to be credentialed. >>>>>> >>>>>> However, it's also possible that *none* of the network traffic in >>>>>> the cross-origin, same-site bucket actually needs to be credentialed, so >>>>>> the breakage is *somewhere* between 0% and 100% of SAA usage... >>>>>> which is not very helpful. It's impossible for the browser to measure >>>>>> more >>>>>> specifically (other than checking the credentials mode), since the >>>>>> browser >>>>>> can't tell that cookies are required to be present on a given request. >>>>>> >>>>>> While writing this I realized that the browser *does *know the >>>>>> request's credentials mode, so the breakage estimate can at least exclude >>>>>> the portion of requests that opt out of cookies entirely. I'll update the >>>>>> metric accordingly; I expect this will reduce the 9% figure a bit. >>>>>> >>>>>> *Vlad*: >>>>>> Not exactly, the upper bound of breakage is 0.08% of pageloads (under >>>>>> the same assumptions as above). In practice I expect the real figure to >>>>>> be >>>>>> much lower, as not every such iframe will issue a cross-origin, same-site >>>>>> request; and of those that do, probably not all of those requests >>>>>> actually >>>>>> need to be credentialed. >>>>>> >>>>>> The 9% figure is the proportion of network traffic that could be >>>>>> affected from iframes that have called SAA. E.g., if we assume that every >>>>>> iframe that calls SAA then sends 11 network requests (and one of them is >>>>>> cross-origin same-site), then about 9% of that traffic falls into the >>>>>> bucket that's changing in this launch. As that example illustrates, it's >>>>>> possible that *all* of the 0.08% of pageloads that use SAA are >>>>>> affected by this launch; it's also possible that only a small fraction >>>>>> are >>>>>> affected. >>>>>> >>>>>> Re: nature of the breakage, the cross-origin same-site subset of >>>>>> network requests would no longer carry cross-site cookies from an iframe >>>>>> that has called `document.requestStorageAccess()`, by default. The real >>>>>> consequences of that could be anything from a completely broken >>>>>> experience, >>>>>> to unnoticeable; but since sites use cookies in such a variety of ways, >>>>>> it's kind of impossible to predict where on that spectrum this will fall. >>>>>> >>>>>> Re: vendor signals, yes, I'll do that. >>>>>> >>>>>> On Wednesday, March 19, 2025 at 11:23:28 AM UTC-4 Vladimir Levin >>>>>> wrote: >>>>>> >>>>>>> Is it a correct reading that that it's roughly 9% of 0.08% of >>>>>>> pageloads that will be affected? That still seems large. Can you speak >>>>>>> to >>>>>>> the nature of the breakage? Specifically, do the sites that currently >>>>>>> use >>>>>>> it become unusable or is it a milder change from that? >>>>>>> >>>>>>> On the process side, do you mind filing vendor signals (Gecko and >>>>>>> Webkit) for this? >>>>>>> >>>>>>> Thanks, >>>>>>> Vlad >>>>>>> >>>>>>> On Monday, March 17, 2025 at 2:28:23 PM UTC-4 Alex Russell wrote: >>>>>>> >>>>>>>> Hey Chris, >>>>>>>> >>>>>>>> Do you have a sense for what fraction of Storage Access API use >>>>>>>> (yes, I know it's low) will be impacted by this change? Is there a way >>>>>>>> to >>>>>>>> tell? >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> On Wednesday, March 12, 2025 at 9:04:37 AM UTC-7 Chris Fredrickson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> cfred...@chromium.org >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://github.com/privacycg/storage-access/pull/213 >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> Adjusts the Storage Access API semantics to strictly follow the >>>>>>>>> Same Origin Policy, w.r.t. security. I.e., using >>>>>>>>> document.requestStorageAccess() in a frame only attaches cookies to >>>>>>>>> requests to the iframe's origin (not site) by default. >>>>>>>>> >>>>>>>>> Note: the CookiesAllowedForUrls enterprise policy and/or Storage >>>>>>>>> Access Headers may still be used to unblock cross-site cookies. >>>>>>>>> >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Blink>StorageAccessAPI >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorageAccessAPI%22> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> Not requested since this is a small change to the existing Storage >>>>>>>>> Access proposal that improves security and has no impact on privacy >>>>>>>>> or user >>>>>>>>> experience. >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> N/A >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> The Storage Access API specification is imprecise about its >>>>>>>>> integration with Fetch, and does not define whether same-site, >>>>>>>>> cross-origin >>>>>>>>> requests ought to be credentialed after an iframe has used the Storage >>>>>>>>> Access API. >>>>>>>>> >>>>>>>>> Chrome and Firefox both currently include cookies on these >>>>>>>>> same-site cross-origin requests, so there is some risk to making their >>>>>>>>> behaviors diverge. We have discussed this with other browser vendors >>>>>>>>> and >>>>>>>>> they expressed that they were not concerned with Chrome making this >>>>>>>>> change. >>>>>>>>> >>>>>>>>> However, the Storage Access API currently has very little usage in >>>>>>>>> Chrome (0.08% of pageloads). The cross-origin, same-site subset of >>>>>>>>> usage is >>>>>>>>> an even smaller portion (9% of network requests from affected >>>>>>>>> pageloads). >>>>>>>>> So, the impact of breakage is small regardless. >>>>>>>>> >>>>>>>>> Sites that are broken by this can fix themselves using the >>>>>>>>> recently-shipped Storage Access Headers >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/gERgwZfN_-E/m/QIJbT1zUCgAJ> >>>>>>>>> feature. >>>>>>>>> >>>>>>>>> >>>>>>>>> Gecko: No signal >>>>>>>>> >>>>>>>>> WebKit: No signal >>>>>>>>> >>>>>>>>> Web developers: Positive ( >>>>>>>>> https://github.com/privacycg/storage-access/issues/210#issuecomment-2527687508 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> Cookies (and the reasons why they are included/excluded) are >>>>>>>>> debuggable via the Network panel in Chrome DevTools. >>>>>>>>> >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> >>>>>>>>> >>>>>>>>> https://wpt.fyi/results/storage-access-api/requestStorageAccess-cross-origin-fetch.sub.https.tentative.window.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Flag name on about://flags >>>>>>>>> >>>>>>>>> storage-access-api-follows-same-origin-policy >>>>>>>>> >>>>>>>>> Finch feature name >>>>>>>>> >>>>>>>>> StorageAccessApiFollowsSameOriginPolicy >>>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> False >>>>>>>>> >>>>>>>>> Tracking bug >>>>>>>>> >>>>>>>>> https://crbug.com/379030052 >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> 136 >>>>>>>>> >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> None anticipated. >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5169937372676096?gate=5134161335287808 >>>>>>>>> >>>>>>>>> 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/8344a1ee-3466-47e0-a447-b17924af0c7an%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8344a1ee-3466-47e0-a447-b17924af0c7an%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/cfece196-9d6c-43db-8d83-973cc33eedefn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cfece196-9d6c-43db-8d83-973cc33eedefn%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/CAOMQ%2Bw8hgUug3iAH1A%2BTyr6AxJr4Eo8KydHm1_Anrh4O6%3DTzLw%40mail.gmail.com.
