LGTM3 Thanks for doing the necessary work to gauge the compat risk here! :)
On Monday, April 21, 2025 at 4:56:27 PM UTC+2 Chris Harrelson wrote: > LGTM2 > > On Sat, Apr 19, 2025 at 9:43 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> I am recused from giving LGTMs on this one, but the new use counters and >> other mitigations (enterprise policy, finch killswitch, chrome://flags >> entry) suggest to me that the risk is low, and if we get it wrong, we can >> undo the change. >> On 4/18/25 4:39 PM, Andrew Williams wrote: >> >> Hi blink-dev, >> >> > 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! >> >> The Storage Access API non-cookie storage spec [1] and corresponding >> Chromium implementation had already planned to allow access to first-party >> Blob URLs from third-party contexts after a storage handle had been >> granted, and I think it makes sense w.r.t. consistency (effectively >> providing workarounds for all of the APIs changed as part of the Storage >> Partitioning effort). Regarding spec work for this, I opened a spec bug [2] >> to discuss this further and it seems that what's needed is the core work >> still required to make the Storage Access API for non-cookie storage spec >> actually bypass storage partitioning for the other storage APIs as well >> (which is still blocked on the Storage Key having more than just an origin >> [3]). I plan to follow-up on that spec work, but propose we don't block >> shipping this Blob URL partitioning effort on this broader work. Regarding >> testing, we've added WPTs for the integration, including for cases such as >> when a Blob URL fetch occurs from a dedicated worker created after storage >> access has been granted to the document context that created it. >> >> Regarding potential for breakage, the new use counter we added that >> better reflects the potential for breakage is in Chrome Beta, Dev, and >> Canary and the % of page loads affected is very low (currently 0.000001%) >> [4]. For Chrome we have an enterprise policy that can be used if there is >> breakage, we have a killswitch we can use to disable the feature broadly if >> major breakage is encountered, and we've also added a chrome://flags >> entry that can be used to disable the feature by users directly. I think >> it's safe to conclude that this change is safe but in the worst case we can >> mitigate breakage effectively if we need to. >> >> Assuming Domenic's LGTM still stands, it looks like we still need two >> more. Would any other Blink API owners support moving forward with this? >> >> Thank you! >> >> -Andrew >> >> [1] https://privacycg.github.io/saa-non-cookie-storage/#document-changes >> [2] https://github.com/privacycg/saa-non-cookie-storage/issues/34 >> [3] https://github.com/whatwg/storage/pull/144 >> [4] https://chromestatus.com/metrics/feature/timeline/popularity/5330 >> >> On Tue, Mar 4, 2025 at 8:46 PM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> >>> >>> 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/a69a3de1-ebc7-4119-976b-cbe65468cb3e%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a69a3de1-ebc7-4119-976b-cbe65468cb3e%40chromium.org?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/4527c567-38e4-4e61-bef1-f640274855c2n%40chromium.org.
