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 16:36:43 +0200
Message-ID: <51FD157B.5080702@gmail.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: whatwg@lists.whatwg.org
Le 03/08/2013 16:02, Boris Zbarsky a écrit :
> On 8/3/13 9:48 AM, David Bruant wrote:
>> "a.example.org" can sandbox the iframe to "b.example.org" and process
>> isolation becomes possible again
>
> Yes, agreed.  This might be a good idea.  It just has nothing to do 
> with protecting one from attacks by the other in general, because they 
> can use window.open and loads...
Yes yes, that's only for iframe isolation, not "any-frame" isolation, 
but I feel it already gets a long way.

As a developer, I'm dreaming of a world (10 years from now? :-/) where 
an iframe would be a WebWorker with a UI.
That would make ideas like CanvasProxy [1] (transferable part of a 
canvas for off-main-thread drawing) obselete.

>> What I'm suggesting is the following: poison the document.domain setter
>> in sandboxed iframes regardless of whether there is allow-same-origin.
>
> I like it, yes.
Awesome! Looking forward to other browser vendors opinion!

>> 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".
>
> It doesn't matter, because _both_ have to set document.domain.
oh ok. I guess I misunderstood the spec after all, but that supports the 
idea of poisonning the document.domain setter, yay!

David

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasproxy
Received on Saturday, 3 August 2013 14:37:11 UTC

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