- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 19 Mar 2014 15:05:57 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- 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 6:19 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> 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:. I guess it depends on what you want the scope for a blob URL to be. I don't really see any problem with sharing it with an <iframe> for instance through postMessage() (the API on the other side only deals with URLs, not URLs or something else). > 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*. That makes sense. > 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. We could have an attribute on the various loading contexts, no? >> 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. It seems this would prevent certain scenarios too. Also, I think coupling tainting with the response makes more sense given service workers. You could fetch http://crossorigin.example/ and the response could be generated by a service worker and be untainted. As I understand the latest discussions, we want that to work. Blob URLs would not be much different, they would always return untainted responses, unless a redirect was involved. -- http://annevankesteren.nl/
Received on Wednesday, 19 March 2014 15:06:24 UTC