Implement and Ship: Blob URL Partitioning: Fetching/Navigation

218 views
Skip to first unread message

Janice Liu

unread,
Oct 29, 2024, 3:14:22 PMOct 29
to blink-dev, Andrew Williams, Mike Taylor

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. ( iconOpened 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

unread,
Oct 30, 2024, 1:22:00 AMOct 30
to Janice Liu, blink-dev, Andrew Williams, Mike Taylor
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. ( iconOpened 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

unread,
Oct 31, 2024, 10:04:36 AMOct 31
to Domenic Denicola, Janice Liu, blink-dev, Mike Taylor
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
Reply all
Reply to author
Forward
0 new messages