The need for secure messaging

Whatsapp and iMessage are a duopoly in the instant messaging space which is probably not new to anyone. Meta is known for making money from user data. Living in India means Whatsapp is the primary means of communication. (iMessage not used as much due to the abundance of SMS spams and lack of iPhone users). To my surprise on my PiHole setup one day I noticed a lot of requests being blocked to this domain – dit.whatsapp.com

Looking at the networking tab in my browser while using whatsapp web –

This kind of sent me down the rabbit hole of understanding what this exactly was and made me aware of the DIT metadata system meta engineering blog whatsapp faq post.

It's of course impressive the amount of engineering it takes to deploy such a system at scale. Also is a bit weird that this much engineering effort was put to just collect user data. Even though its anonymous as they repeatedly claim in the blog, and the intention is just to improve the working of the app and do analysis on events such as app crashes, they could change this at anytime since its not open sourced. And as mentioned in various posts such as this and this, its very clear that the anonymous claims aren't very promising either.

If the privacy angle isn't enough to migrate, I think this graph can drive another point home.

For the unaware, Whatsapp Business API is the cash cow which gave Meta multifold returns on their $19B buyout of the business back in 2014. A direct effect of this is very noticeable now after number of years of free use. This is how most people's archived chats look like (if they use this feature like me to basically shove all the businesses spamming ads).
Tired of all this I went looking into various threat models for instant messaging services and found a couple of attack vectors I had concerns over: – Identity registration service – Cloud backup service – Media upload endpoints – Messages service – Audio/Video call service – Push notification service

If one takes the case of Whatsapp or any centralized messaging apps, the claims of end to end encryption can maybe put your worries to rest when it comes to the messaging service but MITM attacks are still a concern as concluded in this white paper.

When it comes to the cloud backup system, that is a major concern due to it being unencrypted by default. In this white paper it is also discussed about some issues with the password attempt count being modifiable –

Tons of folks in the privacy space recommend Signal being the go to with the highly battle tested Signal protocol, but I did want to go full decentralized due to the elimination of any central trust anchor and see how that would work. I think Signal should be sufficient, but now that I am in this rabbit hole, might as well go full psycho.

Now there are quite a lot of great comparisons online such as this, and I was curious to try SimpleX chat out based on its move away from any user identifiers at all. One great thing about this when compared to something like Session is that I am not too fond of the idea of onion routing just because you would be adding your server as a node in the tor network. I would much rather prefer my server just being used for communication amongst my friends and family (one can argue this is less private but I would prefer it this way)

Five out of the six main issues which are mentioned earlier are all basically solved if I go with SimpleX. Why push notifs is still kind of an issue I will get into later. For the more curious folks wanting to do a deep dive into its architecture, please check out their protocol spec.

  1. Starting off with identity registration being the main problem with most apps like Signal/Whatsapp/Telegram, I never understood why phone numbers have to be involved. My idea of an instant messenger would involve sharing some sort of link/QR code with someone you met and can now keep in touch with. This idea of phone numbers being involved in any messaging app will eventually lead them to capitalize on it by sending you ads. (Since your phone number is basically linked to all other services)
  2. Cloud backups as mentioned earlier are a major issue by design because you are basically sending all your chat logs somewhere less secure. Now end to end backups are a thing, but I still would want control over where my backups get pushed to / what I can do with them. A simple export and import option would be great but whatsapp still doesn't allow an easy way to import the exported data.
  3. Support for self hosted messaging service (SMP) and media file transfer service (XFTP) is one of the biggest advantage with SimpleX and removes reliance on any centralized authority.
  4. Audio and video in most modern apps use Web-RTC based communication and in this case we again have the option to use our own.
  5. Push notification is a major problem due to Apple enforcing a closed ecosystem requiring all notifications to pass through the Apple Push Notification service (APNs), which have very strict rules. Unlike other platforms, iOS does not allow apps to maintain direct, persistent connections to custom servers to receive messages, making a custom backend to APNs bridge necessary. On Android, its very much possible thanks to UnifiedPush and other such implementations.

How I Setup SimpleX Chat with custom servers

Now that we have discussed the concerns and understood other options out there, let's set this up so people can use it with their peer groups. I want to keep the setup fairly simple like this –

If you or your peer has this setup already then all you would need is the addresses for the SMP, XFTP and the WebRTC servers and you should be good to go. If you are the first one in your group, then I'm just going to provide some links related to hosting these which you can follow - – Simplex Chat Self Hosting DocumentationSimplex as your private messengerCoturn Docker ImageSmp-server Docker ImageXFTP-Server Docker Image

In my case, due to resource limitations in my vps, I didn't go ahead with standard docker images but instead pulled the binaries out of the docker images and just created systemd services to avoid docker overhead.

Once the servers are setup, can follow the steps below for setting up the client app -

  1. When one installs the app and has created their profile, you are given a choice to choose either SimpleX or Flux servers, can choose either for now, we would not be using these later anyway.
  2. Notification privacy options can be confusing. This is the only service in the app which is not decentralized, due to restrictions enforced by Apple as mentioned before but they do give an option to not use any push servers. I would probably go with the instant option for now since its as secure if not better than other messaging apps.
  3. Once the initial setup is done, we dive into Settings > Network & servers > Your servers and add both the custom SMP and XFTP servers. If using port other than 5224 for xftp then should be mentioned in the address. Here the format is usually: xftp://<server-identifier>@<domain-name>:<custom-port> If using port other than 5223 for smp then should be mentioned in the address. Here the format is usually: smp://<server-identifier>@<domain-name>:<custom-port> Do test out both servers and enable use for new connections
  4. After adding both servers just disable the SimpleX Chat preset server and Save the custom servers. Set the WebRTC ICE servers by adding details for your TURN and STUN servers. The format is usually -stun:<domain>:<port>turn:<username>:<password>@<domain>:<port>
    5. These are some advanced settings that can be applied

    And voila you should have your custom completely private setup running. Now all you have to do is share the qr codes with friends and enjoy super private messaging! More on that here

By – Shaurya

No AI involved in writing these :)