22 ms·

Doesn’t look too secure.

thih9 6y ago
Could you elaborate?
kelnos 6y ago
Quite the contrary; if you host this yourself, remove the TURN server list, and host your own STUN server, it's much more secure than pretty much any of the third-party-hosted services out there. Assuming you trust your browser, that is. Obviously I haven't audited the code, but it's pretty small, and wouldn't be hard to thoroughly audit. It's surprisingly light on dependencies, just pulling in express as the webapp server, and socket.io for the call signaling. Personally I'd probably roll my own signaling over websocket to avoid that dependency (socket.io is an awful protocol, though for generally understandable reasons), but that would likely more than double the amount of code the author would've had to write.
- Kiro 6y ago
  Why is socket.io awful?
  - lioeters 6y ago
    I was curious too, since I'm generally fond of socket.io. I've written my own small library around bare WebSocket API, and there are many aspects to consider, like fallbacks and reconnection. In my opinion, socket.io provides a simple and smallish interface that takes care of most needs. Here's an article I found, with opinions on the good and the bad. https://dzone.com/articles/socketio-the-good-the-bad-and-the-ugly https://dzone.com/articles/socketio-the-good-the-bad-and-the... (2018)
    - kelnos 6y ago
      The interface is nice (from Javascript; it's impossible to write something type-safe in any language where you like to care about type safety); the protocol and implementation itself is horrifying. Some of the protocol's handshaking gymnastics was necessary 15 years ago when you couldn't rely on there being a standards-conforming Websocket implementation, but those days are long gone. Documentation is sparse, and when you find some docs, half the time it isn't clear which (incompatible) version of the protocol they're talking about. Source: I was working on writing an interoperable server implementation of socket.io a couple years ago, and it was way more work than it should have been.

Could you elaborate?

Quite the contrary; if you host this yourself, remove the TURN server list, and host your own STUN server, it's much more secure than pretty much any of the third-party-hosted services out there. Assuming you trust your browser, that is. Obviously I haven't audited the code, but it's pretty small, and wouldn't be hard to thoroughly audit. It's surprisingly light on dependencies, just pulling in express as the webapp server, and socket.io for the call signaling. Personally I'd probably roll my own signaling over websocket to avoid that dependency (socket.io is an awful protocol, though for generally understandable reasons), but that would likely more than double the amount of code the author would've had to write.

Kiro 6y ago
Why is socket.io awful?
- lioeters 6y ago
  I was curious too, since I'm generally fond of socket.io. I've written my own small library around bare WebSocket API, and there are many aspects to consider, like fallbacks and reconnection. In my opinion, socket.io provides a simple and smallish interface that takes care of most needs. Here's an article I found, with opinions on the good and the bad. https://dzone.com/articles/socketio-the-good-the-bad-and-the-ugly https://dzone.com/articles/socketio-the-good-the-bad-and-the... (2018)
  - kelnos 6y ago
    The interface is nice (from Javascript; it's impossible to write something type-safe in any language where you like to care about type safety); the protocol and implementation itself is horrifying. Some of the protocol's handshaking gymnastics was necessary 15 years ago when you couldn't rely on there being a standards-conforming Websocket implementation, but those days are long gone. Documentation is sparse, and when you find some docs, half the time it isn't clear which (incompatible) version of the protocol they're talking about. Source: I was working on writing an interoperable server implementation of socket.io a couple years ago, and it was way more work than it should have been.