W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Re: Updates to File API

From: Mark Seaborn <mseaborn@chromium.org>
Date: Sun, 13 Jun 2010 22:46:24 -0700
Message-ID: <AANLkTikv5VlMD9eKZRJz9dLuUzL7rMN6VgNF0DU0lecB@mail.gmail.com>
To: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
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
Received on Monday, 14 June 2010 05:47:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT