Hacker News Reader

Comment by timkam | Hacker News Reader

I guess Zoom says they're end-to-end encrypted because they're using WebRTC, which probably means traffic is end-to-end encrypted after signaling, but users need to trust that zoom's signaling server doesn't do anything fishy.

Edit: I do not understand the reason for the downvotes. I am not defending the practice but am just describing their potential line of explanation. Please let me know explicitly if my comment is technically incorrect. Also, I would be interested what other vendors claim, who probably use similar technology under the hood.

View on HN

Yeah somewhere in their documentation they state that they are end-to-end encrypted because the connections peer1<->zoom and zoom<->peer2 are encrypted. I cant find the page anymore but they really tried to redefine the name for end to end encryption...

end-to-middle-to-end encrypted...

Point-to-point encryption

middle-out encryption

There's no way the audio can be end-to-end encrypted, because I can call in from a normal telephone and hear everyone.

Video conferences via WebRTC usually have a central server that distributes all the video streams and are therefore not end-to-end encrypted.

End to End encryption in conferences of >2 participants causes substantial quality degradation for the same bandwidth use, since you can't have a central server re encoding streams to produce low quality streams for those participants who need it.

I believe zooms reputation as being more likely to 'just work' in part hinges on that,

That's a fair technical tradeoff, but you can't have it both ways.

If end-to-end symmetrical is not feasible then use fully homomorphic public key encryption, which will allow operations without decryption.

Show me any system allowing video re-encoding with this...

Right, so I suppose that the numerous gateways zoom and others need to offer are an additional problem which implies that these services have to do "something fishy" on the signaling server. Generally, WebRTC traffic does not need to go through a centralized sever, though. It's peer-to-peer after signaling if possible, and if not it can use routing servers that merely route encrypted traffic. So I am wondering if these providers largely make use of standard WebRTC infrastructure plus gateways and how much proprietary magic they have on top/as an alternative. Of course, in no scenario the traffic is really secure.

https://webrtchacks.com/zoom-avoids-using-webrtc/

Reply on news.ycombinator.com