I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).
I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.
The world is full of clueless firewall administrators who block everything but port 80 and 443 because security. It inconveniences users a lot more than attackers, but if you try explaining this you get a bunch of cargo cultism about reducing attack surface area, etc.
Never mind that these protocols now tunnel everything and thus have equivalent attack surface area to just opening your network. I call it cargo cultism because these people superficially know security buzz-concepts but do not understand them deeply. The application of security concepts in this superficial way does tremendous harm, not to mention creating a false sense of security among the cargo cultists and their followers.
So we engage in an arms race with ourselves. We block everything, then design protocols to tunnel through our firewalls to reenable all the things we blocked, then repeat.
SSH is another penultimate tcp over tcp protocol.
The only real solution to the security problems these hacks fix is to fix operating system app and privilege isolation. But that's more work so let's just break IP with firewalls and then pretend it secures us.
It's hard to beat the browser when it comes to building adequate software on a budget. It will never beat a native app in a race to be the best, but most software is about "making it work" instead of being #1 in the app store. The latter case of course gets a lot more press.
HTTP is really good at being a generic RPC protocol, what with proxy support and authentication and caching and content negotiation and automatic redirects and chunked streaming and etc. etc. ad infinitum. This, and not the fact that web browsers use it, is why people implement their service APIs in HTTP.
When you give a developer a websocket/WebRTC data channel/etc. and tell them to do RPC over it as a "lower-overhead alternative to HTTP", you inevitably get badly-greenspun (and almost never actually-lower-overhead) HTTP. Making HTTP itself lower-overhead is the best decision in the medium-term.
(In the long term, an HTTP-compatible RPC protocol that runs directly over SCTP+DTLS would be pretty cool, though.)
Comments
The best description of this protocol I have seen is "TCP over TCP."
I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).
I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.
The world is full of clueless firewall administrators who block everything but port 80 and 443 because security. It inconveniences users a lot more than attackers, but if you try explaining this you get a bunch of cargo cultism about reducing attack surface area, etc.
Never mind that these protocols now tunnel everything and thus have equivalent attack surface area to just opening your network. I call it cargo cultism because these people superficially know security buzz-concepts but do not understand them deeply. The application of security concepts in this superficial way does tremendous harm, not to mention creating a false sense of security among the cargo cultists and their followers.
So we engage in an arms race with ourselves. We block everything, then design protocols to tunnel through our firewalls to reenable all the things we blocked, then repeat.
SSH is another penultimate tcp over tcp protocol.
The only real solution to the security problems these hacks fix is to fix operating system app and privilege isolation. But that's more work so let's just break IP with firewalls and then pretend it secures us.
The firewalls are going to get very expensive once everything runs on port 80.
Unhappy users are sometimes the only way to get policies to change.
It's hard to beat the browser when it comes to building adequate software on a budget. It will never beat a native app in a race to be the best, but most software is about "making it work" instead of being #1 in the app store. The latter case of course gets a lot more press.
You say that as if cross platform development was easy.*
* (without cheating and effectively embedding a browser engine in your application.)
HTTP is really good at being a generic RPC protocol, what with proxy support and authentication and caching and content negotiation and automatic redirects and chunked streaming and etc. etc. ad infinitum. This, and not the fact that web browsers use it, is why people implement their service APIs in HTTP.
When you give a developer a websocket/WebRTC data channel/etc. and tell them to do RPC over it as a "lower-overhead alternative to HTTP", you inevitably get badly-greenspun (and almost never actually-lower-overhead) HTTP. Making HTTP itself lower-overhead is the best decision in the medium-term.
(In the long term, an HTTP-compatible RPC protocol that runs directly over SCTP+DTLS would be pretty cool, though.)
I'd say "HTTP over SCTP over TLS over TCP."