domenic at domenicdenicola.com (2013-08-09T20:14:33.148Z)
On Wed, Jul 31, 2013 at 5:16 PM, Mark S. Miller <erights at google.com> wrote: > 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. Re a topic on another thread, this also requires Array.isArray to work across membranes just as it works across realms. Which is to say, Array.isArray really should be transparent across membranes.
On Wed, Jul 31, 2013 at 5:16 PM, Mark S. Miller <erights at google.com> wrote: > On Wed, Jul 31, 2013 at 5:00 PM, Brendan Eich <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. > > The reason FF does is because of the %^##*^&%&(*#@#& 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. > > 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. > Re a topic on another thread, this also requires Array.isArray to work across membranes just as it works across realms. Which is to say, Array.isArray really should be transparent across membranes. > > 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? > > > >> >> 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 >> 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/efc2b9e3/attachment-0001.html>