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 top-level 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 top-level 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 the relevant specs have been updated to reflect these changes. This change can be temporarily reverted by setting the PartitionedBlobURLUsage policy. The policy will be deprecated when the other storage partitioning related enterprise policies are deprecated. Note: This launched for users with third-party cookies disabled in M137 and for all users in M142
By adding Storage Key checks to BlobURLStoreImpl::ResolveAsURLLoaderFactory and BlobURLStoreImpl::ResolveForNavigation, it caused the two existing tests to fail. Both tests relate to creating Blob URLs in a Chrome extension context and then using the Blob URLs on regular pages. Previously, there are no origin checks are performed on Blob URLs passed to these functions, allowing any context to resolve a blob URL from another. Spec links: - https://html.spec.whatwg.org/#get-noopener-for-window-open - https://html.spec.whatwg.org/#get-an-element's-noopener - https://fetch.spec.whatwg.org/#scheme-fetch - https://w3c.github.io/FileAPI/#partitioningOfBlobUrls
Explainers: https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md