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 On Thu, Oct 31, 2024 at 10:03 AM Andrew Williams <awil...@chromium.org> wrote: > 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 > > On Wed, Oct 30, 2024 at 1:21 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> It's awesome to see this work progressing! >> >> On Wed, Oct 30, 2024 at 4:14 AM Janice Liu <janice...@chromium.org> >> wrote: >> >>> 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>). >>> >> >> 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. >> >> >>> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGspLPiMu-dV2eRJyTSXMZu1S5zCnBsDaMqkFmdSaQbgFitfwg%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVtENDGFPir_UyiGUqOk2LumXSqf6%3DsyKVE3TZ9FjL2TA%40mail.gmail.com.
