Re: postMessage, workers and sandboxing

Brad Hill <hillbrad@gmail.com> writes:

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

To clarify my understanding: is this breaking the object-capability
model because populating the origin according to context is like leaking
a capability?

I think that having the origin information would be useful even if you
assume this trust model.

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

Do you mind expanding on how setting the origin would get in the way?
Sorry if this is obvious.

Thanks,
Deian

Received on Friday, 30 January 2015 03:08:07 UTC