W3C home > Mailing lists > Public > public-html-comments@w3.org > June 2008

RE: postMessage feedback

From: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
Date: Thu, 19 Jun 2008 19:49:57 -0700
To: Ian Hickson <ian@hixie.ch>
CC: Sunava Dutta <sunavad@windows.microsoft.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Message-ID: <72F767ADE7C63540BE69CD2722A41F440E9C93E23A@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Wednesday, June 18, 2008 10:51 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; public-html-comments@w3.org; Chris Wilson; IE8 Core
> Subject: RE: postMessage feedback
> On Wed, 18 Jun 2008, Zhenbin Xu wrote:
> >
> > 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/
> Sure. We can just say no. :-)

[Zhenbin Xu]  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.

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.

> > 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 redundant and
> inelegant.
> 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.

[Zhenbin Xu] 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 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.
> 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.

[Zhenbin Xu] 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;

        function sendSecretData(event) {
        if (event.origin == "http://example.com") { // TOC
                        event.source.postMessage("secret: " + secretData); // TOU

> > 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.
> Why? If the parties want to talk, then they shouldn't navigate away
> from
> each other. That seems pretty simple. :-)

[Zhenbin Xu]  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.

> > 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.

[Zhenbin Xu] 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.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
> ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'
Received on Friday, 20 June 2008 02:50:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:24 UTC