W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: New full Unicode for ES6 idea

From: Brendan Eich <brendan@mozilla.com>
Date: Sun, 19 Feb 2012 13:52:07 -0800
Message-ID: <4F416F07.8030207@mozilla.com>
To: "Mark S. Miller" <erights@google.com>
CC: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, mranney@voxer.com
Mark S. Miller wrote:
> On Sun, Feb 19, 2012 at 11:49 AM, Brendan Eich <brendan@mozilla.com 
> <mailto:brendan@mozilla.com>> wrote:
> [...]
>
>     Not all engines mediate cross-same-origin-window accesses. I hear
>     IE9+ may, indeed rumor is it remotes to another process sometimes
>     (breaking run-to-completion a bit; something we should explore
>     breaking in the future for window=vat). SpiderMonkey just recently
>     (not sure if this is in a Firefox channel yet) went to compartment
>     per global, for good savings once things were refactored to
>     maximize sharing of internal immutables.
>
>
> Other than the origin truncation issue that I am still confused about,

Do you mean document.domain setting? That allows code in an origin to 
join its origin's super-domain (but not a dotless top level). See

http://www.w3.org/TR/2009/WD-html5-20090212/browsers.html#dom-document-domain

and

http://www.w3.org/TR/2009/WD-html5-20090212/browsers.html#effective-script-origin

> what other benefits are there to mediating interframe access within 
> the same origin?

The WindowProxy in HTML5 reflects a de-facto standard developed by 
browser implementors to avoid 
closure-survives-navigation-to-other-origin attacks. See

http://www.w3.org/TR/html5/browsers.html#the-windowproxy-object

Demons from the First Age included attacks that loaded a document 
containing a script defining a closure from evil.org into a subframe, 
then stuck a ref to the closure in the super-frame, then navigated the 
sub-frame to victim.com. Guess whose scope the closure saw, with only 
Window objects and no WindowProxy wrappers for the named (not implicit 
in identifier resolution) window/frame objects?

>     My R2 resolution is not specific to any engine, but I have hopes
>     it can be accepted. It is concrete enough to help overcome
>     large-yet-vague doubts about implementation impact (at least
>     IMHO). Recall that document.domain setting may have to split a
>     merged same-origin window/frame graph, at any time. Again
>     implementation solutions vary, but this suggests cross-window
>     mediation can be interposed lazily.
>
>
> How? By doing a full walk of the object graph and doing surgery on it? 
> This sounds more painful than imposing mediation up front.

No, by indirection, of course ;-). The details vary among browsers.

> But I'm still hoping that objects same origin iframes can communicate 
> directly, without mediation.

Why? Anyway, it's unsafe, wherefore WindowProxy. No big deal. There's no 
mediation for identifier resolution (i.e., scope chain lookup) and 
indeed JITting VMs optimize the heck out of local global accesses already.

/be
Received on Sunday, 19 February 2012 21:52:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC