Earlier quoted context omitted.
That you don't like the design is well known. But this is not the reason to lie. You understand the design quite well, from our past conversations, you simply don't like the fact that we don't recognise user IP address as a permanent user identifier on the protocol level. It is indeed a transport identifier, not a protocol-level identifier that all other messaging networks have for the users (in addition to transport…
>you simply don't like the fact that we don't recognise user IP address as a permanent user identifier on the protocol level So how exactly are all those DMCA letters finding themselves to the correct household if IP address doesn't deanonymize you? >Message routing protocol has anonymous pairwise identifiers for the connections between users I'm so tired of you avoiding the obvious question. What does this identifie…
https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
"""
SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a server
* IP address / host name [alice-land.net or similar]
* port
* and hash of the long-lived offline certificate*
* a queue ID
* Alice's E2EE public key.
"""
The queue ID is of interest here. The text also says
"""
When setting up a queue, the server will create separate sender and recipient queue IDs (provided to Alice during set-up and Bob during initial connection)."
"""
---
So the queue is basically a pair of port numbers generated by the server. The server gives Alice queue number pair (a11cea11ce, b0bb0bb0b0b).
Alice's introduction message tells Bob that if Bob puts messages to server's port number a11cea11ce, they are sent to her. And upon first connection to Alice, Bob receives from server queue number b0bb0bb0b0b, and he knows, that when he puts messages to that port, they go to Alice. Since these are used to deliver packets, they can not be used by other SimpleX users. So Simplex has created the functional equivalent of emails user46453451@simplex.com and user2646453@simplex.com for the two users, and the users can use these emails to converse.
The server knows that port a11cea11ce is read by 414.414.414.414 (Alice) and if it's suddenly 414.414.414.224, or tor.tor.tor.tor exit node, it's still the same user, and it now knows that user is trying to become anonymous. If OTOH Alice registered via Tor, if she ever fails at connecting to port a11cea11ce without Tor, she must assume her queue number is permanently deanonymized.
But there is queue rotation. https://github.com/simplex-chat/simplexmq/blob/56986f82c89b0...?
The problem is, if Alice requests a new queue number, she is still connected via the same session and user that was already associated with the deanonymized IP-addrees. The service can just add the new queue-pair as the newest queues associated with Alice's account. Alice can not re-anonymize her account again, the server always knows it's the same user, unless Alice creates a completely new account from behind Tor and starts using new queues. This is why SimpleX should force connections through Tor, but it leaves configuration of proxies to the user. Yet it claims it's supposedly more private than the competition, like Cwtch.
"But the server doesn't know who the people behind the IP-addresses are"
Neither does Signal know who the people behind phone numbers or IP-addresses. But that's not the problem.
The server can accumulate data, and Alice's friendly fascist government can come around asking for these logs. Suppose Bob was apprehended and his device was confiscated and the local FSB wants to know who is behind queue ID a11cea11ce. A malicious server will have accumulated Alice's accidental connection to the service without Tor, so the queue ID a11cea11ce can be correlated with Alice's IP address, and the ISP can tell which subscriber was using the IP-address at the time. Again, defaulting to Tor in clients would have prevented the temptation to aggregate user data on server-side.
So reading your documentation, it's not exactly unclear why my reasoning was wrong. Please do tell me how a malicious server can't correlate IP-addresses with queues when your threat model states https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
"""
The server can
* perform the correlation of the queue used to receive messages (matching multiple queues to a single user) via either a re-used transport connection, user's IP Address, or connection timing regularities.
* learn a recipient's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
"""
Your service doesn't seem to be adding anything ground breaking to the mix with queues. It's not using usernames, or registered accounts. Or phone numbers. It's generating queue numbers that are just random identifiers, that can be used to cross-correlate how may ciphertexts each user sent to one another, and it can bind all IP-addresses to those users. It can't be the case both the IP-address and the queue number changes at the same time, yet the service knows to which user it should deliver an incoming ciphertext.
The bottom line is this. The server that always knows where to relay ciphertexts, can always eventually deanonymize the user, unless the system defaults to Tor.
What is being said on the front page:
>Other apps have user IDs: Signal, Matrix, Session, Briar, Jami, Cwtch, etc. SimpleX does not, not even random numbers.
doesn't match the fine-print under threat model.
So explain to me, why isn't a list of tuples a malicious server secretly builds over time
[
(queue-number1, Tor-IP-address1),
(queue-number1, Tor-IP-address2),
(queue-number2, Tor-IP-address2),
(queue-number3, Tor-IP-address2),
(queue-number3, Deanonymized IPv4 address),
(queue-number3, Tor-IP-address3),
(queue-number4, Tor-IP-address3),
(queue-number4, Tor-IP-address3),
(queue-number4, Tor-IP-address4),
(queue-number4, Tor-IP-address5),
]
not a valid user ID that can be used to deanonymize Alice based on queue-number4 on Bob's confiscated device?
Why is this better than Cwtch where it's just a long term onion address that was never deanonymized? Cwtch didn't require 20 page manual to setup either.