302558 2025-11-14 16:04:46 -0800 Allow top-level blob URL documents to fetch themselves 2025-11-21 16:05:11 -0800 1 1 1 Unclassified WebKit Page Loading WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Enhancement --- 1 awillia webkit-unassigned annevk beidson webkit-bug-importer oldest_to_newest 2158938 0 awillia 2025-11-14 16:04:46 -0800 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. 2160750 1 webkit-bug-importer 2025-11-21 16:05:11 -0800 <rdar://problem/165239246>