The original message never showed up, sadly, so the threading's going to be a 
bit wrong here, unfortunately.


Currently postMessage is great for sending authenticated messages
between frames. The receiver knows exactly where each message came
from. However, it doesn't provide any confidentiality guarantees. When
you're posting a message to a window, you have no way of knowing who
is listening on the other end, because the same-origin policy prevents
you from reading the domain and URI of that window. The window may
have been showing a page loaded from foo.com the last time you
received a message from it, but it might be displaying content from
bar.com now; if you send it a message, you don't whether the message
will be received by foo.com or bar.com.

I noted in IRC discussion that postMessage being sync allows a 
challenge-response protocol to be safely used here, and you can determine the 
target's identification using domain/uri on the responding message; 
counterresponse was that's somewhat complicated.  Fair enough; I'm not sure if 
super-security is the main use case for this feature or not (lightweight 
collaboration seems more likely to me, but I don't really know), so I'm 
hesitant to comment too much on it.


The postMessage API could be extended to provide confidentiality by
adding some optional arguments:

void postMessage(in DOMString message, [optional] in DOMString domain,
[optional] in DOMString uri);

If "domain" or "uri" are specified, the browser would only deliver the
message if the recipient's location matches the specified domain and/or
URI. (Being able to specify the URI allows sites to differentiate
between http and https URIs.)

This seems reasonable enough.


For privacy, postMessage should be designed not to reveal the domain
or URI of the receiving window, so if there is a mismatch, the message
should be silently dropped.

Silent dropping is definitely good.


Providing the domain and URI for replies should be easy since these
values are already parameters of the event.

True -- problem is requiring people use them, since they're not forced to do so 
now.

Jeff

Reply via email to