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/b4ee825e-bf89-41ca-a211-d6b459e5e2e9n%40chromium.org.
