[whatwg] Disabling document.domain setting on iframe at sandbox (especially with allow-same-origin)
David Bruant
bruant.d at gmail.com
Sat Aug 3 07:36:43 PDT 2013
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
More information about the whatwg
mailing list