End-to-end encryption has been named as a required feature for telehealth in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks for obvious reasons. So I've been trying really hard to work out if Zoom is E2E, and reached the same conclusions as the article. First, it isn't, and second, Zoom are really going out of their way to obscure that fact.
It's great that The Intercept is taking a look at this, because it's absolutely beyond the capabilities of healthcare practitioners and the professional bodies to get to the bottom of. There's a ridiculous amount of confusion here, compounded by "you need to get the HIPAA version because HIPAA means privacy".
Just an FYI, two weeks ago, CMS announced it would be suspending enforcement of telehealth tools used in good faith during the COVID pandemic. [0]
Basically, if you are a family doc that's been thrown into the telehealth ringer, you can get started with everyday tools for video chat, like Facetime, Google Hangouts, Skype, etc - regardless of that tool's Hipaa compliance.
Overtime I do expect they'll want to see providers transition to compliant solutions, but they understand thousands of doctors, some of whom have never delivered telemedicine, can't simply audit and on-boarding a new provider overnight.
As a note, HIPAA does not require end-to-end encryption as long as you have a BAA with the provider. Zoom has an option for a BAA starting at $200/month.
edit: Server-client communication does need to be encrypted which zoom does.
The Security Rule and Transmission Control Standard mention encryption, but as Addressable, not Required, if memory serves. That means you have to do it if it's "reasonable and appropriate", and in this context they just mean transport encryption like TLS, not Signal-style actual E2E.
Not that you shouldn't, of course. And you better have an excuse for not doing it (e.g. we don't re-encrypt after the load balancer terminates TLS is a common one). But doctor's offices fax stuff to each other all the time, and that certainly is not encrypted. Perhaps you're thinking of a HITRUST control?
It's a bit more nuanced. Hipaa (two a's) does not require the type end-to-end encryption that most devs come to think of.
Generally, Hipaa does require transport encryption from the client to the server processing the request. The importance here is SSL/TLS should be terminated at the app server.
A BAA is a Business Associate Agreement. It's a standard HIPAA document where an entity with PHI (typically a Covered Entity, which is an entity specifically mentioned by HIPAA, such as e.g. a healthcare facility) effectively puts a vendor on notice: we may stuff PHI in your service, you agree to abide by this set of rules and regulations. A big one is that the vendor agrees to disclose when they've been breached, and the timeline on which that happens.
Even though a lot of online sources suggest BAAs are only for Covered Entities, that's not strictly speaking true. The standard form document doesn't require the buyer to certify they're a CE. It makes tons of sense for vendors of CEs, themselves bound by BAAs, to bind _their_ vendors to BAAs! If there's a decent chance your customers put PHI in your service, there's a decent chance they put PHI in your support system, and they don't really care if your support system is something in-house or Zendesk when that happens. There's also a good chance that PHI might end up in your logging system, and from there in your Slack instance, and... before you know it everyone's signed a BAA with everyone.
The life-hack consequence for that is that you can just collect BAAs from anyone who will sign them and now you have disclosure timeline guarantees.
A contract which defined how protected health information will be dealt with by the provider and how HIPAA provisions will be followed (ie: provider will do X but you need to do Y to be compliant).
Hold on, E2E encryption is now required for telehealth in Australia, yet the Australian government passed laws that required LEO's to have access to E2E encrypted data [1]? How are tech companies supposed to comply with that?
This is a fairly small/simple example but a significant (yet hidden) portion of compliance is figuring out how best to "comply" with conflicting regulations. Everyone always complains about the operational cost of compliance but the expense that goes into making these decisions (risk assessment, lawyers, senior executive time, board meetings, etc.) is where compliance quickly gets very costly IMO.
A requirement for e2e is that the company doesn't hold the keys, otherwise it's just regular transport encryption + a promise that they'll never peak at the your data, even though they can. So yes, it's very much incompatible technically.
You just have two modes, one with e2e enabled and one not. e2e is enabled normally but when LE requests access, the user client receives a message telling it not to use e2e. That may not satisfy you as someone who wants secure encryption (and it probably shouldn't), but it is e2e when it's actually enabled.
Does it inform the user or otherwise stop functioning for telehealth once the signal is received? If not, then does that mean that someone is considered e2e encrypted if it in theory can support e2e encryption even if it isn't using it right now?
It looks like the situation has not been fully thought through and the government is creating a Kafka trap when its laws.
> does that mean that someone is considered e2e encrypted if it in theory can support e2e encryption even if it isn't using it right now?
No. My assumption is that certain communications are required to be end-to-end encrypted, unless the individual is under surveillance. All end-to-end encrypted communications providers are required to have a mechanism in place for disabling and MITMing e2e communications. It stops being e2e encrypted for the duration of that surveillance.
I suppose it's possible that a foolhardy government (I'm not Australian, so I can't say for sure what they've done) would word the laws in such a way that they can't technically be achieved, but there's no reason why they have to be. The laws aren't bad laws because they are logically impossible to fulfill (if they are), they're bad laws because they violate the individual's right to privacy.
Note that the law might also prohibit the government from surveilling communications between patients and licensed health professionals. In that case it would be quite possible to mandate no-exceptions e2e for those communications, and a mechanism for disabling e2e. e2e that is never disabled is always e2e.
The company doesn't have to keep the keys for everyone. They can switch you on request from E2E to central encryption for you account only. Without an opensource client and the possibility to verify the used keys, you wouldn't know that happened. And realistically, even with those options, almost nobody verifies the changed fingerprint.
That adds an even bigger layer of complexity for people to understand. The whole point of E2E was so that only the two ends could decrypt the data being transferred. If we now add "except if government agency requests it" then we're hijacking the term and making it no more meaningful that saying "yeah our app has encryption".
I'm not trying to hijack the term. Once LEO puts in the request the system stops being E2E - that's true. It would be good if this wasn't possible, but for that we need the whole stack of: open protocol, opensource implementation, signed verified release, and people keen to verify fingerprints. And if we're pedantic, also a verifiable execution environment.
The law actually requires the companies MITM the video to give them access. It doesn't place any requirement on the end user.
So use a solution that doesn't put a company in the middle. Use open source, E2E encrypt with keys secured by the user and not central server and you are good. One solution available now - Signal.
Despite the heat being laid on Zoom, they have no choice. Any platform that does mixing to produce a composite image with Picture in Picture like Zoom does has no choice. That includes Hangouts, Skype and so on. They do it to save bandwidth - something I've been grateful for.
Probably the simplest way would be for the clients to chose a key for E2E encryption, and then to encrypt a copy of that key with some government public key, and save that encrypted copy of the E2E key somewhere that the government can get to when the law requires that they be able to access the plaintext of the encrypted communications.
This lets the tech company comply with the law, without the tech company itself gaining access to the plaintext.
> The server is one of the "ends" in "end to end".
Not in the phrase "end to end encryption", which is specifically used to refer to schemes and services where the service provider does not have the ability to access the communications (a-la Signal).
If that wasn't the case then any site with TLS would be called "end to end encryption".
> The law didn't contemplate that you would use a service but not want that service to access your data.
This law in particular does. The only restriction (relevant here) is that TCNs must not result in the creation of a "systemic vulnerability". The meaning of this term is not outlined in the legislation -- my understanding is that it is meant to mean something like "backdooring OpenSSL and thus making most of the internet insecure" rather than "backdooring all communications using a particular service provider". If that understanding is accurate, then it's a meaningless restriction.
Same in the EU: service providers that provide services that allow people to share content must install content filters that screen for illegal (read: copyrighted by large corps) content.
You can't operate an E2E encrypted communication service in Europe without breaking the law.
caveat: I'm not sure whether this has actually been adopted/ratified by either the EU or member states yet.
First of all, there are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption doesn't cause any problem at all.
For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU) and the sending clients send multiple resolutions (either independent, called "Simulcast" or dependent, called "SVC"). In that case, the adaptation is done by the server in selecting which resolution to forward at any given time. This is fairly common practice in the industry. For example: https://github.com/jitsi/jitsi-videobridge and https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and https://www.w3.org/TR/webrtc-svc/.
For those types of group calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en
(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).
That would seem to require significantly more upload bandwidth & compression capacity from clients, which is often not broadly available to consumers. I guess you could drop down to the lowest resolution only when sending to the service if you have a bandwidth challenge, but that seems less than ideal.
Lots of video conferencing systems already work this way (the SFU way). Compared to just sending the full resolution all the time, adding the smaller resolutions doesn't add that much bandwidth and compression because they are so much smaller.
Actually I'm calling BS on this. Zoom is literally adjusting frame rates at the single frame per second level. There is definitely upload pressure. SFU isn't going to be enough.
I used to work in video and if I remember correctly there were I, P and B frames. You need I and P but the B frames are optional. So if some meta data is unencrypted the server can tell which packets are B frames and decide not to send them to slow clients. The actual data is still encrypted.
I'd probably have each client encode one high quality stream that's targeted to be accessible to 90+% of clients, and a very low quality stream that's 5% of the bitrate of the high quality one. Low encoding complexity and adds a negligible amount to your upload bandwidth requirements. (Obviously if a client can't meet the upload quota for the highest quality, you max out at whatever they can do.)
Note: what follows is probably not how anyone actually does it. It is just an illustration that adaptive video is not incompatible with E2E encryption.
Suppose you have a block of 4 pixels, represented by 4 24-bit values. Instead of sending the 4 pixel values, send one 24-bit value that is the average of all 4 pixel values, and then the actual 24-bit values for 3 of the 4 pixels. The receiver can figure out the 4th pixel from those 3 and the average.
Send the average values and the groups of 3 discrete pixel values in logically separate streams, separately encrypted.
If something transporting this needs to lower the bandwidth, it can just drop the E2E discrete pixel stream, leaving just the E2E average stream. The receiver can then use that average value for all 4 pixels, in effect getting a video that is 1/2 the resolution both horizontally and vertically.
This scheme only gives you two rates: Full resolution and 1/2 x 1/2. No doubt you could do systems based on block sizes other than 2x2, and with multiple levels of averaging, that would give a wider range of fall backs.
Actual state of the art video encoding is, I believe, based on things like the discrete cosine transform, which represents an image as a sum of cosines of various various frequencies.
In this kind of representation the higher frequencies correspond to higher resolution detail in the image. I'd expect that you could do an E2E transmission scheme were you have different encrypted streams for different frequency ranges. Like with my far less sophisticated or clever 2x2 averaging scheme above, you could simply drop the streams for higher frequencies and the receiver would be able to reconstruct a lower resolution image, but unlike my 2x2 averaging scheme this would have much finer drops in resolution.
> Suppose you have a block of 4 pixels, represented by 4 24-bit values. Instead of sending the 4 pixel values, send one 24-bit value that is the average of all 4 pixel values, and then the actual 24-bit values for 3 of the 4 pixels.
So you still send 4*24 bits? what's the point?
> If something transporting this needs to lower the bandwidth, it can just drop the E2E discrete pixel stream, leaving just the E2E average stream. The receiver can then use that average value for all 4 pixels, in effect getting a video that is 1/2 the resolution both horizontally and vertically.
But you need knowledge of this protocol, so the sender is the only one able to do this. In that case just encode the downsampled resolution and send that, no tricks needed.
The way these video meeting services work is the participants all connect to the service's servers. Each participant sends their video feed to the server, which sends it on to the other participants in the meeting.
It's that server that wants to be able to dynamically downgrade outgoing feeds based on the bandwidth between it and the meeting participants, which can vary from participant to participant.
Alice, for example, might be on a symmetric gig fiber connection with consistent and low latency. Her client can send a high resolution feed to the server. Bob might have no trouble with receiving that, but Carol might be on slower, less stable connection, and need a lower resolution version.
If you aren't trying to do E2E encryption, you can handle this by having the server deal with taking the high resolution feed from Alice and generating a low resolution feed and then sending the other participants whichever is the best version they can handle. That works because without E2E encryption the server actually has access to the video, so it can do things like resample and re-encode.
If you are using E2E though then the only parties that should have access to the video itself are the meeting participants. The server should not have access to the video except in encrypted form.
The problem then is how to encode and encrypt a video stream in such a way that a server that is copying that stream between a sender and one or more recipients can alter a copy of the stream in such a way as to reduce the resolution even though it does not have access to unencrypted video?
The key point is that a video consult with a doctor is now (as of last week) available to most of the population, including those in the city, and can be claimed on Medicare. That’s a huge change from previously where it only applied in specific scenarios.
I’m sure the RFDS did some video/phone consults but their patients are literally remote - some hundreds of kilometres from the next property.
I'm not sure that you can really say "a system that tosses privacy out the door". There's lots of privacy protections in place. Sure, it requires trustworthy providers, but that's largely true of a non-open source E2E solution as well.
End-to-end encryption is hard to implement, might cost more processing or bandwidth or storage (depending on the product) and does not yield benefits for companies interested in processing user data.
If it's not clearly advertised on the front page, _emphasized_ and not a foot note, then it's NOT e2e encrypted.
There are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption incurs negligible processing and bandwidth. Do you worry about the processing and bandwidth increase when using HTTPS/SSL? Probably not. Same goes for 1:1 calls.
For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU). One benefit of SFUs is that they take much less processing for the server than the other kinds (where the video is re-encoded by the server). For those types of group calls, e2e encryption can be implemented with negligible increases to processing and bandwidth.
However, you are correct that it is harder to implement correctly. And it does prevent certain features to be added to the product, such as recording and server-based processing of information (for example, meeting transcriptions).
(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).
Recording will work fine locally, no (albeit perhaps more fiddly)? It does push some things off the server obviously, but arguably none of those things should be happening on the server in a situation when E2E is mandated, anyway.
Yeah, I was just trying to point out that there is a feature vs. privacy/security tradeoff. Although I think e2e encryption is usually much more valuable.
Given that Signal doesn't have reproducible builds and may therefore have absolutely anything inside of it's distributed binaries, I'm not sure if this is meant to be a good or a bad example.
It's not clear from the context if you mean to say that's simple or hard with that link.
A OTP might be mathematically simple, but logistically it's very hard - you have to safely distribute the key and that key must be at least as long as the message you're passing.
For any health professionals out there looking for a good video solution tailored for doctors and psychologists; check out Confrere. It's a Norwegian company that has built it's service on top of the webRTC-protocol. I have helped several Norwegian doctors offices to get up and running the last few weeks, and they love it!
I don't know that Zoom is really going out of its way to obscure that it is not E2E. I never for a second thought they were doing E2E when I enabled the encryption. It was very clear from how the features was described that you got TLS to Zoom's servers, not E2E.
Right - if you have used signal - I have - zoom is obviously not that. The pain to do call mixing, call recording, join a call late and do playback, join a call at all - does E2E even work in telehealth? I do virtual visits in the US and it doesn't look at all E2E to me.
The telehealth platforms I see are terminating through the health provider itself. It does the call setup, conference setup if needed, waiting room for prior call to end, if you send a photo it can be saved to your record etc.
If this is e2e to the physicians home, how does the telehealth system do all these add in functions?
At least in the US, the requirement have been understand to use secure transport everywhere. Folks keep on saying HIPPA requires e2e but I've literally not seen anything that looks like that out there in the actual market for this - the enterprise paying the big bucks usually wants features that are incompatible with e2e as far as I can tell.
I didn't investigate this requirement, but it's probably insufficiently thought out. Presumably you need E2E encryption so that the SP can't intercept (either willfully, compelled, or as a result of compromise) en masse. If that's the case, then you also need to have a way to verify keys of both parties, and you need a way to do that for group communications.
This is hard.
So even if Zoom is E2E, this is checkbox compliance. (if my assumptions are correct for the reasons behind it)
How is a doctor supposed to do a video consultation if the blotches on your bum, purely for example, are all blurry because the definition is less than HD?
You get most of the consultation with history, described symptoms, etc. handled over telehealth and a quick follow-up in person if you require a physical examination. The process has to cover people who call from a landline as well.
Actually zoom despite its privacy concerns is on the whitelist for telemedical application by the insurers in Germany, so I think they understand how to play the game...
It's not (see the list in the sibling comment). To get certified you need to transport the video/audio stream peer-to-peer between the clients only and end-to-end encrypted, see § 5 of the agreement https://www.kbv.de/media/sp/Anlage_31b_Videosprechstunde.pdf The regulatory bodies took some time to understand the issues and this is why it took so long until it arrived at all.
Private consultations not billed through public insurance is not quite as regulated though.
Thanks for pointing out. I thought the false claim of E2EE was exactly the reason. I got the false (?) info from my neighbor working for a large AT provider. They are making money exactly with such regulational requirements, so I am really puzzled on the actual state of affairs.
Hipaa has additional restriction/controls for psychotherapy notes as they are considered highly sensitive. I'd expect this is the same line of thinking in Germany.
Discussing your heart disease or skin condition is sensitive, but it's not as sensitive as discussing deeply personal thoughts or inner monologues.
Now I know why it was the only video conferencing service that worked in Dubai. Others, like meet, WhatsApp - video are not working for censorship reasons.
I'm pretty sure that Google Meet isn't end-to-end encrypted either. Nothing that Google does is.
WhatsApp does claim that videos are end-to-end encrypted as well, although given Facebook announced they'll implement client-side agents for processing user data and given its proprietary nature, I avoid WhatsApp for anything very sensitive as well.
Google provides close captioning for meet calls. That means it's not E2E. Also pretty much no service can provide multi-party video call with adaptive quality without completely destroying your bandwidth.
I'm interested in knowing more about why closed captions would imply not end-to-end encrypted. Wouldn't it be possible to build a model and distribute the model with the client-side application, and run it at the edge?
"“The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia,” said Turnbull.
Turnbull’s comments came as he proposed a new law to force tech companies to give security services access to encrypted messages."
"The UK home secretary Amber Rudd has previously called encryption “completely unacceptable” and the UK prime minister Theresa May has said that the big internet companies give terrorists “safe spaces” to communicate."
> The UK home secretary Amber Rudd has previously called encryption "completely unacceptable" ... Theresa May has said that the big internet companies give terrorists "safe spaces" to communicate.
Ironically, the UK government in fact uses Zoom for all its meetings depsite privacy and security implications. Saudi Arabia, take note.
It doesn't matter where they're based. What matters is that Zoom isn't safe by any measure and tells you about that if you spend a little time reading critically.
It’s certainly no less safe than the backdoored-for-decades phone/fax networks used by medical professionals to discuss medical secrets with patients and send prescriptions to pharmacies. It’d be nice if it was more safe, but it’s hard to sink lower than a telco line.
You can send faxes to someone without the telco running a local webserver on your fax machine, and you don't run thousands of other applications on your fax machine, and your fax machine doesn't usually come with a nifty record feature, nor a camera and a microphone.
I hesitate to point this out, but quite a lot of fax machines come with a microphone.
(And, noting the prevalence of articles from a few years ago talking about "update your fax machine firmware", I suspect you could fuzz their telco line-parser for very interesting results!)
Good point--you're talking about the embedded handset or something else? That said, as you hint at: not quite the same thing from a threat model perspective :)
If they're based in Australia they can be legally coerced into installing any code the Australian government feels like telling them to insert. So I'm not sure that China is much worse.
Zoom raises the possibility of this perception in their S-1 filing [0]:
"we have a high concentration of research and development personnel in China, which could expose us to market scrutiny regarding the integrity of our solution or data security features"
It goes far further than stupid comments by our (former) prime minister. The current legislation (passed in 2018) allows the government to force the installation of backdoors through a process that doesn't have any judicial overview or substantial public scrutiny whatsoever.
Atlassian is an Australian company, headquartered in Sydney, though the current plc is legally in the UK. (I have no idea if that means they're bound by said backdoor law.)
They are because they provide services to Australians and have an Australian subsidiary -- just as anyone in Australia must comply with a warrant or any other lawful request by law enforcement.
If they employ a single Aussie developer, or have foreign developers on Australian soil, the government can coerce those developer to insert anything they like.
This is not quite true, though it was reported widely. The legislation doesn't consider individuals as "designated communications providers" if they work for one (unless they are self-employed or sole traders). The way it works is that your employer gets a TCN and then they disclose it to the employees necessary to implement it.
But note that if you have an Australian employee (unless they are a sole trader / contractor) you must already have an Australian subsidiary of your company (for tax and superannuation reasons).
Don't get me wrong, I am absolutely opposed to this legislation and think it is a draconian overstep of government power which (despite the PR spin doled out by the government) was absolutely not necessary for effective law enforcement. But it's best not to fall into the trap of overstating what the law actually allows the government to do.
I realize HN will think much the same of it either way, but AFAICT that second quote of yours is a lie; she called WhatsApp's encryption unacceptable, not encryption in general.
> Meeting data transmitted across the network is protected using a unique Advanced Encryption Standard (AES) with a 256-bit key generated and securely distributed to all participants at the start of each session.
It does not guarantee that the key is withheld from the server, which is unsurprising given that e.g. the recording and chat history features are implemented server-side.
EDIT: For comparison, the Australian government provides a telehealth platform that clearly states it does not allow the server to inspect the call video/audio:
> Data shared in actual calls between participants is only ever available in decrypted form to the participating endpoints of the call. All other intermediaries that forward the call can only see encrypted data.
For those looking to hold Zoom accountable, the question to ask is: “Does your country’s law permit Zoom’s servers to be considered an ‘endpoint’ capable of decrypting a telehealth call?”.
I'm not sure a company can make their own definition of "end-to-end encryption" and say they're E2E because they meet their own definition of the term.
Sure, they're legally in the green perhaps. But this is not E2E, it is not the decades-long definition of E2E, and this is ultimately deceptive marketing.
This really is false marketing, but technically what they're doing seems reasonable. Key quote:
> Matthew Green, a cryptographer and computer science professor at Johns Hopkins University, points out that group video conferencing is difficult to encrypt end to end. That’s because the service provider needs to detect who is talking to act like a switchboard, which allows it to only send a high-resolution videostream from the person who is talking at the moment, or who a user selects to the rest of the group, and to send low-resolution videostreams of other participants. This type of optimization is much easier if the service provider can see everything because it’s unencrypted... This isn’t impossible, though, Green said, as demonstrated by Apple’s FaceTime, which allows group video conferencing that’s end-to-end encrypted. “It’s doable. It’s just not easy.”
Group videoconferencing is inherently centralized through a server that needs to analyze video/audio not only for signals as to who's talking, but also mix normalized audio and re-encode streams not just for lower thumbnail resolutions, but for clients with different bitrates.
I don't doubt that FaceTime finds a way to do this, but everyone is using Zoom instead because its performance is way better. I'm not entirely sure that all the necessary signal processing can be done performantly client-side, especially when you're allowing for a wide variety of endpoints (WebRTC, phone calls, etc.). You certainly can't mix encrypted audio (at least to the best of my knowledge?), for instance, which means increased bandwidth to everyone to handle overlapping speakers (someone interjecting "could I just say something?" while two other people are talking).
Also, handling key management for groups of people where you don't have the bandwidth to re-encrypt the stream separately for each receiver is very complex too, and in the end you're basically just going to have to trust that Zoom itself can't access the keys. Because usually Zoom will be able to, so that it can handle phone dial-ins.
But regardless... while Zoom should absolutely advertise full encryption, Zoom should absolutely not advertise end-to-end encryption. That's bad, and harms user trust in security overall when advertised technical terms become meaningless.
the audio processing can be done fine on consumer hardware, not really an issue. You can't mix the audio streams in the traditional sense, but you can multiplex the packets, demux them client side and decrypt/mix.
> If you have Zoom installed and visit that website, you will be auto-joined to a call, and your webcam activated without any interaction on your part—even if you closed Zoom before clicking the link.
> Worse yet, uninstalling Zoom doesn’t remove the web server. The web server can reinstall Zoom on its own as well. So if you visit a malicious link, it can reinstall Zoom, join you to a call, and start your webcam, all without any interaction from you.
What the &@$##!! How long has Zoom been around, how did it become popular (or did it ever), and why are people still using it?
I've resolved to not using Zoom - when it was suggested at work I just posted links to the issues (mostly gotten from HN actually) so we decided against it.
Because you think of the millions of streams going on, Zoom will snoop on yours? I mean as a security issue it isn’t black or white, you are always having some detrimental issue trade off and by chance. Use face time, have janky video cut offs etc lose productivity, man hours. That’s a trade off. Use zoom, Zoom may broad cast your video to your competitors and you lose money, what is more likely though?
Security through obscurity is a fantasy, and a dangerous one. You start thinking your screen door matters to the bear sauntering by, smelling what you're cooking, and coming in for a snack.
Sure. However I don't think he's promoting security through obscurity so much as figuring out his threat model and risk acceptance. For most businesses and end users who love Zoom, everything else they've tried has failed to do the thing acceptably. Like, they probably are more secure in so far as not enough people can successfully use them, so doing no video conferencing is more secure than doing some video conferencing.
And to be honest, most business stuff is by unencrypted e-mail, so I don't see how a TLS encrypted Video Chat increases their exposure.
Finally, the chance of someone, even zoom, recording and analyzing all the video conferences ever to somehow get important info from a video conference seems pretty low anyway. Unless you're worried about the NSA, and even then, it seems like they'd have a way into WebEx etc also, so even on risk.
At this point, it seems reasonable to go by what works for people. And Zoom works.
Well, they became the popular go to solution because the other popular solutions suck. Now they are also in the focus of privacy interested media and therefore end up becoming stories.
The Intercept didn't care about Zoom a few months ago and wouldn't have without Corona.
Yeah, it was picked up because it was a much bigger deal.
Now the issues are a smaller deal but are still being picked up.
Most people I work with haven't even heard about Zoom until those last months when they've been forced to use a teleconference for the first time in their lifes. They also probably didn't even hear about the issue last year too.
I'm still not convinced this coverage is in any way related to Zoom's current popularity or COVID-19, I just think a company that keeps fucking up is a better story than a one-off.
It's all over and I find it very curious that you've not been able to find anything in Danish media even though it looks the same for the english speaking outlets.
Zoom has been doing shady shit forever. Last year it was for installing a web server on localhost to save a click then dragging their feet on a fix when told how stupid that is.
They may have been doing that forever but that doesn't change anything about my argument.
They just were not as popular as they are these days which makes them much more newsworthy and which is why we're seeing constant new articles about them now about issues that have been there for a long time but which were not newsworthy a few months ago.
Edit: no, I'm not defending them. I just explain why they are all over the news these days.
My best example is a friend who needed a video conference fast and needed an alternative to WebEx which stopped recognizing his video feed from one day to another (I couldn't find a solution for that too). Jitsi doesn't work for more then two. We tried to set up teams. Took too long (I tried it again a week later, people had issues with the invites, some got audio error messages even though it worked with zoom... we gave up). So I went for zoom. EVERYBODY (old people, first time video conferencing) was able to install it and it just worked flawlessly. Even I was surprised.
This is what people need these days and this is why Zoom is so popular.
So sad, still getting this wrong after so many years.
I was part of a startup Sococo some 8 years ago. We had end-to-end encryption right out of the box. Plus video, document sharing, chat. All encrypted, end to end with rotating keys. Up to 100 people in a meeting, sharing and chatting indiscriminately.
Its gone now, and the new folks are starting way down the feature ladder from where we were. It's disappointing. Now its 'good' if you can get 6 in a conference.
I hear Zoom can support large meetings. So they may be doing something right.
I remember using sococo in a Boston based Startup Accelerator with around 30 employees - it head incredibly good performance even running from the browser and with all employees participating.
You could see a virtual layout of rooms and where you could knock and see who was in which room. It was such an innovative approach and a wow moment that is really rare. I miss Sococo until today and have never found anything like it again.
I got to know your CEO over dinner in Boston and am not surprised he threw it all under the bus. My boss at the time who introduced us tuned out to be a major scam artist who got rich peddling grey market pharmaceuticals online but claimed it was from selling a pre-web chat/gaming platform to Murdoch - he was also infamous for being the main investor of StartCom which we all know what happened to them (WoSign). The 2 guys got on like a house on fire.
Yeah he spent all our runway on hiring marketing buddies then got fired. Then we got bought and had to switch to WebRTC junk. I volunteered to be downsized (I had written the audio/video/chat/control transport that was discarded).
Very cool! They got the conference server stuff right then. Its critical to manage bandwidth, share streams, have backpressure at every stage. So easy to have packets pile up at unexpected places (bufferbloat-like) and experience delayed audio or dropouts.
Also, resilience thru network changes and weird packet behavior. Back then we encountered home routers that would drop 50% (every other) UDP packets! And reorder UDP, which is very much better to survive and recover than to drop.
As I recall, our product would let you walk around with your laptop, roaming from Wifi to Wifi, plugging and unplugging your wired connection, and it would switch seamlessly to the new network, all streams intact.
It's disappointing to see a company that has better tech than its rivals playing these games. I have been singing Zoom's praises, but this really makes me want to look elsewhere. What a bummer.
Zoom has always been shady as hell. Between the ridiculous web server on MacOS, web client anti-patterns and other endless nonsense the only explanation for their popularity is good marketing.
The explanation for their popularity is that it isn't a constant struggle to use zoom for meetings. Their software may have other problems, but people can run it and get into a meeting with minimal effort.
Yesterday by comparison half the people on a Skype meeting had to dial into an audio bridge with their cell phones because their computer audio didn't work for no fucking reason, and screen sharing kept lagging unless restarted every so often.
The good marketing for zoom is that webex is awful.
>The good marketing for zoom is that webex is awful.
100% this. We switched to zoom as stay home orders came out. And only because it worked 100% every time, with little to no fiddling. The non-tech literate employees at my place are patting themselves on the back for being able to set up and host a zoom meeting. Because it's one button.
And that's why they're used so much. They are the literal definition of it just works. People aren't worried about anything else right now.
I would never call them "just works." I had it completely lock up my macbook (no mouse movement or anything until it finally black screened) on joining a conference this afternoon. No program has done that to me in the past year.
Sure but that’s kind of like saying Wells Fargo has competitive interest rates. The advertised product isn’t the problem. It’s everything they make you take along with it.
I think it's more incompetence on the part of their engineers.
Engineers code shitty apps to fill requirements. Lie to project/product managers about what is complete, or have a "good enough" attitude. Managers communicate to marketing that Zoom is end to end encrypted.
- Still can't use Webex across Linux, Windows and Mac in 2020.
- Same goes for Skype, plus half the users who have Skype don't realise it's Linc and the two are completely different.
2. It's far more bandwidth efficient than things like Slack.
The codecs are much more resilient, this applies (from what I can tell) to all the embedded options that are just using the browser.
3. It's going to be around.
- Google Hangouts has previously been renamed and deprioritised. They also dropped their low-bandwidth codecs and cpu usage went through the roof in my personal experience.
I'm unclear on some of the items against Zoom. But there's a lot of hate and emotion around it in the last 10 days - my sense is that some people have an axe to grind - I'm always cautious of a crowd with pitchforks.
Also it's simple. If I want to add someone to a meeting, I just punch in their cell phone number. They get a call and the AI voice thing says "Press 1 to enter the meeting.". And they press 1. And boom they are in.
No extra software to download, no jumbling around with meeting codes, no "are you the meeting leader" bs. Straightforward and simple UX.
Crazy theory, so just hear me out for a second. Maybe the fact that they do some things that violate security is the reason that "it just works". I'm not saying Zoom shouldn't do better here, I'm just saying that there are probably legitimate product/business reasons.
From Steve Yegge's platform rant:[0]
Like anything else big and important in life, Accessibility has an evil twin who, jilted by the unbalanced affection displayed by their parents in their youth, has grown into an equally powerful Arch-Nemesis (yes, there's more than one nemesis to accessibility) named Security. And boy howdy are the two ever at odds.
But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.
I don't think "it's going to be around" is the main reason people are using Zoom instead of Hangouts: regardless of how you interpret Google's confusing messaging here, Hangouts is clearly not going to disappear while lots of people are relying on it in the middle of a pandemic.
Instead I think it's that Zoom is better: easier to join, it can show you more faces at once, more controls for the meeting owner, lower CPU usage, etc.
(Disclosure: I work for Google, speaking only for myself)
You should do 30 seconds of research. Zoom has a long history of shady bullshit.
The “pitchforks” are people who pay attention and do not trust Zoom for established reasons. We are now forced to use it because I guess business in 2020 requires the ability to look like you’re on a beach in your sweat pants.
Video/sound quality is much better than any alternative I have tried. You can see video from up to 25 (or even more now?) people at the same time. It's easy for people to set it up and join meetings. Easy to share screens/audio.
Second this.I used to use Skype back in the day and even with astronomical Internet at the time it used be painful. Zoom managed to pull it off somehow.
Are people just looking for things to be mad at Zoom for at this point? When Zoom says E2E encryption they're using older notion when it was common for services to not use encryption at all for these kinds of things and it was somewhat of a technical accomplishment that every client-server-server-client leg was all encrypted.
Like it's fine to point out that the bar has been raised in the security community and that the term E2E now requires that only the participants be able to decrypt the content and they should change their copy but it ignores the fact that E2E in healthcare means exactly what Zoom is doing. In the HIPPA world providers are trusted entities.
A simple example could be something like using TLS or DTLS between all nodes in the network. But that doesn't mean data on a Zoom server sitting in the middle of a call is encrypted.
The point is that the term "E2E encryption" was never used for "there is TLS involved". Because that's not what end-to-end means.
E2E encryption was always clearly defined as "only the two communicating parties can access the information". Using the term "E2E encryption" in other ways is deliberately confusing. Edit: and pretending that E2E encryption meant something else in some unspecified past is revising history.
With true E2E encryption, could you support features like recording a video and making it available for download? If yes, does that reflect how their video recording features work now?
"Bank-level cryptography" with some of them still storing passwords in cleartext, and others made a very painful transition to unsalted md5 within the last 5 years because they "couldn't budget it in" any earlier.
Sure you could. Either a participants client records the stream and uploads, or a ‘recording client’ is added to the conversation by the service.
However, I think the real value of mitm is more to do with redistribution of streams and muxing to reducing total bandwidth over that required by a full e2e encrypted p2p mesh. I.e one upload vs one per peer (although this could also be done with e2e encryption with multiple recipients and simply routing through the service) and potentially a single download too (depending on how the muxing is done), rather than one per peer (but this couldn’t be done with e2e encryption).
"When Zoom says E2E encryption they're using older notion "
This is not the case. End-to-end encryption was popularized as a computing term in the 90's with PGP, and it meant that when sending eg email messages, no computer or server in the middle could decrypt the content. Only the the personal computers of the sender and recipient could. The computing field always used the term that way.
If you think about the expression "end-to-end", it carries its own meaning. The only way you could become confused about this is by exposure to totally crazy marketing spiel that will sell you black as white.
If the article is accurate, this is clearly not "end-to-end" in the way that most people believe it. If Zoom was considered "end-to-end" encrypted, then any site that uses HTTPS should be able to claim so as well.
I interpret end-to-end encrypted to mean only the participants have access to the content, the intermediary couldn't spy on my calls even if they wanted to. This appears to NOT be the case with Zoom.
You make a useful point about older definitions and/or the world of HIPAA, and nothing else you say dilutes or undermines that.
However, I take issue with your opening ad hominem abuse. People are looking for abuses of trust. That has nothing to do with “being mad at zoom.” That has everything to do with uncovering dishonest behaviour that is detrimental to the industry.
You positioning it as some kind of emotional crusade does a disservice to people who care about important matters like informed consent.
All that being said, the factual information you shared is valuable, and I thank you for it.
The “fact” that E2E has an older meaning in industry seems very hard to chase down right now. We also have the problem that if we accept this as honest or acceptable marketing language, then Apple and Google should be allowed to engage in similar standards of marketing language.
I do not think Zoom are being honest about this matter. What they are is “encrypted in transit.” I appreciate that there may be %REASONS% that E2E is unachievable given the feature set they wish to provide, but to me, that juts means they should be up front.
“All Zoom communications are encrypted-in-transit. We do process them on our servers to provide features like X, Y, or Z.”
End-to-end encryption is traditionally defined as a means to stop man in the middle attacks. If there's a man always in the middle it defeats the point a little bit.
You could argue whether the attack on Zoom is warranted. But don't start revising history to make your point. E2E has never meant that. There's no such "old notion".
I can't find any sources saying HIPAA would use that deviating definition. Most sources I see use Whatsapp as an example, which is E2E under the proper definition.
> I can't find any sources saying HIPAA would use that deviating definition.
That's because HIPAA does not define any implementation details. Google "Hipaa end to end encryption" and you'll quickly realize the Hipaa world uses a much looser definition than the security world.
"End-to-end" in the context of Hipaa is typically used to indicate encryption (specifically SSL/TLS) of on-the-wire data through the entire request process. Practically this means on-the-wire data needs to be protected all the way to the underlying app service.
For example, if you're running Rails with Docker. SSL/TLS transport needs to be present all the way to the container. A load balancer (or other device) is allowed to terminate/re-encrypt as long as on-the-wire data remains protected.
From the actual HIPAA regulations, one must "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."
Then you can follow along the official HHS guide[0] to see if you're abiding by these rules. If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine.
As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice.
> As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice.
Trust me. I am not. I'm simply trying to demonstrate colloquial usage of the term within the Hipaa community.
> If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine.
This is not correct, though. Both of those use cases CAN be fine. They can both also NOT be fine.
* Client-to-client (assuming we're talking about a computer client) over SSL/TLS is completely fine if the usage case allows for it. You don't need a server involved to exchange ePHI.
* Conversely, client-to-server does not automatically make the use case allowable.
Maybe it's because I use Qwant, but my search results for HIPAA end to end encryption gave articles about actual E2E encryption for emails (since they typically pass through a third-party email server). So I'm starting to think the term isn't being misused even in the HIPAA community.
And sorry, I meant client-to-client with the assumption that there's a server between the two. And sure. I think it's safe to assume that SSL/TLS is perfectly fine for a client-to-server situation. But like I said, let the company read the actual regulations and consult their IT team.
Instead of asking people to Google it, your argument would hold more weight if you provided the specific sources you mean readers to go Google and find themselves. It'll save readers some time and improve your argument.
Several people have tried to "google it" and tried to find alternative definitions of end-to-end encryption in the context of HIPAA and have so far failed. If end to end encryption really does mean something else in the context of HIPAA, what is your evidence/source?
I'm suggesting people should Google it because a list of singular examples does not indicate widespread usage. It's a case of "you need to see for yourself" to understand how this term is actually used in the wild.
The problem is people are trying to find definitions for things that Hipaa literally doesn't define. You won't find a definition for "end-to-end" because Hipaa doesn't actually define it. "end-to-end" is an implementation detail. Hipaa does not define or green-light implementations.
This is both a blessing and a curse of Hipaa.
On the blessing side, it means companies can use tools they see fit and follow industry best practices as long as they can demonstrate the compliance of those tools. This is great because it means companies don't need to wait for Hipaa to explicitly say "you can now use TLS 1.x" or "this widely accepted algorithm is cool for disk encryption".
On the curse side, it means there's no explicit guidance and a lot of leeway. It's on individual companies to demonstrate their implementation patterns are secure.
??? In IT, E2E has always meant End-to-End, as in, nothing in between can decrypt the content. HIPAA, or brazillian telcos, or the FAA, or my local beer tasting club are fine to come up with whatever interpretation they want, but that doesn't change what it has always been the obvious meaning. No real room for ambiguity here...
It seems that HN is flooded with commenters trying to redefine the well-established meaning of strong E2E encryption. I ask myself if there is any motivation for such comments?
I’m annoyed by pile on culture and hate when a company goes from darling to demon. But as distasteful as I find that element of our society, I don’t think this is an example of pile on culture. Rather, I think that in this case, Zoom is using a false message with real life implications.
If you have a level of technical sophistication, you can see the shades of grey in all security. So maybe this usage of E2E can be overlooked in HIPAA or other threat contexts. But a wider array of people, including senior decision makers in sensitive organizations believe that E2E means ‘gooder’. :)
When I look at it through this lens, I’m not comfortable with the implications of their marketing message. I’m not sure this makes Zoom a demon, but I definitely trust them less as a result. Is that reasonable or am I overreacting to something? If I am, I would love to know where I’m wrong!
>> Are people just looking for things to be mad at Zoom for at this point?
Having been a really happy user of Zoom for more than couple of years - I have referred many friends to use it succesfully. Despite that it looks like Zoom has legit issues that are surfacing. However I have to say it cannot be ruled out there might be some negative PR going on too since I can't help see using any Zoom alternative! Everything else pretty much sucks.
> E2E in healthcare means exactly what Zoom is doing
In what context is E2E used within HIPAA in any other context than "not accessible by intermediaries"?
Having no experience with HIPAA but plenty with PCI DSS, where E2EE is used only in this regular sense, it is easy to find public HIPAA compliance checklists which are very explicit about the end-to-end part and hard to find anyone that would allow Zoom-like uses.
> Are people just looking for things to be mad at Zoom for at this point?
I guess when they're being one of the most popular video conferencing platform right now, it invites attention. Doesn't help that people are Zoombombing, and their privacy track record certainly does not help.
I mean, nice new unicorn, but very shady dealings ala Facebook. Not a good look.
Also surely one of the limitations here is technical / usability. One of the big features of Zoom is transcoding streams from all manner of devices and sending them to all manner of devices. Doing this on the fly is still computationally demanding and not feasible for consumer devices (or the E's in the true E2E model).
It didn’t. OP is making a claim which was never at any point since at least the mid-90s correct. Various marketing teams have tried to redefine it but that’s always been criticized rather than accepted.
Inherent to any e2e encryption scheme is the question; are you talking to who you think you are talking to? In other words; are you the victim of a man in the middle attack?
So if you ever encounter a system that has the ease of use feature where you don't have to verify the identity of the other participant(s) with something like a identity fingerprint number then you already know you do not have all the protection that e2e encryption can provide. This is particularly relevant in a case like Zoom, where all the data goes through servers that Zoom controls making a MITM attack trivial.
So we really should of known that Zoom doesn't provide complete e2e encryption already just from the lack of the identity check.
Skipping the identity verification step seems to be common these days. Even Signal does that by default, but they at least make the verification of what they call "safety numbers" fairly easy and straightforward.
Added: So can true e2e encryption ever be practical for conferences involving a large number of participants? Perhaps Zoom is claiming the impossible... The issues surrounding the addition of OMEMO encryption to XMPP conferences make for an entirely relevant example. What do you do if one of the participants is not known to all the others? There are lots of possible answers to that question.
Added2: >The only feature of Zoom that does appear to be end-to-end encrypted is in-meeting text chat.
I don't see how this can be true either based on the same thinking.
For those types of conference calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en
(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).
It's true that you need an out-of-band verification to determine who the other party is in an end-to-end encrypted system. But it is not true that the absence of such a verification means you don't have end-to-end encryption.
It means only that you don't know for sure who the other party is. You are only put at risk if there is an active MITM attack in progress.
Depending on your threat model that's an enormous change.
Additionally, just because you have o-o-b verification, that still doesn't mean that it is e2ee. Until you can view the source and build it yourself, who knows what back doors could exist. But this is the challenge, how do you balance security and convenience? People, by and large, aren't building source and side loading. They are going to have to take a leap and trust someone. It is a very hard problem to solve. Generally, no one cares until the one bad thing happens, then they care immensely. I've said that it is hard to get people to care about privacy when they live stream and share pictures of their life every 30 minutes already.
Just semantics at this point. A system that distributed the keys to all participants in the clear from a central server is still encrypted end to end in some sense. As pointed out by someone else in this comment section, the expression "end to end encryption" comes from the early day of PGP. PGP specifically protects against MITM with a fairly sophisticated web of trust system. So it is entirely legitimate to assume that e2e encryption includes MITM protection as a hard requirement.
PGP's "Web of trust" doesn't actually scale and so it doesn't meaningfully improve upon just doing out-of-band verification with a handful of your closest peers and nothing for everybody else.
Web of trust can give an illusion of scaling because it uses sleight of hand to persuade you to accept transitivity of trust. If you see someone who took this seriously you'll find that almost all contacts show as "unverified" (when I've had PGP setups in the past that's what happened). If they just click blindly along accepting trust transitivity then everything is "verified" but based on trust beliefs that have no basis in reality.
The sleight of hand goes like this. You trust Alice. Alice says this is Bob and she trusts Bob. The correct inference is that this is indeed Bob (Alice says so and we trust her) but we still don't trust Bob. PGP tries hard to persuade you that you in fact now trust Bob. Bob says another contact is Carol, and he trusts Carol. The correct inference is null, we don't trust Bob so we don't care what Bob says. But PGP encourages us to accept that this is Carol and we should trust Carol too.
I think no news is good news in this case. And a positive for Wire is that since it's all open source, you can go right to their github and see how active their development is.
It would be nice if The Intercept and other journalists would include these actually E2E-encrypted alternatives besides the Mac/iOS-only FaceTime.
Firstly, classical VOIP including ones involving video have two stages: a signalling protocol called session initialization protocol (SIP). Secondly they have a real-time protocol, or RTP. SIP is used so that clients can find each other over the internet. If they can punch through their firewall, great. If not they might need help from STUN servers. Once done, the clients then talk to each other using RTP directly, not via the central server.
In the SRTP variant, this involves using DTLS, i.e. peer-to-peer TLS.
Wire does calling, except the SIP part is replaced by the existing messaging system they already have: the double ratchet. So if you want to call, that's just another end to end encrypted state of the art message exchange to signal that fact and agree a key.
The original RFC for SRTP isn't great and many of those options are still supported in implementations. Here's the RFC for SRTP: https://tools.ietf.org/html/rfc3711#section-4 . This document would likely result in tptacek banging his head so much on his keyboard that he manages to write a perl script capable of mind control that runs wild, turns on its creator and turns him into a PGP and DNSSEC loving zealot (presumably the motivation would be spite for having been written in perl). Or with a little less hyberbole, the crypto is a product of the times in which that spec was written, and we'd do better now.
I mean... NULL cipher? We have that option already. It's just plain RTP without the S.
I can't see any evidence in the codebase right now that there's any attempt to do anything custom with SRTP for Wire (SRTP used because of WebRTC), so, I assume that they're simply using whatever is available by default for video/voice as provided by Electron and/or your browser.
I can't find any evidence existing audits have looked into the security of the voice/video protocol. They appear mostly to have focused on: a) the X3DH/Signal Protocol implementation and b) a high level audit of the whole application.
So far we're just talking point-to-point. Things get fun when you want group chat: do you a) establish any-to-any multicast (can be encrypted e2e) and let clients composite the video onto their (possibly low powered phone) screen or b) provide and RTP mixer (mitm), that needs the raw unencrypted video to combine it and provide a unified stream? Presumably Zoom opted for the latter; as far as I understand it Wire etc have opted for the former.
I don't own any Apple Devices so it's hard to look into their offerings, but MDG in the article states they've managed it. For Text, having copied Signal, Wire have some claim to be the most secure platform (or rather, one of them). However, I suspect that actually everybody in this space sucks really badly and nobody is actually looking into it.
In short, the security of text messages is about as state of the art as you can get. The security of video/voice, for _all_ "secure messengers", likely leaks a bit of metadata at best, and might use some funky 2000s era crypto at worst.
tl;dr they're using exactly the same standards for voice/video as everyone else, no secret sauce.
Zoom seems to have adopted the "Move fast and break things" mentality and it's catching up with them.
Don't have real E2E encryption? Don't say you do. Don't wave away a giant security vulnerability as "a feature". Don't explain monitoring and tracking as something you need to do for advertising when you don't show advertising.
Their product may be superior in quality compared to the competition but their Marketing and PR teams comes across as bush league at best.
The only incident I can give them any credit for is the Facebook reporting. They handled that well in my opinion by admitting the problem existed and immediately resolved that issue.
I am willing to chalk this up to an honest mistake considering "end-to-end" encryption as being from the client's end to the server, although that's not the accepted use of the term. This appears to be their explanation. I hope their marketing team fixes this now that it's been pointed out to them though.
That’s not an honest mistake. It’s an inexcusable fuckup. End to end encryption is not a difficult concept. Redefining the “ends” doesn’t excuse Zoom’s continually shady behavior.
A single honest mistake in the privacy/security area is already close to inexcusable. Zoom has a proven terrible track record in anything security and privacy related. So letting this one go would be very very naive.
I am willing to chalk this up to an honest mistake considering "encryption" as being compression, although that's not the accepted use of the term. This appears to be their explanation. I hope their marketing team fixes this now that it's been pointed out to them though.
Since this comment was written, narsil (Vinod Chandruis) has edited his profile to remove the fact that he is a co-founder of Kloudless. You can see it cached in google search results:
https://www.google.com/search?q=narsil+kloudless
Kloudless is currently promoting security solutions on their twitter timeline.
I'm not really seeing how this is relevant or how the post is justified. People edit their profiles all the time, and have a right to. It's up to them what they want to put in there. This comment seems to be crossing into personal attack and a mild sort of doxxing. Please don't go there on HN.
Irrelevant.
That as nothing to due with the fact that they say they are. Zoom is being completely dishonest, and as some other commented here, some orgs like in health care area, have E2E encryption as requirement, Zoom says they have, but don't. It's literally fraud.
1. HIPAA et al have very specific meaning that do not have anything to do with end-to-end encryption at all. If you know this, read this line, and care about HIPAA you know exactly this.
2. end-to-end has several meanings, for users it means what Signal does, for machines it means TLS is securing edges.
I'm usually not the one for conspiracy theories and this is most likely just media outlets fixating on one topic for clicks, but sometimes this just feels like a smear campaign against Zoom. I'm sure a lot of these issues could be found for other providers as well.
If you fucked up bad enough multiple times people will find lore. Years ago it was constant news about uber now its zoom. If a company is dishonest enough you will find enough more bad news, and as long as bad news get clicked...
But i am happy theres media attention for this exact topic because it was dishonest all the time and people have chosen zoom over other solutions because zoom is the only one claiming end to end encryption.
GoToMeeting claims end to end encryption[1] and in the same sentence say it's just SSL just like Zoom. Never the less they offer call-in as well so end to end becomes impossible right there. I have serious doubts about any conference software offering real end to end encryption as it's unrealistic for clients to be dealing with that many av streams.
End-to-end encryption doesn't require participants to receive full-quality video from everyone. Each client can be responsible for encoding their own video feed at multiple quality levels simultaneously – what WebRTC calls simulcasting. That does increase required processing power and upload bandwidth, but not to the point of infeasibility. And you do inevitably leak the identity of the person currently talking, as the server has to know whether to relay the high- or low-quality video stream for each participant to each other participant, and it can trivially tell the difference between the two based on bitrate. But that's much less bad than leaking the whole video stream.
>That does increase required processing power and upload bandwidth, but not to the point of infeasibility.
Most devices now do video encoding/decoding in a dedicated hardware unit, so those additional streams will have a vastly disproportionate impact on performance and power consumption. Some desktops and high-performance laptops support multiple streams, but most mobile devices don't. It's feasible, but very much non-trivial.
It looks like WebRTC doesn't support it, so basically no-one can because all these browser-based technologies end up just being WebRTC in the end.
From the Jitsi Meet README:
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls.
I don't understand "WebRTC doesn't support it". What do you mean?
WebRTC uses an external signalling channel to negotiate ICE candidates, codecs, and necessary information to establish a media communication. Once this is done, the visio/audio conference is P2P and encrypted from the caller to the callee: how is this not E2E? (Genuinely curious, not criticizing)
That is, if you're not using a TURN relay server, which is easy enough to know.
Maybe you meant that multi-party (one-to-many or many-to-many) calls are not E2E. Again I'm not too sure I understand: it is possible to have multi-party conf calls: each participants can encrypt its media stream and send it to the N-1 other participants. Obviously this costs a lot of CPU (for multiple encryption) and a lot of uplink because the same stream is sent N-1 times. But it is __possible__, and certainly viable with only 3 or 4 participants, provided people have a decent connection (WebRTC uses adapative bitrate streaming [0] to compensate for bandwith usage).
Then again, I know that generally, with WebRTC people would use MCU [1] when dealing with many-to-many conf calls, and then I agree it breaks E2E.
But for the other mentioned cases, WebRTC is E2E, isn't it?
Again, I'm genuinely curious about this, not trying to criticize or undermine.
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls. As a result, your stream is encrypted on the network but decrypted on the machine that hosts the bridge when using Jitsi Meet.
> The Jitsi Meet architecture allows you to deploy your own version, including all server components. In that case, your security guarantees will be roughly equivalent to a direct one-to-one WebRTC call. This is the uniqueness of Jitsi Meet in terms of security.
1. Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would.
2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second, with unencrypted markers showing where they can be sliced and joined. If you can upload a 1080p stream, chances are you've got the bandwidth to send a 360p stream too!
3. Each client tells the server which other call participants they'd like to see, and the server sends them the appropriate encrypted streams, switching between low and high bandwidth as appropriate.
>Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would.
how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? How do you plan on doing that without any substantial lag?
>2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second
you have managed to double your egress for almost no value.
> how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins?
By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats.
> you have managed to double your egress
Not at all.
Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%.
Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs.
A master node negotiates a symmetric key that lasts for the duration of the call. The master is either selected by the server or in round of Paxos, and since everybody has the same key, if he leaves it just needs a new round of negotiation.
Only compared to the current, unencrypted version. For E2E encryption, the alternative, as I see it, is pushing out an encrypted video stream per recipient. He has reduced his egress from O(n) to O(1).
I think they would claim the terminology is ambiguous. If the connection is encrypted between all clients and the central server, a business person might say that's end-to-end, ie all traffic in flight.
I'm afraid of other services catching on to this "semantic loophole". Would changing the terminology to perhaps client-to-client encryption solve this?
You abandon the server-side processing part and have all 50 participants share a single key. The server then acts as a dumb broadcast network. It's definitely not easy, which is probably a big reason no-one in this space is doing it.
You lose a lot of features, too. No calling in from a normal telephone if your Internet connection sucks. Everyone has to share the same stream, so no tailoring res/bitrate/etc to individual participants.
You can't, without having every client process all the video and mix all audio. In other words, with current consumer hardware and internet coverage, you can't.
So, I got around a issue like this in the past by using url fragments. I imagine the same thing could work for zoom?
Basically you would join a meeting by going to zoom.us/meeting-id-number#secrethashtag
The "secrethashtag" is never sent to the server, but can be accessed by javascript on the client end. Im not sure if this would be acceptable for security nuts though, as I am sure they would make the argument zoom could insert some nefarious js to intercept the url fragment.
If you read their white paper it only says E2E encryption applies to Zoom chat. Although they seem a bit loose on the wording, they should clarify video is just TLS encrypted. https://zoom.us/docs/doc/Zoom-Security-White-Paper.pdf
> In fact, Zoom is using its own definition of [end-to-end encryption], one that lets Zoom itself access unencrypted video and audio from meetings.
It's not a standard. If you want compliance to a standard then create/adopt/require one. When you go by marketing materials all you have is "Trust us, everything will be fine"
The encryption that Zoom uses to protect meetings is TLS, the same
technology that web servers use to secure HTTPS websites. This means
that the connection between the Zoom app running on a user’s computer
or phone and Zoom’s server is encrypted in the same way the connection
between your web browser and this article (on https://theintercept.com)
is encrypted. This is known as transport encryption, which is
different from end-to-end encryption because the Zoom service itself
can access the unencrypted video and audio content of Zoom meetings.
jumbles TLS with end to end. zoom could e.g. proxy or support rendevous of peer to peer connections and still use TLS to negotiate end-to-end encryption between the clients (though this would be MITMable). anyway.
Interested in getting more informed on the performance penalties of a proper E2E implementation for videoconferencing use cases.
If Zoom implements proper E2E like Facetime, would it be more laggy, less able to handle meetings of more than 50 people, etc.? Will the general user experience degrade noticeably?
It's not end to end encrypted, and it apparently has the charming people of saving other people's "private" messages in the minutes if they send them during a meeting.
Why did zoom suddenly become so popular? It's not like there's a shortage of options.
The private message thing was completely overblown though, wasn't it?
From what I understood it only saves your own private messages in the log. So the only time you could get in trouble is if you exported the log and then shared the file with others without removing your private messages. So just like you took a screenshot and didn't censor the parts you wanted to keep hidden.
Hardly the massive scandal that some people on Twitter seemed to try to make it.
Do people still remember Telegram don't have E2E encryption on by default? and does not work across multiple platforms when E2E is on? I am annoyed because those are my favorite apps and they don't have what's important.
This is how you realize the power of marketing. Despite many other options for video calls out there, Zoom seems to be grabbing the biggest slice of the pie, while not being provenly any better or superior to alternatives. See DHH's tweet: https://twitter.com/dhh/status/1243907341868609537?s=20 as well as others (he's been pretty vocal about zoom's flaws) :)
This is not "slightly" dishonest on Zoom's part. It is dishonest.
Edit: now that the title has been modified, I feel I need to add back context. Zoom claims to support end-to-end encryption when it doesn't. That is dishonest.
There's the technical definition of "end-to-end" that we all know here—encrypted at one endpoint and decrypted at the other—but I'm wondering how well-understood that term is in broader context. I could see someone saying "end-to-end" encrypted meaning that each segment in the path is encrypted, but with the intermediate nodes decrypting and re-encrypting the payload. Perhaps we should try to come up with a more specific term? Or we should at least be aware of the potential for confusion.
"End to end encryption" is the more specific term! The specific term for each segment being encrypted is "link encryption". The general term is plain "encryption".
Yes, this term has been used in the industry for always encrypted on the wire and at rest, but not "never decrypted" over the years.
If you think about it for hosted services that provide non-trivial functions for your data, you'd see the definition of e2e we apply to messenging apps would never apply.
>Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data.
No motivation at all. My only connection to Zoom (full disclosure) is that I own a small amount of their stock. My purpose in pointing this out is that what we understand as well-understood technical terms are easily confused when communicated to a larger audience. While we should absolutely criticize anyone misusing the term, we also need to take a step back and question whether we're communicating effectively to a non-technical audience.
My Zoom client even has a little green lock with an "E" in it in the upper left side that says "Zoom is using an end to end encrypted connection" when hovering over it.
It looks like the title was modified again, to include "despite marketing". Thank you, moderators! Please feel free to delete this comment and my comment above it.
Regarding the ranking: This post is currently #1 on the front page.
It was posted around 08:00 UTC. In my experience it is generally very hard to get traction for a post that is posted before ~14:00 UTC. This is a site with lots of US users, and it’s still early on the west coast (07:18 PDT).
This post managed to climb to the top despite that, probably because Zoom is a company that is interesting to techies, the article is from a well-regarded news source (at least in this crowd), it covers misleading marketing, it’s a bit related to Covid-19 and it also touches the topic of E2EE.
Interesting. It reached #2 an hour after submission, and then it suddenly dropped to position #13 within the same hour, around the same time when it was renamed by the mods.
"Zoom... claims to implement end-to-end encryption, widely understood as the most private form of internet communication, protecting conversations from all outside parties. In fact, Zoom is using its own definition of the term, one that lets Zoom itself access unencrypted video and audio from meetings."
I guess Zoom says they're end-to-end encrypted because they're using WebRTC, which probably means traffic is end-to-end encrypted after signaling, but users need to trust that zoom's signaling server doesn't do anything fishy.
Edit: I do not understand the reason for the downvotes. I am not defending the practice but am just describing their potential line of explanation. Please let me know explicitly if my comment is technically incorrect. Also, I would be interested what other vendors claim, who probably use similar technology under the hood.
Yeah somewhere in their documentation they state that they are end-to-end encrypted because the connections peer1<->zoom and zoom<->peer2 are encrypted. I cant find the page anymore but they really tried to redefine the name for end to end encryption...
End to End encryption in conferences of >2 participants causes substantial quality degradation for the same bandwidth use, since you can't have a central server re encoding streams to produce low quality streams for those participants who need it.
I believe zooms reputation as being more likely to 'just work' in part hinges on that,
Right, so I suppose that the numerous gateways zoom and others need to offer are an additional problem which implies that these services have to do "something fishy" on the signaling server. Generally, WebRTC traffic does not need to go through a centralized sever, though. It's peer-to-peer after signaling if possible, and if not it can use routing servers that merely route encrypted traffic. So I am wondering if these providers largely make use of standard WebRTC infrastructure plus gateways and how much proprietary magic they have on top/as an alternative. Of course, in no scenario the traffic is really secure.
It's great that The Intercept is taking a look at this, because it's absolutely beyond the capabilities of healthcare practitioners and the professional bodies to get to the bottom of. There's a ridiculous amount of confusion here, compounded by "you need to get the HIPAA version because HIPAA means privacy".