Re: [w3c/FileAPI] Proposal: Add a crossOrigin option to Blob (Issue #192)

> I'm not sure how using "site" is better? It has a defined meaning in HTML and it's not related to opaque origins.

Note that this proposal creates new "site", which is not a opaque origin. And because it is designed to always be cross-site when rendered as a document, the [site](https://html.spec.whatwg.org/multipage/browsers.html#sites) definition in HTML clearly matches this API.

> > What does navigation to Blob objects look like?
> 
> Imagine the navigation API gaining support for Blob objects.

I think that's not an issue. Navigation API only supports same-origin endpoints for most of API (like navigate event). There few probably few places where cross-origin Blob "could be" supported (e.g. `navigation.navigate`), and we can decide to either block it, or convert the given blob into URL.

From this API point of view, we just need 2 things.

1. When a unique Blob URL is rendered as a document, it is treated cross-site to the creator.
2. When a unique Blob URL is used as a resource, it is origin tainted.

If we can acheve this with Blob objects (which I believe we can), then it's probably non-issue for navigating/downloading Blob objects.

> Exfiltration through top-level navigation is "fine" as that's "visible".

Then we agree that it's not a perfect protection then 🙂 And an attacker can call `history.back()` to hide it, so I doubt how "visible" it would be. 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/192#issuecomment-1428555211

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/192/1428555211@github.com>