Re: postMessage, workers and sandboxing

Well, cross-origin workers don't exist yet, so I wouldn't rule anything out
completely.  But I would suggest that a pretty compelling case will have to
be made for the advantages of doing so compared to the costs of introducing
incompatibilities with how they work in same-origin workers.  Changing how
they work in same-origin workers is will be VERY hard, given the existing
deployments of workers.



On Fri Jan 30 2015 at 1:26:35 PM Deian Stefan <deian@cs.stanford.edu> wrote:

> Brad Hill <hillbrad@gmail.com> writes:
>
> > 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.
>
> This has been my impression as well.
>
> I'm not convinced that origin-checking breaks functionality in practice
> though. (I would interested to hear of cases where this did happen
> though.) In particular, y.example.com can always ignore the origin
> argument if it doesn't consider communication a security concern. But if
> it is concerned and wishes to know what origin is at the other end of
> the channel, it currently has no way to do so. Of course x.example.com
> can serve as an intermediary for m.example.com, but it seems like having
> the origin information would be helpful to thinking about security at
> the global (origin) level. (Especially if port leakage are a concern.)
>
> I'm also thinking about this in the context of cross-origin workers,
> where the lack of origin information would force authors (of worker
> code) to always make such decisions server-side.
>
> Is revisiting this design choice out of scope? I propose that we at
> least consider it for cross-origin workers. WDYT?
>
> Thanks,
> Deian
>