On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Fri, Mar 14, 2014 at 10:40 PM, Ian Hickson <i...@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
