Earlier quoted context omitted.
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!
Zoom meetings aren’t end-to-end encrypted, despite marketing
271–280 of 351 posts
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#272Earlier quoted context omitted.
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.
As far as I know, there's nothing special about telehealth that prevents it from using e2e encryption.
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#273Earlier quoted context omitted.
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 spec…
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?
>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.
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#274Earlier quoted context omitted.
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…
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"…
How stupid the WOT may or may not be affects my point about what the phrase "e2e encryption" means not at all.
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#275Earlier quoted context omitted.
> 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
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#276Earlier quoted context omitted.
Video conferences via WebRTC usually have a central server that distributes all the video streams and are therefore not end-to-end encrypted.
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,
If end-to-end symmetrical is not feasible then use fully homomorphic public key encryption, which will allow operations without decryption.
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#277Earlier quoted context omitted.
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.
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#278End-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 t…
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.
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. ;-)
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#279Inherent 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…
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).
Re: Zoom meetings aren’t end-to-end encrypted, despite marketing
#280Earlier quoted context omitted.
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,…
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.