- From: Brad Hill <hillbrad@gmail.com>
- Date: Mon, 15 Dec 2014 21:50:47 +0000
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8hjD1w7TFOt6iXfetck+gM5PVJvA19XpC6JEERcPt1f4Q@mail.gmail.com>
<semi-offtopic> Since it came up at the end of our call, I thought I'd share something I myself was confused about and learned by writing test code and from Hixie telling me (in the most polite and oblique way possible) to RTFM when I didn't understand the results. There are two varieties of postMessage(). The "window" kind and the "MessageChannel" kind. The "window" kind is when someone grabs a reference to your document's window object and tries to pass you a message, unsolicited. For this case, the "origin" is set on the event, since otherwise you have no idea where that message came from. The "MessageChannel" variety is the idea that you create two ports and explicitly give each one to someone as a capability handle (that is to say, they can themselves hand them off to somebody else). This kind of postMessage does not come with an origin indication because that would be a problem for the capability security model it is trying to achieve. You should know who you gave it to originally, and if you trust them, it's none of your business if they delegate it to someone else they trust. Workers use the "MessageChannel" variety of postMessge, so the "origin" is never set on events through that channel. Incidentally, this means that the possibility of a sandboxed or cross-origin worker is already pretty sensible in the existing model. -Brad
Received on Monday, 15 December 2014 21:51:15 UTC