SoylentNews is people
SoylentNews
from the you-don't-get-what-you-don't-pay-for dept.
Zoom says free users won't get end-to-end encryption so FBI and police can access calls:
Video calling company Zoom confirmed this week that it won't enable end-to-end encryption for free calls in part because it wants to give law enforcement access to these calls if necessary. "We think this feature should be a part of our offering" for professional customers, said Zoom CEO Eric Yuan in a meeting with investors Tuesday. "Free users — for sure we don't want to give [them] that, because we also want to work together with the FBI, with local law enforcement, in case some people use Zoom for a bad purpose."
Encryption is a key issue for Zoom, which has been attempting to beef up its privacy and security after heavy usage exposed weak points during the COVID-19 pandemic. Reuters reported last week that the company will only roll out high-security end-to-end encryption to paying customers, potentially with exceptions for dissident groups or nonprofits that require the added security.
Additional Coverage At:
Zoom Restricts End-to-End Encryption to Paid Users
Zoom's End-to-End Encryption Will Be for Paying Customers Only
Zoom says free users won't get end-to-end encryption so FBI and police can access calls
Zoom faces criticism for denying free users e2e encryption
(Score: 3, Insightful) by hendrikboom on Sunday June 07 2020, @06:56PM (4 children)
Given the way Zoom puts multiple video feeds together, presumably at the server, it's likely much more difficult to do true end-to-end encryption without greatly inflating bandwidth as you end up with separate video stream from each particiant currently on-screen.
Their compositing at the server will have to process decrypted streams.
Reserving true end-to-end encryption for paying customers is a no-brainer.
And users who can only afford free service are unlikely to have the kind of hardware or network connexions that can support those multiple video streams anyway.
I guess an option would be to support end-to-end encryption for those free users that request it, have all the compositing and video compression performed on the user's cell phone, and letting poor quality service drive them to abandon it.
-- hendrik
(Score: -1, Offtopic) by Anonymous Coward on Sunday June 07 2020, @07:30PM
I'm so angry right now! As an American, i insist that words be spelled the *American* way. That means it's 'connection', not 'connexion'.
Now that I've replaced my keyboard (after smashing the old one in frustration at your hateful and inflammatory behaviour), I'll continue.
Because things must be done the proper way, and never for the first time [youtube.com]. Except for the American spelling.
So do us all a favour and endeavour to get it right!
(Score: 1, Informative) by Anonymous Coward on Sunday June 07 2020, @10:58PM (2 children)
Its not as hard as you think and there are already implementations, the biggest and (somewhat) browser compatible being Jitsi. Most implementations use a modified form of DTLS-SRTP. If you don't want to use un-bridged P2P, then you can just use a group key or session key setup. The biggest hurdle is that people want software that will also work in their browser.
(Score: 2) by hendrikboom on Tuesday June 09 2020, @05:25PM (1 child)
For the community view, that shows all the participants tiled on one screen -- that has to be composited somewhere. I see no way of doing this encrypted. If it's done on the server it would have to be decrypted on the server and encrypted after compositing. If done on the client it need not be decrypted on the server, but the client would have to accept a separate video stream from each client. That's where the extra bandwidth comes in.
-- hendrik
(Score: 0) by Anonymous Coward on Tuesday June 09 2020, @09:00PM
I don't see the problem, just compost them on the client. That is what they do unencrypted and hop-encrypted as well. The bridge doesn't mux each feed together for each participant while transcoding resolution. Your bridge CPU requirements would be orders of magnitude higher to even think of that and paying for it would cut into your profits. All the bridge needs to do is SRTCP the maximum allowed media settings (or start dropping packets) and proxy the connections.