RE: postMessage feedback


It is still the developer's decision to decide whether or not to treat the
Message as public (*) or private (targetOrign).  The thing I don't like with
"*" is that people would start to want finer grain control. E.g. *://example.com/,
http://*.example.com/    The other issue is that this is different from
other programming pattern such as XHR.open, where username and password need to
be provided if needed.

Web developers need to be aware of the ramification of sending public message.
It is worth prominently calling out the example you have below in spec.  But forcing
them to add a "*" smells redundancy and inelegant.

The second thing I want to point out is that the TOC-TOU example below is a
by-product of the async model that was just added. With sync model, source window
cannot navigate away until postMessage returns.  As consequence of async model,
postMessage is no longer a reliable way of conversion -- one party of the conversion
may be gone while the other party is still trying to talk back.  I feel this is
going to severely limit its usefulness.

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?


Thanks!
Zhenbin



> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Monday, June 16, 2008 5:44 PM
> To: Sunava Dutta
> Cc: public-html-comments@w3.org; Chris Wilson; IE8 Core AJAX SWAT Team
> Subject: RE: postMessage feedback
>
> On Mon, 16 Jun 2008, Sunava Dutta wrote:
> >
> > On Tue, 22 Apr 2008, Jeff Walden wrote:
> > >
> > > Make the targetOrigin argument non-optional.  "*" would mean "don't
> > > care" while anything else would specify an origin (or result in a
> > > syntax error).  If this is done, it's no longer possible to have
> > > time-of-check/time-of-use issues (in the async case) without the
> web
> > > developer explicitly choosing to do so.  This change shouldn't be
> any
> > > more than 5-10 lines, and fixing existing testcases to adjust for
> this
> > > change is straightforward.
> >
> > I didn’t quite get how the TOC-TOU issue can happen here? Can we
> > elaborate.
>
> If you don't have the second argument, then between the time where the
> source has checked that the target is the expected target, and the time
> the target actually receives the message, the target could change.
>
> For example:
>
>    window.onmessage = sendSecretData;
>    iframe.contentWindow.postMessage('hello');
>
>    function sendSecretData(event) {
>      if (event.origin == "http://example.com") { // TOC
>        // (at this point, if event.source is in a different thread,
>        // e.g. a different IE8 tab, then it could be navigated in
>        // between the if statement above and the following line)
>        event.source.postMessage("secret: " + secretData); // TOU
>      } else {
>        // event.source is not from the expected origin!
>      }
>    }
>
> With the two-argument form, this is no longer possible except by
> explicitly opting in with the wildcard argument.
>
> HTH,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
> ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'

Received on Thursday, 19 June 2008 02:27:29 UTC