That's entirely true and it's one reason why I hesitated before nitpicking. That said, I think that the distinction should be properly made when someone is discussing a new way to sling data over a network from the application layer. If the author had written what you'd written, I'd have let my reply go.

(Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)

i think its fair what you said. webrtc offers "automatically" encrypted UDP if we are comparing like that.

But we already knew that. It's in the article, so again there is a story here that you're missing. We want a client/server protocol that is encrypted and simple -- not requiring ICE/STUN/TURN (OMG).

If you already have Websockets, then Simple-Peer makes it very easy to deal with WebRTC negotiation. As I've mentioned elsewhere, I've created a 4 process WebRTC UDP proxy with that running under nodejs. My use case is precisely client-server.

There is DTLS if you really want turnkey encryption for UDP, and it's implemented by openssl so it's straightforward enough to find an implementation. Not the most widely deployed protocol out there, to be sure, but if browsers wanted to make that the condition of use it would soon become widely implemented.

"openssl [...] straightforward" I don't think so. It's in the article; DTLS is too complex. The author wants something simple.

Most implementations (eg. WebRTC) involve pulling in truck loads of C libs; it's insane. And then you want to support other clients? Good luck.

Not quite turnkey, but openvpn is essentially tls over udp with an ip tunnel on top