Live data from Hacker News

SpaceX bans Zoom over privacy concerns

reuters.com

271–280 of 301 posts

Re: SpaceX bans Zoom over privacy concerns

#271

Earlier quoted context omitted.

On GCBD's servers in China. Possibly on Apple's servers in the US if they are running a wiretap. Due to the way key distribution works for iMessage, it is trivial for Apple and GCBD to do so. https://news.ycombinator.com/item?id=22755903

Your message, through several layers of indirection, relies on a security conference paper from 7 years ago[0] + the assumption that Apple haven't updated the protocol in 7 those years. [0] https://blog.quarkslab.com/imessage-privacy.html

No, my message relies on the fact that people have been looking at iMessage for years, and nobody, least of all Apple, has said that the implementation changed in any way to prevent Apple from viewing the messages.

Here is another article from 2016, which shows that Apple patched iMessage to prevent attackers who don't have access to Apple's servers from reading the messages but still kept the ability to read the messages themselves. https://blog.cryptographyengineering.com/category/imessage/

Apple was aware that people knew it could decrypt iMessage messages this entire time, but Apple made no changes that would fix that. That should give you some idea of whether Apple intends to ever fix that.

Re: SpaceX bans Zoom over privacy concerns

#272
post #236

Earlier quoted context omitted.

A company this prominent is unlikely to be that incompetent. Malice is more probable at this point, Hanlon's razor notwithstanding.

Eh, haven't large companies leaked private details from their customers time and time again, in basic ways like forgetting that they have backups on S3 buckets with zero protection? Being incompetent has nothing to do with the size or prominence of the company. Big/prominent companies fuck up/are sloppy all the time.

This is not a fuck up or negligence, Zoom deliberately used "end-to-end" with a completely different meaning than the rest of the world. I can't describe this as anything else than malicious and fraudulent.

Their intention was to deceive users that the communication was encrypted, when in reality it wasn't.

Re: SpaceX bans Zoom over privacy concerns

#273
post #4

The fact that they show end users (no pun intended) an "end-to-end encrypted" badge on the meeting window itself, and elsewhere explain how a Zoom server (not Zoom client) is what constitutes an "end" despite the whole rest of the electronic communication industry using "end-to-end" to refer exclusively to user agents, is bonkers.

If one is to believe their blog post (https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-...), then they do in fact use end-to-end encryption:

> To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients.

The first problem is:

> Zoom currently maintains the key management system for these systems in the cloud.

Obviously, this compromises many of the benefits of e2e encryption. Having said that, it doesn't remove all of the benefits, and it's a (bad) precedent that has been set by other companies (eg. apple) where keys for end-to-end encrypted communication are backed up to the cloud.

The second problem is that Zoom has a second class of "client" called a "Connector" which runs in the cloud, and also has access to the keys for decrypting the stream. I definitely think that when one of these connectors is being used, it is false advertising to show the "e2e encrypted" status. However, there are clear technical reasons why these connectors are needed. Being able to dial into a meeting from an ordinary phone is important functionality that simply cannot support end-to-end encryption.

The interesting section to me is the later paragraph:

> For those who want additional control of their keys, an on-premise solution exists today for the entire meeting infrastructure, and a solution will be available later this year to allow organizations to leverage Zoom’s cloud infrastructure but host the key management system within their environment. Additionally, enterprise customers have the option to run certain versions of our connectors within their own data centers if they would like to manage the decryption and translation process themselves.

In particular, being able to use your own key management system would make this truly end-to-end encrypted by any definition, even if you are still using Zoom's cloud infrastructure.

Re: SpaceX bans Zoom over privacy concerns

#274

Good, the less we use Zoom the better. Even facebook Messenger is more secure.

Would you suggest organisational video conference meetings of e.g. 25-100 people over Messenger...? There is a niche Zoom is occupying very well.

It's more of a "trusting" facebook transparency vs if Messenger has the same solution that Zoom fits in.

Meanwhile, it's 2020. Didn't think video conferencing was such a big deal.

Re: SpaceX bans Zoom over privacy concerns

#275
post #4

The fact that they show end users (no pun intended) an "end-to-end encrypted" badge on the meeting window itself, and elsewhere explain how a Zoom server (not Zoom client) is what constitutes an "end" despite the whole rest of the electronic communication industry using "end-to-end" to refer exclusively to user agents, is bonkers.

If one is to believe their blog post ( https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-... ), then they do in fact use end-to-end encryption: > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the rec…

> other companies (eg. apple) where keys for end-to-end encrypted communication are backed up to the cloud

Backed up for iCloud users who might not know any better, but not backed up for people who take the time to learn how to guarantee the full protection of E2E by keeping iCloud off. The fact that the full benefit is available with little effort, albeit not obvious, creates a contrast to how:

> Zoom has never built a mechanism to decrypt live meetings for lawful intercept purposes

...but they easily could. Users can't just search for how to harden the Zoom encryption to the point of lawful intercept becoming impossible and find a simple solution the way they can with Apple.

> an on-premise solution exists today for the entire meeting infrastructure

...is not practical for most.

So, eliminating the E2E badge was the right move. The fact that it was there until now is shady.

Re: SpaceX bans Zoom over privacy concerns

#276
post #251

Earlier quoted context omitted.

It's entirely possible to do multi-device end-to-end encryption. See Signal or XMPP+OMEMO.

Isn't that just for text? I know Signal uses WebRTC for Audio & Video and doesn't yet support group chats, (unless something changed recently)?

Yeah, the parent conversation was about whether iMessage is end-to-end encrypted. GP claimed that it cannot be due to it supporting multi-device sync, which is not true.

Re: SpaceX bans Zoom over privacy concerns

#277
post #4

The fact that they show end users (no pun intended) an "end-to-end encrypted" badge on the meeting window itself, and elsewhere explain how a Zoom server (not Zoom client) is what constitutes an "end" despite the whole rest of the electronic communication industry using "end-to-end" to refer exclusively to user agents, is bonkers.

If one is to believe their blog post ( https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-... ), then they do in fact use end-to-end encryption: > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the rec…

It's not encrypted "end-to-end" if it can be decrypted between those two ends.

Re: SpaceX bans Zoom over privacy concerns

#278

Earlier quoted context omitted.

On GCBD's servers in China. Possibly on Apple's servers in the US if they are running a wiretap. Due to the way key distribution works for iMessage, it is trivial for Apple and GCBD to do so. https://news.ycombinator.com/item?id=22755903

Apple can, of course, do whatever it likes, up to simply recording the screen and sending that to weird & wonderful government agencies. Like almost everything in mainstream security, it comes down to who you trust. It doesn't mean it isn't E2E though.

> It doesn't mean it isn't E2E though.

E2E encryption simply means that messages are only decrypted at the endpoints. That certainly isn't true of iMessage in China, and it might not even be true for some users in the US — we have no way of knowing because the protocol makes no guarantee against it.

Re: SpaceX bans Zoom over privacy concerns

#279

Earlier quoted context omitted.

Only recommend free software, this way you minimize reputation drama

Sadly, my experience has been the opposite, because open-source stuff usually takes more work to run and is seldom as polished, and users hate that. I rarely, if ever, recommend open-source anything for end-user use. Zoom did well because it had the least hassle of any solution, hands-down. I'm not saying it's impossible to subscribe to a hosted open-source service that's as good, but it doesn't exist yet.

https://meet.jit.si/roomname123

where's the hassle? or the lack of shine? it works better than any other proprietary service

Re: SpaceX bans Zoom over privacy concerns

#280
post #263

Earlier quoted context omitted.

The clients could control which video streams they want to subscribe to without the server decrypting them. If you want to support thumbnail/fullscreen versions of streams, the clients could just send along two streams or use a codec that supports this kind, like h.264 SVC.

Yes, with effective 2 streams per client, the client could tell the server to send max. 1 full resolution stream and any number of low res streams. If you want full encryption, they have to be send as separate streams from each client. Also, the encryption would need to be negotiated between each pair of participants separately, that is doable, but scales with the square of all participants. So yes, full end-to-end e…

Now we've moved into the territory of what's easier to implement, that's a different discussion and involves also the lack of implementation complexity at the server end.

There is no problem doing key exchanges between all the participants as long as the number of participants isn't too huge. Everyone just needs to kex with everyone else, so from the POV of a single participant the effort scales linearly with number of participants, even though the work collectively done by everyone is squared.

Post reply on HN