If nobody was paying attention, it would not have been a problem. But many people, beyond the niche of technologists and privacy supporters, are misled to see privacy as something that enables rather than reduces crime, and it may have very damaging consequences for democracy – it's a real threat. So this response is necessary. 

 1. Main reasons why the app isn't recommended: Provide a transparency report.

It is available online and updated at least quarterly, or if anything changes: https://simplex.chat/transparency/ 

 2. Company jurisdiction: UK

We disagree that there are any jurisdictions that are particularly good for privacy.

Also, this might important for centralised services, like Threema, where the users can't host servers, and much less important for decentralized network, such as SimpleX, where there are hundreds (if not thousands) of servers that we don't control. 

 3. Cryptographic primitives. Curve25519 / XSalsa20 256 / Poly1305 (downgraded for the absence of PQ encryption).

We added PQ encryption in March this year: https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html

This is done in the same way as Apple describes as PQ3 here: https://security.apple.com/blog/imessage-pq3/

it provides stronger protection than Signal design where PQ encryption only applies to the initial key exchange. 

 4. Directory service could be modified to enable a MITM attack? Yes

This is incorrect, as there is no user directory service at all (and no knowledge of even the number of users), and MITM by servers is not possible by design, even without optional security code verification (that exists to mitigate MITM by the channel you used to pass one-time invitation link, e.g. email). 

 5. Does the company log timestamps/IP addresses? Yes

This is incorrect, we never logged IP addresses and access timestamps of the users.

Further, the private message routing that is now enabled by default for all users prevents such logging by any 3rd party servers with modified code:

https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html 

 6. Is the design well documented? Somewhat

The design documentation was reviewed in preparation for design security audit in July 2024 - report is about to be published. 

 Thanks to our users who highlighted these inaccuracies to us! 

 It is not the same. Build reproducibility means that every time you build the app from the source code you would get exactly the same result, identical byte by byte. It would allow independent parties to validate that the apps that we distribute via different channels are built from the source code we publish.

The problem is that to achieve this quality requires that the build process is deterministic, and in general case it is not:
- some libraries may embed timestamps during compilation.
- compilers my use random numbers for some identifiers.
- etc.

We plan to solve this problem, but it is much harder than it may seem. 

 Opened now again - was limited to 100 responses 

 Please upgrade desktop app to v6.0 as well. 

 If any applicable legislation were to be passed, then we will be getting a legal advice based on its final wording about what is the course of action that is both legal and also benefits our users most.

At this point it would be unprofessional to speculate about it. 

 We love Nostr as a publishing platform that offers unparalleled censorship resistance. But NIP44 does NOT provide most of the important qualities of e2e encryption:

- break-in recovery.
- repudiation (deniability).
- visibility of connection graph to observers.
- fixed message sizes (although it can be provided by the specific app)
- resistance to Shore algorithm (PQ encryption).

It's unclear whether it provides forward secrecy, but the spec implies that it does not - I might be wrong here.

We wrote this post about the qualities of e2e encryption and why they are important: https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html 

 Because I specifically do not want to use any public currency blockchain - I want an accounting method, not money. There many useful legal differences when the flow of money is the opposite to the flow of cryptographic keys. Read the doc. 

 No, not like Session at all.

We are not going to throw away double ratchet, and we are not going to create cryptocurrencies based on public blockchains. If we ever replace double ratchet with any other scheme, we would replace it with the more secure one, not with a less secure one like Session did.

We are moving to a very different direction from Session's: https://simplex.chat/blog/20240516-simplex-redefining-privacy-hard-choices.html

Also, the design of the  private routing achieves the level of metadata privacy that onion routing in Session doesn’t provide - I can comment more on it, but here is the post: https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html

I understand that Session fans might be angry about my criticism of Session, but its crisis is of their own doing - Session's decision to remove double ratchet was a wrong one - users who choose Session need double ratchet, at least.

The path for Session to regain users' trust would be:
1) get double ratchet back, with all its qualities, and figure out how to solve multidevice without compromising encryption security - I’d happily collaborate on that, as an acceptable solution doesn’t exist yet.
2) make node ownership optionally transparent and let clients choose nodes owned by known and different operators (to avoid unknown operators who potentially collude undermining onion routing promises - these promises only hold under the assumption that operators of nodes chosen for the circuit do not collude).
3) decentralise media storage in the same way messages are decentralised - Session may as well adopt XFTP protocol we designed - it's independent from messaging, and that can create some collaboration points too.
4) add a notification when another device access the same profile via recovery code.
5) protect access to recovery code in the app with PIN.

In its current state Session is simply dangerous to use for any scenarios requiring privacy and security.

Solving points 4 and 5 would remove Session from "dangerous" territory and make it simply “not too secure”.  I don't understand why it wasn't already done after the public conversation with Keith several months ago, see the links here: https://x.com/SimpleXChat/status/1755216356159414602

Solving 1 would make it secure. Solving 2 and 3 would make it private.

It's correct to point out SimpleX network limitations, and we work on resolving them.

But by misleading the audience about Session level of privacy and security you are creating risks that may cost some people their lives or freedom - this is really bad for the community and detrimental for your reputation as well. 

 You’re ahead of us - thank you, reposted :) 

 Yes, but in Session it is sadly achieved it at a cost of compromising security - and the recovery phrase is just two taps away, to be copied unnoticeably even by technically incompetent attacker… 

 Repudiation is the important quality for any private conversation - it gives digital conversation the same properties as face to face - you can plausibly deny it. And yes, non-repudiation can be added in the context where it is needed. 

 I don’t think you can equate the amount of metadata available to Matrix and Signal servers with what is available to SimpleX servers - it’s actually less than what is available to Nostr relays users connect to. Putting them in one list, however flattering, implies a similar amount of metadata available, which is very far from reality and is misleading. 

  @Vitor Pamplona Thanks for the suggestions. We did indeed consider various ideas about how to reduce the persistence queue ID, but the to rotate the queues to another server periodically seemed simpler and providing better metadata protection. The current approach also allows some basic protection from resource exhaustion attacks.

What I don't quite follow - if the same key A is used to retrieve the messages how it is any better than having queue ID from the perspective of correlating messages to the users? Wouldn't it still identify the user any better, and now instead of mapping IP addresses to queues, the server could map IP addresses to the messages... Maybe I don't understand what you propose?

The ideas we considered were about trying to avoid any persistent IDs entirely, e.g. via some kind of DHT tables, and something like this might happen in "v3" of the protocols (we are currently still moving to "v2"). 

 Would be good to look at the spec. 

 Yep, there was a broken M1 binary a the one uploaded now is fixed (in 5.3.1) 

 Working on it - this week seems likely! 

 F-droid is always a bit behind, you can check our fdroid repo: https://simplex.chat/fdroid 

 Via export in database settings, but you can’t use one profile in both devices yet 

 I don’t think that marketing Session in competitor’s threads is a viable replacement for lost deniability and forward secrecy, and for the fact that whoever has passphrase can read user’s messages without them knowing. So no, I don’t think anybody needs to use session, even Signal seems a better trade off. 

 Thanks all - got it! 

 Verified! 

 There is a desktop app beta via GitHub releases but it can only work with a separate profile for now - it’ll be announced soon!