jani...@chromium.org, awi...@chromium.org, mike...@chromium.org
https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
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 ).
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.
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.
N/A
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:
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.
We are exploring ways to notify developers when they encounter these changes to Blob URL usage, such as raising DevTools Issues.
All except WebView.
Yes
https://wpt.fyi/results/FileAPI/BlobURL?label=experimental&label=master&aligned
None
EnforceNoopenerOnBlobURLNavigation, BlockCrossPartitionBlobUrlFetching
No.
We plan to be feature complete by M132.
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
https://chromestatus.com/feature/5130361898795008?gate=6298001774215168
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 ).
--
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.