On Sat, 3 Aug 2013, David Bruant wrote: > Boris Zbarsky wrote: > > > > So his proposed implementation gives good defence in depth for things > > that are completely different origins and always will be, but does > > nothing for protecting mail.google.com from calendar.google.com, say, > > compared to the current situation.. > > And apparently @sandbox doesn't help here if there is allow-same-origin. So > here is an idea: make the document.domain setter throw inside an > iframe@sandbox, *regardless* of allow-same-origin. That solves the > mail.google.com VS calendar.google.com case.
How does it solve it? (What _is_ the "mail.google.com vs calendar.google.com case"?) > It doesn't solve the case of when the parent shortens its document.domain to > match the allow-same-origin sandboxed iframe, but I feel it's a rare case to > load an x.y iframe from an w.x.y page. I think this is based on a misunderstanding of document.domain. For document.domain to work, _both_ sides have to do it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'