Implement and Ship: Blob URL Partitioning: Fetching/Navigation

[Janice Liu]

Contact emails

jani...@chromium.org, awi...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md

Specification

Firefox and Safari have provided support on speccing these changes and we will implement this alongside working on the Chromium Implementation. ( Opened 4 years ago#153 Blob URL store partitioning ).

Summary

As a continuation of Storage Partitioning, Chromium will implement partitioning of Blob URL access by Storage Key (top-level site, frame origin, and the has-cross-site-ancestor boolean), with the exception of navigations which will remain partitioned only by frame origin. This behavior is similar to what’s currently implemented by both Firefox and Safari, and aligns Blob URL usage with the partitioning scheme used by other storage APIs as part of Storage Partitioning. In addition, Chromium will enforce noopener on renderer-initiated navigations to Blob URLs where the corresponding site is cross-site to the top-level site performing the navigation. This aligns Chromium with similar behavior in Safari, and we will pursue spec updates to reflect both of these changes.

Blink component

Blink>Storage>FileAPI

TAG review

The general blob URL partitioning was included in the original review for third-party storage partitioning (https://github.com/w3ctag/design-reviews/issues/629). The implementation details have changed slightly but not enough to warrant a new TAG review.

TAG review status

N/A

Risks

Interoperability and Compatibility

Restricting Blob URL fetches by Storage Key means that sites using Blob URLs across top-level site boundaries or in frames with a cross-site ancestor may break. In addition, enforcing noopener for Blob URLs navigated to from contexts with different top-level sites may result in site breakage. Given that Firefox and Safari have already shipped similar features, and given that Storage Partitioning has already introduced partitioning by Storage Key to restrict most other storage and communications APIs, this change seems web compatible.

Gecko: Firefox already partitions Blob URL fetches by storage key using the same storage key implementation as Chrome. They also have expressed support for enforcing noopener on cross-site Blob URL navigation. https://github.com/w3c/FileAPI/issues/153#issuecomment-2332288047

WebKit: WebKit already partitions Blob URL fetches by top-level origin and enforces noopener on cross-top-level-origin Blob URL navigations. They are currently investigating moving to a site boundary instead of an origin boundary. https://github.com/w3c/FileAPI/issues/153#issuecomment-2332086739 

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None. In general, storage partitioning hasn’t launched on WebView.

Debuggability

We are exploring ways to notify developers when they encounter these changes to Blob URL usage, such as raising DevTools Issues.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

All except WebView. 

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/FileAPI/BlobURL?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

EnforceNoopenerOnBlobURLNavigation, BlockCrossPartitionBlobUrlFetching

Requires code in //chrome?

No.

Tracking bug

https://crbug.com/40057646

Estimated milestones

We plan to be feature complete by M132. 

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/w3c/FileAPI/issues/153

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5130361898795008?gate=6298001774215168

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

It's awesome to see this work progressing!

On Wed, Oct 30, 2024 at 4:14 AM Janice Liu <jani...@chromium.org> wrote:

Contact emails

jani...@chromium.org, awi...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md

Specification

Firefox and Safari have provided support on speccing these changes and we will implement this alongside working on the Chromium Implementation. ( Opened 4 years ago#153 Blob URL store partitioning ).

To approve an Intent to Ship like this one, we need at least a draft specification up for review. The link you've given here is just to an issue.

I see at the bottom of the issue there are links to https://github.com/whatwg/fetch/pull/1783 and https://github.com/w3c/FileAPI/pull/201 . Does that specification work correspond to what you're planning to ship? Or is there more? You mention something about noopener and a subsequent spec PR, so I'm guessing we don't have a complete specification up yet.

 

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGspLPiMu-dV2eRJyTSXMZu1S5zCnBsDaMqkFmdSaQbgFitfwg%40mail.gmail.com.

[Andrew Williams]

Hi Domenic,

You are correct - there was one more spec change we had planned related to this, which we now have a PR for at https://github.com/whatwg/html/pull/10731

Thanks!

-Andrew

[Andrew Williams]

Quick update - the spec changes for this have all landed:

 - https://github.com/whatwg/html/pull/10731

 - https://github.com/whatwg/fetch/pull/1783

 - https://github.com/w3c/FileAPI/pull/201

-Andrew

[Gregg Tavares]

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.

[Domenic Denicola]

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.

[Daniel Bratell]

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

--
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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%40mail.gmail.com.

[Andrew Williams]

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

[Andrew Williams]

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

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

[Yoav Weiss (@Shopify)]

Thanks for the compat analysis!

On Fri, Feb 7, 2025 at 6:48 PM Andrew Williams <awi...@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?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%40mail.gmail.com.

[Andrew Williams]

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

[Andrew Williams]

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)

-Andrew

[Domenic Denicola]

On Wed, Mar 5, 2025 at 2:35 AM Andrew Williams <awi...@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 Williams]

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

[Mike Taylor]

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.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a69a3de1-ebc7-4119-976b-cbe65468cb3e%40chromium.org.

[Yoav Weiss (@Shopify)]

LGTM3

Thanks for doing the necessary work to gauge the compat risk here! :)

-Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Andrew Williams]

Thanks everyone! This feature will roll out in M137

-Andrew

-Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%40mail.gmail.com.

--
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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%40mail.gmail.com.

--
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+...@chromium.org.