- From: David Bruant <bruant.d@gmail.com>
- Date: Sat, 03 Aug 2013 16:36:43 +0200
- 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