Mark S. Miller wrote:
> On Wed, Jul 31, 2013 at 5:00 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>     Taking a tip from Mark and pulling my own words out of the
>     "Agreeing on user-defined symbols" thread:
>
>     This serialize point is good, and gets to something I raised with
>     Allen yesterday, which he originally stated: realms should be
>     *more* isolated. We may want distribuited (cross-machine) realms.
>     IE and other browsers may already do cross-process window.open,
>     returning a DCOM proxy or some such. SpiderMonkey in Firefox uses
>     membranes across all realm/global boundaries, even same-origin.
>
>     Given this, I think instanceof (or typeof with an extension that
>     must be realm-specific because implemented by user-code, or else
>     we have to reify the "world of realms" as discussed in the other
>     thread) breaking cross-realm could be addressed by saying "proxy
>     harder". IOW let's not complicate JS with realms, worlds, truly
>     global string to symbol registries, etc. etc.
>
>     Let's get back to the simplicity of same-realm as the normal case,
>     with few-and-legacy exceptions. Can we do it?
>
>     -----
>
>     Realms are a good addition but if browsers are all using membranes
>     cross-realm, then this enables us to do more via proxies
>     (wrappers) to satisfy user-facing API and built-in operator
>     constraints.
>
>
> I think this is the legacy compat issue that may tie our hands here. 
> As I understand it, all browsers enable cross realm intimate mixing of 
> object graphs via same origin iframes. Firefox does impose a membrane 
> boundary here. I believe WebKit does not. I do not know what IE does. 
> I would guess that Opera now does whatever WebKit does.

You mean Blink :-P -- now diverging from WebKit, including in DOM 
implementation. I believe now the native (C++-implemented) DOM stuff 
implements the needed tracing GC hooks to avoid cyclic leaks through 
reference-counted and V8-rooted edges.

Anyway, the point is browsers have changed over the years, and membranes 
and proxies -- including WindowProxy codified by HTML5 -- are now 
common. Can we make use of this?

> The reason FF does is because of the %^##*^&%&(*#@#&

Tell me how you really feel :-P

But no, this is not why we use membranes across all real/global 
boundaries. We do it for performance, to make the global object and its 
"compartment" 1:1.

> origin truncation kludge that the web still continues to support, 
> where two frames that are same origin at t-zero may become different 
> origin at t-one. FF revokes inappropriate inter-realm access at that 
> point, because such access would then violate same origin separation. 
> I don't know how browsers without such inter-frame membranes cope with 
> the sudden need to impose origin separation that cuts through an 
> entangled object graph, but presumably in an observably different 
> manner. I also have no idea what html5 specifies must be done in this 
> situation.

HTML5 specifies document.domain fully:

http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html

> In any case, as long as these realms remain same origin, I believe all 
> browsers act compatibly. This requires that the membrane used by FF be 
> fully transparent until revoked, so that it acts identically to the 
> lack of a membrane on the other browsers.
>
> Please, anyone who knows the actual situation should speak up, either 
> to correct or confirm what I'm saying, because I'm really uncertain 
> about this. What's the actual situation?

I know you hate document.domain, but as noted above, it's not the 
proximate cause of our compartment-per-global model. Also, I'm told even 
IE9 could remote window.open cross-process, which really isolates realms 
even if same-origin. (But perhaps it doesn't remote unless 
different-origin?)

So yes, calling all implementors. Cc'ing a few.

/be

>
>
>     If I'm right that user-extensible methods and values, including
>     typeof customization, require either realm-sensitivity or else
>     world-of-realms spec and even more user-facing complexity, then we
>     also ought to think twice about the "isolate realms harder" option.
>
>     /be
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> -- 
>     Cheers,
>     --MarkM

Mark S. Miller wrote:

> I think this is the legacy compat issue that may tie our hands here. 
> As I understand it, all browsers enable cross realm intimate mixing of 
> object graphs via same origin iframes. Firefox does impose a membrane 
> boundary here. I believe WebKit does not. I do not know what IE does. 
> I would guess that Opera now does whatever WebKit does.

You mean Blink :-P -- now diverging from WebKit, including in DOM 
implementation. I believe now the native (C++-implemented) DOM stuff 
implements the needed tracing GC hooks to avoid cyclic leaks through 
reference-counted and V8-rooted edges.

Anyway, the point is browsers have changed over the years, and membranes 
and proxies -- including WindowProxy codified by HTML5 -- are now 
common. Can we make use of this?

> The reason FF does is because of the %^##*^&%&(*#@#&

Tell me how you really feel :-P

But no, this is not why we use membranes across all real/global 
boundaries. We do it for performance, to make the global object and its 
"compartment" 1:1.

> origin truncation kludge that the web still continues to support, 
> where two frames that are same origin at t-zero may become different 
> origin at t-one. FF revokes inappropriate inter-realm access at that 
> point, because such access would then violate same origin separation. 
> I don't know how browsers without such inter-frame membranes cope with 
> the sudden need to impose origin separation that cuts through an 
> entangled object graph, but presumably in an observably different 
> manner. I also have no idea what html5 specifies must be done in this 
> situation.

HTML5 specifies document.domain fully:

http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html

> In any case, as long as these realms remain same origin, I believe all 
> browsers act compatibly. This requires that the membrane used by FF be 
> fully transparent until revoked, so that it acts identically to the 
> lack of a membrane on the other browsers.
>
> Please, anyone who knows the actual situation should speak up, either 
> to correct or confirm what I'm saying, because I'm really uncertain 
> about this. What's the actual situation?

I know you hate document.domain, but as noted above, it's not the 
proximate cause of our compartment-per-global model. Also, I'm told even 
IE9 could remote window.open cross-process, which really isolates realms 
even if same-origin. (But perhaps it doesn't remote unless 
different-origin?)

So yes, calling all implementors. Cc'ing a few.