I do think there’s a third category there. Saying your product has E2EE when it does in fact not, and then doubling down on it by “redefining” what you think E2EE means is unforgivable. Using ECB mode with AES, for anything but random data (really there’s no reason to ever use ECB for anything), well if that’s not on purpose, then it shows that the developers responsible for that code are pretty incompetent. I really don’t know what else you can “call it”.
It supports Windows XP SP3, Mac OS 10.7 and many distributions and versions of Linux. It supports iOS, Android and even BlackBerry. Among browsers, it supports Safari 7, Chrome 30, Firefox 27 and Internet Explorer 11. In other words, even if you haven’t updated your browser in the last six years, or your operating system in the last twenty, you can still use Zoom!
Is not a good thing as it encourages people to stay on legacy unsupported systems with no security updates whatsoever.
I do think there’s a third category there. Saying your product has E2EE when it does in fact not, and then doubling down on it by “redefining” what you think E2EE means is unforgivable.
Using ECB mode with AES, for anything but random data (really there’s no reason to ever use ECB for anything), well if that’s not on purpose, then it shows that the developers responsible for that code are pretty incompetent. I really don’t know what else you can “call it”.
I don’t really know why anyone would intentionally use less secure encryption. I think this too falls under the category of accidental security flaws.
Now we learn that some calls were accidentally routed through China, that mixed with weak encryption doesn’t sound awesome.
Again, this seems to fall under the category of unintentional vulnerabilities, and so far, it really seems as though Zoom is receiving the criticism well. Of course we’ll have to see how much they actually fix, but then again, it can’t be easy to suddenly go from 10 million users to 200 million.
Is not a good thing as it encourages people to stay on legacy unsupported systems with no security updates whatsoever.
I think we just have different opinions on this. I obviously understand what you mean. But there are few things I dislike as much as arbitrarily limiting people’s freedom in the name of security, especially when it’s my own freedom, and especially when there’s only an indirect, potential threat, of which I am already aware.
I do think there’s a third category there. Saying your product has E2EE when it does in fact not, and then doubling down on it by “redefining” what you think E2EE means is unforgivable.
Using ECB mode with AES, for anything but random data (really there’s no reason to ever use ECB for anything), well if that’s not on purpose, then it shows that the developers responsible for that code are pretty incompetent. I really don’t know what else you can “call it”.
I don’t really know why anyone would intentionally use less secure encryption. I think this too falls under the category of accidental security flaws.
Anyone who is developing software with encryption should know that ECB is a bad choice. Everywhere I’ve ever seen it mentioned, it goes with warnings ie: never use this. Even the Wikipedia article very clearly states the issues with it.
The reason I said it was incompetence is because it shows the developers didn’t do minimal research before implementing this feature in this way. The alternative is malicious compliance. I hope we haven’t forgotten about Bullrun just quite yet.
As part of Bullrun, NSA has also been actively working to “Insert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communications devices used by targets”.
Now we learn that some calls were accidentally routed through China, that mixed with weak encryption doesn’t sound awesome.
Again, this seems to fall under the category of unintentional vulnerabilities, and so far, it really seems as though Zoom is receiving the criticism well. Of course we’ll have to see how much they actually fix, but then again, it can’t be easy to suddenly go from 10 million users to 200 million.
Unfortunately with using services like this, we will never know if certain accounts may have their calls re-routed to less privacy friendly jurisdictions for certain reasons. If it can happen by accident, can it happen on purpose?
Without true E2EE those communications may not be safe.
Is not a good thing as it encourages people to stay on legacy unsupported systems with no security updates whatsoever.
But there are few things I dislike as much as arbitrarily limiting people’s freedom in the name of security, especially when it’s my own freedom, and especially when there’s only an indirect, potential threat, of which I am already aware.
Not all users may be “aware” of the threats. Software should be designed in a way the user does not need to keep track of all that, especially when not all of us have the ability or time to do so. Many of those threats may not be “potential” but in fact very real.
To expect largely abandoned platforms from 20 years ago to still be supported without any kind of support contract, is a form of entitlement. Support for legacy platforms quite often holds back features on newer platforms being developed with a simpler solution. It also expends time in providing a solution that will be compatible with legacy environments. This time would be far better invested on security and privacy in general.
Look, I’m not happy either that Zoom is a non-free, closed-source, non-end-to-end-encrypted service that, in the end, cannot be trusted. But I also realize how difficult it is to develop a good, usable and accessible product with end-to-end encryption. Zoom is doing well at the moment because they have a good, usable and accessible product (and support for old operating systems and browsers is a part of that).
And there’s a difference between security and privacy, which I think shouldn’t be ignored, considering the title of your post is “protecting your privacy”. Governments need security. Normal people primarily need privacy. Compared to popular alternatives, there are some security problems with Zoom, sure, but privacy issues? I don’t see them.
To expect largely abandoned platforms from 20 years ago to still be supported without any kind of support contract, is a form of entitlement.
I’m not expecting anything – you’re the one expecting that they withdraw support.
Zoom is doing well at the moment because they have a good, usable and accessible product (and support for old operating systems and browsers is a part of that).
Going back to your blog article:
It supports Windows XP SP3, Mac OS 10.7 and many distributions and versions of Linux. It supports iOS, Android and even BlackBerry. Among browsers, it supports Safari 7, Chrome 30, Firefox 27 and Internet Explorer 11.
Why stop there? Why not IE6, why not Windows 95. The point is a line needs to be drawn somewhere. I’d also highly doubt anyone was running Chrome 30, why frozen on that particular version? Chrome has always had auto-updates, and Firefox got that in version 15.
And there’s a difference between security and privacy, which I think shouldn’t be ignored, considering the title of your post is “protecting your privacy”.
You can’t have privacy without security. Privacy is obtained through the use of secure features. If it’s not secure it is going to inevitably be exploited and thus not private.
Governments need security. Normal people primarily need privacy.
They need both. That particular statement made me think of this: “we are talking about consumer products and services such as messaging, smart phones, e-mail, and voice and data applications,” and “not talking about protecting the nation’s nuclear launch codes.”
Compared to popular alternatives, there are some security problems with Zoom, sure, but privacy issues? I don’t see them.
A market decision, not a technical one. Look at what people are using, and see what you need to support to get your target percent-of-population-supported numbers.
I just installed Zoom and set up an account 2 days ago to do a few get-togethers with some friends, so I tried to actually read through all of the links:
According to the link on “malicious websites to enable your webcam”, this was from summer 2019. Supposedly they removed the hidden web server and implemented meeting join confirmations with video preview since that was reported. I think I’ll try and check on this myself later. Possibly pending any interesting later discoveries, yawn.
On “use your camera without consent”, we have evidence that the OS X installer is doing some sketchy things, and that there are some local-only privilege exploits. The article is dated April 1, 3 days ago. It also cites an update to the app, released April 2nd, 1 day later, that supposedly fixes these exploits. If the fix is real, fixing in 1 day is pretty impressive, even if the original code that allowed this is disappointingly sloppy. Still sounds like a big meh with all things put together.
On “Windows username and ability to steal credentials” - this sounds pretty weak to me. If you’re 1. On windows, on a domain account, and 2. Your windows domain account has some type of interesting access to internet-reachable servers and 3. Somebody posts a link to a malicious SMB file server in your Zoom chat, and 4. You click on that link, then the owner of that malicious SMB server might be able to steal your Windows credentials and use them to log onto those other interesting servers as you. Zoom’s big supposed weakness is that they make those links clickable. Meh. IMO, this sounds like a weakness for Windows and this SMB authentication, not so much for Zoom. Zoom seems to have responded by de-linking all links in chat. For all of the people who are zoom chatting with malicious people and using text chat on a video conferencing system.
People also seem to be complaining that meeting video and audio are not actually end-to-end encrypted, despite supposed claims. It’s mildly sketchy if they are falsely claiming that it is, but real E2E encryption for such large meetings sounds somewhere between very difficult and impossible to do properly. I don’t know of anybody else doing it. Lots of system seem to be having lots of trouble with video quality and reliability without challenges like E2E encryption. I’m not gonna really fault them for this.
In summary, I don’t see any issues of real concern. I think this is just bash on Zoom for the clicks season. I see no reason to go to the trouble of sandboxing the app. It sounds like Zoom on the whole has responded pretty well to a massive jump in userbase and use cases. Change my mind if you can.
I think the recent spate of Zoom articles/spam is due to bored developers being forced to use it for remote work, running Wireguard on the traffic, and freaking out that they’re forced to use privacy-invading software they presumably had no problems everyone else using in the Before Times.
I certainly agree, the long list of issues (even if some of them are resolved), will contribute to attracting attention to other details that might have been otherwise missed.
I don’t see any issues of real concern. I think this is just bash on Zoom for the clicks season
Considering we have no advertising and make no money from “clicks”, that’s hardly a motivation.
Since this was written, The Intercept also published a piece about their choice using AES with ECB mode, which cannot be explained away with “oh that was an accident”. Everyone knows ECB is bad, especially anyone developing software like this, (well they should).
Considering we have no advertising and make no money from “clicks”, that’s hardly a motivation.
It doesn’t have to be for actual cash money. We’re all writing for attention - myself included. Bashing on Zoom is in style now, so many people will write articles to jump on the bandwagon. The fact that very few of them will make any actual money isn’t really a factor in the phenomenon.
Personally, I tend to be highly suspicious of anything that appears to be a bandwagon.
Since this was written, The Intercept also published a piece about their choice using AES with ECB mode, which cannot be explained away with “oh that was an accident”. Everyone knows ECB is bad, especially anyone developing software like this, (well they should).
I am not an encryption expert. I don’t know if you are or aren’t. But I did see some discussion over on HN from some actual encryption experts. Like tptacek here, and this other thread here. Summary from those in the know is more that getting an actual secure encryption of a compressed AV stream that needs to be decoded on the server for recompression at different bitrates, needs to be encoded and decoded in realtime on thousands of devices, some of which might be pretty slow, needs to support slow, laggy, jittery, and otherwise flaky connections, and needs to support users joining and leaving at arbitrary times, is a very complex task. Shouting ECB is bad because I read it on Wikipedia doesn’t help much.
While I don’t claim to be an expert in any of the technical sub-fields, I have been involved in implementing solutions for large and complex real-world systems like this. Enough to easily envision the difficulties imposed by their requirements, and how inadequate commitment to ideological perfection is in the face of those requirements. There is a real network effect to these things, and a system that works for everybody, everywhere, 100% of the time, seamlessly, despite not being technically perfect, has a completely dominant advantage over technically superior systems that fall short on those other factors.
I had a Zoom party last night, for about a dozen non-technical friends. Everybody’s connection worked, despite old devices, poor internet connections, people entering and leaving at random, a variety of device types and operating systems, etc. I genuinely, politely want to know - what is the superior solution here? Is there something out there with better encryption that will work on everybody’s device the first time with no hassles, even if it’s kind of old or on a poor connection? I haven’t heard of anything that I trust to do that.
Sadly, many students (and non-students) have Macs with 8GB RAM since that’s the default and Apple asks 240 Euro for an upgrade to 16GB last time I checked. A 2GB of 4GB RAM VM will probably slow their machine to a crawl.
Also, assuming that the Zoom Linux client support hardware H.264 encoding/decoding through e.g. VA-API (I don’t know if it does), will that still work in a VM? CPU fans spinning at high RPMs can be very annoying especially if someone also has a bad microphone or noise-cancellation does not work well. I have had to cancel meetings with students in the past, until they had a better setup, because they were inaudible or the ambient noise was so bad that it was impossible to have a conversation.
Alternatives for Mac/Windows: (1) use the web version of Zoom; (2) use Zoom on a phone or tablet (at least iOS has good sandboxing).
(Not saying that using a VM is not a solution, but it comes with strong disadvantages as well.)
Why (practically) no mention of xmpp/jabber? It’s federated, has E2EE support (OMEMO), many FOSS clients and server implementations, and providers generally don’t require any personal info to sign up. The article only mentions that last bit briefly, but instead spends more time focusing on the various walled garden services out there.
It’s not trendy and new? Honestly the only reason I can think why these articles always gloss over it.
From a user point of view, I can see why it struggled. It is old, it wasn’t always great, OMEMO rollout has been slow and steady.
However, if you are writing an article like this you should know that XMPP in 2019 is really good. Services like Conversations make it a program that I use with real people in the real world every day.
Nerds like me use their domain as their ID. Other people just use hosted services. Doesn’t matter, it all works.
Decentralised services are always going to have a branding issue I guess.
It is listed under Worth Mentioning of our Federated section. The reason why it is not a main feature is because client quality is such fragmented ecosystem, and this is due largely to poor quality of documentation. Many of the XEPs still remain in draft or proposed status.
However, if you are writing an article like this you should know that XMPP in 2019 is really good. Services like Conversations make it a program that I use with real people in the real world every day.
The issue is Conversations is the only good client. If there were iOS and Desktop clients as good as that then we would be more likely to make it a main feature.
Nerds like me use their domain as their ID. Other people just use hosted services. Doesn’t matter, it all works.
There is also Quicksy.im by the Conversations author that provides even easier on-boarding for non-nerds but still uses XMPP underneath.
For me the biggest problems with XMPP are lack of good clients for iOS and desktops. There is Dino.im but still in beta and it’s not clear if there will ever be an iOS client with Conversations feature-parity.
It’s not trendy and new? Honestly the only reason I can think why these articles always gloss over it.
I should mention here that is not the case at all. We look at number of factors, including client quality, developer documentation quality, types of ‘footguns’ involved, ie where a user might expect something to be encrypted and in reality it is not etc.
You’re being too kind to XMPP, like PGP it’s another example of focusing on things that are trendy in some FOSS circles and meanwhile losing focus on actually providing value where it really matters to users.
It’s trendy to assume that federation is an unequivocal good thing and centralized services are bad, when looking deeper into the topic reveals it’s a mess of tradeoffs. Every time this comes up, Moxie’s “The Ecosystem is Moving” post is looking more and more insightful.
XMPP, like PGP provides a horrible user experience unless you have extensive domain-specific knowledge. In XMPP’s case, federation is partly to blame for that. Another part is that XMPP is very much a “by nerds, for nerds” thing which comes with a very different set of priorities than anything that aims to be used by most people.
For me the biggest problems with XMPP are lack of good clients for iOS and desktops.
For the desktop there is Gajim (gajim.org). It has OMEMO and works very well with Conversations. I have been using this for years and years, although I can only attest to the Linux version.
Yes, I agree. Gajim is fully featured. It’s not without flaws: outdated UI, OMEMO not built in and enabled by default and apparently no official MacOS version (there is https://beagle.im/ for MacOS though…).
I guess XMPP’s problem no 1 is software fragmentation as there is no single company that’s maintaining full suite of software. It’s always mix-and-match depending on what OS/phone is used by one’s friends.
For me the biggest problems with XMPP are lack of good clients for iOS and desktops. There is Dino.im but still in beta and it’s not clear if there will ever be an iOS client with Conversations feature-parity.
The issue with that is they have no tagged releases, which means maintainers have some ancient random old version or have to keep up to date with every commit. It is unacceptable for something as complex as an instant messenger program to have no tagged release and we believe this because the developers are not comfortable in the completeness of the product to do so.
Because it does not solve any privacy, security or resilience problems from the point of view of individual.
a) Federation is meaningless from resilience PoV since XMPP accounts are not transferable; if someone is targeting me they can take down server I’m using. User or programmer giving a damn about “network being resilient as whole” is irrational. It’s should always be about end-user experience.
b) Until people will figure out how to create Open Incentive-Aligned Cloud Messaging Platform (replacement for FCM and APNS) battery life will suck. Having multiple tcp sockets each with its own heartbeat for every of your apps means short battery life. I want one socket with heartbeat values optimized for network I’m using ATM.
If you want to figure out how to build open replacement for FCM/APNS, I would love to help.
Aren’t all of there points especially worse for the services mentioned in the article? They all depend on a single company, none of the accounts or services are transferable.
Battery life doesn’t ‘suck’. My nexus 5x regularly sees 24hr+ with moderate xmpp usage through Conversations (and no Google play services installed)
I’ve been using XMPP with OMEMO E2EE for about a year now, after a FOSS enthusiast convinced me to use it. I’m using Gajim (https://gajim.org/) pretty much daily now and am quite happy with the feel and performance of the chat. It even has code highlighting blocks and other goodies and addons, and it stores the history in a sqlite database. Apparently it’s also possible to use multiple clients on the same account and the messages go to all your clients once they’re hooked up, but I’ve never tried it myself.
Apparently it’s also possible to use multiple clients on the same account and the messages go to all your clients once they’re hooked up, but I’ve never tried it myself.
It’s not abundantly clear to the user whether their file transfer was sent with E2EE or not. As for VOIP over Jingle, there’s no E2EE to be found there. We believe all channels should be E2EE and not “some features only”.
I’ve been using XMPP with OMEMO E2EE for about a year now, after a FOSS enthusiast convinced me to use it. I’m using Gajim (https://gajim.org/) pretty much daily now and am quite happy with the feel and performance of the chat.
That is the client we suggested for desktop under our Federated section.
We would like to see documentation for MacOS. Pages like https://gajim.org/download/ just simply say things like:
Apparently it’s also possible to use multiple clients on the same account and the messages go to all your clients once they’re hooked up, but I’ve never tried it myself.
Yes, and it works very well. I am using Conversation on my mobile and Gajim on the desktop. Both support OMEMO.
See omemo.top for the OMEMO implementation status across a large number of XMPP clients.
Thanks for the links (and your contribution), interesting stuff. I had a discussion about the recommendations on that site just the other day within my friend group. Most people thought it was confusing that services/software/protocols are kind of interleaved in there. It looks like that’s mostly cleared up now (e.g. instead of promoting Riot, it’s now Matrix).
That said, the blog post mentions Telegram is without encryption by default. While it doesn’t do E2EE, stating it doesn’t do encryption at all is not completely true either. As shady as MTProto is, it does provide encryption. This might just be a simplification catering to non-crypto-savvy users though, but it stood out to me.
I’m really rooting for Matrix, I hope that the client ecosystem becomes more mature so we don’t all have to rely on Riot as much, and that enough people start using it as a “main” IM thing.
Yes it’s been quite a work in progress and has certainly taken me and the team (and our contributors in particular djoate) quite some time.
We will be doing the same to the email section in the coming months. We plan to launch that with a criteria mentioned here. I have contacted all the providers listed, and we will be keeping the ones which meet the new requirements to stay listed. We want to see more providers implement these RFCs or place priority on it as that will be good for everyone.
The deadline given to providers for that is March 2020 to coincide with the deprecation of TLS 1.0 and 1.1 in major browsers.
That said, the blog post mentions Telegram is without encryption by default. While it doesn’t do E2EE, stating it doesn’t do encryption at all is not completely true either. As shady as MTProto is, it does provide encryption. This might just be a simplification catering to non-crypto-savvy users though, but it stood out to me.
One of the things we place importance on is security auditing, as we like to see things are verified. My understanding is that Telegram’s MTProto 2.0 has not been formally audited. I don’t agree with releasing a product first and auditing later. This may make sense from a business point of view, but if people put trust in a product and it then fails them, that could have terrible consequences.
They provide “cracking competitions” which are a bit of a marketing red flag and really don’t add too much value by themselves.
Our site is placing more importance on auditing and formal verification by external parties. We’re doing this because we live in a world where we are swamped with marketing spiel that, you can’t really trust.
I’m really rooting for Matrix, I hope that the client ecosystem becomes more mature so we don’t all have to rely on Riot as much, and that enough people start using it as a “main” IM thing.
I think this is very well a possibility. The spec is in great shape, unlike some other federated instant messaging platforms.
I’ll shamelessly re-post my thoughts on Zoom here and echo the opinion of MasonJar that I don’t see any big reasons for concern over Zoom and privacy.
I do think there’s a third category there. Saying your product has E2EE when it does in fact not, and then doubling down on it by “redefining” what you think E2EE means is unforgivable. Using ECB mode with AES, for anything but random data (really there’s no reason to ever use ECB for anything), well if that’s not on purpose, then it shows that the developers responsible for that code are pretty incompetent. I really don’t know what else you can “call it”.
Now we learn that some calls were accidentally routed through China, that mixed with weak encryption doesn’t sound awesome.
Also your last point there:
Is not a good thing as it encourages people to stay on legacy unsupported systems with no security updates whatsoever.
Well, at least they apologized.
I don’t really know why anyone would intentionally use less secure encryption. I think this too falls under the category of accidental security flaws.
Again, this seems to fall under the category of unintentional vulnerabilities, and so far, it really seems as though Zoom is receiving the criticism well. Of course we’ll have to see how much they actually fix, but then again, it can’t be easy to suddenly go from 10 million users to 200 million.
I think we just have different opinions on this. I obviously understand what you mean. But there are few things I dislike as much as arbitrarily limiting people’s freedom in the name of security, especially when it’s my own freedom, and especially when there’s only an indirect, potential threat, of which I am already aware.
Anyone who is developing software with encryption should know that ECB is a bad choice. Everywhere I’ve ever seen it mentioned, it goes with warnings ie: never use this. Even the Wikipedia article very clearly states the issues with it.
The reason I said it was incompetence is because it shows the developers didn’t do minimal research before implementing this feature in this way. The alternative is malicious compliance. I hope we haven’t forgotten about Bullrun just quite yet.
Unfortunately with using services like this, we will never know if certain accounts may have their calls re-routed to less privacy friendly jurisdictions for certain reasons. If it can happen by accident, can it happen on purpose?
Without true E2EE those communications may not be safe.
Not all users may be “aware” of the threats. Software should be designed in a way the user does not need to keep track of all that, especially when not all of us have the ability or time to do so. Many of those threats may not be “potential” but in fact very real.
To expect largely abandoned platforms from 20 years ago to still be supported without any kind of support contract, is a form of entitlement. Support for legacy platforms quite often holds back features on newer platforms being developed with a simpler solution. It also expends time in providing a solution that will be compatible with legacy environments. This time would be far better invested on security and privacy in general.
Look, I’m not happy either that Zoom is a non-free, closed-source, non-end-to-end-encrypted service that, in the end, cannot be trusted. But I also realize how difficult it is to develop a good, usable and accessible product with end-to-end encryption. Zoom is doing well at the moment because they have a good, usable and accessible product (and support for old operating systems and browsers is a part of that).
And there’s a difference between security and privacy, which I think shouldn’t be ignored, considering the title of your post is “protecting your privacy”. Governments need security. Normal people primarily need privacy. Compared to popular alternatives, there are some security problems with Zoom, sure, but privacy issues? I don’t see them.
I’m not expecting anything – you’re the one expecting that they withdraw support.
Going back to your blog article:
Why stop there? Why not IE6, why not Windows 95. The point is a line needs to be drawn somewhere. I’d also highly doubt anyone was running Chrome 30, why frozen on that particular version? Chrome has always had auto-updates, and Firefox got that in version 15.
You can’t have privacy without security. Privacy is obtained through the use of secure features. If it’s not secure it is going to inevitably be exploited and thus not private.
They need both. That particular statement made me think of this: “we are talking about consumer products and services such as messaging, smart phones, e-mail, and voice and data applications,” and “not talking about protecting the nation’s nuclear launch codes.”
We can thank the media for drawing attention to that or it would be still happening: Zoom Removes Code That Sends Data to Facebook. Zoom Tightens Privacy Policy, Says No User Videos Are Analyzed for Ads. Having read the privacy policy, it is in better shape than it once was.
A market decision, not a technical one. Look at what people are using, and see what you need to support to get your target percent-of-population-supported numbers.
I just installed Zoom and set up an account 2 days ago to do a few get-togethers with some friends, so I tried to actually read through all of the links:
According to the link on “malicious websites to enable your webcam”, this was from summer 2019. Supposedly they removed the hidden web server and implemented meeting join confirmations with video preview since that was reported. I think I’ll try and check on this myself later. Possibly pending any interesting later discoveries, yawn.
On “use your camera without consent”, we have evidence that the OS X installer is doing some sketchy things, and that there are some local-only privilege exploits. The article is dated April 1, 3 days ago. It also cites an update to the app, released April 2nd, 1 day later, that supposedly fixes these exploits. If the fix is real, fixing in 1 day is pretty impressive, even if the original code that allowed this is disappointingly sloppy. Still sounds like a big meh with all things put together.
On “Windows username and ability to steal credentials” - this sounds pretty weak to me. If you’re 1. On windows, on a domain account, and 2. Your windows domain account has some type of interesting access to internet-reachable servers and 3. Somebody posts a link to a malicious SMB file server in your Zoom chat, and 4. You click on that link, then the owner of that malicious SMB server might be able to steal your Windows credentials and use them to log onto those other interesting servers as you. Zoom’s big supposed weakness is that they make those links clickable. Meh. IMO, this sounds like a weakness for Windows and this SMB authentication, not so much for Zoom. Zoom seems to have responded by de-linking all links in chat. For all of the people who are zoom chatting with malicious people and using text chat on a video conferencing system.
People also seem to be complaining that meeting video and audio are not actually end-to-end encrypted, despite supposed claims. It’s mildly sketchy if they are falsely claiming that it is, but real E2E encryption for such large meetings sounds somewhere between very difficult and impossible to do properly. I don’t know of anybody else doing it. Lots of system seem to be having lots of trouble with video quality and reliability without challenges like E2E encryption. I’m not gonna really fault them for this.
In summary, I don’t see any issues of real concern. I think this is just bash on Zoom for the clicks season. I see no reason to go to the trouble of sandboxing the app. It sounds like Zoom on the whole has responded pretty well to a massive jump in userbase and use cases. Change my mind if you can.
I think the recent spate of Zoom articles/spam is due to bored developers being forced to use it for remote work, running Wireguard on the traffic, and freaking out that they’re forced to use privacy-invading software they presumably had no problems everyone else using in the Before Times.
Don’t you mean Wireshark? :-)
I certainly agree, the long list of issues (even if some of them are resolved), will contribute to attracting attention to other details that might have been otherwise missed.
Duh, yeah I meant Wireshark. Too late to edit now!
Considering we have no advertising and make no money from “clicks”, that’s hardly a motivation.
Since this was written, The Intercept also published a piece about their choice using AES with ECB mode, which cannot be explained away with “oh that was an accident”. Everyone knows ECB is bad, especially anyone developing software like this, (well they should).
It doesn’t have to be for actual cash money. We’re all writing for attention - myself included. Bashing on Zoom is in style now, so many people will write articles to jump on the bandwagon. The fact that very few of them will make any actual money isn’t really a factor in the phenomenon.
Personally, I tend to be highly suspicious of anything that appears to be a bandwagon.
I am not an encryption expert. I don’t know if you are or aren’t. But I did see some discussion over on HN from some actual encryption experts. Like tptacek here, and this other thread here. Summary from those in the know is more that getting an actual secure encryption of a compressed AV stream that needs to be decoded on the server for recompression at different bitrates, needs to be encoded and decoded in realtime on thousands of devices, some of which might be pretty slow, needs to support slow, laggy, jittery, and otherwise flaky connections, and needs to support users joining and leaving at arbitrary times, is a very complex task. Shouting ECB is bad because I read it on Wikipedia doesn’t help much.
While I don’t claim to be an expert in any of the technical sub-fields, I have been involved in implementing solutions for large and complex real-world systems like this. Enough to easily envision the difficulties imposed by their requirements, and how inadequate commitment to ideological perfection is in the face of those requirements. There is a real network effect to these things, and a system that works for everybody, everywhere, 100% of the time, seamlessly, despite not being technically perfect, has a completely dominant advantage over technically superior systems that fall short on those other factors.
I had a Zoom party last night, for about a dozen non-technical friends. Everybody’s connection worked, despite old devices, poor internet connections, people entering and leaving at random, a variety of device types and operating systems, etc. I genuinely, politely want to know - what is the superior solution here? Is there something out there with better encryption that will work on everybody’s device the first time with no hassles, even if it’s kind of old or on a poor connection? I haven’t heard of anything that I trust to do that.
Note that it’s much, much simpler to just run Zoom inside Firejail, if you run on a system that supports it: https://github.com/netblue30/firejail/blob/master/etc/zoom.profile
Yep, that’s another way of doing it, sadly many of our readers are students on Windows/Mac based systems.
Definitely see the value in starting with the most widely-applicable approaches; sure.
Sadly, many students (and non-students) have Macs with 8GB RAM since that’s the default and Apple asks 240 Euro for an upgrade to 16GB last time I checked. A 2GB of 4GB RAM VM will probably slow their machine to a crawl.
Also, assuming that the Zoom Linux client support hardware H.264 encoding/decoding through e.g. VA-API (I don’t know if it does), will that still work in a VM? CPU fans spinning at high RPMs can be very annoying especially if someone also has a bad microphone or noise-cancellation does not work well. I have had to cancel meetings with students in the past, until they had a better setup, because they were inaudible or the ambient noise was so bad that it was impossible to have a conversation.
Alternatives for Mac/Windows: (1) use the web version of Zoom; (2) use Zoom on a phone or tablet (at least iOS has good sandboxing).
(Not saying that using a VM is not a solution, but it comes with strong disadvantages as well.)
Or with bubblewrap or via Flatpak (which uses bubblewrap).
Why (practically) no mention of xmpp/jabber? It’s federated, has E2EE support (OMEMO), many FOSS clients and server implementations, and providers generally don’t require any personal info to sign up. The article only mentions that last bit briefly, but instead spends more time focusing on the various walled garden services out there.
It’s not trendy and new? Honestly the only reason I can think why these articles always gloss over it.
From a user point of view, I can see why it struggled. It is old, it wasn’t always great, OMEMO rollout has been slow and steady.
However, if you are writing an article like this you should know that XMPP in 2019 is really good. Services like Conversations make it a program that I use with real people in the real world every day.
Nerds like me use their domain as their ID. Other people just use hosted services. Doesn’t matter, it all works.
Decentralised services are always going to have a branding issue I guess.
It is listed under Worth Mentioning of our Federated section. The reason why it is not a main feature is because client quality is such fragmented ecosystem, and this is due largely to poor quality of documentation. Many of the XEPs still remain in draft or proposed status.
The issue is Conversations is the only good client. If there were iOS and Desktop clients as good as that then we would be more likely to make it a main feature.
There is also Quicksy.im by the Conversations author that provides even easier on-boarding for non-nerds but still uses XMPP underneath.
For me the biggest problems with XMPP are lack of good clients for iOS and desktops. There is Dino.im but still in beta and it’s not clear if there will ever be an iOS client with Conversations feature-parity.
Edit: It seems some members of privacytools.io actually like XMPP: https://github.com/privacytoolsIO/privacytools.io/pull/1500#issuecomment-559405853
I should mention here that is not the case at all. We look at number of factors, including client quality, developer documentation quality, types of ‘footguns’ involved, ie where a user might expect something to be encrypted and in reality it is not etc.
You’re being too kind to XMPP, like PGP it’s another example of focusing on things that are trendy in some FOSS circles and meanwhile losing focus on actually providing value where it really matters to users.
It’s trendy to assume that federation is an unequivocal good thing and centralized services are bad, when looking deeper into the topic reveals it’s a mess of tradeoffs. Every time this comes up, Moxie’s “The Ecosystem is Moving” post is looking more and more insightful.
XMPP, like PGP provides a horrible user experience unless you have extensive domain-specific knowledge. In XMPP’s case, federation is partly to blame for that. Another part is that XMPP is very much a “by nerds, for nerds” thing which comes with a very different set of priorities than anything that aims to be used by most people.
For a different perspective on the subject see “An Objection to ‘The ecosystem is moving’”.
I personally like this one I don’t trust Signal by Drew DeVault.
For the desktop there is Gajim (gajim.org). It has OMEMO and works very well with Conversations. I have been using this for years and years, although I can only attest to the Linux version.
Yes, I agree. Gajim is fully featured. It’s not without flaws: outdated UI, OMEMO not built in and enabled by default and apparently no official MacOS version (there is https://beagle.im/ for MacOS though…).
I guess XMPP’s problem no 1 is software fragmentation as there is no single company that’s maintaining full suite of software. It’s always mix-and-match depending on what OS/phone is used by one’s friends.
Ah, iOS is a big deal. Didn’t realise Conversations didn’t have an app on there.
Yeah. Some people report good results with ChatSecure or Monal or Siskin.im but it seems all of them have minor issues here and there.
The issue with that is they have no tagged releases, which means maintainers have some ancient random old version or have to keep up to date with every commit. It is unacceptable for something as complex as an instant messenger program to have no tagged release and we believe this because the developers are not comfortable in the completeness of the product to do so.
https://github.com/privacytoolsIO/privacytools.io/pull/1500#discussion_r347156496
Because it does not solve any privacy, security or resilience problems from the point of view of individual.
a) Federation is meaningless from resilience PoV since XMPP accounts are not transferable; if someone is targeting me they can take down server I’m using. User or programmer giving a damn about “network being resilient as whole” is irrational. It’s should always be about end-user experience.
b) Until people will figure out how to create Open Incentive-Aligned Cloud Messaging Platform (replacement for FCM and APNS) battery life will suck. Having multiple tcp sockets each with its own heartbeat for every of your apps means short battery life. I want one socket with heartbeat values optimized for network I’m using ATM.
If you want to figure out how to build open replacement for FCM/APNS, I would love to help.
Aren’t all of there points especially worse for the services mentioned in the article? They all depend on a single company, none of the accounts or services are transferable.
Battery life doesn’t ‘suck’. My nexus 5x regularly sees 24hr+ with moderate xmpp usage through Conversations (and no Google play services installed)
I’ve been using XMPP with OMEMO E2EE for about a year now, after a FOSS enthusiast convinced me to use it. I’m using Gajim (https://gajim.org/) pretty much daily now and am quite happy with the feel and performance of the chat. It even has code highlighting blocks and other goodies and addons, and it stores the history in a sqlite database. Apparently it’s also possible to use multiple clients on the same account and the messages go to all your clients once they’re hooked up, but I’ve never tried it myself.
Yeah I use it on my phone and desktop, much like one might use whatsapp and whatsapp web. Only your phone doesn’t have to be on for it to work.
Yep, I believe that’s XEP-0280 ‘message carbons’. Many servers/clients support it.
The other issue we have with XMPP is that E2EE is not consistent. For example file transfer and VOIP.
https://github.com/privacytoolsIO/privacytools.io/pull/1500#discussion_r351079569
It’s not abundantly clear to the user whether their file transfer was sent with E2EE or not. As for VOIP over Jingle, there’s no E2EE to be found there. We believe all channels should be E2EE and not “some features only”.
That is the client we suggested for desktop under our Federated section.
We would like to see documentation for MacOS. Pages like https://gajim.org/download/ just simply say things like:
Yes, and it works very well. I am using Conversation on my mobile and Gajim on the desktop. Both support OMEMO.
See omemo.top for the OMEMO implementation status across a large number of XMPP clients.
I wrote the content in https://github.com/privacytoolsIO/privacytools.io/pull/1500 which became this blog article and was the changes on our website https://www.privacytools.io/software/real-time-communication/
Thanks for the links (and your contribution), interesting stuff. I had a discussion about the recommendations on that site just the other day within my friend group. Most people thought it was confusing that services/software/protocols are kind of interleaved in there. It looks like that’s mostly cleared up now (e.g. instead of promoting Riot, it’s now Matrix).
That said, the blog post mentions Telegram is without encryption by default. While it doesn’t do E2EE, stating it doesn’t do encryption at all is not completely true either. As shady as MTProto is, it does provide encryption. This might just be a simplification catering to non-crypto-savvy users though, but it stood out to me.
I’m really rooting for Matrix, I hope that the client ecosystem becomes more mature so we don’t all have to rely on Riot as much, and that enough people start using it as a “main” IM thing.
Yes it’s been quite a work in progress and has certainly taken me and the team (and our contributors in particular djoate) quite some time.
We will be doing the same to the email section in the coming months. We plan to launch that with a criteria mentioned here. I have contacted all the providers listed, and we will be keeping the ones which meet the new requirements to stay listed. We want to see more providers implement these RFCs or place priority on it as that will be good for everyone.
The deadline given to providers for that is March 2020 to coincide with the deprecation of TLS 1.0 and 1.1 in major browsers.
One of the things we place importance on is security auditing, as we like to see things are verified. My understanding is that Telegram’s MTProto 2.0 has not been formally audited. I don’t agree with releasing a product first and auditing later. This may make sense from a business point of view, but if people put trust in a product and it then fails them, that could have terrible consequences.
They provide “cracking competitions” which are a bit of a marketing red flag and really don’t add too much value by themselves.
Our site is placing more importance on auditing and formal verification by external parties. We’re doing this because we live in a world where we are swamped with marketing spiel that, you can’t really trust.
I think this is very well a possibility. The spec is in great shape, unlike some other federated instant messaging platforms.