This suggests that everybody is less smart than you, and you know better what should and should not be used.
General Timothy D. Haugh picks up Python on his spare time and writes a messaging app that uses no encryption at all, and that sends all the messages to the NSA by default. On the front page of his NSA Spy Messenger, he writes: “This application is unencrypted and sends all the data to the NSA”
I think this is an application that can be used safely. Why? Because the front page tells you exactly what it does.
It’s the lying, and lying by omission, that’s the problem.
Every technology has its limitation, and nobody should indiscriminately recommend any tech for all cases.
You’re absolutely right. Which is why it’s so important to be upfront about the limitations, even if it hurts you. The point of secure messaging is to protect the user and the user must be informed on the limitations.
SimpleX prides itself with having no identifiers.
Yet the front page says
The first messenger without user IDs
User ID is anything that can ties actions of a user together.
SimpleX user profiles are not assigned any distinct identifiers in the network
So the first messaging app that doesn’t require things like phone number or email? But we’ll just lie by omission and exclude IP address that is often uniquely identifying.
Every server you connect to knows the IP address - it includes your ISP, VPN providers, websites and services you connect to, and even Tor and i2p relays, and your peers in p2p networks.
What? Does duckduckgo.com know my local IP when I connect to it via Tor Browser? Or is your point that the Tor entry node knows your IP? If so, that’s the weakest argument I’ve seen since Telegram’s PhD in geometry. The point of getting rid of metadata is for the client to do what it can to protect itself from server, and the best tech currently in existence is onion routing. That’s the standard. If you want to be able to say SimpleX has no user IDs, you better make sure the most common identifier is handled with best practices. Nobody is asking you to do more.
there is no technology that protects IP address in all cases - and Tor also is not such technology.
Again. Best practices are enough. Users who need more can go wardriving by themselves.
ISP can always do it, but it is not always the case for the third parties.
So be upfront that law enforcement can take over servers and determine users’ real life identities because IP-addresses are not being masked.
Alsos be upfront that smaller authoritarian nation states that compromise the servers can access the logs. Compromising Tor is limited to global passive adversaries like FVEY that can do end-to-end correlation pretty much anywhere.
Security of IP address (and security in general) can be only be discussed in the context of “security from whom” - the whole concept of security requires the presence of attacker.
My point also, I fail to see you providing nuanced threat model that discusses which threats your system protects against, and which it doesn’t.
It is covered on the front-page of the website
Where?
It’s absolutely fine to criticise how we disclose our security limitations
Yes. Why is link to
not on the front page? Surely you’re all for user security and not afraid of being transparent about limiations of SimpleX?
some other comparable service that is as explicit in disclosing it
https://docs.onionshare.org/2.3.1/en/security.html
Second, with the addition of 2-hop routing (aka “private message routing”) in the messaging protocol it is no longer the case
So sounds like you’re fixing the problem with exactly the thing you were supposed to be fixing, with proxy chains. Only, you’re pulling the Telegram move and reinventing the wheel with an inferior design. What is your node pool size? Who is running those pools? Where are they hosted? E.g. last time I checked, Hetzner hosts majority of Session’s onion routing nodes, not exactly a decentralized solution.
even if both servers are operated by the same owner, it would be far from trivial, and it would require server code modifications
Yeah I think you should develop your software thinking the server is by default compromised, and running the most malicious code possible. The system needs to be secure even in that case.
that would be a violation of privacy policy.
So are you providing privacy by policy, or privacy by design? Pick a lane. Obviously the attacker wipes their scrotum with your policy and as for state actors, it’s obviously the opposite of illegal in the authoritarian countries that conduct these kinds of attacks.
Also am I wrong in that there is in fact no onion routing network to the messaging server, but instead, you have two servers run by two independent parties, that route messages. How is this functionally different from decentralized messaging networks like Matrix?
Your front page comparison with other protocols talks about Single or Centralized network for XMPP, Matrix being not secure, as it does not protect users’ metadata privacy. Queues is not the answer. Matrix is not anonymous because two server’s data can be pulled and cross-correlated. That’s how email’s metadata protection sucks. You can go to Google and ask who did example1@gmail.com send messages to, and then Google says that to example2@office365.com, and then they can go to Microsoft to ask for IP logs and determine the contact.
To me it sounds like you’re killing the trivial issue of server accumulating full metadata log for two conversing IP addresses, but it doesn’t sound like you’re really determined to deal with the underlying issue of IP addresses leaking to servers by default, in the first place.
Queue rotation is agreed between the clients, and the queue the clients rotate to is not known to the server as its address is agreed inside e2e encrypted messages
That’s good to hear. I admit I was wrong about that, and that’s also how I would have implemented it.
as long as the client has another configured server
What is the available server pool size? How are you preventing two clients from using the same server? How are users picking servers? I.e. is it a list with check boxes, or do they manually write the DNS name from a list?
the servers can see client sessions
So Tor is more or less useless in protecting the user. Even if the queue ID space was massive to enable server to act as a dead drop, you’re checking the identity of anyone accessing the drop with session tokens.
To mitigate it the clients offer an option to use separate Tor circuits for each connections, but it will create much more traffic, so cannot be enabled by default.
I fail to see how this removes the need for the session token.
This statement ignores the limitations of Tor, that many parties operate a large number of Tor relays and therefore are able to deanonymize Tor hidden service addresses that are used for a long time.
What’s preventing delivering a new onion address through the end-to-end encrypted channel?
Also random third parties enumerating the v3 onion address space is computationally infeasible. I get that some people will post their address publicly and that’s a risk. But you don’t have to offer it as a feature, just like you’re currently requiring users to perform off-band handshake first.
What I believe is a very important quality of SimpleX network is the lack of operator anonymity
Who is going to be running the servers? How are you ensuring they’re not all running under Hetzner? What are the incentives to run a server? How many users are you expecting per server? Who foots the bill? How are you vetting they are seasoned cypherpunks and not undercover CIA agents?
Any network that provides onion routing and at the same time allows anonymous participation of routing nodes can be used to break the security model by any party that runs many nodes
Again best practices are all we can do. The adversaries that can run a bunch of nodes like FVEY, don’t have to. Global passive adversaries just tap the nearest IX point, ISP etc.
SimpleX alone offers a better security/usability trade off than using it with Tor.
You’re absolutely free to set your own preferred point of diminishing returns for added security at the cost of UX. My issue is not that, but your transparency about the limitations. “First messaging app without User IDs [we know your IP]” is still not the slogan you want to carry.
I would suggest you adjust your threat model and express it in simple terms such as
“Like your phone number is not hidden from Signal’s server, your IP address is not hidden from the SimpleX server. Your communication metadata with your contact is not hidden from two servers collaborating. We try to identify distinct entities are running the servers, but we can’t be sure what they’re doing behind closed doors.”
[Signal Kobeissi etc]
Kobeissi had issues with Signal’s management, not technical side of things. Let’s not got there the posts are long enough as they are.
I can’t repeat enough that “security” is always about protecting against some attackers, and there is no such thing as security in the absence of attacker
Which is why you might want to list the attacker capabilities needed to overcome each layer of security you’re providing.
No need to go into wild stuff like spurious emanations, and endpoint security is also clearly out of scope.
so saying that something has the best security against all attackers is just wrong
who is the user, what do they do, which country they in, how they configure it, and who is the user trying to be secure against. I can’t repeat enough that “security” is always about protecting against some attackers, and there is no such thing as security in the absence of attacker
Finally, nuance. Maybe bring that up before making your caveat ridden first thesis about SimpleX providing more metadata privacy against user IDs than Cwtch.
Specifically about Tor, it fails to protect anonymity of the users against attackers who run many Tor nodes
SimpleX fails to protect anonymity of users against attackers who run many SimpleX servers. You’re not adding security here. Once your system is more expensive to compromise than sybil attack against Tor, I might consider it an alternative.
it also does not protect agains global passive adversaries
SimpleX does not protect against global passive adversaries. Otherwise Tor would have forked your tech day 1.
the protection of a given Tor address is becoming worse the longer it is used
Again, when anonymity of Tor fails, the IP address of the user is unmasked. You’re implying you’re giving more protection than Cwtch, and that includes IP. You’re not hiding the IP from the server. You’re replacing centralized server architecture with decentralized server architecture, while arguing Matrix does not provide metadata privacy.
For majority of users who don’t break laws
So who exactly are your users. Clearly it’s not homosexuals in arab countries, Uighurs in China, or activists in Myanmar. SimpleX, First messaging app for people who don’t fight their oppressors?
Clearly you undestand the nuance that law and ethics do not go hand in hand. If messaging apps are not protecting the most vulnerable in our societies, who on earth are they for?
[usernames] enable long term mass surveillance for the commercial reasons at low cost
So what commercial surveillance is e.g. Signal doing? It’s clearly not aggregating user data for commercial purposes. What are you adding to the mix and to whom?
Given the economics of mass surveillance, it’s not necessary to make building connection graph impossible - it’s enough to make it more expensive.
So we as an organisation are much more interested in raising the baseline security for ordinary users than protecting from high budget attacks.
So incremental metadata security by requiring two warrants instead of one, as long as they’re not both under same provider like Hetzner. Got it. I do get that it’s not necessarily the case both entities running the server, are logging just for the fun of it, especially when the splitting scheme does strip full access to IP-to-IP metadata. It still doesn’t solve the fact running just two SimpleX servers is enough to get accurate metadata on many conversing SimpleX users’ IPs conversing.
so all activity that happens within the circuit can still be used for correlation.
You know the Tor circuit lifetime is 10 minutes, right?
But please stop selling solutions that have known limitations as perfect or as the best - it would put lives at risk.
Tor is not misrepresenting itself. The reason I say Tor is the best anonymity tool, is because the adversary with largest global passive tapping system, largest cryptanalytics force, and the largest general, offensive digital capability said that in their own top secret slides.
“Still the King of high secure, low latencyt Internet Anonymity. There are no contenders for the throne in waiting”
Source: Tor: 'The king of high-secure, low-latency anonymity' | US news | theguardian.com
Also for NSA’s capabilities, direct quote
“With manual analysis we can de-anonymize a very small fraction of Tor users, however, no success de-anonymizing a user in response to a TOPI request / on demand”
Source: 'Tor Stinks' presentation – read the full document | US news | theguardian.com
But I’m sure you have much more accurate information at your disposal. You really think they’re now saying “Until SimpleX decided to make two servers swap ciphertexts via anonymous credentials”?
Some of your criticism about IP addresses was correct with the old network design, and we improved the network design based on your and other users’ criticism and suggestions.
Good. That’s the way forward.
- Do what you can, use best practices or improve on them if you can. Do not upsell inferior designs.
- Be upfront about the limitations, make threat model and limitations trivial to access: One click is the right amount. Right now there’s three, which given the already bloated navigation tree, is two clicks too much.
I’m not against your project, I’m against the way you fail at communicating its limitations. You’re not improving over Cwtch, you’re doing something that’s less secure, and you’re implying it is an improvement.
But this doesn’t justify your absolutist stance about SimpleX threat model being bad for all users, which is what you say
Messaging apps are tools built for purpose. When you misrepresent the purpose your tool fits, I think it’s a bad tool in general. Half of the security comes from users knowing they’re using the right tool, and the front page is not helping.
literally, and Cwtch threat model being good for all users.
Cwtch is communicating its threat model correctly. It’s not saying a persistent identifier isn’t there when it is.
Both views are incorrect, and it is not the objective fact-based stance a professional/expert should be taking.
What we do is hard work, and we are not interested to improve on what we think is a bad solution for most users.
It’s enough you are more transparent. Like I said above add something like
“Like your phone number is not hidden from Signal’s server, your IP address is not hidden from the SimpleX server. Your communication metadata with your contact is not hidden from two servers collaborating. We try to identify distinct entities are running the servers, but we can’t be sure what they’re doing behind closed doors.”
The time and the userbase will be the ultimate judge on who is right.
Surely Telegram’s 800 million users are right what is the ultimate encrypted app. Maybe run some polls on your users, whether they think that the
“The first messenger without user IDs Other apps have user IDs: Signal, Matrix, Session, Briar, Jami, Cwtch, etc. SimpleX does not, not even random numbers. This radically improves your privacy.”
means IP address is protected, especially if they know Cwtch already figured out that part.