On Wed, Mar 5, 2025 at 2:35 AM Andrew Williams <awil...@chromium.org> wrote:
> 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) > Hmm, that extra complexity seems a bit unfortunate, but oh well; I'm happy to trust your judgement that it's the best path. Please keep us updated on the spec and test work for that extra integration! > > -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/CAM0wra_QQZC6%2BHtOe8zGANaz7tx4f_p9DumGTL2dkd8K%3DPAaug%40mail.gmail.com.
