Bug 302558 – Allow top-level blob URL documents to fetch themselves

• Status: NEW
• Component: Page Loading

[Andrew Williams]

As part of https://github.com/w3c/FileAPI/issues/210 we are planning to update the specs related to blob URL partitioning such that a top-level blob URL document should be able to fetch itself, even when the blob URL was created in a different partition. In Chrome this was needed to prevent breakage when navigating to a blob URL with a media mime type. In that case a document is created that uses the blob URL as the src of a media element so that media controls are present when playing the media. The fetch from that media element was being blocked if the blob URL was created from a third-party context (since the media src fetch would be coming from a first-party context). Chrome's behavior in this case and what we plan to spec is the more general behavior of allowing top-level blob URL documents to fetch their URL.

We don't expect this new behavior to have much of an impact on cross-partition leakage. The blob URL contents are immutable, so it can't be used as a persistent channel for the third-party context to pass information to the first-party page (which isn't otherwise possible since the opener is severed for cross-top-level-origin navigations as is implemented in Safari IIUC). The third-party context can revoke the blob URL which would be observable to the first-party context, but that can only occur once and in general this doesn't seem too helpful since any data the third-party context wanted to pass initially at least it could have just put in the blob used for the opened document. Also, the first-party context still shouldn't be able to revoke its blob URL, so it can't use that to affect state in the third-party partition.

[Radar WebKit Bug Importer]

<rdar://problem/165239246>