On Wed, Jul 31, 2013 at 5:26 PM, Brendan Eich <brendan at mozilla.com> wrote:
> 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<http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html>
>
> So regarding this issue, what does it say?
>
> 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<https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/d8a5348f/attachment.html>
domenic at domenicdenicola.com (2013-08-09T20:15:45.664Z)
> HTML5 specifies document.domain fully:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html
So regarding this issue, what does it say?
On Wed, Jul 31, 2013 at 5:26 PM, Brendan Eich <brendan at mozilla.com> wrote: > 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<http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html> > > So regarding this issue, what does it say? > > 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<https://mail.mozilla.org/listinfo/es-discuss> >> >> >> >> >> -- >> Cheers, >> --MarkM >> > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/d8a5348f/attachment.html>