W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 2 Aug 2013 22:55:37 +0000 (UTC)
To: David Bruant <bruant.d@gmail.com>
Message-ID: <alpine.DEB.2.00.1308022252380.27623@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@whatwg.org>
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.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 2 August 2013 22:56:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC