- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 28 Mar 2013 19:38:57 +0000
- 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). -- http://annevankesteren.nl/
Received on Thursday, 28 March 2013 19:39:25 UTC