Re: Blob URL Origin

I think it should be easy to add CORS to the limited subset of HTTP headers already specified when dereferencing Blob URLs. The idea was always that we’d add headers that seemed useful incrementally. I think we assumed CORS would be useful.

On May 20, 2014, at 3:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, May 20, 2014 at 1:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Mon, May 19, 2014 at 9:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Mon, May 19, 2014 at 2:00 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>>> Again fair, but do we consider that something we want to fix or do we
>>>> want to enshrine this?
>>> 
>>> Given that there's no way to set CORS headers on these (yet), I think
>>> there's very limited value in allowing them to be read cross-origin.
>> 
>> I meant fixing not generating unique enough IDs. The way I see it such
>> a URL is effectively a capability URL (given a unique enough ID) and
>> at that point it should not be that different from handing out a Blob
>> object across origins.
>> 
>> The perceived danger is apparently people sticking these URLs in
>> things sans sandboxing and shooting themselves in the foot. So it
>> seems reasonable to treat such URLs as cross-origin for <iframe> and
>> workers (CSP's child-src), but for <canvas> that does not seem that
>> clear.
> 
> I think you are confusing issues. Or at least talking about two
> separate issues at once in a way that I'm not sure what you are
> talking about. The issue of "is there an XSS issue with treated blob:
> like we treat data:" is a separate issue from "should we treat
> cross-origin blob: like cross-origin http:, i.e. should we allow
> pointing an <img> to a cross-origin blob:".
> 
> I had hoped that we had settled the former and decided that blob:
> should not be treated as data:. And I think we've also decided that we
> should use the explicit origin syntax, i.e. something like
> "blob:http://example.com/uuid"
> 
> Now that leaves the question of if blob: URLs should be loadable
> cross-origin. I.e. if a page from http://a.com should be able to use
> <img src="blob:http://b.com/uuid">.
> 
> Yes, we could demand that that implementations generate unguessable
> UUIDs. And then define that a page from http://a.com can use <img
> src="blob:http://b.com/uuid">, but if it then used that element to
> drawImage into a <canvas>, that the canvas would get tainted.
> 
> But there appears to be very little utility of doing this. Rather than
> spending time implementing an unguessable UUID generator, and then
> worrying that someone would still accidentally pass a blob: URL where
> they shouldn't, I'd rather implement a way to generate a blob: URL
> which is explicitly usable cross-origin. But in <img> and in XHR. I.e.
> a Blob URL which responds with CORS headers.
> 
> / Jonas