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

[David Bruant]

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