Hacker News new | past | comments | ask | show | jobs | submit login
Zoom meetings aren’t end-to-end encrypted, despite marketing (theintercept.com)
1230 points by tony101 on March 31, 2020 | hide | past | favorite | 339 comments

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.

[0] https://www.cms.gov/newsroom/fact-sheets/medicare-telemedici...

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?

(Minor nit: HIPAA, not HIPPA.)

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.

HIPAA (all caps)

What is a BAA?

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.

PHI: Protected Health Information.

I figured someone asking what BAA stands for doesn't necessarily know all the other acronyms.

Edit: Fixed definition!

Protected, not Personal.

Fixed, thanks!

> disclosure timeline guarantees.

depends on your definition of "guarantee".

what you really have is externalisation of risk.

Business Associate Agreement.

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).


I wrote this a while back for our customers: https://www.aptible.com/hipaa/what-is-a-baa/

Business Associate Agreement, which defines the legal requirements between two parties sharing HIPAA data.

Note this only applies to the USA, other countries might not have loosened their regulations quite yet.

Extremely loose in Canada as well. Facetime, skype, phone calls are all fair game currently

FaceTime is E2E, fwiw, although it might not comply with other requirements.

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?

[1]: https://www.wired.com/story/australia-encryption-law-global-...

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.

It's not incompatible technically. The law requires access on request, not all the time. If LEO doesn't ask, it may be still E2E.

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.

PIP or other effects can be done well on client side eg with WebGL or nultiple canvases.

Possibly you can save on BW by server processing - far from "no choice" however.

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".

The law didn't contemplate that you would use a service but not want that service to access your data.

> 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.

How do you E2E encrypt a video stream and still allow adaptive bit rates?

If the server can't read (decrypt) the video, it cannot re-encode the video at different bitrates for different clients.

Or the Zoom client has to encode multiple steams and upload them locally...or it just downgrades to the bitrate of the slowest client...

You get shitty video and E2E encryption or good video and transport encryption.

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.

But a lot of video conferencing systems are designed for office environments, where you tend to have symmetric bandwidth.

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.

Sure. Then maybe don't claim that the service is e2e-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?

Probably something like this:


I'm concerned that the exigencies of pandemic will cause people to get used to a system that tosses privacy out the door. Not sure how to stop this.

A couple of nits to pick:

> in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks

Slight exaggeration; wouldn't you call the royal flying doctors service telehealth? And HIPPA is a US law.

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.

Nit: HIPPA is not a US law, but HIPAA is. ;-)

> Nit: HIPPA is not a US law, but HIPAA is. ;-)

Touché! I'm even HIPAA trained and have to deal with it all the time yet I chronically make that error. I can't even see it when proof reading. Ouch.

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.

Example: https://signal.org

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.

fair enough

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.

Signal for Android has had reproducible builds since 2016: https://signal.org/blog/reproducible-android/

It says it does not right on that page.

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.

They literally call it "an end to end encrypted connection" and "secure with end to end encryption".

How is this "clear" that it is not E2E?

Because I live in a world where that term is pretty ambiguous because they aren't security experts.

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.

As far as I know, there's nothing special about telehealth that prevents it from using e2e encryption.

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.

You mean, other than requirements that service provides track & preserve an audit trail for all data. ;-)

I believe this is a similar problem with financial trading systems with ETS.

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)

I have a telehealth appointment (in Australia) this week, and they are using https://doxy.me/

Anybody know much about that one?

My wife uses this when talking to clients (shes a psychologist), but she has the upgraded version that is HD.

If your doctor is on the free plan, it is highly pixelated, and because they offer a hippa-compliant free plan, most providers are on the free plan.

They had a 3-4 hour outage recently. Assuming because of the number of new free users.

> LD video

TIL: there is a quality below SD.

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?

Perhaps the system could allow users to send high resolution still photographs alongside the low-quality video stream.

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.

really? Psychotherapists are required to use one of the certified providers to be able to bill for tele sessions.


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 Duo is end-to-end encrypted [0]. I don't know about Meet.

Disclaimer: Working at Google, in the same org as Duo.

[0] http://support.google.com/duo/answer/9280240?hl=en

Ah, it's nice to hear that Duo does e2e, thanks.

Very well explained, too. Great work.

> I'm pretty sure that Google Meet isn't end-to-end encrypted either. Nothing that Google does is.

To the best of my understanding, they say that it is https://support.google.com/a/answer/7582940?hl=en

EDIT: On rereading they actually just say that it is encrypted, not neccesarily end-to-end encrypted.

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?

If they did that, everyone would have the model (meaning you would see closed captions in a lot more places, because it would absolutely be stolen).

Google translate and Google Gboard offer offline voice to text transcription... So it would seem the model is indeed on your device, and Google says as such - http://ai.googleblog.com/2019/03/an-all-neural-on-device-spe...

On the ARM TrustZone, maybe? Or whatever co-processor run Widevine.

Isn't 128-bit AES and SHA-1 fairly weak encryption nowadays?

128-bit AES is not "weak" by any definition of the term.

SHA-1 is deprecated but it's good enough for this application for the near future.

>128-bit AES

Perfectly fine...


You missed the important bit:


Also perfectly fine...

Do you have any opinions on Pexip Infinity? Would Zoom be a better replacement if it did have E2E?

Hopefully we've reconsidered the laws of mathematics in the last few years ...


"“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."

Going to have to get over this first :/

> 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.

Ref: https://www.businessinsider.com/coronavirus-boris-johnson-zo...

So with the right URL, you can tell them yourself!

Actually: Just a screenshot tweeted by Boris Johnson himself should be enough (if he was faster to tweet it): https://twitter.com/BorisJohnson/status/1244985949534199808

That's terrible for national security. Zoom engineers are based in China: https://www.cnbc.com/2019/03/26/zoom-key-profit-driver-ahead...

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 :)


That depends entirely on whether the handset is physically disconnected by the on-hook switch, or if a firmware exploit could remotely enable it.

Threat modeling a fax machine in the era of fuzzing-RCEs is a particularly interesting thing to consider.

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.

Charles tells me that when I installed Zoom, my iPhone made four HTTPS connections to zoom.com.cn/

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"

[0]: https://www.sec.gov/Archives/edgar/data/1585521/000119312519...

Components of the GB 5g network are also being outsourced to China. Some of the ruling party's MP's are not happy about it.

The noisy back-benchers are a little silly as all of Huawei's work is scrutenised: https://www.wired.co.uk/article/huawei-gchq-security-evaluat...

Of course, in the UK, calling Tory back-benchers "a little silly" is an understatement.

Are the NATO countries refusing to use Huawei's work for their 5g networks also all "a little silly"?

What if Huawei was Russian, would it still be "a little silly"?

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.

Number one reason we dropped JIRA.

Out of curiosity, what did you switch to?

Why? How is it related to Jira?

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.

useful correction, thanks :)

Atlassian is based in Australia.

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.

"Encryption we can't backdoor isn't acceptable"

> The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia,” said Turnbull.

Heh, that reminds me of the Indiana Pi Bill[0], where the state tried to legislate the value of pi to be 3.2.


> ... the [former] UK prime minister Theresa May has said that the big internet companies give terrorists “safe spaces” to communicate.

Yes, IIRC she also said wanted to enter a dialogue about this "with the people that know the right hashtags"!

That was Amber Rudd.

Zoom’s HIPAA product documentation does define Zoom’s “end-to-end encryption” as:


> 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?”.

As a note, to be HIPAA compliant you also need to sign a BAA with Zoom. This, interestingly, disables cloud capture and a bunch of other things.


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.

It would be extraordinarily difficult for me to sell consulting services, and guarantee 100% on time delivery with zero defects.

Which is why, when I was consulting, I did not promise these things, nor did I say things that could be easily misunderstood to imply them.

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.

It's not ideal for a number of reasons.

Fuck these guys. This isn't the first time they've been caught being dishonest and deceptive:


> 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?

Another day, another Zoom issue.

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.

What are y'all using now?

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.

tl;dr of your comment is "I don't care about privacy, if the product works".

But privacy is not about those privileged enough to where privacy doesn't matter.

I don't care that you don't care. Privacy matters.

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.

> The Intercept didn't care about Zoom a few months ago and wouldn't have without Corona.

The 2019 Zoom vulnerability[1] was a much bigger deal and did get picked up by the media. Zoom already had a terrible reputation before COVID-19.

[1] https://news.ycombinator.com/item?id=20387298

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.

Most of the articles over here in Germany don't even mention the last fuck up and the news about the company are now beyond the tech media.

You may not be convinced even after you attributed to my argument but it won't change anything about the facts.

Edit: since I can't post in god knows how long due to the wonderful stfu tech here on hn here are sources for german media:


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.

> the news about the company are now beyond the tech media.

I searched around a little and neither this nor the recent Facebook story have been covered by Danish non-tech media at this time.

EDIT: The story is still new, it might get coverage later this week.

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.

Not sure what your point is... are you defending Zoom's behavior here?

I must say that Google Meet has been a smooth experience at work, but if I had to go with a privacy-focused solution, that'd be Jitsi and not Zoom.

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).

When our company picked up Zoom we did a test and had 100 users all on camera and it worked flawlessly.

We had 500 people on a meeting yesterday. Not all broadcasting, but plenty still sending video. Works just as well as a 3 person call.

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.

That was a cool product. Sigh.

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.

I dont know, their competitors are probably the reason for their popularity. It’s definitely a space with a lack of genuinely UX focused competitors.

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.

Honest question, what do you find is better about zoom? Compared to webex, skype, slack call…

What do people like about zoom?

It works.

1. It's actually cross-platform:

- 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.

> It works.

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.

[0] - https://gist.github.com/chitchcock/1281611

None of their dark patterns or shenanigans make it easier to use. They don't make it harder, but they really do nothing for the user experience.

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)

>Still can't use Webex across Linux, Windows and Mac in 2020.

Have you tried just running webex in a browser? Works fine for me on Chrome in windows or linux

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.

I think seeing up to 25 people in Gallery view is the default but there's a checkbox to enable seeing up to 49 people.

Schools like it because it can handle hundreds of participants in a single meeting and you can pay for extras to handle over a thousand.

It works.

I tried multiple other tools over time, zoom was the first one where all attendees had it working on all systems without problems.

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.

Gallery view, you can see everyone at once - we have All Hands where you can flick through the whole company (~75 people) seeing 25 at a time.

Hangouts hides people in meetings with more than about 5, so psychologically you don't even realise they are there.

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.

I've always understood E2E to mean that it's encrypted from one end to the other, without any intermediate decryption stops. This is how https://en.wikipedia.org/wiki/End-to-end_encryption defines it, and has since it was a stub in 2007 (https://en.wikipedia.org/w/index.php?title=End-to-end_encryp...).

Do you have any links for E2E being used in this "older" way?

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?

That’s not the point. If it’s not truly E2E, they shouldn’t market it as such.

“Military grade encryption” might’ve sold better too.

Don't forget another marketing favorite: "Bank-level encryption"

"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.

No, thanks.

Why hire a software engineer when you can just run some ads about the dangers of identity theft instead?

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).

Yes, of course you can. But the recording has to be done on one of the clients.

Then the other client can download the video via the same e2e tunnel.

You can always record at either end.

"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.”

Would they lose even one sale if they said this?

> E2E now requires that only the participants be able to decrypt the content

That is the literal meaning of the phrase "end to end"... There is not much room for ambiguity there

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.

[0] https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...

> 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.

While I think people need to chill out on Zoom I can't find any alternative standards for end to end with HIPPA. Zoom fucked up here.

??? 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?

Yeah, without a single citation supporting the existence of this imaginary "older definition" of E2E encryption.

The “EARN IT” act of 2020, possibly?


Have you been introduced to our new comment lord and savior, sentiment-based NLP models adjusted to context?

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!

e2e always meant e2e. What you are referring to is transport encryption, which as seen doesn't mean execatly the same thing.

Absolutely. What zoom is providing is really a P2P encryption using TLS.

No, they are providing "P2S" encryption. Peer-to-Server. Huge difference.

>> 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).

I think the answer to your first question is yes.

It puts the negative reporting on all other tech companies that start to see success in context.

Remember what they did with Facebook?

It’s how the outrage made operates

That's messed up, how could the security community have allowed such ambiguity in terminology?

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.

The "security community" was always clear and unambiguous, but the marketing department aren't quite so precise.

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.

It is possible to have conference calls with e2e encryption.

Many conference 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 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.

How stupid the WOT may or may not be affects my point about what the phrase "e2e encryption" means not at all.

I used wire before is opensourced parts of the backend. I thought it was well designed and interesting.

They claim to be the only video conferencing with end to end encryption that is opensource. https://wire.com/en/features/encrypted-voice-video/

Has anyone followed wire more closely?

I've heard nothing about Wire recently.

Wickr.com is another similar service that claims to be end-to-end encrypted, but again I haven't seen much about them at all.

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.

According to this survey of SRTP security: https://tools.ietf.org/html/rfc7201 some sane options (AES-GCM and to a certain extent AES-CCM, but AES-SIV would have been better) are available, defined in rfc 7714. I have found this post from 2017 indicating that GCM support exists in the webrtc library: https://groups.google.com/forum/#!topic/discuss-webrtc/fz3kh...

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.

SRTP also leaks metadata all over the show: https://webrtc-security.github.io/#4.3.4.

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.

Sorry I'm just getting to this now.

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.

Also, please don't repost comments that were flag-killed (https://news.ycombinator.com/item?id=22738656).


Zoom has received a fair bit of critical feedback lately. Has anyone given other platforms such as Vidyo identical levels of scrutiny?

TBF it's mostly short sellers doing this, because the complaints have been... poor.

The first one was about an advertisement pixel, which everybody is doing but for some reason surfaced only for Zoom.

The second one is end-to-end encryption, which is not expected at all for VC apps. NOBODY does it!

>NOBODY does it!

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.

Where does it say they have e2e video encryption? I can only find something about chats.


"Achieve HIPAA (signed BAA) and PIPEDA/PHIPA compliance with complete end-to-end 256-bit AES encryption."

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.

What if one pays $200/mo for the HIPAA-compliant plans?

I really hope that this stupid "short seller conspiracy" meme is going away soon.

According to the article Apple does end-to-end encryption for video conferences. Also other providers are not lying about it like zoom does.

Apple has a VC product? I wasn't aware of this

FaceTime can do group chats since 2018.

> NOBODY does it!

Google Duo does.


It is not a VC application, it's a user chat application

You can have a group call with up to 12 people now. https://www.neowin.net/news/google-duo-now-supports-up-to-12...

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.

Name one provider that claims to provide end-to-end encrypted video calls but doesn't.

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.

1. https://support.goto.com/meeting/help/security-faqs-g2m05001...

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.

To add on this, an encrypted stream with a variable bitrate encoding allows to guess the amount of transmitted information entropy.

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