Re: File API: why is there same-origin restriction on blob URLs?

On Wed, Mar 27, 2013 at 1:35 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Same question applies if you create an <img src="blob:..."> and then
> drawImage it into a canvas, does the canvas get tainted? Again, I
> think different browsers do different things for data: URLs here.
>

You'd need to say <img crossorigin> to not taint, since it's still
cross-origin, but other than that there's no reason to taint.  The idea of
image tainting is preventing access when the caller wouldn't have direct
access to pixels, which isn't the case here.


On Wed, Mar 27, 2013 at 3:16 PM, Arun Ranganathan <arun@mozilla.com> wrote:

> > I think the original concern was that implementations might not be
> > able to reliably generate unguessable URLs. Potentially that's
> > something that we could require though.
>
> We already require this -- "opaque strings" should be globally unique.
>

Globally unique doesn't imply unguessable, of course, but it's still
trivial to do (a 256-bit securely-random number is all you need).


On Thu, Mar 28, 2013 at 12:55 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> As for a use case, you could have a widget that does something given a
> URL. E.g. put Googly eyes on the image resource. This widget could be
> embedded anywhere and all you'd need to do is postMessage() it a URL.
> Requiring a special code path for URLs generated from a Blob seems
> annoying for both the consumer of the widget and the producer of it.
>

At least for code that isn't a quick hack (where you can't ignore the
problem), you're going to need a special code path anyway to revoke the
URL.  The widget needs to communicate when it's done with the URL, and the
user needs to listen for that and revoke the URL.  If you pass in a blob,
you don't have to care about this at the widget-interface level and the
widget itself can (hopefully, some day) just use autoRevoke, and things
don't get complex if the widget wants to reuse the resource later.

This all seems more complex than just taking a Blob in the first place.
The widget (or worker, or whatever) can just say

var url = (event.data.src instanceof Blob)?
URL.createObjectURL(event.data.src, {autoRevoke: true}): event.data.src;

and use that URL.  The sender can then send either a regular URL or a
Blob.  This way, there's no extra careful communication needed to
coordinate freeing a blob URL.  It also works better in a shared worker,
where the worker might outlive the sender.

I'm not opposed to relaxing the same-origin restriction, since it seems
like a general simplification and doesn't seem to have any purpose, but I
can't really think of any case where I'd ever use it.

-- 
Glenn Maynard