Re: [w3c/FileAPI] Top-level navigations to blob URLs with media mime types result in resource load subject to partitioning (Issue #210)

recvfrom left a comment (w3c/FileAPI#210)

> What would break if we somehow let top-level navigations to blob URLs inherit the partition key from the blob URL?

Hmm, it's possible that sites could be relying on a newly opened window having a first-party storage key, although cross-top-level-site blob URL navigations aren't very common: https://chromestatus.com/metrics/feature/timeline/popularity/5200 For the Chromium implementation I wonder if there could be challenges with code assuming that an outer-most frame has a first-party storage key. @arichiv did you run into any of these issues when implementing support for [partitioned popins](https://github.com/explainers-by-googlers/partitioned-popins)?

> If this only impacts top-level documents and those documents can't have an opener

For the Chromium implementation there is one case where this mitigation would also be helpful even when an opener is set, which is when a media blob URL is created from and navigated to by an A -> B -> A iframe. We wouldn't set noopener because it's not a cross-top-level site navigation, but the resource load after the navigation would still fail because the "is-cross-site" boolean associated with the blob URL being true would make it a cross-partition fetch. Maybe this case doesn't matter too much, though.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/210#issuecomment-3000865484
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/210/3000865484@github.com>