Hi Jeff,
On Jul 16, 2007, at 12:17 PM, 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.
There's already a handful of Window properties and methods where
access bypasses the normal cross-domain security checks, such as the
close() method and the closed property. So this isn't a new concept.
In WebKit at least we handle these domain security exceptions in a
unified way, and adding one more method that works the same way would
not be a big deal.
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 with 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.
I don't think that's the case, given that browsers must already
implement the other exceptions.
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.
I would say go with the simpler API, since I don't think either way
creates extra implementation difficulties.
Regards,
Maciej