Re: Updates to File API

On Sun, Jun 13, 2010 at 10:46 PM, Mark Seaborn <mseaborn@chromium.org> wrote:
> 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?

URLs weren't always designed to be security sensitive. One common way
they leak is through the "referer" (sic) header. So if the File whose
.url you were loading was an HTML file, and you loaded it using an
<iframe>, you could very easily leak the URL to untrusted parties.

At the very least the same-origin check applies such that if a
cross-origin file uri is used on <img>, this would be considered a
cross-origin load if that <img> was later pasted into a <canvas>.
Similarly, if a cross-origin <video> is loaded, I think some events
are with-held, though I'm less sure about that.

However, in firefox we've taken a more strict approach. We disallow
cross-origin <img> loads for filedata URIs. I.e. if site A receives a
File with a url. Then even if site B manages to get hold of that url,
it can't use <img> to load it.

This definitely needs to be specified in spec though.

/ Jonas

Received on Monday, 14 June 2010 07:41:51 UTC