[whatwg] The cross-document messaging APIs

[Ian Hickson]

I've moved the cross-document messaging API postMessage() to Window 
instead of Document. I haven't otherwise changed it. I know it's not what 
everyone wanted, but the various requests were somewhat incompatible so 
someone had to not get what they wanted. :-) In particular, I haven't 
change postMessage() to be on the source Window instead of the target 
Window, since we had implementation feedback in both directions.


On Tue, 10 Jul 2007, Jeff Walden wrote:
> 
> First, on a less substantial note: I agree with the spec note that this 
> API should be on Window (and change source's type to Window as well).  
> There can be multiple documents associated with a Window, but the 
> principal is the same for the entire bundle -- it's tied to the window, 
> not to the document.

Done.


> Also, in my skim of Mozilla's Window implementation, it seems to contain 
> far more of the methods with security considerations, whereas the 
> HTMLDocument implementation contains fewer; I think concentrating the 
> security-conscious methods in fewer locations and greater quantities is 
> a good idea.

Agreed.


> (It would be nice if the XSS concern mentioned in the note were 
> explained, because I'm not sure to what it refers, and it might 
> conceivably affect my opinion here.)

I'm not sure what you're referring to here.


> Second: as currently specified, postMessage (section 6.4, cross-domain 
> messaging), requires that an implementation "punch" a hole through its 
> security specifically for calls to postMessage on windows (assuming it 
> were moved to Window), as well as possibly for enumerating a window's 
> properties, doing |"postMessage" in win| checks, and ensuring that 
> |win.postMessage| doesn't refer to a function that |win| might have 
> defined in a custom modification (if the property weren't 
> ReadOnly+DontDelete; the spec doesn't mention).

Yes, this is already quite common on Window for several other APIs.


> I was discussing this with a friend recently, and he made the following 
> suggestion: why not instead change the API to |postMessage(message, 
> otherWindow)|, such that sending a message to another window involves 
> getting the other window and calling |postMessage| on *your* window?  
> It's already possible to acquire and use objects associated with other 
> browsing contexts, and you can even pass them to APIs (usually you'll 
> get an error, but it's not a guard-dog -- it's an error raised by that 
> specific method).  This removes the need to punch the hole to make 
> |postMessage| available to any script, and it means only postMessage 
> itself (and not other pieces of the browser's security code) needs to be 
> able to punch same-origin holes -- a significantly smaller change 
> security-wise, and much easier to audit and reason about.

This is not a bad argument, but I think it is neater to call the method on 
the target window (and easier to understand at a glance).

The security issue would be more of a problem if there wasn't such a 
precedent for carefully crafted holes in the Window object.


On Tue, 10 Jul 2007, Aaron Boodman wrote:
> On 7/10/07, Jeff Walden <jwalden+whatwg at mit.edu> wrote:
>>
>> why not instead change the API to |postMessage(message, otherWindow)|, 
>> such that sending a message to another window involves getting the 
>> other window and calling |postMessage| on *your* window?
> 
> This is a great idea. We were thinking of implementing PostMessage in 
> Gears and it would be much easier if that were the API.

I apologise for making your life harder, but I hope that leaving it as it 
is in the spec will not prove to be a huge blocker for you.


On Sat, 14 Jul 2007, Jeff Walden wrote:
>
> Second, in the interests of explicitness, we should be clear about the 
> exact values of event.domain and event.uri.  Two concerns: how does 
> setting document.domain interact with the computed value for 
> event.domain, and what are the contents of event.domain in the presence 
> of default and non-default ports?  I think the answers to these two 
> concerns must be as follows.  Setting document.domain must have no 
> effect on the value of event.domain, in the interests of web hosts who 
> host content on subdomains of their main domain, e.g. 
> myhomepage.webhost.com and webhost.com (else it would allow spoofing in 
> pages which listened for cross-domain messages but didn't check the 
> uri).  The contents of event.domain must include the port number iff it 
> is not the default port number for the protocol (80 for http, 443 for 
> https) and must omit it otherwise.

The domain is intended to only contain the domain (no port); the port and 
protocol can be obtained from the "uri" attribute if it is needed.

I've added a note to myself to fix this in due course.


> Third, with the modified API, the following is possible:
> 
>  // kidFrame is same-origin wrt window
>  window.frames.kidFrame.postMessage(otherWindow, message);
> 
> With the current design, this would basically allow a window to send an 
> event which looks as though it has been created by another (same-origin, 
> or joined-principals via document.domain) window, with a different 
> event.uri. Since the two windows are same-session this probably isn't a 
> real concern, but I think it's worth mentioning that the change makes it 
> possible to send a message from a window different from the one 
> currently executing the script.

This is actually a good argument against it, IMHO, though of course since 
you can use dispatchEvent() you can always fake the event in this kind of 
situation.


> Fourth, and probably most importantly, is the event dispatched by 
> postMessage dispatched synchronously (event fired and processed before 
> postMessage returns) or asynchronously?  I interpret the current wording 
> to mean synchronously, in accordance with the DOM 3 Events section on 
> reentrance, but I'd like to be clear that's the intended interpretation.

Clarified in the spec.

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