Aside from the obvious flaws (Threema isn't secure: https://breakingthe3ma.app/), this is LARPing: the author wants to keep his chats secret, but he doesn't discuss why and from whom. This is amateurish, as your efforts should be defined by the threat model, not the other way around. How much effort is your attacker capable of? How much effort are you willing to spend on opsec, a notoriously hard and inhuman task?
There's a whole difference if you want to keep your affair secret from your wife, your small-time weed dealing from the police, your spy ring from the FBI, coordinating anti-Russian attacks in Ukraine, or a Chinese resident resisting the regime.
The author is simply sharing their preferred messaging apps, and they describe the criteria used. Sure it's not an objective in-depth security analysis or a result of professional audits but it's also not claiming to be those things, right?
Understanding the threat model isn't an "in-depth security analysis", though. It's just a matter of understanding why you care about secure apps - who you want to be secure from. If you don't know that, then these are just toys, and you're just playing.
The introduction implies some level of security analysis based on the list of "criteria" (e.g., "does not expose personal information" and "does not leak data") and the "testing setup" link.
That's exactly my point. Ask the author. They implied that they did some analysis beyond trusting claims made my developers, but there aren't sufficient details.
Really great list. Thank you. Some of these I wasn't even aware of. I've been using Session for about a year. A year ago it definitely had some missed messages and I was about to ditch it but I held strong and haven't experienced that issue in a while. Been flawless for about half a year. The Oxen/Loki network overall https://oxen.io/ is a really interesting alternative to Monero and Tor. It's interesting how it can be both!
Indeed, but the man hours involved was quite surprising to me. Some work was per platform, some per cellular provider, some per country, etc.
Also it's less confusing for users if they can say "if you use signal, it's encrypted", unless of the confusing and hard to support decision tree, which is made doubly confusing because Signal uses phone numbers are part of your identity.
The virtue of it was that you could tell your less-clued-in friends and relatives to "just replace your SMS app with Signal and use it all the time", and they would; the hope being that mass usage would create a virtuous smokescreen of innocuous encrypted communication, so that people who actually had secrets to discuss would not stand out.
Perhaps this is less important now that idiosyncratic messenger apps seem to have become well-accepted? I don't know, anymore, how easy it would be for the NSA or some other evil adversary to single out Signal traffic.
Matrix/Element was the best fit when I looked into reasonably private messaging for a small org.
- Matrix has E2EE support, the able to be self-hosted, decent if not perfect clients for all platforms, and an easy to spin up hosted solution through their services company. I think who talks to who could leak, but I think the content is reasonably put into an envelope so to speak. The 2019 security issue seems to have been resolved.
I just wish there was a built-in option for Matrix (Element.io) instances to enforce "only allow E2EE chats". I mean: allowing instances to disable federation prevents some outflows, and E2EE by default is sane, but I want to NOT allow users to accidentally (e.g., in ignorance) click the toggle switch that turns off E2EE for communication chats that they create.
BIGGEST FEEDBACK ON MATRIX/Element: I really think this "only allow E2EE" should be part of the protocol somehow (as an option for instances), and not just a server customization/implementation detail.
--> I haven't had the courage to contribute this meek suggestion to "More Instant Messaging Interoperability (MIMI)" [0, 1], but does anyone know if it's being talked about? Does this make sense? It seems sort of obvious to me.
This list was nice to learn about some apps I wasn't yet aware of. One thing the author mentioned as a "con" a couple of times is "No option for automatic deletion of messages". It might be worth noting that no app can provide automatic deletion of messages. Yes there are some apps that have messages disappear after a time but there is nothing stopping those messages from being saved by the other party before that time. If not a data export then a screenshot, and if not a screenshot then a camera pointed at the screen. If the message is to be consumed by a human then it can be recorded.
The threat model that's addressed by deletion of message is the seizing of one's device by a hostile party (eg dictatorship). One cannot be incriminated by messages that have been deleted.
As you pointed out this will not help if your correspondent cannot be trusted.
Right, disappearing messages aren’t a safeguard against a malicious recipient, they’re a blast radius limiter on future device compromise on either end.
The purpose of automatic message deletion isn't to protect you from someone actively trying to record your messages, it's to limit both parties liability in the event one or both parties are compromised by a third party after the fact.
The telecom industry runs around the legacy SIP/WebRTC protocols. What about these? Both of them can be secured (TLS/SRTP/DTLS), but they are usually centralized.
You could easily spin up some FreePBX server (or similar) and connect SIP devices to talk to each other entirely securely. But calls out to the PSTN are a whole different issue.
> Accounts can only be used on a single device, multi-device support is planned for the future
Can confirm that this is not true. I have multi device set up and it works just fine.
> Files are temporarily stored on a central server (encrypted) until the recipients retrieve them
Not just files, but also your messages. However, it's not as "centralized" as you think. The messages are stored across the Loki network, not just on one centralized server.
> Still new, bugs exists and features may change
Another con I would add is that it is painfully slow. There's often a delay of 10-15 or more seconds between sending a text message and receiving it. Interestingly, media files have about the same "lag". This makes faster conversations difficult, since I would send a message and an older message would backfill in making my message irrelevant. For example, I would receive "I have an idea", send back "what is the idea", but then a few seconds later a message would backfill in and appear before the message I just sent with clarification on the idea.
But that being said, I still think Session is one of the best truly-secure messengers out there. It's bug-free enough for daily use, very decentralized, solves the "offline message" issue. The only concern I have left is their weird crypto integration. The nodes in the Loki network are crypto nodes and it requires staking some $LOKI to join the pool. You do get rewarded for participating in some ways, however.
46 comments
[ 11.4 ms ] story [ 117 ms ] threadThere's a whole difference if you want to keep your affair secret from your wife, your small-time weed dealing from the police, your spy ring from the FBI, coordinating anti-Russian attacks in Ukraine, or a Chinese resident resisting the regime.
https://github.com/TokTok/c-toxcore/releases
https://github.com/TokTok/c-toxcore/pull/2269
Tox is developed entirely by unpaid volunteers which means it will have periods of prolonged inactivity, but it's certainly not dead.
[1]: https://wickr.com/our-focus-on-end-to-end-encrypted-enterpri...
Chitchatter does ephemeral P2P messaging, audio and video chat, and file sharing in a serverless manner.
Also it's less confusing for users if they can say "if you use signal, it's encrypted", unless of the confusing and hard to support decision tree, which is made doubly confusing because Signal uses phone numbers are part of your identity.
Perhaps this is less important now that idiosyncratic messenger apps seem to have become well-accepted? I don't know, anymore, how easy it would be for the NSA or some other evil adversary to single out Signal traffic.
- Matrix has E2EE support, the able to be self-hosted, decent if not perfect clients for all platforms, and an easy to spin up hosted solution through their services company. I think who talks to who could leak, but I think the content is reasonably put into an envelope so to speak. The 2019 security issue seems to have been resolved.
I just wish there was a built-in option for Matrix (Element.io) instances to enforce "only allow E2EE chats". I mean: allowing instances to disable federation prevents some outflows, and E2EE by default is sane, but I want to NOT allow users to accidentally (e.g., in ignorance) click the toggle switch that turns off E2EE for communication chats that they create.
BIGGEST FEEDBACK ON MATRIX/Element: I really think this "only allow E2EE" should be part of the protocol somehow (as an option for instances), and not just a server customization/implementation detail. --> I haven't had the courage to contribute this meek suggestion to "More Instant Messaging Interoperability (MIMI)" [0, 1], but does anyone know if it's being talked about? Does this make sense? It seems sort of obvious to me.
[0] https://mailarchive.ietf.org/arch/browse/mimi/
[1] https://turt2live.github.io/ietf-mimi-matrix-message-format/...
As you pointed out this will not help if your correspondent cannot be trusted.
> It is like a peer to peer messaging app except that there is a server with a messaging queue in the middle acting as a proxy.
Isn't that the definition of not peer-to-peer? I mean at this point, Signal is peer-to-peer as well (except that there is a server in the middle).
A detailed comparison spreadsheet with ordered scoring: https://docs.google.com/spreadsheets/d/1-UlA4-tslROBDS9IqHal...
> Accounts can only be used on a single device, multi-device support is planned for the future
Can confirm that this is not true. I have multi device set up and it works just fine.
> Files are temporarily stored on a central server (encrypted) until the recipients retrieve them
Not just files, but also your messages. However, it's not as "centralized" as you think. The messages are stored across the Loki network, not just on one centralized server.
> Still new, bugs exists and features may change
Another con I would add is that it is painfully slow. There's often a delay of 10-15 or more seconds between sending a text message and receiving it. Interestingly, media files have about the same "lag". This makes faster conversations difficult, since I would send a message and an older message would backfill in making my message irrelevant. For example, I would receive "I have an idea", send back "what is the idea", but then a few seconds later a message would backfill in and appear before the message I just sent with clarification on the idea.
But that being said, I still think Session is one of the best truly-secure messengers out there. It's bug-free enough for daily use, very decentralized, solves the "offline message" issue. The only concern I have left is their weird crypto integration. The nodes in the Loki network are crypto nodes and it requires staking some $LOKI to join the pool. You do get rewarded for participating in some ways, however.
> Quicksy (XMPP) - A fork of Conversations that makes it easy to signup, your phone number is used as your ID. Worth considering? really?
Also, Conversations HAS "Key Change Alerts".