- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 17 Mar 2014 11:19:35 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <arun@mozilla.com>, Travis Leithead <travis.leithead@microsoft.com>, public-webapps <public-webapps@w3.org>
On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson <ian@hixie.ch> wrote: >> On Fri, 14 Mar 2014, Arun Ranganathan wrote: >>> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL >> >> LGTM. Assuming that UAs implement this, that makes Workers automatically >> support blob: URLs, too. > > I don't think this is the way we should go about this. I don't > understand why a blob URL would have an origin. Because URLs with origins are much simpler than what we do for data:. The main indicator of that is that we still haven't managed to get implementations to agree on how to do security boundaries for data:, whereas we're quite well aligned on security boundaries for http:. Inheriting origins the way data: does it is actually quite tricky from an security point of view. Internally in gecko we're moving towards adding a flag whenever we're doing a resource load that indiciates "Allow this load to inherit origin if it wants to". The default for that flag would be *false*. This is because we have been bit several times by having code from security context A (in our case code from chrome://) receive a URL from code from security context B. A would then load that URL. This way B can trick A into creating content that B controls, but that runs with As privileges. I'd love it if the web also had such an opt-in flag, but I don't know how possible that is to create. > Trying to couple origins with strings seems like a bad idea. Isn't that what http does? I'd actually love it if data: encoded an origin too in a way that prevented the above attack. But that doesn't seem possible. / Jonas
Received on Monday, 17 March 2014 18:20:33 UTC