In my previous email regarding HTML5's postMessage (section 6.4, cross-domain
communication), I suggested changing the API to
|yourWindow.postMessage(message, otherWindow)|. I have a few more
questions/suggestions after playing around with an implementation of this in
Mozilla (bug postMessage for anyone who cares); I somewhat hope to get this in
1.9.
First, I think placing |otherWindow| as the first argument and |message| as the
second is more aesthetically pleasing than the other way around, tweaking the
suggestion I made last time. I don't have a strong reason for this beyond its
being analogous to the traditional security model in the literature (which
seems good enough to me in the absence of strong reasons going the other way):
yourWindow . postMessage ( otherWindow , message ) ;
actor does verb to object
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.
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.
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.
Jeff
