If I remember correctly, zoom used to have on the front page - use this it's encrypted, and 'even used by us govt something-something' - so I assumed it was completely secure.
I actually refused to use other conference services much to the bemoans of many clients who already had other 'goto' software installed, used and understood - and convinced them that in order to talk turkey we needed to use the real secure zoom system.
It passed the smell test at the time for me because they also had paid plans which meant to me a legitimate business that did not need to slay privacy with ads and such, as they had a clear path to make money.
Now they are tarnished, and my reputation with several clients and doctors and others may be as well - as this is getting mainstream press (I think that's a good thing actually) - I'm livid about this.
I agree with below it is also fraud - and another commentator mentioned they changed to "your client connection is encrypted" is still deception imho. Needs a big asterisk and real explanation of the lack of privacy.
I know it's the kind of thing that can randomly keep a person up at night, but I think you can probably safely forget about this awkwardness and move on.
People in Tennessee watching regular news on free over the air antenna (non-cable news) -> https://www.wsmv.com/news/security-experts-warn-about-zoom-h...
any anyone who is within earshot of such 'non-tech news' is hearing how unsecure zoom is.
Sure most of my clients are unlikely to read HN at all, and most are unlikely to read tech crunch regularly if at all - but I bet some have TC or something similar in their fbook feed.
People watching TV news in Utah see: https://fox17.com/news/nation-world/zoom-call-with-utah-elem...
However people who don't even own computers are seeing this debacle.
So, anyone I've advised to use zoom for privacy and security, citing the encryption and use by US gov - is going to have to wonder - how do these things happen on a secure, private, encrypted system - must not be what it was purported to be by that guy Steve. Then they are going to wonder what kind of damage could be done with the info that was 'securely' shared with the service.
where's the hassle? or the lack of shine? it works better than any other proprietary service
1) I don't want to train them on it
2) I don't want to support them on it
3) It isn't good enough for them to use without 1-2
So I pick the shiny costly commercial version that comes with training and support.
I mean, I've done the recommend my parents and older coworkers use difficult OSS software thing in my past, and I honestly regret it. No one won.
insert Hanlons razor quote here
But just because someone uses a word wrong doesn't give you any proof about their intentions. See https://news.ycombinator.com/item?id=22767447 for further elaboration on that point.
Again, it's harmful to use words incorrectly, _especially_ when it comes to E2E, so they should rightly get flak for getting it wrong. You all seem to be so sure that it was intentional though, while I've seen the same problem so many times before in the industry without it being intentional. If you do have proof it's intentional, please share it with the rest of us so we can be on the same page.
Being incompetent has nothing to do with the size or prominence of the company. Big/prominent companies fuck up/are sloppy all the time.
Their intention was to deceive users that the communication was encrypted, when in reality it wasn't.
I'm in no way saying it's impossible that Zoom did say E2E encryption while knowing that's not true, but I could imagine a scenario where a security person says "Yeah, we're encrypting connections to our backend" and a marketing person researching E2E and then saying to themselves "Yeah, sounds like we're doing E2E, let's write that", because this stuff happens all the time in the industry.
> Their intention was to deceive users
You sound so sure about their intentions, do you have any actual proof of this that others are missing? Again, I'm not saying it's impossible that their intention was to deceive users, but as an engineer, I always favor proof over guessing.
It's natural that there is a divide and marketing isn't expected to understand every engineering thing (nor the other way around.) If your job is to write words, though, you are responsible for the words you right.
Wait, did you do that on purpose? :)
> 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.
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.
On a more serious note, you would need to trust not one ISP if the video wasn't encrypted, but all the ISPs in the room simultaneously, and that is probably something even less trustworthy than Facebook.
FaceTime chats, though, truly are end-to-end encrypted and the calls aren't backed up like iMessages are.
They merely mention that backups to iCloud happen automatically by default, and not that doing so means the default is that Apple can view and decrypt all your messages.
Two options impact it: "Messages in iCloud" re-encrypts and uploads messages to the user's iCloud account and stores the key in iCloud Keychain (also end-to-end encrypted).
Only when enabling iCloud backup will that key be revealed to Apple.
iMessage doesn't store your decryption keys on Apple's servers unless you opt into iCloud backup which is a whole different service and security concern.
> Apple does not have the ability to read your messages.
iCloud backup is an Apple service and it has the ability to read most of your messages even if you don't use it, which makes this statement categorically false.
That I may have given Apple my private key through a different message in no way affects that end-to-end encryption, because it is trivial to decide not to give Apple that key.
You can decide not to give your keys to Apple, but you can't decide for all your friends to not give their keys to Apple, and the result is the same: Apple can read your messages.
And the marketing is so misleading that hardly anyone knows that Apple can read most iMessages.
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.
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.
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
What we know is that they can and do decrypt iMessages from iCloud backups in response to law enforcement requests[1]. This proves that they hold the keys, if their own support pages weren't enough evidence for you.
[1] https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
> > iCloud isn't some separate entity from iMessage. It's all Apple.
> Got any sources for that? Sounds a lot like FUD.
You don't use a password to encrypt your iCloud backups... They're specific to the hardware your backing up. If you have an itouch for example it's backups are separate from your phone.
So now you have these backups in the cloud and you lose your iPhone, you remote wipe it.
Now your new one arrives and you restore from backup... Your iMessage private keys are available to apple unencrypted .... Because you didn't need to provide a second factor of authentication for unlocking the backup you were just asked which one to use.
Apple and any reputable nation-state can read your iMessages with a subpoena ... If you use iCloud backups and not local backups with a password.
I wish this meme of trying to sound fancy by misusing the term "nation-state" would die.
2) What about your iCloud account and password that are required to encrypt, store, access, and decrypt the backups there? Is that not a factor worth consideration?
This is why WhatsApp for example notifies users when the key of the recipient changes, and they give you a way of verifying that the both keys at both ends are identical.
https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
https://threatpost.com/apple-imessage-open-to-man-in-the-mid...
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
Ultimately, it's false to equate iMessage's encryption scheme, which is end-to-end, to an encryption scheme that requires a server to relay decrypted data.
Utterly false. Real end-to-end encryption would encrypt the backup with a key that is not available to the backup service (e.g. derived from a passphrase not sent to the server).
Of course this system has better usability, which is why Apple does it. But it's still a farce to call a system where Apple has the ability to decrypt the majority of messages "end-to-end" encrypted. The fact that it's through the backup servers instead of the iMessage servers makes no difference.
What's more, it's possible to do better without sacrificing usability. For several years Android has been end-to-end encrypting backups using the user's lock screen passcode, with protection against brute force attacks provided by hardware secure elements. https://security.googleblog.com/2018/10/google-and-android-h...
It makes a big difference. If I print out the texts I receive, it doesn't change whether the texting program is end-to-end encrypted. The same goes for backups. An unencrypted system-level backup doesn't mean that the program being backed up is failing at security.
It's bad that Apple doesn't let you encrypt your backups properly, but it's a separate issue.
> An unencrypted system-level backup doesn't mean that the program being backed up is failing at security.
iOS programs can choose how their data is backed up. iMessage isn't just getting its data stolen by iCloud accidentally. These backups are a feature of iMessage as much as iCloud. And besides, iCloud is made by the same company, it's not a separate entity.
> iOS programs choose how their data is backed up.
Well desktop apps don't. Would you say that no desktop app that saves its key can ever qualify as end-to-end encrypted?
> And besides, iCloud is made by the same company, it's not a separate entity.
I'm not convinced that's relevant to whether the encryption is end-to-end or not.
I would say that no app can qualify as end-to-end encrypted if a large fraction of users send their data to the maker of the app in a form that can be decrypted by the maker of the app, regardless of the reason.
Have you considered that some people trust Apple but don't trust Zoom? At some point you have to trust somebody, right?
> At some point you have to trust somebody, right?
It's possible to use an actual end to end encrypted app that doesn't have the keys to read your messages stored on their servers.