Hi everyone, Quick update on this. We landed a new use counter implementation last week that better gauges actual breakage, and preliminary data from Chrome Canary shows that no instances of breakage were detected except for a few from yesterday, and those likely correspond to me running the partitioning tests on wpt.fyi locally to confirm that the use counter actually works as intended. :) For reference, there are orders of magnitude more instances of the BlobStoreAccessAcrossTopLevelSite use counter (which we used for the previous breakage analysis) being reported for the same Chrome Canary clients and during the same time period. I'll check the "real" use counter data once it's available in Chrome Status, but I suspect the percentage of page loads that would break will be significantly lower than we calculated earlier.
Also, before launching we plan to integrate with the Storage Access API so that contexts that have been granted a StorageAccessHandle will still be able to fetch Blob URLs in the same way they could before this change (so, without regard to top-level site or the "has-cross-site-ancestor" boolean) -Andrew On Mon, Feb 10, 2025 at 2:34 PM Andrew Williams <awil...@chromium.org> wrote: > Thanks Yoav, responses inline! > > > So the upper bound for potential breakage is 0.04%? > > I believe this is a reasonable estimate, although I think it assumes that > page loads are evenly distributed across UMA-enabled clients and I'm not > sure whether that's the case > > > Are there ways to tighten it? (e.g. through manual sampling or > use-counter changes) > > Regarding manual sampling, we could investigate by looking at the domains > associated with an existing use counter for this: > https://chromestatus.com/metrics/feature/timeline/popularity/4169. I > suspect that the majority of cases we would encounter would be the > cross-origin fetches that are already blocked, though, matching the high > percentage of these in our metrics. > > Making use-counter changes is certainly an option if the consensus is that > the upper bound still seems too risky (even given that Firefox and Safari > currently ship this behavior and given the proposed mitigations). > > Alternatively, we could enable this functionality in Chrome Canary, Dev, > and Beta for a few weeks and see if we get any bug reports. WDYT? > > > What does breakage look like? What do these sites see in Safari today? > > Blocking cross-partition fetches / subframe navigations is implemented in > both Firefox and Safari today, so for both of those browsers the fetch / > navigation fails and DevTools shows a warning message. The partitioning > scheme is slightly different across browsers - Safari partitions by > top-level origin and Firefox partitions by top-level site + whether there > was a cross-site frame in the frame tree, and the Chrome behavior will > match the Firefox behavior for this. > > -Andrew > > On Sun, Feb 9, 2025 at 11:21 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> Thanks for the compat analysis! >> >> >> On Fri, Feb 7, 2025 at 6:48 PM Andrew Williams <awil...@chromium.org> >> wrote: >> >>> Hey everyone, >>> >>> From looking at use counters for these cases, cross-top-level-site Blob >>> URL navigations that would have noopener set as part of this change are >>> seen on 0.0004% of page loads. Note that this is calculated from data from >>> pre-stable channels and could change when looking at Stable data, but it >>> seems unlikely to change by orders of magnitude. >>> >>> For cross-partition Blob URL fetches, these occur on 0.21% of page >>> loads, but from digging into this more and from looking at UMA data, at >>> least 83% of those cross-partition Blob URL fetches are guaranteed to >>> be blocked today because they are also cross-origin, and only ~21% of >>> UMA-enabled clients reported at least one cross-partition fetch that wasn't >>> guaranteed to be blocked. It's likely that the remaining 17% of >>> cross-partition Blob URL fetches are cross-origin as well and would already >>> be blocked, but our current use counter / metrics implementations don't >>> provide a way to gauge this. More details on this analysis can be found at: >>> https://crbug.com/387655548#comment2 >>> >> >> So the upper bound for potential breakage is 0.04%? >> If so, that's too high for comfort from my perspective. >> Are there ways to tighten it? (e.g. through manual sampling or >> use-counter changes) >> What does breakage look like? What do these sites see in Safari today? >> >> >>> Overall I think the use counter metrics + supporting UMA data support >>> moving forward with this change, as does the fact that Firefox and Safari >>> have already implemented similar functionality. If there is breakage as a >>> result of this, we do have an enterprise policy to disable it, we'll have a >>> chrome://flags entry so that users can disable it, and we'll have a Finch >>> feature flag as a killswitch for any cases of widespread, significant >>> breakage. >>> >>> Regarding formal signals from Gecko and Webkit, we opened one from Gecko >>> but haven't heard anything: >>> https://github.com/mozilla/standards-positions/issues/1151. For WebKit, >>> we reached out regarding whether we should open one and they mentioned they >>> didn't think we needed to, given that we plan to implement what the >>> functionality they have already, just using sites instead of origins. >>> >>> -Andrew >>> >>> On Thu, Dec 12, 2024 at 12:35 PM Andrew Williams <awil...@chromium.org> >>> wrote: >>> >>>> Thanks Domenic, we've landed a change to remove .tentative from the >>>> test file names: >>>> https://chromium-review.googlesource.com/c/chromium/src/+/5967596 >>>> >>>> Gregg, IIUC "top-level->iframe(blob-from-top-level)" means the >>>> top-level creates a blob URL and then creates an iframe where the src is >>>> that blob URL. Similarly, >>>> "top-level->iframe(3rd-party)->iframe(blob-from-3rd-party)" means that the >>>> 3rd-party iframe creates a blob URL and then creates an iframe where the >>>> src is that blob URL. Neither of those cases will be affected by this >>>> change. >>>> >>>> Daniel, thanks for the feedback. We will collect use counts on this and >>>> report back once the data is available (should be around mid-February). In >>>> the meantime, we will request formal signals from Gecko and WebKit as you >>>> recommended. >>>> >>>> On the topic of alignment across browsers, the I2S mentions that all >>>> navigations will remain partitioned only by frame origin, but I learned >>>> recently that Safari and Firefox partition subframe navigations (like using >>>> a blob URL as the src of an iframe) by storage key / the top-level as well >>>> (and this is what was originally proposed in >>>> https://github.com/w3c/FileAPI/issues/153). It's only top-level >>>> navigations that remain partitioned only by frame origin. Our >>>> implementation will follow suit. I'll update the Chrome Status description >>>> accordingly. >>>> >>>> -Andrew >>>> >>>> On Wed, Dec 11, 2024 at 11:38 AM Daniel Bratell <bratel...@gmail.com> >>>> wrote: >>>> >>>>> After discussing this on the API OWNER meeting I have a few questions >>>>> and suggestions. >>>>> >>>>> My main concern is that we don't have full understanding of the >>>>> compatibility risk. We believe this is rare, but do we have any hard data >>>>> to confirm that? If not, would it be possible to add a targetted use >>>>> counter that counts the cases where a page tries to use a broken blob? >>>>> >>>>> I think you should also request formal signals from Gecko and WebKit >>>>> since this is not exactly what they have done. It seems from what you >>>>> write >>>>> that we're getting something very slightly different (which also means >>>>> that >>>>> what seems to work for them might still break in Chromium). >>>>> >>>>> /Daniel >>>>> On 2024-12-10 03:29, Domenic Denicola wrote: >>>>> >>>>> LGTM1, nice work on all the spec changes here! >>>>> >>>>> Please send a web platform tests PR to remove the .tentative.html from >>>>> the test filenames. >>>>> >>>>> On Tue, Dec 10, 2024 at 10:49 AM Gregg Tavares <g...@chromium.org> >>>>> wrote: >>>>> >>>>>> Sorry if I'm not up on all of the latest. I have several sites that >>>>>> use blobs in iframes to implement user code execution (think >>>>>> JSFiddle/Codepen). Do I need to be worried? >>>>>> >>>>>> Some use top-level->iframe(blob-from-top-level). Others use >>>>>> top-level->iframe(3rd-party)->iframe(blob-from-3rd-party) >>>>>> >>>>>> They all currently work across browsers so I'm guessing I don't need >>>>>> to worry if Firefox and Safari already implement this. >>>>>> >>>>>> -- >>>>> 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/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%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/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%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/CAEa0%2BkVLiLp%2BAryzrejFG8ZRNNA3RtF6huALAFhcE23DVOyzJA%40mail.gmail.com.
