RE: postMessage feedback

On Thu, 19 Jun 2008, Zhenbin Xu wrote:
> 
> It is important to know whether or not * implies "any protocol" though. 
> I don't think it is prudent to allow postMessage from HTTP to FILE or 
> any other protocols even if "*" is specified. So "*" is not really ALL 
> if we disallow cross protocol posting.

file:// is a UA-specific case (not required for interoperability) but as 
far as other protocols go, I don't see why we would want to block 
cross-protocol communication. What's the security risk? It's already 
possible with fragment identifiers anyway.


> Even if we can say no now, it is conceivable that customer would want 
> something more expressive in the targetOrigin parameter in the future. 
> E.g. server farm scenario (http://mail*.example.com/)
> 
> Either we clearly define a more expressive scheme, or we should just not 
> define wildcard in current spec.

...or we could just say no when more features are requested.

We need a wildcard mechanism, it's likely the most common use for this 
feature. 


> > Sure, but I think it's worth it to bring the fact that it's a wildcard 
> > to the attention of the author. We _want_ this to smell bad, frankly.
> 
> It would sound like this feature is designed with inherent, potential 
> security flaw that we have to make API smell bad. Something is not 
> right.

The security flaw would be in scripts that acidentally use the wildcard 
when it shouldn't be used. By exposing the wildcard, we make it explicit 
and IMHO the problem becomes mostly moot.



> > Well, even with the sync model you could have the receipt and the 
> > sending decoupled in various ways that lead to the same problem. I 
> > agree that it is excacerbated by the async model, but it's not 
> > exclusive to it.
> 
> Yes the TOC-TOU problem in the original sync model could happen (WinA 
> caches WinB, WinB is navigated away without WinA knowing it, WinB 
> postMessage to WinA thinking that it is talking to the same Win).
> 
> However once a conversation starts, there is no TOC-TOU issue anymore.
> This eliminate security issue in the most commonly used pattern:
> 
> No problem doing the following since e.source would not navigate until
> postMessage is done.
>         window.onmessage = sendSecretData;
>         iframe.contentWindow.postMessage('hello');
> 
>         function sendSecretData(event) {
>         if (event.origin == "http://example.com") { // TOC
>                         event.source.postMessage("secret: " + secretData); // TOU
>               }
>         }

I don't think that would be a common pattern, since if the two pages 
aren't going to need to collect other information, then they would only 
need three messages (a handshake request, a response, and a final reply).

The more common use of this API would be something like:

         window.onmessage = messageReceived;
         iframe.contentWindow.postMessage('hello');
 
         function messageReceived(event) {
           if (event.origin == "http://example.com") { // TOC
             getData(function (s) {
               // getData does something async, e.g. db access or XHR
               // this is the callback
               event.source.postMessage(s); // TOU
             });
           }
         }

There's a security flaw in the above. It wouldn't be there if we required 
the second argument:

         window.onmessage = messageReceived;
         iframe.contentWindow.postMessage('hello');
 
         function messageReceived(event) {
           if (event.origin == "http://example.com") { // TOC
             getData(function (s) {
               // getData does something async, e.g. db access or XHR
               // this is the callback
               event.source.postMessage(s, event.origin); // TOU
             });
           }
         }

It would be pretty obvious something was wrong if you used the wildcard.


> > Why? If the parties want to talk, then they shouldn't navigate away 
> > from each other. That seems pretty simple. :-)
> 
> The conversation may be results of user action (e.g clicking on a button 
> to have WinA talk with WinB). In the async model, some script in WinA 
> may trigger navigation before WinB replies (e.g. clicked on another 
> button).  It is not easy for web page author to come up with robust 
> solution against this type of scenario, especially if application 
> running on WinA is sufficiently complicated.

I don't see this as a problem really. If the user navigates away, then the 
user navigates away. So what? The user could also navigate away while the 
script is running. Or shut down the browser.


> > > There are still things about the async model that I don't quite 
> > > understand, such as how to track the replies -- if 5 postMessge is 
> > > called consecutively, how to handle out-of-order reply?
> >
> > That's up to the pages that define their protocols -- but generally, 
> > handling out of order replies is a solved problem in computer science. 
> > You use sequence IDs, topics, explicit context, any number of 
> > solutions come to mind.
> 
> This is additional bookkeeping that should best be handled by the 
> platform. It is especially difficult when we consider, for example, WinA 
> can be refreshed before reply comes back. So the sequence ID could 
> conflict if it is tied to the life time of WinA.
> 
> I argue this is way too much work for web page authors to write a 
> reasonably complex web app using postMessage.

I don't think most uses of postMessage() will need multiple messages or 
anything like that. However, those that do will probably just use 
libraries to manage it for them. Different libraries will have different 
mechanisms for different use cases. Our goal here is to provide basic 
building blocks, not solve all problems.

On the long term we should probably introduce pipes as first class 
objects, which oblivates this concern entirely and makes the whole concept 
much more powerful, as in:

   http://hixie.ch/specs/dom/messages/0.9

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 20 June 2008 06:33:40 UTC