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.
