W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Blob URL Origin

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 20 May 2014 12:24:25 -0700
Message-ID: <CA+c2ei8BNfPjsn9UuwD-4MwvXMRFuT9xFnxM799b57tbJu_rpA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Adam Barth <w3c@adambarth.com>, Joel Weinberger <jww@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
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
Received on Tuesday, 20 May 2014 19:25:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC