Probably performance. Transcoding video is slow enough without having to deal with the WASM overhead. Plus, browsers don’t do low level network access, so if they’re working on the tcp/udp layer they’d need to wrap the entire thing in WebRTC or websockets or something.
Doesn’t discord support video calls in the browser? Surely it cant be the e2e being the problem here? I didn’t know about the WASM overhead, I always thought of it as near native but I guess that’s not the case then? Websockets should work fine though right?
Discord uses unencrypted WebRTC, yes. I don’t know what WhatsApp uses, but the connection is encrypted.
WASM can’t talk to hardware encoders present on your CPU/GPU so performance will be severely impacted. It’s also plain slower than native code (2½-6 times depending on the kind of code).
Using websockets, or TCP in general, is terrible for live audio and video. Normal (video) calling protocols are designed so you can lose several packets and still continue talking with minimal disruption. Transmitting that through websockets will have minor traffic disruptions become major slowdowns. You also can’t do peer to peer in websockets like you can with WebRTC or native protocols.
Based on this blog post, WhatsApp seems to use SRTP to wrap RTP, combined with XMPP and Noise for metadata exchange. I suppose WhatsApp could wrap all that in WebRTC, but I don’t see the business advantage in revamping their entire protocol just so the dozens of “I hate Facebook” customers can call on their Linux machines. Especially as you need to run WhatsApp on an Android/Apple phone/tablet to have an account anyway.
You raise valid points and thank you for the detailed answer. It’s a shame wasm isn’t hardware accelerated, is that because of security or is it simply not implemented yet? (i can google this but I’m just wondering.) I agree that being able to call on a web browser is perhaps less necessary because of the phone having to be linked anyway, but it still would be nice to have :)
WASM is designed to be hardware independent. It’s basically Java but without all the direct access to hardware, and in a slightly weird format. Recent improvements to the standard have added vectorization support which should improve performance, but there’s still no way to access any hardware encoder/decoder. All of those fancy direct access features are exactly why running Java applets used to be such a massive security risk and part of the reason why support for it got purged from anywhere but Internet Explorer.
I believe Google Meet does video processing in the frontend for blur effects and such, and it’s one of the reasons you NEED Chrome to use it properly (its WASM is clearly optimized for Chrome) and why your laptop will heat up if you enable the blur effect. Though, I think they use a native extension to do it these days. And that’s just 720p video, I can’t imagine sending any quality streams through the browser like that.
It’s not technically impossible to do secure video calls from the browser, it’s just not possible with the protocols WhatsApp has set up right now.
For instance, Element has encrypted video calling in their web client, partially because they designed their video calling protocol around web technology.
WhatsApp could implement browser calling, but I don’t see why they’d invest the time and effort.
I’m a noob but how unencrypted are we talking about here? Can someone do a packet capture and reconstruct the video? Or like unencrypted at the machine level and other processes can see.
It’s encrypted between the client and Discord, but not end-to-end encrypted like WhatsApp supposedly is. That means Discord can listen in on any calls, but WhatsApp shouldn’t be able to.
Both are closed source so it’s hard to say how secure both ends are, but at least theoretically WhatsApp is more secure.
Well they probably could get it to work in the browser it’s just that they didn’t. I wonder why?!
Probably performance. Transcoding video is slow enough without having to deal with the WASM overhead. Plus, browsers don’t do low level network access, so if they’re working on the tcp/udp layer they’d need to wrap the entire thing in WebRTC or websockets or something.
Doesn’t discord support video calls in the browser? Surely it cant be the e2e being the problem here? I didn’t know about the WASM overhead, I always thought of it as near native but I guess that’s not the case then? Websockets should work fine though right?
Discord uses unencrypted WebRTC, yes. I don’t know what WhatsApp uses, but the connection is encrypted.
WASM can’t talk to hardware encoders present on your CPU/GPU so performance will be severely impacted. It’s also plain slower than native code (2½-6 times depending on the kind of code).
Using websockets, or TCP in general, is terrible for live audio and video. Normal (video) calling protocols are designed so you can lose several packets and still continue talking with minimal disruption. Transmitting that through websockets will have minor traffic disruptions become major slowdowns. You also can’t do peer to peer in websockets like you can with WebRTC or native protocols.
Based on this blog post, WhatsApp seems to use SRTP to wrap RTP, combined with XMPP and Noise for metadata exchange. I suppose WhatsApp could wrap all that in WebRTC, but I don’t see the business advantage in revamping their entire protocol just so the dozens of “I hate Facebook” customers can call on their Linux machines. Especially as you need to run WhatsApp on an Android/Apple phone/tablet to have an account anyway.
You raise valid points and thank you for the detailed answer. It’s a shame wasm isn’t hardware accelerated, is that because of security or is it simply not implemented yet? (i can google this but I’m just wondering.) I agree that being able to call on a web browser is perhaps less necessary because of the phone having to be linked anyway, but it still would be nice to have :)
WASM is designed to be hardware independent. It’s basically Java but without all the direct access to hardware, and in a slightly weird format. Recent improvements to the standard have added vectorization support which should improve performance, but there’s still no way to access any hardware encoder/decoder. All of those fancy direct access features are exactly why running Java applets used to be such a massive security risk and part of the reason why support for it got purged from anywhere but Internet Explorer.
I believe Google Meet does video processing in the frontend for blur effects and such, and it’s one of the reasons you NEED Chrome to use it properly (its WASM is clearly optimized for Chrome) and why your laptop will heat up if you enable the blur effect. Though, I think they use a native extension to do it these days. And that’s just 720p video, I can’t imagine sending any quality streams through the browser like that.
It’s not technically impossible to do secure video calls from the browser, it’s just not possible with the protocols WhatsApp has set up right now. For instance, Element has encrypted video calling in their web client, partially because they designed their video calling protocol around web technology.
WhatsApp could implement browser calling, but I don’t see why they’d invest the time and effort.
I’m a noob but how unencrypted are we talking about here? Can someone do a packet capture and reconstruct the video? Or like unencrypted at the machine level and other processes can see.
It’s encrypted between the client and Discord, but not end-to-end encrypted like WhatsApp supposedly is. That means Discord can listen in on any calls, but WhatsApp shouldn’t be able to.
Both are closed source so it’s hard to say how secure both ends are, but at least theoretically WhatsApp is more secure.
Ahh, no E2E encryption. Got it.