Contact emails janice...@chromium.org, awil...@chromium.org, miketa...@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. ( [image: icon]Opened 4 years ago#153 Blob URL store partitioning <https://github.com/w3c/FileAPI/issues/153>). 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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileAPI> 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://github.com/w3c/FileAPI/issues/153#issuecomment-2332086739> Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5130361898795008?gate=6298001774215168 This intent message was generated by Chrome Platform Status <https://chromestatus.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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGspLPiMu-dV2eRJyTSXMZu1S5zCnBsDaMqkFmdSaQbgFitfwg%40mail.gmail.com.
