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
