Re: Updates to File API

On Mon, Jun 14, 2010 at 12:40 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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

That's true for "http:" URLs, but AFAIK it's not true for "https:" URLs.
The browser is not supposed to disclose HTTPS URLs via the Referer header,
and I know of at least one app (Tahoe-LAFS) that relies on that.  Since the
File API is creating the new "filedata:" URL scheme, it can specify that it
has the same property.


> 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 is adding a new mechanism, isn't it, since <img> was previously
considered to be normal linking and did not have a same-origin check.

What would happen if a page has an <a href="filedata:..."> link?

Regards,
Mark