Re: postMessage, workers and sandboxing

Totally not obvious.  My best understanding of the design choice behind not
reporting origin on the entangled ports is that because the port is
supposed to act like a capability, the owner should be able to delegate it
to anyone without breaking applications.  So if x.example.com and
y.example.com have entangled ports, and x.example.com passes it's port to
m.example.com, y.example.com should have no reason to know about that, and
it shouldn't break the application, which it might, if y.example.com
checked the origin and would only accept messages from x.example.com.
On Thu Jan 29 2015 at 7:07:43 PM Deian Stefan <deian@cs.stanford.edu> wrote:

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