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.
