W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 28 Mar 2013 19:38:57 +0000
Message-ID: <CADnb78i9XMQgQyYS9x5fzCVjDM2HMJaHjD7Eh40NMbE2_3dLvQ@mail.gmail.com>
To: Arun Ranganathan <arun@mozilla.com>
Cc: jonas <jonas@sicking.cc>, WebApps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>, Ian Hickson <ian@hixie.ch>
On Thu, Mar 28, 2013 at 7:22 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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.

Even if it had an origin from the script, it still ought to work in a
<img> inside a cross-origin <iframe>. You would just not be able to
toDataURL() it. Are we special casing code paths by the way? E.g. if
you drop a blob URL in an <img>, what should <img>.origin return? (It
would return "null" per current specifications).

Received on Thursday, 28 March 2013 19:39:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC