Quick update on this, due to an implementation bug this change only affected users running with third-party cookies disabled. We've fixed this issue and blob URL partitioning will be enabled for all users starting in M142.
My apologies if this has caused any confusion for anyone! -Andrew On Fri, May 2, 2025 at 12:35 PM Andrew Williams <[email protected]> wrote: > Thanks everyone! This feature will roll out in M137 > > -Andrew > > On Wed, Apr 23, 2025 at 7:46 AM Yoav Weiss (@Shopify) < > [email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Mar 5, 2025 at 2:35 AM Andrew Williams <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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) < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Thanks for the compat analysis! >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Feb 7, 2025 at 6:48 PM Andrew Williams < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 [email protected]. >>>>>>>>>>> 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 [email protected]. >>>>>>>>> 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 [email protected]. >>>> >>> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUxpJEtaP%2BYnPvnix6Sd8_ufMjcvK_eg5XkHDxzu1dHzQ%40mail.gmail.com.
