- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Fri, 30 Jan 2015 13:26:32 -0800
- To: Brad Hill <hillbrad@gmail.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
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