Re: postMessage, workers and sandboxing

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

Received on Friday, 30 January 2015 21:26:58 UTC