My list of issues with SimpleX has expanded so I’m adding one more post and trying to summarize like @TheDoc asked:
1. The IP-address leakage: SimpleX claims to be an improvement over Cwtch in that the client does not use persistent identity between two users. The CEO admits it’s impossible to deliver the message from A to B with no identifiers, and claims it’s better that the client leaks the user’s IP address to a SimpleX server, than if there was a persistent random contact ID such as 4sci35xrhp2d45gbm3qpta7ogfedonuw2mucmc36jxemucd7fmgzj3ad that hides the user’s IP-address from every contact and third party.
2. The threat-model: Tools are built for purpose, and since no tool is perfect, communicating the limits is important. The more robust security you’re trying to provide, the more important nuance in that communication becomes. Like Bruce Schneier said, “Security is a process, not a product”. Because SimpleX is trying to market itself as more private than Cwtch, it sets itself on nothing short of the ~highest pedestal in the category of metadata resistant messaging. And since that’s a more challenging category than content-private messengers dominated by Signal, that position understandably comes with burden of having to withstand very different level of scrutiny, and people who care deeply about the topic, won’t stand idle if there’s serious issues.
In this top position, having a threat model available is sort of mandatory. Having that threat model be easy to find is a big plus. It shows you care about your users. A major problem here I have, is the SimpleX threat model does not match the marketing material. It again, lies by omission. It is not the case SimpleX has “no identifiers at all”. Sure, it doesn’t add persistent identifiers on application level. But it also doesn’t prevent your router from shipping your IP address to the server inside the TCP headers.
And this is what pisses me off. Nobody who’s looking for metadata-privacy improvement over Cwtch, wants their IP-address to leak. They obviously expect a superset of metadata to be protected. Like added noise packets to hide when communication takes place, and to mask what type of data is being sent. And even if you really, really want to cater to someone who desperately needs fully automated profile-unlinkability, you’re supposed to be extremely open about the trade-off these users are making by using your product over Cwtch, since you’re the one dragging it out for comparison.
So my problem is the lying by omission to the point of active misleading, and the fact they treat the most important security documentation, that tells the users if the tool fits their needs, that they should be presenting proudly, like a cash-grab fine print, as it directly contradicts the front page marketing fluff. When you’re claiming to be on the top, you need to act like you belong there. Or you get called out as snake oil.
So to remedy:
- Have front page link to the threat model that makes a detailed case with warnings to those switching from Tor based messengers, or
- Ensure the front page matches the threat model, or
- Remove Cwtch from the front page comparison.
3. Nonexistent hosting diversity (NEW): The CEO wasn’t being open about the node pool size in this thread, so I did some digging. The documentation says
SimpleX Chat apps have preset servers (for mobile apps these are smp11, smp12 and smp14.simplex.im), but you can easily change app configuration to use other servers.
So if I’m reading this right, the Android app for average Joe who joins the app, has THREE built-in servers to choose from.
No matter if there’s more servers in reality. According to this GitHub issue from seven months ago,
SimpleX Chat currently uses one single hosting provider for all its all servers which is Linode (belongs to Akamai) in its three EMEA datacenter locations: London (15+ virtual servers), Frankfurt (5 virtual servers in the same datacenter) and Stockholm (5 virtual servers in the same datacenter).
Apparently, after that, SimpleX server status page has also listed six Flux XFTP servers, and six Flux SMP servers. Flux is a partnering company.
So unless I’m badly mistaken, there are JUST TWO ACTORS controlling ALL public SimpleX servers: Akamai, and https://runonflux.com/
Two companies that can be issued subpoenas. Two companies that, like VPN companies, will ALWAYS betray their customers rather than go to jail.
The pigeonhole principle states that when there’s three users using the public, non-onion servers, by default, one of the two companies can perform end-to-end correlation attack against two who ended up using their infrastructure.
No wonder I couldn’t get a straight answer about the pool size, and no wonder the damage control comments about pool size not mattering. Sorry guys. No. The metadata privacy of SimpleX can not rely on NSA, FancyBear etc. never gaining access to out-of-band management systems of Akamai and Flux. The SolarWinds Orion breach is a perfect example of single point of failure compromising pretty much every server under the OOB system’s control. And who knows if the data centers have their own instance of a Room 641A.
9229 Tor relays is MUCH better than two massive for-profit third-party companies with their centralized management systems.
But wait, perhaps the community can come to the rescue here? Probably not. The documentation states
not having a single register of such relays is important for true decentralization
So if I’m reading the documentation correctly, the “over 1000 self-hosted messaging relays” are not even listed. They form their own private ciphertext routing networks without contributing to the collective security. Thus, I’m left with three options if I don’t trust Flux or Akamai. I can
A) Install Tor, and use a public SimpleX Onion Server,
B) Self-host my server at home, still leak my IP which my ISP ties to my credit card, or, configure it to be a Tor-only server, or,
C) I can rent a server and yield control to some corporation like Hetzner, that I again, pay with my credit card information, and unless everyone connects to me via Tor, the payment information between personal relays can be cross-correlated by state actors. Again, Tor is needed to hide the metadata of to whom I’m talking to.
So, the solution was, Tor. Which is what Cwtch defaults to.
When I started poking around, I expected to find between 20 and 50 independent volunteers, excitedly hosting their own servers and that SimpleX has a directory from which it picks the server at random from. I sure as hell wasn’t expecting to find “two VPS companies hosting the entire public server infrastructure” lol.
So it’s either A, B, or C. B/C don’t really add anything to the mix unless you just want control over ciphertext caching server.
A is the logical choice, that most users will choose, so I’ll focus on that below.
4. SimpleX could make using Tor trivial if it wanted
The desktop application already seems to have a decent Tor proxy support.
- From the looks of it, it doesn’t phone home before the user can change proxy settings.
- It automatically swaps the connections to Akamai’s servers via Onion URLs when Tor is used. This shows steps have been taken to make Onion Servers a breeze to use. But no steps have been taken to make Tor proxy trivial to setup.
Why not just have a “Use Tor to hide your IP-address from the server” toggle button in the screen where you opt-in into SimpleX or Flux servers?
You could list the pros and cons for each option, “faster, reveals your IP to us”, “slower, hides your IP from us”
If Tor proxy is not detected, (check with something like $ systemctl is-active --quiet tor && echo 0 || echo 1, or, see if you can ping an onion server server through localhost:9050) you can grey it out and show something like
“Tor is not detected. Is it installed and running?”
Desktop client has to just pick the distro and give a copy-pasteable string like “$ sudo apt install tor -y && sudo service tor start” Android client can just link to Orbot in F-droid and Play-store, and to a simple instructions page.
If and when the user manages to get Tor running and they flip the toggle, it’s safe to store the mere two settings it requires
- Use SOCKS5 proxy “yes”
- Use .onion hosts “required”
It really puzzles me you’ve made switching to Onion Servers this easy, then you trip on the finish line.
Hell, you could even just list Tor as a dependency in the .deb file and bundle its installation with SimpleX. Then switching to Tor on desktop would be just that one toggle button away.
The other problem is the client swaps the server so seamlessly it doesn’t even notify you about onion server usage. From what I looked, there’s no way to check if Tor is being used without correlating IPs captured with WireShark. That’s a serious issue when the client doesn’t by design force connections through Tor, like Cwtch does.
It’s nice to get feedback about unidirectional servers with the “Receiving via”, and “Sending via”. But that section should also have something that says
“Connection: No Proxy detected” (red) with info-button stating the IP-address is leaking to the server, and telling to setup Tor or VPN to remedy it.
“Connection: VPN/Proxy” (yellow) when other than localhost:9050 is used.
“Connection: Tor” (green) when localhost:9050 is used.
Also, that segment should show the active Tor proxy setting values:
- Use onion hosts: No/When available/Required (again, red, yellow, green)
- Use random credentials: Yes/No (green, red)
Also, in settings, ensure the user knows proxy settings are an integral part of the security and privacy settings.
If you’d make Tor a first class citizen in the application, it would make writing a threat model that caters to more needs, and that doesn’t have awkward caveats.
But unless you make that “Use Onion Servers” toggle button enabled by default in the Akamai/Flux server selection setup screen, you’re still going to have to fix the front page claim about having no persistent identifiers.
“SimpleX adapts to multiple threat models” is a better selling point than the current caveat ridden hyperbole.