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

On Mar 28, 2013, at 1:55 AM, Anne van Kesteren wrote:

> On Wed, Mar 27, 2013 at 8:16 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>> 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?
> 
> Well, the question we started with was why they're restricted to same
> origin. That does not appear to be answered yet.


The restriction was due to the (perhaps misguided?) safety assumption that it was prudent to restrict file references via this scheme to the origin invoking URL.createObjectURL.  The initial proposal was scoped to origin, and dates to some antiquity in email from Hixie, which said: 
 
"URL in this scheme would have an intrinsic origin that is equal to the 
origin of the script context (the "first script" in HTML5 terms) that 
invoked the API to get the URL. This URL could then be passed around as a 
string and would be treated as a resource from the same origin as that 
script, and could thus be used with <img> and <canvas> and so on."

 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1110.html

We can relax this requirement, since it has been pointed out that it is a bit restrictive, but I'd like to ensure that Bad Things won't happen. Implementor feedback is welcome.


> 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.


Glenn adds that there may need to be some special casing anyway (http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/1038.html), with respect to revocation, but I'm open to relaxing the origin restriction if assumptions about this being prudent prove to be invalid.

-- A*