[whatwg] More on postMessage

[Maciej Stachowiak]

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