FWIW, I just talked with our javascript security guys and they very much
agree with Jeff. Browsers have to deal with accessing properties on
other windows already, such as otherWindow.open(...). However this is
very hard to implement safely and we have found numerous security
problems with this stuff over the years, some exploitable, some not. So
the fewer properties like this we have the better.
So this is purely an implementation issue. There may be other reasons
too, but implementation wise it's much simpler, and author wise the
difference in syntax is simply:
otherWindow.sendMessage("hi");
vs.
sendMessage(otherWindow, "hi");
which really doesn't matter much I would think.
/ Jonas
Jeff Walden wrote:
Gorm Haug Eriksen wrote:
I agree that postMessage should have been on the window and not on the
document, but why would you like to have the method on yourWindow
instead of the otherWindow you post the message to?
The benefit is that you don't have to punch holes through your existing
security infrastructure to do it. If you're in your code, you can have
a reference to an |otherWindow| that's not same-origin as you, but you
can't do any of the following (and probably more) with it:
var secretProperty = otherWindow.secretProperty; // stolen!
for (var i in otherWindow)
{
// if you get here, you know some of otherWindow's
// properties -- information leak
}
otherWindow.trustedProperty = "subverted"; // oops!
delete otherWindow.importantInfo; // DOS
For you to need to use postMessage on otherWindow, you need to be able
to do many of these things -- but the entire browser security model is
based on not allowing you to do this if the window you've called it on
isn't same-origin with you. You have to punch a hole in this security
to allow getting, calling, or enumerating postMessage, but only if the
object off which the property is gotten is a Window. You also have to
make the property appear ReadOnly/DontDelete externally, so you can't
screw with windows that try to call postMessage on you. Also, how does
this restriction work with other windows which are same-origin? Do they
see only the original postMessage binding, or do they see any
modifications that window makes to it? What if a different window,
same-origin, makes that modification? What if windows pre-HTML5 wanted
to communicate via a postMessage binding? This gets complicated pretty
quickly, and to do it all you have to punch a hole through security, and wi
th the fragility of that hole (only on Window, only if "postMessage",
only with the original binding or only if it hasn't been overridden --
and I'm not at all sure that's enough) and the specific criteria for
that hole to exist, it's going to be easy to accidentally allow more
than you wanted to allow.
In contrast, passing a different-origin value into a function is already
allowed, and you don't need to do anything special to make it possible.
The only security modification to allow the cross-origin-ness is to make
postMessage ignore origins. This is *vastly* simpler, easier to
implement, and hence safer and more secure.
I'll agree that calling postMessage on the other window feels like a
better and more intuitive API for users, but if implementers have to
make such invasive and potentially-unsafe changes to do it, I think it's
the wrong way to do it.
Jeff