simplexmq

s ok anonymity for web browsing, with only occasional streams being de-anonymised, but it provides really bad anonymity for hidden services, because it is enough to deanonymise one stream to deanonymise the hidden service IP address - which is a catastrophic failure of threat model. So, persistent hidden services simply should not be used as means to provide anonymity, and yet they are used as permanent user addresses in Cwtch... If you think I am wrong, we can debate it further, but you really should not be recommending Tor as panacea without understanding limitations of its threat model. Yet, some people do like using Tor, both to access servers via onion addresses that we provide on preset servers, and to host their own servers, either because they don't understand or because they accept the risks of hidden service deanonymisation. The nice side effect of private routing is that it allows people who don't use Tor, send messages to SMP servers available only as Tor hidden services. > As for the hoops, you know, you can just write an install script for the user to auto-configure this stuff correctly. In its current state it's definitely something an average Joe is going to do. I believe that an average Joe must not host his own server, and for people who understand what they are doing following these steps takes 10 minutes. > If this is there just to shut down criticism, maybe you should instead address the criticism, and make it metadata-private by default, without these insane hoops. Meta-data is private by default, without any hoops, and Tor is not required for it - it is absolutely optional. Tor configuration is only needed to allow users using Tor access servers, and to bridge non-Tor users to Tor servers - so it is about better network connectivity, and not about metadata privacy. > Also, your technical documentation how this stuff actually works has 404 issues Moved to "done" folder, will update. You could have guessed ;) https://github.com/simplex-chat/simplexmq/blob/stable/rfcs/d... It's also included in protocol spec now: https://github.com/simplex-chat/simplexmq/blob/stable/protoc...

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.

to shut down criticism, maybe you should instead address the criticism, and make it metadata-private by default, without these insane hoops. If it doesn't get to the point of anonymity by copying a one-liner that runs an install script, i.e. if it's not on par with sudo apt install simplex, it's not going to catch on. Also, your technical documentation how this stuff actually works has 404 issues https://github.com/simplex-chat/simplexmq/blob/stable/rfcs/2...

u, because they have that & the plaintext anyway.

ng with it - you can connect to the team via /simplex command in the chat (myself or somebody else will meet you there) - you feedback and questions.