search

w3c / webappsec-suborigins

Suborigins
https://w3c.github.io/webappsec-suborigins/
Other
25 stars 9 forks source link

What to do with WebSockets #44

Open joelweinberger opened 8 years ago

joelweinberger commented 8 years ago

I think we've discussed before that WebSockets should simply be disallowed. If that's the case, that should be explicitly added to the spec. If not, I assume we'll need to add Suborigin headers to requests. Either way, we need to spec out a solution.

annevk commented 8 years ago

Since you can polyfill WebSockets fairly soon, disallowing might be okay.

kentonv commented 8 years ago

For the Sandstorm use case[0], disallowing websockets would be pretty disappointing, as many of our apps use them extensively -- some without any fallback.

[0] https://docs.sandstorm.io/en/latest/administering/wildcard/#why-sandstorm-needs-wildcard-dns

joelweinberger commented 8 years ago

Fair enough. If we disallowed it, I would consider that a temporary measure for v1 until we decided exactly what to do. @kentonv, do you have particular thoughts on how to work them into the spec today? Just put a Suborigin header in the request?

kentonv commented 8 years ago

I'm not very familiar with the spec, but it seems like the right solution is to include a Suborigin header, and for the Origin header to contain the "serialized suborigin value" as with CORS requests.

devd commented 8 years ago

I think WebSockets can also be pretty easily faked using iframe based privilege separation: it sucks but I think for v1 we have to be pretty brutal about getting a MVP out and seeing how developers use it and what are the issues/problems using it. So, I am totally fine with punting it for v1.

joelweinberger commented 7 years ago

Both in the spec and Chrome implementation, we've disabled WebSockets for v1. I'm leaving this issue open, though, and reclassifying it from bug to next-version so we can hopefully re-enable WebSockets in v2.