v132 · miscellaneous

Blob URL Partitioning: Fetching/Navigation

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

concepts

  1. Blob Partitioning

    Closes a tracking sidechannel for cross-site blob: URL access.

  2. iframe navigation

    The other half of the spec: subresource fetch vs window.open vs iframe.src, with a real minted blob.

  3. storage key explorer

    Pick a frame topology (same-site, cross-site, A>B>A nested, noopener popup) and see the (top, origin, has-cross-site-ancestor) triplet for every frame. Who can fetch the minted blob? Match the triplet.

  4. top-level nav carve-out

    Subresource fetch keys the blob by full storage key. Top-level navigation keys by origin only. Side-by-side table of which APIs survive partitioning and which break.

why it shipped

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.

references