My list of favorite secure messaging apps | Hacker News Reader

My list of favorite secure messaging apps

supernova.tilde.team

78 pointsSami_Lehtinen43 comments

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.

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.

Right, disappearing messages aren’t a safeguard against a malicious recipient, they’re a blast radius limiter on future device compromise on either end.

For Session:

> 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.

No mention of Tox? https://tox.chat/

The project is 10 years old, still at 0.2 release, which is now 9 months old, and virtually no activity on the repo. Looks as good as dead.

There have been 6 releases in the past year, including a major feature merge.

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.

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.

Great! Some of us like play.

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.

Does not expose to whom? Leak to whom?

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.

What about Matrix/Element?

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.

[0] https://mailarchive.ietf.org/arch/browse/mimi/

[1] https://turt2live.github.io/ietf-mimi-matrix-message-format/...

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!

I've been waiting for Briar to show up for iOS ever since I came across it many years ago.

SimpleX looks too good to be true! It even has terminal client https://github.com/simplex-chat/simplex-chat/blob/stable/doc...

Regarding SimpleX:

> 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).

One of the cons for Signal, sending unencrypted SMS messages is being removed soon: https://signal.org/blog/sms-removal-android/

Bummer. That feature made Signal a really compelling main messenger app.

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.

What about WhatsApp…?

What about it? It's not open source, so shouldn't even be considered.

There are non-open source apps listed in the OP.

Which ones?

Why no mentions of Matrix.org, even if just to explain why it's not mentioned/considered?

A detailed comparison spreadsheet with ordered scoring: https://docs.google.com/spreadsheets/d/1-UlA4-tslROBDS9IqHal...

Since it's relevant to the topic, I'd like to share an open source communication tool I started working on last year: https://chitchatter.im/

Chitchatter does ephemeral P2P messaging, audio and video chat, and file sharing in a serverless manner.

Strange list. Lots of Conversations forks, but not Conversations itself. WTF?

> 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".

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.

Why legacy? They're still current, and WebRTC is fairly recent. The SS7 mess behind PSTN networks is perhaps more legacy.

I miss delta chat in that list. :(

what about jami? https://jami.net

Most of them have not heard of

What do you think of Wickr?

For personal use, it's not long for this world.[1]

[1]: https://wickr.com/our-focus-on-end-to-end-encrypted-enterpri...

sad panda

Is telegram so bad?

Most interesting features of Telegram (everything but secret chats) are not end-to-end encrypted. The server can read them.

Reply on news.ycombinator.com