Thanks everyone! This feature will roll out in M137 -Andrew
On Wed, Apr 23, 2025 at 7:46 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > 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/CAEa0%2BkXUCvFKqONMWWSR5%2BjTc%3D8iJ1GxAK_MpMA60FMXdFyx5Q%40mail.gmail.com.
