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

Re: Blob URL Origin

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 16 May 2014 16:11:57 +0200
Message-ID: <CADnb78jWJNNiKUxTrXtsyLNkJxucGcPH_TW=QMu0MSFsP+UcYA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>
On Thu, May 15, 2014 at 8:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> I did. It's not very attractive to use the model of something that so
> far we haven't been able to make work consistently across UAs, and
> which isn't looking like we will be able to get consistently working
> across UAs for a long time to come. Not only does that mean that we'll
> keep blob: in the same limbo, it also means that we don't know if
> after that limbo we'll get something that is particularly great.

You did say this, but this does not explain the actual problem. What
exactly is wrong with the data URL model that we have today and how do
we plan on fixing it?

> Another argument that I'm not sure if I've raised yet is that so far I
> don't see any good solutions for data:. The rfc seems to currently
> call for all data: URLs to be given a unique origin. That means that
> you can't do new Worker("data:..."), which seems bad. And for blob:
> it'd be particularly sad if we couldn't do new Image("blob:") and then
> using that image in WebGL or in canvas2d without the canvas getting
> tainted.

The origin you get out of a URL is not the origin assigned to a
resource, necessarily. At the moment Fetch (and HTML before it)
defines that fetching a data URL is the same as fetching a same-origin
resource and gives you something back that is not tainted. This is the
same for blob URLs, they won't get tainted either. Or about:blank.

> The best solution that I've been able to think of so far was what I
> proposed in another thread of requiring explicit opt-in. However that
> requires messy and unusual syntax everywhere where URLs are used and
> where we might want to treat data: as same-origin. So also not
> something I'd be sad not to have to do for blob:.

I think the sad thing is that if you couple origins with blob URLs you
can no longer hand a blob URL to an <iframe>-based widget and let them
play with it. E.g. draw, modify, and hand a URL back for the modified
image. But I guess this is a scenario you explicitly want to outlaw,
even though you could do the equivalent by passing a Blob object
directly and that would always work.

Received on Friday, 16 May 2014 14:12:35 UTC

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