W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

postMessage, workers and sandboxing

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 15 Dec 2014 21:50:47 +0000
Message-ID: <CAEeYn8hjD1w7TFOt6iXfetck+gM5PVJvA19XpC6JEERcPt1f4Q@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
<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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC