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/CAOMQ%2Bw-btYULA8RehG6DxE85akU-SMYak3h2OfRKWFABnjx2qA%40mail.gmail.com.
