Realm, schmealm!
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.
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?
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.
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:
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.
HTML5 specifies document.domain fully:
www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html
So regarding this issue, what does it say?
You want me to read and interpret and digest it for ya? :-P
Changing document.domain changes effective script origin, which affects some but not all security judgments. Basically the old-school ones that predate CORS; also images/media/fonts are not affected. But web compat still requires content in connected windows w1 and w2, loaded from foo.bar.com and baz.bar.com respectively, to be able to join origins at bar.com.
On Wed, Jul 31, 2013 at 6:44 PM, Brendan Eich <brendan at mozilla.com> wrote:
You want me to read and interpret and digest it for ya? :-P
(Sheepishly) well, uh, yeah.
Changing document.domain changes effective script origin, which affects some but not all security judgments. Basically the old-school ones that predate CORS; also images/media/fonts are not affected. But web compat still requires content in connected windows w1 and w2, loaded from foo.bar.com and baz.bar.com respectively, to be able to join origins at bar.com.
That's not the hard problem relevant to the current question. Given two frames both starting at foo.bar.com. While they're both there, their object graphs become arbitrarily entangled, which is as it should be. Then, one of them truncates to bar.com. Now they are separate origin iframes. What happens to their inter-frame pointers, which are now cross-origin pointers? In a membraneless browser, how are the newly-cross-origin pointers even distinguished from the same-origin pointers?
Mark S. Miller wrote:
That's not the hard problem relevant to the current question. Given two frames both starting at foo.bar.com. While they're both there, their object graphs become arbitrarily entangled, which is as it should be. Then, one of them truncates to bar.com. Now they are separate origin iframes. What happens to their inter-frame pointers, which are now cross-origin pointers? In a membraneless browser, how are the newly-cross-origin pointers even distinguished from the same-origin pointers?
The answer in pre-membrane Firefox was badly: a reference monitor would walk the DOM "parent" link (not parentNode) and try to find the right global object, from whose document to get an effective script origin (essentially).
The problem there was performance. I don't know of fast but incorrect implementations that allowed access where they should not have, but I am old and forgetful (relatively speaking; still have a memory like an elephant :-P).
Cc'ing Boris in case he knows more.
But does the html5 spec say anything about what is supposed to happen?
Mark S. Miller wrote:
But does the html5 spec say anything about what is supposed to happen?
Sure:
3.1.2 Security
Ready for first implementations
User agents must throw a SecurityError exception whenever any properties of a Document object are accessed when the incumbent script has an effective script origin that is not the same as the Document's effective script origin.
Ready for first implementations
Latest Internet Explorer beta: buggy support
Latest Firefox trunk nightly build: buggy support
Latest WebKit or Chromium trunk build: buggy support
Latest Opera beta or preview build: buggy support
JavaScript libraries, plugins, etc: unknown
When the incumbent script's effective script origin is different than a Document object's effective script origin, the user agent must act as if all the properties of that Document object had their [[Enumerable]] attribute set to false.
I don't care about the document objects. What about access between regular normal JavaScript objects that are now in different origins?
On Wed, Jul 31, 2013 at 8:38 PM, Brendan Eich <brendan at mozilla.com> wrote:
When the incumbent script's effective script origin is different than a Document object's effective script origin, the user agent must act as if all the properties of that Document object had their [[Enumerable]] attribute set to false.
What's special about the [[Enumerable]] attribute?
Mark S. Miller wrote:
I don't care about the document objects. What about access between regular normal JavaScript objects that are now in different origins?
6.2.1 Security
User agents must throw a SecurityError exception whenever any properties of a Window object are accessed when the incumbent script has an effective script origin that is not the same as the Window object's Document's effective script origin, with the following exceptions:
Ready for first implementations
Tests: 1 ---View...
Latest Internet Explorer beta: excellent support
Latest Firefox trunk nightly build: excellent support
Latest WebKit or Chromium trunk build: excellent support
Latest Opera beta or preview build: excellent support
JavaScript libraries, plugins, etc: excellent support
- The location attribute
- The postMessage() method
- The window attribute
- The frames attribute
- The self attribute
- The top attribute
- The parent attribute
- The opener attribute
- The closed attribute
- The close() method
- The blur() method
- The focus() method
- The dynamic nested browsing context properties
When the incumbent script's effective script origin is different than a Window object's Document's effective script origin, the user agent must act as if any changes to that Window object's properties, getters, setters, etc, were not present, and as if all the properties of that Window object had their [[Enumerable]] attribute set to false.
For members that return objects (including function objects), each distinct effective script origin that is not the same as the Window object's Document's effective script origin must be provided with a separate set of objects. These objects must have the prototype chain appropriate for the script for which the objects are created (not those that would be appropriate for scripts whose script's global object is the Window object in question).
For instance, if two frames containing Documents from different origins access the same Window object's postMessage() method, they will get distinct objects that are not equal.
Mark Miller wrote:
What's special about the [[Enumerable]] attribute?
I don't recall doing this in Netscape 2-4, so maybe this is a de-facto IE-set standard. Boris may know.
I read it twice and I don't get it. Can you derive from this text what is supposed to happen to a pointing relationship between two regular JS objects from two different frames?
On 7/31/13 7:39 PM, Mark S. Miller wrote:
But does the html5 spec say anything about what is supposed to happen?
Hixie punted on this and specced the current WebKit/Trident/Presto behavior: the only security checks are on access to properties of Document and Window (modulo the Location weirdness) and if you get an object from another page before document.domain is set then you can do whatever you want to with that object and anything reachable from it until you walk through a Window or Document.
I've pointed out to him several that we (Gecko) are not likely to implement what he has specified, because it causes security problems as far as we're concerned. Furthermore, the ad-hoc security checks involved in the model hixie has specced are ... leaky. See lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0621.html for an example, and we have privately reported other similar examples of cross-site information leakage to other browser vendors, even when document.domain is not involved.
On 7/31/13 10:22 PM, Mark S. Miller wrote:
I read it twice and I don't get it. Can you derive from this text what is supposed to happen to a pointing relationship between two regular JS objects from two different frames?
Per hixie's current spec, absolutely nothing.
[+ianh]
This seems like a bad bug in the html5 spec. Is there any public discussion explaining why the currently speced behavior should be considered acceptable? (Other than: It would be difficult to implement without membranes.)
On 7/31/13 10:35 PM, Mark S. Miller wrote:
This seems like a bad bug in the html5 spec. Is there any public discussion explaining why the currently speced behavior should be considered acceptable?
"It's simple and implemented by the majority of UAs" is the main reason as far as I can tell. Ian is not going to spec something people are unwilling to implement, because that would make the spec pretty useless... and I can definitely understand his position. The best way to make progress here is to get UAs fixed.
On 7/31/13 7:29 PM, Brendan Eich wrote:
The answer in pre-membrane Firefox was badly: a reference monitor would walk the DOM "parent" link (not parentNode) and try to find the right global object, from whose document to get an effective script origin (essentially).
Indeed. We ended up with some optimizations for getting to the effective script origin faster (e.g. detecting that the JS object is a DOM object and having DOM objects always have a pointer to something that had an origin hanging directly off it), but the upshot was quickly getting to something that was per-global and hence could usefully provide the global's origin.
The problem there was performance.
Indeed, at least for same-global object access.
Of course a problem for membranes is performance for access across the membrane. :(
Back to Mark's original question, in a membrane-less browser your best bet is to have a very fast security check on every property access or something. And even a very fast security check is not all that fast unless you pay a good bit in RAM (e.g. have each JS object hold a pointer directly to an origin and do a pointer-compare to fast-path same-global access).
(Sorry for breaking threading; catching up on the archives.)
The special thing about [[Enumerable]] is a bit of a red herring. What the spec should say is that if you're looking at a non-same-origin Document or Window then you shouldn't be able to tell what properties it has at all, since that's a cross-site information leak.
Hixie did the [[Enumerable]] thing presumably just because he didn't realize how getOwnPropertyNames behaves.
On Aug 1, 2013, at 7:41 AM, Boris Zbarsky wrote:
(Sorry for breaking threading; catching up on the archives.)
The special thing about [[Enumerable]] is a bit of a red herring. What the spec should say is that if you're looking at a non-same-origin Document or Window then you shouldn't be able to tell what properties it has at all, since that's a cross-site information leak.
Hixie did the [[Enumerable]] thing presumably just because he didn't realize how getOwnPropertyNames behaves.
or that someone could simply do access probes for likely property names?
In sounds like the actual intent is the Document and Window must be exotic objects (ES6-speak) that do caller origin filtering on all MOP operations applied to them. Presumably that is what the FF proxies implement.
This whole discussion and the related www.w3.org/Bugs/Public/show_bug.cgi?id=20567 "change [[Prototype]]" thread sure feel like Wack-A-Mole exercises.
It sounds like we don't actually have a complete/understandable/rational model of how the Document/Window rooted object model is supposed to behave as a data structure shared among Realms/processes/host domains, etc. It isn't even clear to me whether that level of direct sharing is actually needed (except for compatibility issues).
Is it feasible to reboot the design and then go back and see what compatibility shims need to be put in front of a new model.
Unless something like that is done I fear that Wack-a-Mole will continue forever without anything actually getting better.
On Thu, Aug 1, 2013 at 5:09 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
In sounds like the actual intent is the Document and Window must be exotic objects (ES6-speak) that do caller origin filtering on all MOP operations applied to them. Presumably that is what the FF proxies implement.
I think HTML does special casing for Document/Window. Gecko is more complicated. See this simple demonstration:
dump.testsuite.org/js/documentdomain.htm
This whole discussion and the related www.w3.org/Bugs/Public/show_bug.cgi?id=20567 "change [[Prototype]]" thread sure feel like Wack-A-Mole exercises.
It sounds like we don't actually have a complete/understandable/rational model of how the Document/Window rooted object model is supposed to behave as a data structure shared among Realms/processes/host domains, etc. It isn't even clear to me whether that level of direct sharing is actually needed (except for compatibility issues).
It's basically compatibility issues, as I understand it. The other problem is that there's generally great reluctance with respect to cleanup in addition to it being low priority.
On Thu, 1 Aug 2013, Boris Zbarsky wrote:
On 7/31/13 10:35 PM, Mark S. Miller wrote:
This seems like a bad bug in the html5 spec. Is there any public discussion explaining why the currently speced behavior should be considered acceptable?
"It's simple and implemented by the majority of UAs" is the main reason as far as I can tell. Ian is not going to spec something people are unwilling to implement, because that would make the spec pretty useless... and I can definitely understand his position. The best way to make progress here is to get UAs fixed.
Pretty much.
Personally I'd like to drop document.domain entirely, but that's not going to fly any time soon.
Note that it's not a bug, per se. There's no direct security benefit to cutting ties between two documents that used to be connected when you apply document.domain to disconnect them. It provides a defense in depth for the (likely, as it turns out) case where there's some other bug that means that two cross-origin pages can accidentally end up being considered same-origin for some reason and get hold of each other's objects, but if you assume that browser is implemented perfectly per spec (modulo some issues we're currently working to fix), you're not going to introduce any vulnerabilities by not doing this.
document.domain and the effective script origin concept introduces all kinds of problems unrelated to security that it would be nice to get rid of. For example, they limit to what extent you can isolate pages into different processes, because you have to worry about the full set of origins that could ever become related by document.domain (the spec has the term "similar-origin" to handle this, in fact).
Also, note that the Gecko approach to this isn't the only way to approach this defense-in-depth problem. Another way would be to do process isolation at the browsing context level (i.e. make it possible for iframes to be in their own process), and then have one process per group of similar-origin browsing contexts. That actually gets you closer to what the spec says (closer to the legacy model) than the Gecko approach, while still having a pretty solid defense against accidental leakage of cross-origin objects (arguably a stronger model, since you can actually prevent the entire process from having access to the data of other origins at the OS level, rather than just enforcing it at the JS level).
Ian Hickson wrote:
On Thu, 1 Aug 2013, Boris Zbarsky wrote:
On 7/31/13 10:35 PM, Mark S. Miller wrote:
This seems like a bad bug in the html5 spec. Is there any public discussion explaining why the currently speced behavior should be considered acceptable? "It's simple and implemented by the majority of UAs" is the main reason as far as I can tell. Ian is not going to spec something people are unwilling to implement, because that would make the spec pretty useless... and I can definitely understand his position. The best way to make progress here is to get UAs fixed.
Pretty much.
Personally I'd like to drop document.domain entirely, but that's not going to fly any time soon.
Yeah, let's not waste time on things that won't fly.
Also, note that the Gecko approach to this isn't the only way to approach this defense-in-depth problem. Another way would be to do process isolation at the browsing context level (i.e. make it possible for iframes to be in their own process), and then have one process per group of similar-origin browsing contexts.
This isn't different in principle from what we do in Gecko -- we want stronger isolation and the option to remote across processes (as IE apparently does).
That actually gets you closer to what the spec says (closer to the legacy model) than the Gecko approach,
How so? Can you give an example where Gecko doesn't do what the spec says?
while still having a pretty solid defense against accidental leakage of cross-origin objects (arguably a stronger model, since you can actually prevent the entire process from having access to the data of other origins at the OS level, rather than just enforcing it at the JS level).
Yes, process isolation is good. But even membrane mediated same-process is pretty darn good.
How about the non-enumerable thing? That doesn't really protect anything in ES5 era, and as Allen says it doesn't protect against guessed-name probing.
On 8/1/13 1:50 PM, Brendan Eich wrote:
How so? Can you give an example where Gecko doesn't do what the spec says?
Gecko revokes access to properties of all objects when you change document.domain, but per spec only access to properties of Window and Document should be revoked.
On 8/1/13 1:50 PM, Brendan Eich wrote:
How about the non-enumerable thing? That doesn't really protect anything in ES5 era, and as Allen says it doesn't protect against guessed-name probing.
Oh, and here... I agree that it doesn't seem to protect against getOwnPropertyNames. But guessed-name probing is protected against by the fact that [[GetOwnProperty]] should fail for cross-origin access except as whitelisted. I think the spec currently talks about gets or sets, but it should really be specified in terms of the MOP, indeed.
Boris Zbarsky wrote:
On 8/1/13 1:50 PM, Brendan Eich wrote:
How so? Can you give an example where Gecko doesn't do what the spec says?
Gecko revokes access to properties of all objects when you change document.domain, but per spec only access to properties of Window and Document should be revoked.
Ok, but Hixie was contrasting with a process-isolated implementation. It seems that would have to revoke everything too, or do remote proxies, or something.
I agree the spec is too much about "intersection semantics" or "the least that can be required based on browsers" (in 2008? Has nothing evolved?). We should talk about what to spec that's agreeable to the majors and better for security.
Ian Hickson wrote:
On Thu, 1 Aug 2013, Brendan Eich wrote:
That actually gets you closer to what the spec says (closer to the legacy model) than the Gecko approach, How so? Can you give an example where Gecko doesn't do what the spec says?
The difference between the model I described and the Gecko model is that the isolation is amongst groups of similar-origin browsing contexts, so document.domain doesn't cause a problem. That is, two sibling iframes at victim.example.com:80 and hostile.example.com:81 would be in the same process, not isolated from each other. It's essentially the model described in the spec, implemented with Gecko-style defense-in-depth.
So object refs not linked through window or document do get revoked on domain change, or do not?
How about the non-enumerable thing? That doesn't really protect anything in ES5 era, and as Allen says it doesn't protect against guessed-name probing.
I'm not sure what this refers to. Can you elaborate?
www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window
When the incumbent script's effective script origin is different than a Document object's effective script origin, the user agent must act as if all the properties of that Document object had their [[Enumerable]] attribute set to false.
On 8/1/13 4:27 PM, Brendan Eich wrote:
Ok, but Hixie was contrasting with a process-isolated implementation.
Hixie is suggesting process-isolating iframes that are not same-origin to start with and can't be made same-origin via document.domain
He is not suggesting process-isolating iframes which might ever become same-origin.
So his proposed implementation gives good defence in depth for things that are completely different origins and always will be, but does nothing for protecting mail.google.com from calendar.google.com, say, compared to the current situation..
I agree the spec is too much about "intersection semantics" or "the least that can be required based on browsers" (in 2008? Has nothing evolved?). We should talk about what to spec that's agreeable to the majors and better for security.
Bobby and I have tried a few times now to get any other implementor to be willing to do anything other than what's in the spec right now, with ... let's call it limited success.
On Thu, 1 Aug 2013, Brendan Eich wrote:
Ian Hickson wrote:
On Thu, 1 Aug 2013, Brendan Eich wrote:
That actually gets you closer to what the spec says (closer to the legacy model) than the Gecko approach, How so? Can you give an example where Gecko doesn't do what the spec says?
The difference between the model I described and the Gecko model is that the isolation is amongst groups of similar-origin browsing contexts, so document.domain doesn't cause a problem. That is, two sibling iframes at victim.example.com:80 and hostile.example.com:81 would be in the same process, not isolated from each other. It's essentially the model described in the spec, implemented with Gecko-style defense-in-depth.
So object refs not linked through window or document do get revoked on domain change, or do not?
Nothing ever gets revoked in this model. All that changes is that certain properties start throwing when accessed (or, for methods, called).
(The precise mechanism by which this happens is the topic of: www.w3.org/Bugs/Public/show_bug.cgi?id=22346 ...)
How about the non-enumerable thing? That doesn't really protect anything in ES5 era, and as Allen says it doesn't protect against guessed-name probing.
I'm not sure what this refers to. Can you elaborate?
www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window
""" When the incumbent script's effective script origin is different than a Window object's Document's effective script origin, the user agent must act as if any changes to that Window object's properties, getters, setters, etc, were not present, and as if all the properties of that Window object had their [[Enumerable]] attribute set to false. """
That paragraph was added because of: bugzilla.mozilla.org/show_bug.cgi?id=862380#c4
Spec bug: www.w3.org/Bugs/Public/show_bug.cgi?id=22102
Happy to change it to say something else instead, if it's wrong for some reason.
(apologies for the people on the to: and cc: lines getting dupes, I wanted to resend this to make sure it was in the archives and seen by the others on the list)
On Thu, 1 Aug 2013, Brendan Eich wrote:
That actually gets you closer to what the spec says (closer to the legacy model) than the Gecko approach,
How so? Can you give an example where Gecko doesn't do what the spec says?
The difference between the model I described and the Gecko model is that the isolation is amongst groups of similar-origin browsing contexts, so document.domain doesn't cause a problem. That is, two sibling iframes at victim.example.com:80 and hostile.example.com:81 would be in the same process, not isolated from each other. It's essentially the model described in the spec, implemented with Gecko-style defense-in-depth.
How about the non-enumerable thing? That doesn't really protect anything in ES5 era, and as Allen says it doesn't protect against guessed-name probing.
I'm not sure what this refers to. Can you elaborate?
Boris Zbarsky wrote:
On 8/1/13 4:27 PM, Brendan Eich wrote:
Ok, but Hixie was contrasting with a process-isolated implementation.
Hixie is suggesting process-isolating iframes that are not same-origin to start with and can't be made same-origin via document.domain
He is not suggesting process-isolating iframes which might ever become same-origin.
So his proposed implementation gives good defence in depth for things that are completely different origins and always will be, but does nothing for protecting mail.google.com from calendar.google.com, say, compared to the current situation..
For those two to join origins, they'd need to be reachable, which means loaded in related window/iframe(s) and/or visible by the ancestor-rule to window.open. So that helps a bit -- disjoint constellations that cannot be connected can be process-isolated from the get-go, even if their origins are subdomains of a common super-origin.
I'm not sure what the threat is, if any. Still seems kind of hinky.
As a spec, it indeed looks like pave-the-whack-a-mole-paths. Can we do better? My attempt to throw a net over Apple and Microsoft folks here has so far caught no fish. :
Le 01/08/2013 19:50, Brendan Eich a écrit :
Ian Hickson wrote:
Personally I'd like to drop document.domain entirely, but that's not going to fly any time soon.
Yeah, let's not waste time on things that won't fly.
Out of curiosity, are there recent data on setting document.domain? It's been quite a long time I haven't crossed it, replaced by postMessage (most likely out of habit with cross-frame communication where that's the only thing available) but I'm biased.
IIRC the only valid reason to set document.domain is pre-postMessage cross-eTLD+1-frame communication. How big is the intersection of websites both needing to support IE6/7 and cross-eTLD+1-frame communcation?
On Sat, 3 Aug 2013, David Bruant wrote:
IIRC the only valid reason to set document.domain is pre-postMessage cross-eTLD+1-frame communication. How big is the intersection of websites both needing to support IE6/7 and cross-eTLD+1-frame communcation?
There's a trillion or more pages that predate postMessage(). If even 0.0001% of pages need to do cross-domain communication, that's still more than a milion pages. Most pages on the Web are no longer maintained, so there's nobody who can do the work of updating them to use postMessage().
If there's a browser vendor who's willing to drop document.domain support and can show that they don't break sites in doing so, I'd be the first one to champion the effort to convince the other vendors to follow suit.
But as Brendan says, let's not waste time on things that won't fly.
(I think eventually it'll be possible. "Longer", in this case, might be a decade or more.)
On 8/2/13 6:16 PM, David Bruant wrote:
IIRC the only valid reason to set document.domain is pre-postMessage cross-eTLD+1-frame communication.
Yes....
How big is the intersection of websites both needing to support IE6/7 and cross-eTLD+1-frame communcation?
IE8 and IE9 don't support postMessage to a cross-origin window that's not in one of your subframes. And it's not clear what the state of things is in IE10, exactly. See caniuse.com/#search=postMessage
But more importantly, having written your code before postMessage existed is a valid reason to not use postMessage, and that doesn't mean we should necessarily break that code.
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.
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.