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: David Bruant <bruant.d@gmail.com>
Date: Sat, 03 Aug 2013 15:48:42 +0200
Message-ID: <51FD0A3A.2030904@gmail.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: whatwg@lists.whatwg.org
Le 03/08/2013 03:03, Boris Zbarsky a écrit :
> On 8/2/13 6:44 PM, David Bruant wrote:
>> 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 exactly does it solve it?  How is @sandbox even relevant here?
(feeling this might be again an instance of me misunderstanding the 
spec. sigh. sorry about that if that's the case)
I mistakenly wrote "VS" giving the impression that this is a security 
oriented thread, but that's not what I meant. Sorry for the mislead.
I was following up on the iframe process isolation idea.

> document.domain requires opt-on on both sides
Indeed and that's the reason what I describe works I believe.
Let's say we have pages from 2 domains "a.example.org" and 
"b.example.org". One has an iframe to the other. iframe process 
isolation is not possible, because at any point, both could set their 
domains to "example.org" (or process isolation is possible, but the 
deoptimization would have a violent cost)

"a.example.org" can sandbox the iframe to "b.example.org" and process 
isolation becomes possible again, because the parent and iframe are 
guaranteed to be of a different origin. However, this looses the origin 
of the iframe which breaks localstorage, etc. This can be solved with 
allow-same-origin, but process isolation is lost back because we're 
pretty much back in the previous case.

What I'm suggesting is the following: poison the document.domain setter 
in sandboxed iframes regardless of whether there is allow-same-origin. 
This way, in the "a.example.org"/"b.example.org" case, the iframe can be 
process isolated (because guaranteed to be of a different origin).
This also applies to "example.org" with a "b.example.org" iframe.
The only case this doesn't allow to optimize is "a.example.org" with an 
iframe to "example.org", where "a.example.org" might set document.domain 
to "example.org".

David
Received on Saturday, 3 August 2013 13:49:12 UTC

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