v137 · 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

    Blob URLs are now keyed to the top-level site that created them. Cross-site fetches/navigations to a foreign blob URL fail, closing a tracking sidechannel.

  2. Cross-site Blob Navigation

    The carve-out: top-level navigations stay keyed by frame origin. Subframe navigations to a foreign blob URL are blocked — same-origin iframe loads, sandboxed (cross-site) iframe doesn't.

  3. Partition Inspector

    Mint blob: URLs and probe them from three lanes — same-origin, same-site iframe, cross-site simulation. Surfaces the (top-site, origin) key Chrome 137 enforces, plus a full hit/miss matrix.

  4. Blob Lifecycle Tracer

    Create blob URLs, attempt same-partition and cross-partition (simulated) fetches, and revoke them — every event traced on a timeline with timestamps. Shows the partition key (top-level site + frame origin) that owns each URL and why cross-partition access is blocked.

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