2000324 - Allow top-level blob URL documents to fetch themselves

Status: UNCONFIRMED

(Core :: DOM: File, enhancement)

Description

[Andrew Williams]

Steps to reproduce:

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).

I tested whether the media breakage scenario affected Firefox and it didn't seem too, but what we plan to spec is just allowing any blob URL top-level document to fetch itself, and when I tested that in Firefox the fetch was blocked due to partitioning (at least when the fetch was initiated via DevTools). We will be adding a new WPT for the general fetch case (FileAPI/BlobURL/cross-partition-self-fetch.https.tentative.html) so be on the lookout if test failures start being reported associated with that.

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 if the opener is severed, although that's not implemented yet in Firefox - see bug 1928383). 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.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.