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/CAOmohSJNxUps-73RnNnO3Of061GLDc1Pio0hB5wHsuTu%2BSqAAQ%40mail.gmail.com.
