W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

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

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 27 Mar 2013 16:16:31 -0400
Cc: WebApps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
Message-Id: <699CF22D-0BD6-4CD6-9780-DFCF4B904433@mozilla.com>
To: jonas <jonas@sicking.cc>, Anne Van Kesteren <annevk@annevk.nl>
On Mar 26, 2013, at 8:30 PM, Jonas Sicking wrote:

> On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> Hi,
>> Is there any particular reason why we restrict blob URLs to the same
>> origin as the script that created them? In effect they are pretty much
>> like capability URLs (containing an unguessable token). So if someone
>> decides to share one, that should be okay I think. This would be
>> useful in the context of sandboxed code (<iframe sandbox>) and
>> presumably elsewhere too.
> 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.  

> However we'd still need to nail down what the new behavior should be.
> Should it behave like data: URLs? The main advantage of those is that
> implementations still don't agree on how those should behave.

They're very different than data URLs.  What's a good use case for making them cross-origin, that isn't addressed by use of postMessage?

-- A*
Received on Wednesday, 27 March 2013 20:17:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC