[whatwg] Suggestions on postMessage (6.4, cross-document messaging)

[Jeff Walden]

Two things:

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

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

Jeff