- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 3 Aug 2013 02:35:42 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: whatwg@lists.whatwg.org
On Fri, 2 Aug 2013, Boris Zbarsky wrote: > On 8/2/13 6:55 PM, Ian Hickson wrote: > > How does it solve it? (What _is_ the "mail.google.com vs > > calendar.google.com case"?) > > The case is when mail.google.com tries to attack calendar.google.com, > and they can't be in different processes as mitigation because you never > know when they'll both set domain to "google.com"... Ah, ok. It's clearer to describe that as the "victim.example.com vs hostile.example.com" case, since the fact that calendar.google.com redirects to www.google.com and mail.google.com doesn't is mostly just an accident of history at this point. Yes, the model I described in es-discuss doesn't attempt to mitigate that case. It groups similar-origin browsing contexts that share an event loop. It has the advantage (over models that do mitigate that specific case) that it happens to be compatible with the legacy security model (the one implemented, until recently, by all browsers); it has the disadvantage that near siblings, origin-wise, only have one level of protection against each other, not the full defense-in-depth. Honestly, though, at the point where you're able to trick a similar-origin site into changing document.domain so you can attack it, it's not clear to me that the extra level of defense is worth much. You can already, e.g., do XHR to the other origin, at that point, or read or write to its localStorage, or read its cookies, or send postMessage() with their origin credentials, or speak to their workers. I dunno, it seems like the fact that you can't get to objects in other iframes of that origin at that point is mostly moot. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 3 August 2013 02:36:05 UTC