On this page I try to shed some light on the jungle of mobile messaging apps out there. I have also written blog articles about this:
And also some talks:
I focus solely on applications with automatic contact discovery here, because I want to stay close to the SMS or WhatsApp analogy. While there are valid reasons for choosing messengers with custom identifiers like XMPP (I use and recommend Conversations on Android), the barrier to reaching a large audience is much higher. For more background please see the above links.
I try to keep this page up-to-date, but if you see that something is outdated or incorrect, please contact me!
Trust
| Crypto | Client trust | |||||
| E2EE | E2EE default | E2EE group chats | Forward secrecy | Free Software | 3rd Party audit | |
| Yes | Yes | Yes | Yes | No | ? | |
| Telegram | Yes | No | No | Yes | Yes | Yes |
| Threema | Yes | Yes | Yes | Not on E2EE | No | Yes |
| Signal | Yes | Yes | Yes | Yes | mostly | Yes |
| Wire | Yes | Yes | Yes | Yes | mostly | Yes |
| Allo | Yes | No | No | Yes | No | ? |
| Kontalk | Yes | Yes | experimental | No | Yes | ? |
This table gives an overview over how much trust you can put into the application regarding the confidentiality of your messages. You definitely want End-to-End-Encryption (E2EE) to be sure that intercepted messages cannot be read and you also want a Free Software client so that chances are lower they are intercepted before being sent / after being received. Third party audits increase the level of trust, but only if the app is also Free Software. Forward secrecy protects you in the long-term.
Currently Telegram and Kontalk are trustworthy, although both have drawbacks. Signal and Wire both have improved on their Client trust and the clients work on Google-free Android phones, now, but the builds still contain some proprietary dependencies and cannot be included in e.g. F-Droid. Once this gets solved, they would be superior choices.
Metadata and Availability
| Free Software server | Federated system | Notify method | Proxy/TOR support(client) | Alternative Identifiers | |
| No | No | GCM/APNS only? | No | No | |
| Telegram | No | No | Poll optional | No | No |
| Threema | No | No | Poll optional | No? | Custom; E-Mail |
| Signal | Yes | No | WebSocket optional | No | No |
| Wire | Yes | No | WebSocket optional | No | |
| Allo | No | No | GCM/APNS only? | No? | No |
| Kontalk | Yes | partly | Poll optional | Yes | JID |
This table indicates whether you are forced to entrust a single party with your metadata, whether this party shares metadata with Google/Apple and how resilient the system is to failure and/or censorship.
Signal and Wire have improved greatly in this area in recent times. Both now have completely free server implementations that you can host yourself.
However you would loose the ability to contact users on other instances, because there is no federation, something we really need in the long run.
Kontalk has some benefits here, although its federation still has limitations, e.g. encryption doesn’t work with clients outside the official server. Wire and Threema also offer different-than-phone-IDs.
Other features
| Desktop/Web-Client | Multi-Device support | Voice Message | Audio-Calls | Video-Calls | |
| Yes | ? | Yes | Yes | Yes | |
| Telegram | Yes | Not for E2EE | Yes | No | No |
| Threema | Experimental | ? | via plugin | No | No |
| Signal | Yes | limited | Yes | Yes | Yes |
| Wire | Yes | Yes | Yes | Yes | Yes |
| Allo | No | ? | Yes | No | No |
| Kontalk | Yes | Yes | Yes | No | No |
This table shows some features that are not immediately related to security, but might be important to many users.