Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Maybe covid-19 will get them actually grok e2e encryption


e2e encryption for multi-party videoconferencing that works well enough to use for something like this is basically an unsolved problem at this point.


Was it not solved in FaceTime group chats? I can’t see the Apple Security Guide right now, but I know they claim that FaceTime 1-to-1 is e2e, and with their whole marketing thing being privacy, I bet they did it for group conversations too (not that it’s Enterprise ready since there’s no user management or SSO or whatever).

I’ve noticed over the years that FaceTime is much more likely than other video chat software to drop the video connection and move to audio only in case the connection is unstable whereas most others will hitch and lag for 30 seconds before looking into it, so maybe they got around it by only shipping the video in one or two resolutions?


Yeah, there seem to be multiple statements by Apple saying they can't access the content of FaceTime calls, without any qualification that it only applies to one-to-one calls. So it's probably a reasonable assumption that even the group ones are e2e encrypted.

How many participants can you have in a FaceTime group call?

I have also noticed that FaceTime drops the video much more often that other software.


You can video call up to 31 people (32 if you include yourself).


How would it be any different from any other e2e group chat?


You have to send all available qualities of the stream yourself. Normally the server does the recompression for lower qualities. That means: more processing power and more bandwidth needed. Where normally you'd be able to send 720p, now your device may not be able to handle doing both that and lower quality (2-3 streams) at the same time. This multiplies again with screen sharing.

Basically it's doable, but if you can prevent people complaining about the fans taking off and the CPU usage... why would you risk it?


H.264 has a spec for 'scalable video coding' [1] where one stream can contain multiple quality levels, allowing a video's quality to be reduced by just selectively dropping packets.

(No idea how widespread encoder/decoder support is compared to vanilla h264 though)

[1] https://en.wikipedia.org/wiki/Scalable_Video_Coding


That's pretty cool. I wonder how well does it work with bidirectional communication. It sounds like for just sending/receiving where you can saturate the link, that would be awesome.


Wow, that is awesome. I know what I'll be spending some coronatime doing!


Ugh. Multiple compression streams? Why? 720p would be too much IMHO.


>Multiple compression streams? Why?

Zoom automatically switches between quality levels based on your connection speed, who's talking and the size of the viewport. 720p would look fairly rough when fullscreened on most non-mobile displays, but it's orders of magnitude more than necessary when viewed as a thumbnail on a mobile device. Making multi-user video work in a mostly seamless fashion is a surprisingly hard problem.

Using a single stream would substantially degrade the experience, which may be a worthwhile tradeoff for high-security environments but certainly wouldn't be a worthwhile tradeoff for most users.


It's not just about the resolution, but also the bitrate and fps. Perceived video quality is a big deal to companies like Zoom. I don't blame them for not using E2E, it's a tough technical issue, but I do blame them for lying about it.


720p is the standard laptop camera these days. You notice if anyone streams less. Next, desktop sharing is going to be at least 1080p. Then you need to have lower resolutions for anyone who can't handle that much on their connection. Same for desktop share.


> 720p would be too much IMHO.

I may be spoiled with a good real 50/10 Mbit connection but for me in 2020 720p is the bare minimum. Expecially when screen sharing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: