Article author here.
It actually does work long term I can confirm from personal experience. There is zero issues with this setup as you hold everything yourself. No need for smartphones or keeping phone numbers active which I would argue by that logic many services who rely on SMS/phone number aren't long-term. If you or anyone else sees something that is overlooked, I would be happy to hear your thoughts.
Needless to say Telegram is an awful choice for a messenger in terms of security or
privacy. But if you are forced to use it... as
@Sols said it matters where your friends/customers are. I also agree with his suggestion to get a burner phone if you don't want your number exposed.
In the interest of public safety and how many OCT users blindly use Session I will try to give my personal opinion on this without it derailing the topic as this is can become a really lengthy discussion.
My opinion is Session isn't good enough for privacy or security if you are looking for the very best. If you are OK with any risk might as well use imessage or android sms now powered & "secured" by Google. Just because a few people are jumping on that bandwagon it doesn't mean it is secure - another example for this is Telegram. The minute Session team started with bulls**t wordaround explanation of why you don't need Perfect Forward Secrecy (PFS) that said all you need to know about them. Refering to:
(
https://getsession.org/faq)
Instead of making sure a standard such as PFS is met, they decide to mitigate it in their own way. Let's write our own cryptography, what can go wrong? (too much information to reference, google yourself why not to do it). Who profits from PFS not being integrated? Only one entity and the hint is in this wikipedia article
https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later
What is stopping Session team from having both their own solution and standard PFS? That is why this is fishy to developers, security experts etc. who understand the details of it. In all honesty the people who decide to do cryptography their own way or implement something their own way are the same type of people who say we shouldn't add quantum encryption on top of any protocol because it wouldn't be secure. Makes much logic? Nothing stops anyone (well maybe certain "harvesters of encrypted data" spreading bulls**t) from utilizing both the verified solution wrapped around the experimental one.
Session also being Australian screams major red flags as Australia has some really truly awful anti-security laws when it comes to cryptography. It is no secret Session is referred to as an inferior Signal and even a honeypot. Whether you believe that is up to you to do your own
due diligence and research. I know many users here and other forums use Session but that is the facts of the matter and it is those facts that I form my opinion what to believe in or not.
SimpleX is yet to be proven. Written in Haskell which who uses? Most notably Haskell used by Meta and Wire messenger (another not so secure messenger, for history brief ref see
https://medium.com/@DarKrMsg/the-rise-and-fall-of-wire-messenger-469c9c1da27f). Interesting choice of programming language and seems large project completed definitely doesn't look like a hobby project. This is only speculation of course, I'm only outlining what is written in.
My biggest issues with SimpleX are 3.
1) First one and biggest one is there are NO REPRODUCIBLE BUILDS. This means all of their source code might as well be good for nothing if you can't compile it yourself. I want to the direct everyones attention to:
Quote:
Remember what I said earlier in the post about people making their own cryptography, offering words workarounds of "why not" etc.? We can now add the "we offer a mitigation" to those same group of people just as easily. What is the point of open source when you can't reproduce the builds? In this way Signal are just as bad for not allowing ability to run own servers.
In the end SimpleX team might provide those builds sure but for a privacy & security project and all of this talk of security they fail to do the most simple thing for users to gain trust - verify yourself. This is why users as recent as 4 days ago have asked where are all the "simpleX is honeypot" comments are coming from
2) Second one is they seem to be doing a lot of fake marketing by claiming things like Signal can intercept messages on their website (
https://simplex.chat). Reddit discussion says it pretty much how it is:
In addition I would raise it even further by claiming their table of comparisons on their website is more, lets call it "incorrect":
- XMPP requires phone number as "global identity"? SimpleX answer: Yes. My answer? False. Anyone can register with any server (thousands of them) for free not even email needed.
- XMPP depends on DNS? SimpleX answer: Yes. My answer? False. You can run it under different networks including Tor, where is the DNS there?
- Possibility of MITM? SimpleX answer: Yes. My answer? True and False. It is True standard XMPP can be intercepted in almost clear text however anyone using XMPP today and not in the 2000s, now uses a plugin for security. Up until some years ago that plugin was OTR and now the standard is OMEMO. OMEMO is same one used by Signal. OMEMO doesn't have the possibility of MITM.
3) SimpleX is a fairly new "thing". If 1 & 2 are resolved it would take some time and additional audits of multiple firms and individuals over a longer period to convince me personally to use it. A bonus point to this is it is heavily advertised on certain darknet forums. No wonder why people on the reddit thread I mentioned gives them "anom/encrochat" vibes.
tldr;
If you are looking for alternative that is secure, decentralized/federated then XMPP in combination with a plugin like OMEMO (which is what Signal uses) is the perfect choice. You can register at any server, setup your own server, no IDs, no phone numbers, fully open source reproducible builds, open source OMEMO plugin, battle tested.
