Re: Updates to File API

On Wed, Jun 2, 2010 at 5:06 PM, Jian Li <jianli@chromium.org> wrote:

> I have one question regarding the scheme for Blob.url. The latest spec says
> that "The proposed URL scheme is filedata:. Mozilla already ships with
> moz-filedata:". Since the URL is now part of the Blob and it could be used
> to refer to both file data blob and binary data blob, should we consider
> making the scheme as "blobdata:" for better generalization? In addition,
> we're thinking it will probably be a good practice to encode the security
> origin in the blob URL scheme, like blobdata:
> http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make
> doing the security origin check easier when a page tries to access the blob
> url that is created in another process, under multi-process architecture.
>

Why do the "filedata:" URLs need to apply a same-origin check?  It seems
like this would unnecessarily reduce composability.  In practice, the URLs
returned by the File API would be unguessable anyway.  Why not use
unguessability of these tokens as the security mechanism?  So if a web app
wants to share the file with other, co-operating entities (e.g. in an iframe
or another tab), it can do so by sharing the URL; otherwise, it can withhold
the URL.

When would the currently-proposed same-origin checks apply?  Would I be
right in thinking that they only apply to XMLHttpRequests from Javascript,
and don't apply if the URL is linked from an <img> element?

Regards,
Mark