[whatwg] web messaging - postMessage

[Ian Hickson]

On Mon, 5 Aug 2013, Jack (Zhan, Hua Ping) wrote:
> 
> The "origin" in this context means the msg destination.

The term "origin" in Web standards means a security token, essentially:

   http://tools.ietf.org/html/rfc6454

In the case of window.postMessage(), there's two places that an origin is 
used. The first is in the method call:

   destinationWindow.postMessage(message, targetOrigin);

Here, targetOrigin is the origin that the destinationWindow object's 
active Document is required to have for the message to be delivered. We 
have this feature so that if the target page gets navigated away 
unexpectedly, you don't end up sending secrets to evil pages.

The second is in the received MessageEvent object:

   // window is the destinationWindow of the script above
   // but here we're on the receiving end
   window.onmessage = function (event) {
     // event.data is the message from the call above
     // event.origin is the origin of the Window that sent the message
     // event.source is the Window that sent the message
   }

Note that event.origin is _not_ targetOrigin.


> Think it over, it seems to be "polling", but in your design, seems there 
> is no polling. in fact, there is. In your design, the receiver has to 
> check "origin".

It has to check that it is receiving messages from a trusted source, 
right.


> This means the receivers have to check the destination of the message.

No, they're checking the source of the message.


> > If you need to communicate between two otherwise unrelated tabs, there 
> > are basically two solutions: a shared worker, or a broadcast 
> > mechanism. The latter isn't currently specced, but discussion on how 
> > to do it is here:
> >
> >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628
> >
> > You can also currently fake this using the 'onstorage' event.
>
> Yes. I know these two solutions since someone told me before. but shared 
> worker is much more complicated than needed, isn't it? broadcast will 
> lose privacy, won't it?

How would broadcast lose privacy?


> >> My better proposal .....
> > This is basically a broadcast mechanism, right.
> Yes. you are right, but message dispatch is done by the user agent, only 
> the intended receiver will receive the msg, so no communication 
> information would be leaked. And when broadcast is really needed, just 
> use wildcard for destination.

As far as I can tell, what you are describing is consistent with the 
proposal in the bug above.


> > One things that would be useful in making progress on this would be 
> > more use cases, in particular use cases where it's important to be 
> > able to respond after a broadcast.
> >
> > There's basically only one use case in the bug above, namely informing 
> > other windows of a state change (e.g. user logged in). This can 
> > currently be done using "onstorage" and that could arguably in fact be 
> > a sufficient solution (since for a "change" notification, there's no 
> > need to respond, and it's typically stored state that has changed).
>
> You are thinking in such a way. I really do not understand.

There's an infinite number of features we could add, but we could not 
implement them all -- there's limited resources to implement stuff, and 
the more we implement, the more buggy stuff is since the resources get 
spread thinner and thinner.

We have therefore to prioritise and only implement the most important 
things.

To determine if something is important, we look at how people want to use 
it, and what problems they are trying to solve (use cases).

Currently for this feature we lack many use cases.


> I think this interface is really nice. Compare the original design and
> this design, it is easy to see the difference.
> >>>o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
> window.postMessage(msgdata, targetDomain optional,targetWindowIDs optional);
> 
> window is the general js object. the destination can be specified by 
> domain and/or window/tab ID, both of them can be omitted which means a 
> broadcast.

window IDs aren't a good thing to use for naming windows, since they are 
trivially spoofed.


> the major difference is the "o.contentWindow", this is really weird.
> Once you specify the target receiver, you do not have to care its
> window handle. The user agent should take care of it.

There's an important difference between the Window object of the target, 
and the origin of the Document currently loaded in the target. It's easy 
for an attacker to renavigate an iframe or window to their site, so it's 
important to say the origin of where you're sending the data, so that an 
evil site can't intercept it.


> For security reason, the interface at the receiver side, will be bound 
> to a specific msg name "msgpost". This msg name is added by the user 
> agent. The msg name is some kind of identifying the msg channel, so the 
> receiver will have an idea where this message comes from. Of course, msg 
> source will also be available for the receiver to check. But as a 
> receiver, checking msg destination is not needed since this should be 
> done by the user agent.

I don't understand how this improves security. What's the attack model you 
have in mind that this mitigates?

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