On Mon, Mar 17, 2014 at 6:19 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Mon, Mar 17, 2014 at 4:59 AM, Anne van Kesteren <ann...@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/
