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
