
Messenger systems compared by security, privacy, compatibility, and features - lrvick
https://docs.google.com/spreadsheets/d/1-UlA4-tslROBDS9IqHalWVztqZo7uxlCeKPQ-8uoFOU/edit
======
lvh
This is neat but it has plenty of flaws.

I wish the definitions were spelled out. It says Signal isn't "anonymous",
which I assume means "uses a phone number to find peers". And it has the usual
feature matrix problem: sure XMPP "does E2E". But what does that mean? It
supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and
SCIMP too: but you need to be an expert in messaging schemes to understand how
those are different. None of them implement double ratchets. None of them
implement even close to the privacy features Signal has implemented. But on
this diagram it is clearly better because there is more green and less red.

Another example: "open server" and "on-premise" says nothing about whether or
not you really want to run one of those instances. It just says that
hypothetically one could.

In terms of errors: the linked "E2E audit" for Telegram did not audit E2E at
all, and in fact only cites sources saying that it's probably fucked. Wire has
a real audit that isn't listed. WhatsApp uses Signal, just with fewer of the.

Use WhatsApp to talk to normal people. Use Signal for nerds, and... probably
Matrix for group collab? Or maybe stop caring about secure messages for group
collab so much :-)

~~~
lrvick
Please make comments on individual cells for improvements to be seen/added
more easily. This is obviously big research undertaking that got thrown
together last weekend :)

> Another example: "open server" and "on-premise" says nothing about whether
> or not you really want to run one of those instances. It just says that
> hypothetically one could.

I know a number of people that run matrix.org servers for personal use and
companies. The entire French government runs on riot.im/matrix.org.

When security and really privacy matters, you don't want a third party being
able to push updates to your clients/servers at any time without warning.

> None of them implement even close to the privacy features Signal has
> implemented. But on this diagram it is clearly better because there is more
> green and less red.

What features specifically? Happy to add more columns if signal really has
anything unique to offer here.

The things Signal gets red marks on are pretty fair though imo, and things
others do better.

> Use WhatsApp to talk to normal people.

I think you will find many options above WhatsApp on the list in terms of
security and privacy that have clients that are every bit as simple to use.

Other than their (very) effective marketing advantage, -why- would you
encourage people towards these respective walled gardens instead of more open
alternatives listed?

~~~
lvh
In order to comment on individual cells, we appear to first have to have an
argument about how audits work. You say WhatsApp can only "claim" certain
features as a consequence of it being closed source, but that's because of a
misunderstanding about how audits work.

In a backchannel, as a consequence of this HN article, someone (names withheld
to protect the guilty, they can identify themselves if they'd like) started
looking at Dust and figured out the key store password is a hardcoded, short,
ASCII string and the messages are encrypted with unauthenticated AES-CBC. They
did not need the source code to do that.

JP Aumasson phrased it more eloquently than I could:
[https://research.kudelskisecurity.com/2018/10/02/open-
source...](https://research.kudelskisecurity.com/2018/10/02/open-source-
crypto-is-no-better-than-closed-source-crypto/)

~~~
lrvick
Even if they release all their code at this moment to a dozen third party code
auditing firms, they can then undermine all the verified security with the
next closed binary they release.

I will never use Signal with their current direction and don't recommend
anyone use it, but they get credit where it is due. They actually offer source
code for their walled garden and allow that their basic crypto can -generally-
be verified except for extreme cases like my other comment.

Allo, Whatsapp and other closed systems that give you no reason to trust them
other than faith in the people advocating them and that their engineers got it
100% right. Their claims can't be verified so they can only be marked as just
that, claims.

Sure, plenty of obvious flaws can be spotted without source code access, but
many are hard to find even if you -do- have source code to the point they
would probably have never been found were they not open to allow the right set
of eyes to eventually read the right section of code (Heartbleed etc).

I found random number generation flaws in Terraform I would of -never- found
without source code access. It is for this reason I trust Terraform and
Hashicorp quite a bit. They normally get it right, but are not afraid to have
other people audit and point out flaws because they don't have this arrogant
idea their engineers will get everything right 100% of the time.

Security is -hard- and anyone that thinks they can get it right with a SPOF
closed source approach is more interested in marketshare than security.

Trust, but verify. Likewise if you are not even allowed to verify, you should
instantly distrust.

~~~
lvh
> Allo, whatsapp and other closed systems that give you no resaon to trust
> them other than faith in the people shilling them. Their claims can't be
> verified so they can only be marked as just that, claims.

I have repeatedly refuted that point and you have repeatedly ignored it.

> Sure, plenty of obvious flaws can be spotted without source code access, but
> many are hard to find even if you -do- have source code to the point they
> would probably have never been found were they not open to allow the right
> set of eyes to eventually read the right section of code (Heartbleed etc).

You are implying that no source code prevents you from finding obvious flaws,
and I have given you two counterexamples in a messaging service that came up
in this thread that I had never heard of before. That was casual peeking, not
even a serious audit.

> I found random number generation flaws in Terraform I would of -never- found
> without source code access.

Do you professionally audit software? The fact that you can't find a bug
without source does not mean that no-one can. Project Zero finds bugs in
Windows and Edge every other day that are a lot more complicated than figuring
out what RNG Terraform uses and how Terraform uses it.

> Security is -hard- and anyone that thinks they can get it right with a SPOF
> closed source approach is more interested in marketshare than security.

Since you've impugned my motives in two separate places in that post
(referring to me as a "shill"), I am no longer interested in discussing this
with you. I'm sure people can make up their minds from the thread.

~~~
lrvick
I changed the word "shill" in an edit right after I posted as that was
unfair/unhelpful and realized you might think it was directed at you. It was
not. I welcome this type of debate personally.

> Do you professionally audit software?

I do as a matter of fact. I'll be honest it is normally much easier in closed
products as I know what to look for. It is generally much harder to find flaws
in popular open source systems as someone else has usally long beaten me to
the low hanging fruit in critical codepaths.

I have been burned and seen others burned so many times by closed software and
teams that ship security regressions that I now personally use only open tools
I can audit at some level, or can audit the auditing and reproducible build
process. I have seen "security" companies cut corners too many times in order
to feature farm to trust anything that won't let me see the source code.

I have even professionally audited multiple systems on the spreadsheet myself,
some of which I am aware of vulnerabilities for currently under embargo.

So far you have cited examples which I not only didn't ignore but responded to
in the form of counter examples.

This is however turning into a open source vs closed source debate with
subjective evidence, which in the end always boils down to if you have blind
faith in a small group of people or not.

In the spreadsheet I tried to only include things that could be fairly
objective, but when we get into concepts of trust of binaries and their
authors, it gets muddy to be sure, and we will end up choosing paths based on
our own threat profiles and experience.

This is why I tried to include -everything- in the spreadsheet I am aware of,
so people with threat profiles different than mine can make informed choices.

~~~
tptacek
You professionally audit secure messaging applications? For what kinds of
vulnerabilities? I have turned down invitations to audit some of these
applications because I didn't feel qualified to render an assessment (I've
been doing professional software security assessment, of closed/open source
applications, since 1996). Did you take money for those assessments? Which
ones did you do? I'd like to take a closer look at some of them sometime.

~~~
lrvick
I audit tools myself, my employers, or partners consider and if I find obvious
flaws then I file bugs for those products and generally we either don't use
them or limit their use.

I feel qualified only to certify that a tool is obviously insecure, but I
don't think -anyone- will ever be qualified to solo certify something as
totally secure. (but sadly that is how clean audits are generally read). I
have in the past hired 3-4 audit firms and each would find flaws the others
did not, and that mine did not, but fail to spot flaws that mine did. No one
has the full picture.

The only relevant one not under embargo atm was my recent casual 2-3 hour
audit of Lifesize which I found right away had a number of alarming issues the
company would not address. Some of these may of been found to be non issues
under further inspection, but there was more than enough to assert security
was not a major focus of the platform.

This cursory look was all it took for me to feel confident in ending any
consideration of that product to protect the interests of the entity
considering it.

I reported all these to the company and there was no response for over 90 days
and made my findings public after due warning.

They are available here:
[https://gist.github.com/lrvick/6e600d8484cfb415d1e2b06e8b345...](https://gist.github.com/lrvick/6e600d8484cfb415d1e2b06e8b3452c2)

(reminder: this was only 2-3 hours of work and by all means grain of salt)

~~~
tptacek
I think you probably understand where I am coming from at this point. When I
think about "audits" for secure messengers, I think about professional,
specialized, contracted assessments with dedicated teams of experts (I'm a
little biased, since that used to be my line of work). And my two objections
to this discussion are:

1\. I think LVH is right to point out that "audit" doesn't have much meaning
in the document you've produced; it gloms together assessments of wildly
differing depth and quality and condenses them all to a single pass/fail.

2\. Secure messaging security is _hard_ , much harder than secure transports
(which you alluded to in the other subthread when you mentioned TLS). There
are in fact not that many people in the world who can do a proper
cryptographic assessment of a messenger at this point (not because it's
prohibitively difficult; it should be well within the reach of everyone with a
graduate degree in cryptography who enjoys coding --- rather, just because
it's a specialized skill set that not many people have an opportunity to get
good at). Like I said: I wouldn't say I'm qualified to perform such an
assessment (LVH, different story). And all that "just" gets you the
cryptography! If your messenger gets popular, the framework it's built on
becomes one of the most important targets on the Internet!

So I get itchy when people say things that amount to "I've audited things, I
have an authoritative opinion about this stuff". Probably not? Maybe, but,
like, if we were going to place a bet...?

You can turn that logic around on me. But I'm not the one making an
extraordinary claim. You are. So: what _really_ bugs me is the idea that this
is a problem domain you can reduce to a Wikipedia-style comparison chart. That
kind of chart will get people hurt.

~~~
lrvick
I don't know that I made any extrodinary claims.

You did ask me if I audited things before and I answered honestly. I
frequently report vulnerabilities in a range of open and closed systems and
read a lot about those others find. I also don't consider myself an expert and
generally distrust people that claim they are in this space because it is, as
you say, really hard.

I initially started a spreadsheet to document the very high level objective
traits of messengers I find useful and others found it interesting/useful and
helped extend it.

It is far too much cognitive overhead to do deep dive evaluation of 75+
messengers, but what this list allows one to do is quickly eliminate services
from consideration that lack features vital to address their use cases,
platform targets, or threat profile: for instance the ability to self host, or
end to end encryption.

From there once you have your short list, you can then make more effective use
of time reading code, doing audits, reviewing audits of others.

If a list like this simply makes someone aware of new up and coming projects
in the space, or old ones that have been quietly evolving in capability...
then I feel justified in having shared it instead of having kept it as a
private document of my personal notes.

I for one learned about a number of new projects when putting this sheet
together, and interesting new approaches on solving these problems.

The thing that is pretty subjective about the list is how I sorted items based
on my own research and threat profile.

I won't sit here and say Matrix or briar or any other items near the top are
perfect, or lacks any security flaws. I personally place my bets on Matrix at
this point based on my deep dive evaluation of it and similarly featured
alternatives, but that is subject to change! Others are free to share your
view that a well funded but closed source messenger like whatsapp is the
general best bet.

To sober up on this topic a bit: Matrix has had glaring security flaws in the
past, but also so have the options you personally recommend like Signal and
Whatsapp.

At the end of the day all one can do is collect data, look over all the
options, deep dive into the relative merits and claims of each to the extent
one can, look at the research provided by others, and make a judgement call.

This list should be considered a starting point for research and a way to
discover lesser known projects as it was for me.

It should -not- be seen as an end all "use this it is most secure"
recommendation by any means. Anyone that looks at any one high level list of
binary data points and makes an exclusive choice on that alone is doomed to
shoot themselves in the foot with or without my help.

Hopefully that addresses your concerns about my intent here.

~~~
pvg
_I don 't know that I made any extrodinary claims._

You published a spreadsheet listing messaging apps 'ordered by security' in
which Signal, Whatsapp and iMessage are shown as way less secure than IRC. It
also still says, and you've repeatedly argued here, that things like whether,
say, WhatsApp uses E2E encryption is essentially unknowable.

~~~
lrvick
IRC is lacking in features but setup correctly with modern OTR I stand by it
having easy to reason about security advantages Whatsapp and iMessage do not.
(Usability is another story)

Notably if there was a blackbox audit of Whatsapp or iMessage 6 months ago you
have no path to easily check if a blatant backdoor was introduced in the build
you installed last night. You also can't know if there were obvious flaws in
the code the whole time that would be very hard spot in blackbox testing if
you didn't know what to look for. Maybe the app build from last night leaks
its key intentionally via very subtle steganography in metadata?

Compare to a binary I installed via F-Droid that I can confirm was built
reproducibly from a given git head I can go see the code review for.

To use a simple analogy: I can see the exact ingredients of what went into
-my- meal instead of what went into the meal of the food inspector.

This allows much deeper release accountability and -is- a major security
feature iMessage and Whatsapp lack worth flagging.

Verifying security with source code is hard enough. Without source code it is
substantially harder and I for one have no interest in using or recommending
security tools that fail to be 100% transparent about how they work.

Without source code all we have are claims that can never be thoroughly
verified.

~~~
tptacek
You keep making this argument and ignoring experts who tell you it is bogus.
The whole thread is there for everyone to read; you can pretend you haven't
read the rebuttals, but you can't pretend for everyone else. The idea that
"without source code we can't thoroughly verify things" is false, and at odds
with basically all of modern software security.

~~~
lrvick
Oh, I read them. I simply firmly disagree with them and my personal experience
of 15+ years finding and fixing security issues flys in the face of your
statements. We clearly test software for bugs very differently.

I made specific arguments and use cases to justify my position and you have
simply told me I am wrong without directly addressing them.

Once again, I find the term "expert" overrated. I for one admit I am not an
expert on security, a field that is already hard enough on auditors like
myself without withheld source code.

I have also worked with a half dozen or so security auditing firms all of
which stated source code access would make their job much easier.

It didn't take me hours of blackbox testing for me to find CVE-2018-9057. It
took me 20 minutes of reading code on Github half asleep at 4am because I was
curious about an unrelated bug.

I remain convinced blackbox testing would of very probably never found that
vuln, and even if it did, not in as short of a time period. I trust Terraform
over closed alternatives because it was patched within a couple hours of me
mentioning it on IRC by a peer who submitted the bug report and patch in one
shot. I could verify the source code fix easily and compile the new binary
myself to take advantage of the patch before Hashicorp even merged it.

I can also easily verify there are no regressions in future releases.

Tell me how you go about solving for this or other subtle cases like stego
exfiltration more easily -without- source code. Also how you or your team
could of patched the issue yourself without source code.

If I really solved this the hard way then I will by all means move my security
engineering career to focus more on blackbox testing as you seem to be
advocating for.

~~~
tptacek
It sounds like you're arguing that you'd require source code to see whether
something was using math/rand vs. crypto/rand, something that is literally
evident in the control flow graph of a program. I do not doubt that source
code makes it easier to review code when you're half-asleep at 4 in the
morning.

For your particular example: go download a copy of radare and pull up any go
build artifact and see for yourself how hard it is understand what's going on.

I don't know about your security engineering career, but if you intend to get
serious about vulnerability research, yes, you should learn more about how
researchers test shrink-wrap software. I spent years at a single stodgy
midwest financial client doing IDA assessments to find vulnerabilities in
everything from Windows management tools to storage appliances. It wasn't my
IDA license; I was augmenting their in-house security team, which had 4 other
licenses. This was in 2005.

~~~
lrvick
The primary vulnerability here was that the author used the current time as
the sole random seed for generating passwords. From there the output of a PRNG
-looks- random, but is in fact based on something that happens every day and
thus not really random.

If you can understand a PRNG algorithim and how it was seeded without source
code using nothing but radare faster than I could read the code... then you
really do have some superhuman skill, and most of my arguments fall flat.

Subtle cryprography flaws like this could be introduced intentionally as well
by a bad actor, or pressure from a state actor. They are very hard to see
without source code in my experience.

You just kind of made my point for me, in that seeing the output in something
like radare -is- often much harder to understand what is going on than just
looking at the source code.

Don't get me wrong, I have a deep respect for people that are very good at
finding bugs this way. When you -don't have source code then finding bugs via
methods like this is the only thing you have on the table, and it is
impressive.

What I am taking issue with is you trying to in effect claim that some people
like yourself are so good at blackbox testing that you could find all
potential bugs faster with those tactics than you could reading the relevant
source code.

Consider though that not all researchers work this way. Many bugs have been
found by myself and other researchers I know by simply reading source code, so
your argument that a vendor releasing source code gives it no security
advantage is just not true.

While I am no fan of Signal, the fact they make their source code public makes
it much easier to audit and trust its e2e cryptography implementation than say
Whatsapp. Even the two tools you favor are wildly unequal in transparency and
auditability.

Perhaps the majority of my background working with FOSS software has made me
undervalue blackbox testing and you have made a good argument for it. It would
make me more well rounded and I intend to pursue it.

I think if there is anything you can take from my side of this discussion it
is seeing the value of providing source code to the right eyeballs that know
how to quickly spot certian classes of issues.

That source code in the hands of the right person is a faster way to find some
bugs than one could in a binary reverse engineering environment.

~~~
tptacek
Oh for God's sake, dude. Write a Go program with a function that seeds
math/rand from time.Time, compile it, and then load it into radare. "aa", then
find the symbol for your function, then switch to disasm view and look at the
function.

(The Terraform function you found this problem in is literally called
"generatePassword", in case you planned on writing 6 paragraphs on how hard it
is to find the right symbol to start analysis at.)

This is such a silly, marginal bug, it's bizarre to see you kibbitzing on the
"right" way to fix it (the bug is that they're using math/rand to generate a
password instead of crypto/rand, not that they're seeding math/rand from
time). But whatever! Either way: it's clear as day from literally just the
call graph of the program what is happening.

Your example of a bug that is hard to spot from disassembly is a terrible,
silly example, that I've trivially refuted in just a couple of Unix shell
commands.

I don't think you understand the arguing you're trying to have. I get it:
_you_ have a hard time looking for bugs in software. That's fine: auditing
messengers is supposed to be hard. You don't have to be up to the task; others
are.

------
lucideer
As there's pretty obvious bias showing in the values, some methodology would
be good to accompany this sheet.

e.g.

\- Telegram: E2E Private: TRUE

\- WhatsApp: E2E Private: CLAIMED

These are either both "true", or both "claimed". Pick one.

In particular, what's the definition of the "Open Spec" column? Signal's GPL
spec gets a FALSE here so I'm presuming the definition is something along the
lines of "Spec produced by one ofa group of arbitrarily approved bodies of
which Open Whisper is not a member"

~~~
cbg0
The comments specify what "claimed" means:

> Not possible to verify as application is closed source. Maintainer could
> compromise security at any time without detection.

I think it's useful to have this differentiation, even though technically you
could say E2E is TRUE for both of these.

~~~
drdaeman
Telegram’s state of source code availability (and whenever prebuilt binaries
match that) is a total mess. I think only F-Droid build would qualify, but not
the mainstream sources.

~~~
craftyguy
That argument goes for every floss app. If you download their binaries from a
play store (that is not f-droid), there's no guarantee that what you get is
the same as what the source code would produce. f-droid is not a 100%
guarantee either (e.g. not all apps support reproducible builds), but it's
certainly better than the mainstream play stores.

~~~
lvh
As I've mentioned elsewhere: this is why you audit the apk, not the claimed
source.

~~~
craftyguy
This is why you only use app stores that support reproducible builds.

~~~
lvh
That only works if you trust the store, and you somehow only know how to audit
from source. Neither is true for professional audits: you'd generally start
from the APK anyway, even if it's minified, and in many cases you'd actually
get the source (which is an optimization only, e.g. to make bug descriptions
better/faster).

------
LinuxBender
There is no mention of Mumble (client) or Murmur (server). [1] From a privacy
perspective, I find it superior to everything else. End-to-end voice
encryption with PFS. As much or little server logging as you wish. Super easy
to set up and scales to large numbers of people. I have a few of them running
on VM's with 1GB ram. Only downside for me: It is not as happy-clicky
(frictionless) as discord, yet.

Authentication can be tied into 3rd party apps (LDAP, phpBB, etc) but I have
not tested this yet. [2]

If you try it, use their latest snapshot for server and client. Incredible
sound quality. Nice UI/UX experience. Decent support for game overlays. Very
low CPU usage.

[1] -
[https://wiki.mumble.info/wiki/Main_Page](https://wiki.mumble.info/wiki/Main_Page)

[2] -
[https://wiki.mumble.info/wiki/3rd_Party_Applications#Authent...](https://wiki.mumble.info/wiki/3rd_Party_Applications#Authenticators)

~~~
lrvick
Added!

------
arendtio
Well, that is a protocol comparison. A client comparison would be much closer
to the real world user experience. Don't get me wrong, I am a huge fan (and
daily user) of XMPP, but the best protocol will not be of any use if the
clients are too complicated or buggy to use.

So yes, XMPP supports audio and video calls but finding two different clients
which work on the first try together can be a challenge. Sometimes I wish
there would be some compatibility XEP which defines a common set of supported
XEPs including a test suite to run it against.

~~~
ge0rg
We have the XMPP Compliance Suites 2018[0] providing an overview of protocol-
level specifications that a modern client or server should implement, and
there was recently a nice article[1] for some example use cases.

What is still missing is everything above the wire protocol level. The XSF,
being the XMPP Standards Foundation, is guarding the protocols, and things
like UX and client interoperability are considered as off-scope. However,
there are people interested in these topics as well looking for fresh
collaborators.

[0]
[https://xmpp.org/extensions/xep-0387.html](https://xmpp.org/extensions/xep-0387.html)

[1] [https://www.erlang-solutions.com/blog/21-xmpp-use-cases-
and-...](https://www.erlang-solutions.com/blog/21-xmpp-use-cases-and-the-best-
ways-to-achieve-them.html)

~~~
arendtio
That looks pretty cool. Maybe I should ask SamWhited why they didn't include
OMEMO, Audio and Video Calls as features as he is writing in this thread too
:D

------
otabdeveloper1
Where's the "don't allocate 8 gigabytes and crash the system" feature?

(Yeah Slack, I'm looking at you.)

~~~
toxik
Indeed, and for "compatibility" it doesn't really say anything about the
quality of the software for that system. Signal, for example, doesn't have a
native iOS app and it shows.

~~~
chrisballinger
Yes it does? [https://github.com/signalapp/Signal-
iOS](https://github.com/signalapp/Signal-iOS)

------
rdtsc
It's funny and sad that XMPP hits almost all of the points, has been around
since 1999 and yet every year someone reinvents the wheel and makes another
messenger system. There are what, about 60+ by now.

Granted XMPP is not a messenger it's a protocol and a bunch of standards but
still it's hard not to laugh.

~~~
brianacton
When Jan and I evaluated XMPP in 2009, we found that it was not very mobile
friendly. To provide a couple of examples -- (1) The login path required an
inordinate number of round trips (I think it was 4+). This slowed down login
quite considerably. (2) XMPP is byte verbose and expensive on mobile networks.

We came to the conclusion that XMPP was built for desktop computers connected
to strong internet via LAN connections not for mobile networks. We went on to
invent our own protocol which was byte efficient and minimized roundtrips.

Now take all of this with a grain of salt. It is now 2018 and things have
changed considerably.

~~~
seba_dos1
> that XMPP was built for desktop computers connected to strong internet via
> LAN connections not for mobile networks

Oh it definitely was. However, extending it to work well on mobile devices
without throwing the whole protocol away turned out to be feasible.

------
proaralyst
I would like to use Riot/Matrix but its UI (at least on Android) is terrible.
I can't convince non-technical friends & family to switch.

Part of the problem is the inability to assign nicknames to contacts, so you
have to remember everyone's Matrix ID.

~~~
electrograv
For me, the problem is how _incredibly slow_ Riot is (and every other client
I've tried has almost unusable bad UI, sometimes in combination with being
slow).

IMO: Text chat with a few emojis and images here and there should not _ever_
be among the things that slows your computer to a crawl.

EDIT: I'm speaking of the UI, not the network connection; the latter is
sometimes slow too, but that's understandable

~~~
ATsch
It's very likely that what was slow there was not riot, but the server. The
Matrix.org homeserver is notoriously overloaded.

~~~
seba_dos1
Matrix.org is so slow it's borderline unusable, that's right. However, while
switching to another homeserver (and avoiding federating with big rooms like
Matrix HQ) helps a lot, Riot isn't exactly a lightweight client as well.

------
fyfy18
Are there any good XMPP clients that provide a "modern" messenger experience?
For example seamlessly switching between online/offline mode, built in audio
and video calls, sharing photos/videos.

~~~
pmlnr
Cross platform, closed source, including Jingle (audio/video):
[http://astrachat.com/](http://astrachat.com/)

Android (no audio/video):
[https://conversations.im/](https://conversations.im/)

Web: [https://conversejs.org/](https://conversejs.org/)

Web with extras: [https://movim.eu/](https://movim.eu/)

Desktop (Mac): [https://adium.im/](https://adium.im/)

Desktop (Win): [https://gajim.org/](https://gajim.org/) (not sure about this)

Desktop (Linux): [http://pidgin.im/](http://pidgin.im/) (needs extras:
[https://petermolnar.net/instant-messenger-hell/#extra-
plugin...](https://petermolnar.net/instant-messenger-hell/#extra-plugins-for-
pidgin) )

~~~
vader1
Pidgin is barely maintained for the last couple of years and doesn't support
most modern XMPP extensions. I'd definitely recommend Gajim on both Windows
and Linux, which supports everything you need out of the box.

~~~
pmlnr
> doesn't support most modern XMPP extensions

Hence the link for extras, but it is a valid issue. Gajim is XMPP only, where
Pidgin is multi-protocol, which is the main reason why I'm still using it.

------
CiPHPerCoder
> Signal --- Introduced: 2017

What [https://signal.org/blog/the-new-
textsecure/](https://signal.org/blog/the-new-textsecure/)

------
swiftcoder
What is the data source for all of these? I'm particularly curious about a
number of the "claimed" entries.

~~~
ub
+1 It seems like someone just created a spreadsheet with no description of
what methodology was used to test the assertions.

~~~
lrvick
If you click the cells you will see the rationale for columns or what
"claimed" means etc.

------
akareilly
Here's another scorecard:
[https://www.securemessagingapps.com/](https://www.securemessagingapps.com/)

The EFF doesn't do recommendations for all users - whether a messenger works
for someone depends on their threat model.
[https://www.eff.org/deeplinks/2018/03/why-we-cant-give-
you-r...](https://www.eff.org/deeplinks/2018/03/why-we-cant-give-you-
recommendation)

------
pmontra
A missing column among the Features is if a system allows automation (chatbots
or other). Notable examples: Telegram and FB Messenger do, WhatsApp doesn't
(there are workarounds but they're mostly against the Terms of Service.)

~~~
lrvick
Great suggestion. Will add this.

------
SamWhited
XMPP is a protocol meant for building chat services; some of these others are
chat services themselves so eg. it doesn't make sense to say that XMPP is not
e2e by default (of course it's not, it's a protocol which may or may not be
used to build an e2e encrypted chat service). Maybe that should be changed to
"Jabber" which is what a lot of people call the public, federated network of
servers built on XMPP these days? (The term has all sorts of other historical
baggage and some people use XMPP/Jabber as synonyms, but mostly I think people
use Jabber to refer to the public network these days and XMPP to the protocol,
rather like email and SMTP).

------
turdnagel
Surprised public API availability is not listed.

~~~
mappu
This is a pretty important category for me. Users are actually pretty happy to
migrate to new chat systems (with clear benefits) if you can pull off a
gradual migration with seamless chat linking.

I did a gradual migration of our group chat from $LEGACY_CHAT_SYSTEM to
Telegram because at the time, all the options with better crypto stories fell
down; WhatsApp is very anti-bot, Wire's API was unusable on free accounts,
Signal's group chats work differently / would've needed O(n) phone numbers,
Rocketchat's IRC integration was incompatible, Matrix couldn't be simplified
to hide the federation for standalone, etc etc.

------
John_KZ
There still isn't a popular messaging and voice call platform that supports
private end-to-end encryption by default. How terrible is this? I mean it
would be so trivial to establish a secure and private communications standard.
Europe and North America has a population of almost a billion people combined.
If 500 millions of those live in first-world conditions and only 1% cares
about privacy, with $1/year worth of giving a fuck we could have a budget of
$5M/year, or close to 50 top notch developers to pull this off. Obviously a
lot more could be spend, but even with this minuscule spending we could still
have a viable, standardized alternative to Facebook and Google.

We literally had better privacy when we had analog phone lines that anyone
could tap into. That's just terrible.

~~~
lucideer
WhatsApp does but the author of this sheet has chosen to list it as "claimed",
despite other also-unverified clients like Telegram getting a "true" for their
(non-default) e2e support.

FWIW I believe Riot/Matrix are planning e2e by default as soon as their
implementation stabilises. Theirs is more complex/powerful than WhatsApp's
though since they have multidevice support (which WhatsApp lacks). They've
avoided making it default sofar due to bad UX and the possibility of losing
access to conversations across devices, but it's improving rapidly.

~~~
amandine
Yup planning to get it on in the coming months. As a data point e2e by default
is on for the French government deployment and we haven't seen huge drama, so
we're mostly waiting to get the UX out. We'll be sharing our work for insights
this week.

------
Peskier
Maybe we could add a section regarding Api's, developer features or available
authentication methods?

------
oropolo
With categories emphasizing security, open standards, and audited code, I'm
surprised SpiderOak's Semaphor isn't on this list:
[https://spideroak.com/semaphor/](https://spideroak.com/semaphor/)

------
nolok
There are two "Line" listed, is it a mistake or are there really two of the
same name ?

Because LINE claims to support E2E by default ("Letter Sealing"), but only one
of those two listing says "claimed" (the other say false).

------
bootlooped
Kakao Talk has claimed to have E2E Encrypted chat at least since 2014; it is
not on by default.

[https://www.pcworld.com/article/2856452/kakao-talk-adds-
secr...](https://www.pcworld.com/article/2856452/kakao-talk-adds-secret-chat-
feature-amid-privacy-worries.html)

[https://techcrunch.com/2014/12/07/chat-app-kakao-talk-
begins...](https://techcrunch.com/2014/12/07/chat-app-kakao-talk-begins-
offering-opt-in-encryption-following-recent-privacy-storm/)

~~~
daurnimator
Amended.

------
tanderson92
The spreadsheet seems to be missing e-mail.

------
paxy
What's the difference behind TLS "true" or "claimed"? It's pretty
straightforward to verify all outgoing requests the client is making without
looking at source code.

------
mxuribe
So, riot/matrix, nextcloud/talk, briar, and xmpp should merge together into a
super-mega-awesome-protocol and transform into mega-message! ;-)

------
momentito
Have your tried Grape (chatgrape.com)? On-Premises and Eurocloud, used by
banks, telco providers, city departments, energy providers etc. in Europe

------
ac4tw
Interesting comparison Irvick. Enjoying the resuling conversation too. More
detail on meanings and methodology would be helpful as some other HN folks
suggest.

Stealthy.im isn't mentioned (I develop that presently).

Stealthy makes use of decentralized identity in the blockchain and a
decentralized storage system called GAIA. Regular chat is E2E encrypted using
ECIES. Currently released for Android and iOS.

------
codedokode
I think Tox should be higher than Jabber. With Tox, there are no servers and
contact list is stored on your device. With Jabber, it is stored on the server
(and will be happily provided to NSA when needed). So unless you deploy your
own Jabber server, it provides less privacy.

Regarding Wire, is not contact list stored on Wire's server? Then it is even
less private than Jabber.

------
unsignedint
LINE E2E are "Partial Claimed" their E2E encryption only encrypts text and GPS
location and other are not encrypted.[0]

[0]:
[https://engineering.linecorp.com/en/blog/detail/65](https://engineering.linecorp.com/en/blog/detail/65)

------
bkfh
I came across Tungsten Messenger the other day and it's supporting even
multiple personas (public, private) and runs traffic via Tor. Pretty neat UI
and the team is throwing out new features regularly:
[http://tungstenapp.com/](http://tungstenapp.com/)

(Edit: typo)

------
p4bl0
Nice. It's missing RetroShare (which is not only a messenger system but can be
used as one) :).

------
tooker
[https://forsta.io](https://forsta.io) is missing.

------
geoah
This is great thank you!!

Would love if the decentralised/federated were two distinct columns. :D

------
amckinlay
Is there any messenger that does end-to-end encryption with reliable, in-order
delivery with decentralized group chat and conversation history syncing? Been
looking for years but so far the double-ratchet is inadequate.

~~~
LinuxBender
Mumble / Murmur are close to this, but without chat history syncing. End-To-
End PFS encryption though. Very decentralized, but you can tie it into ldap
and other authentication systems. I linked in another part of this thread.

------
singhrac
Does anyone know what supports E2E encrypted video? (Great doc btw)

~~~
CodeArtisan
Wire [https://wire.com/](https://wire.com/)

~~~
datamoshr
Wire comes with a short-fall by virtue of the fact they store a lot of
metadata about you.[1]

Obviously your threat model informs this.

[1]:
[https://twitter.com/tqbf/status/862394778331361281](https://twitter.com/tqbf/status/862394778331361281)

------
jplayer01
A flawed document like this does far more harm than it does good. I'd implore
the author to take it down before they mislead people into drawing the wrong
conclusions.

------
jstanley
What does "E2E Audit" mean? Or, why does Ricochet have a "false"? The Ricochet
codebase has been audited, if that's what it's supposed to mean.

~~~
jhammons
I think it means two parties can verify their public encryption keys with one
another.

~~~
jstanley
E.g. by comparing them in person? Ricochet can do that. The "Ricochet ID" is
just a hash of the public key, so if you meet up in person and verify that you
have added the correct ID for your counterparty, that sounds like you've
verified the public keys, no?

------
pricechild
IRC is listed as "E2E Private" true?

~~~
geoah
I assume it depends on the client?

~~~
pricechild
If you can communicate random text, you can layer E2E encryption over almost
any communication medium. OTR is a great example of this. But it isn't a
feature of the protocol.

Many irc servers listen on an ssl port, but this then only encrypts data
between client and server. The data is decrypted on the server and sent to
other clients. (Maybe encrypted)

Some ircd's support "encrypted only channels" where if you're not connected
via ssl, you can't /join

------
kilare
No mention of Semaphor by SpiderOak?

~~~
lrvick
looking into it and adding it.

------
egypturnash
So many competing, incompatible protocols. So, so many.

Also this is lacking a column for "stickers". Seriously they are one of the
things that has my and my crowd using Telegram, especially since it's really
easy to make your own custom sets instead of relying on whatever they pay
someone to draw for you.

------
saagarjha
iMessage is technically phoneless; you can sign up with your Apple ID on
macOS.

------
gyvastis
Would be nice to show some numbers as well, how much are these platforms used.

------
mirap
Why is Signal scoring so bad?

~~~
fiter
I stopped using Signal due to being bitten by the the issue where a friend
uninstalled Signal without going through a special process and then I couldn't
send messages to them without changing my message type from encrypted to
unencrypted every time. See report/references here[0].

[0] [https://github.com/signalapp/Signal-
Android/issues/8181](https://github.com/signalapp/Signal-Android/issues/8181)

------
crunchiebones
I can't see Jitsi there

~~~
crunchiebones
also, what about 'blockchain messaging' apps like Dust, Echo etc. ?

~~~
lvh
Dust is woefully underspecified and uses an ancient design with no forward
secrecy and no (specified) message or sender authentication of any kind.

Blockchain, as usual, purports to solve a problem nobody had. Dust doesn't try
to address the simplest, best-understood problems we have for reputation
systems on chained blocks.

------
clofresh
Needs to be updated to show which of my friends use which system

------
c8g
nextcloud talk looks good. btw, telegram web has mobile support.

~~~
eeetzatrap
Just installed the Nextcloud Talk App. I'm toes deep, but it looks pretty neat
so far.

------
touristtam
No hipchat from atlassian ?

------
mo3gut
It's amusing that this is hosted by a spyware vendor.

------
lucaspottersky
look at that, XMPP is the future! /sarcasm

