Those aren’t privacy services either. Real privacy services and projects would rather take a financial hit or shut down completely instead of violating the privacy of their users.
3 Likes
If they don’t build correctly yeah. There was the lavabit case back then, when something like this happened and thats it.
Proton for example gave the recovery email address compromising its user with no second thoughts.
Anyway we don’t need to divert from the topic. We are discussing about funding at the moment and i believe a non-profit approach serves better these projects. Signal is one good example.
Cwtch is funded through the non-profit openprivacy.ca research society that seems pretty transparent.
This post will age well, Bitwarden already start backfiring.
They were legally forced to. Do you think they will shut down their company because of one clueless guy with horrible OPSec? No, that would never happen with any company.
If everything is free, who pays for it?
Someone has to.
@maqp, as usual, triggers some great discussions.
This comment requires a substantive response, as some of these points are correct, but only partially. I will come back to them all in a couple of days.
As a side comment, “run to the hills” is neither what we do, nor the language one should use in a civilised discussion, unless you want to spread FUD, whatever the motivation.
4 Likes
When I wrote the long comment above, it had been been 55 days when I left the comments on HN. I can’t be the only one of us two to think you weren’t going to take further part in that conversation. But yeah, since we’re here, please take your time and ensure you clarify your positions and explain the threat model and how you address it with your security design.
it had been been 55 days when I left the comments on HN
Probably didn’t see it - please share the link.
SimpleX is not the program you want to use. I have on several occasions tried to get epoberezkin to answer basic questions, but every time they run to the hills.
“This is not the language you want to use”. This suggests that everybody is less smart than you, and you know better what should and should not be used. Every technology has its limitation, and nobody should indiscriminately recommend any tech for all cases.
SimpleX prides itself with having no identifiers.
We never said that, and no tech can work without identifiers. What is important though, and it’s a unique quality of SimpleX network, is that SimpleX user profiles are not assigned any distinct identifiers in the network, unlike all other networks do.
SimpleX server knows your IP-address by default.
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.
But the CEO pretends this is not an issue. They ignore the fact IP-addresses are constantly used to determine identity of copyright infringers using torrents etc.
Again, you are ascribing me the words I never said. It is impossible to use Internet without IP addresses, as you know. And it indeed may create issues if users do not manage their network transport security. But these issues are not specific to any particular system, and while there are tech solutions that reduce impact of IP address visibility to some servers, including Tor, i2p SimpleX network, and some other solutions, there is no technology that protects IP address in all cases - and Tor also is not such technology.
They either tie to the household, or to the person if they live alone.
This is sometimes correct, and sometimes it is not, depending on who can use it to tie it to that level. ISP can always do it, but it is not always the case for the third parties. 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.
SimpleX is not transparent enough about the fact the server can trivially correlate the IP addresses that converse.
First, we were transparent about it when it was the case. It is covered on the front-page of the website, and in all technical documents that cover the security limitations. It’s absolutely fine to criticise how we disclose our security limitations, but I suggest you show some other comparable service that is as explicit in disclosing it - I’ve only seen Pond doing that, where we modelled it from.
Second, with the addition of 2-hop routing (aka “private message routing”) in the messaging protocol it is no longer the case - even if both servers are operated by the same owner, it would be far from trivial, and it would require server code modifications that would be a violation of privacy policy. Neither having access to server storage or traffic observation does not allow it.
Third, with the addition of the second operator to the app (coming this November), it would be impossible even if one of the operators does modify server code in violation of the privacy policy - private message routing protects not only IP addresses, but also sessions.
There is queue rotation, but since unauthorized users must not be able to change the queues between Alice and Bob, the server must authenticate Alice before this action. This means Alice is recognized by the server, regardless of which IP-address they connect. So Alice can’t rotate their queues without the server knowing which queue pair Alice and Bob use next.
This is incorrect. 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. Clients always choose another server to rotate to (as long as the client has another configured server), and with the addition of the second operator, the clients will choose the server of another operator. So it is very non-trivial to connect which queue the connection rotated to.
Since the server knows the queue ID between two users in long term (that is, unless they re-register for Simplex and start fresh), the server can keep accumulating all queue IDs associated with Alice and Bob. The server can also associate every IP-address it has seen Alice connect from to that user.
It is based on incorrect assumption, so it is incorrect. Further, because of 2-hop routing, while a modified server can indeed determine the list of queues the client connects to in default configuration, the server still cannot determine IP addresses that send messages to these queues, so it does not provide the knowledge of user connection graph, even if server modifies the code.
If Alice and Bob use Tor from day one, and somehow never fail to misconfigure Tor and leak their IP, SimpleX is probably OK. If they ever fail, then the user is permanently deanonymized.
What you don’t say, that it would be the case even if clients connect via Tor, as while servers can’t see IP address of the client (Tor relay can see it instead), the servers can see client sessions. This is disclosed in the privacy policy. 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.
But irrespective of that, this does not show how IP addresses and message queues connect to conversation graph.
This is why SimpleX sucks compared to Cwtch. Cwtch uses anonymous Tor IDs, that are trivial to spin up, and take down. You can have as many user IDs as you want, even 1:1 mapping for all contacts to micromanage your online status for every contact.
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. Even with the addition of guards a successful attack on hidden service anonymity is possible over several months or maybe even weeks of usage, so Cwtch should be disclaiming that users have to rotate these addresses too, as otherwise Tor relay operators that run many nodes can build the connection graph between IP addresses and hidden service addresses used for a long time.
What I believe is a very important quality of SimpleX network is the lack of operator anonymity - it allows client to choose different operators for message delivery route (something that will be available this month). 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 - a single operator controlling even 2-3% of nodes results in a high probability of successful deanonymization over a prolonged usage.
My huge issue with SimpleX, is the CEO is vacillating between the positions of “Tor has vulnerabilities, therefore it’s not 100% solution”, and at the same time offering Tor as an opt-in solution for paranoid users (their words, not mine.)
There is no contradiction here, it is called “security in depth” or “defence in depth”. SimpleX has an alternative security model with packet routing (as opposed to Tor’s circuit routing) and with operator transparency (as opposed to Tor’s operator anonymity), so we believe that for many users SimpleX alone offers a better security/usability trade off than using it with Tor. It doesn’t mean that Tor should not be used - it can be used in addition to SimpleX, as a transport level anonymisation network, providing better overall security to some users. Further, we use Tor’s SOCKS proxy circuit isolation property to further improve Tor anonymity by using more than one circuit - something I am aware of only Tor browser doing.
Tor is obviously not a panacea, but the CEO conveniently forgets, is there is for now, nothing better.
I do take issue when security and technology experts take such stance. For example, the stance “there is nothing better than Signal, so we should not criticise it” led to years of complacency, ignoring security issues, misleading marketing and over-inflated budget. Read this.
Likewise, the statement “there is nothing better than Tor” is misleading, as it ignores the fact that it very much depends on 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 - so saying that something has the best security against all attackers is just wrong, in general. Specifically about Tor, it fails to protect anonymity of the users against attackers who run many Tor nodes, it also does not protect agains global passive adversaries, so while it provides a much better anonymity for web access than alternatives, the protection of a given Tor address is becoming worse the longer it is used.
SimpleX solved the non-issue of usernames and offered the same IP-address protection as every bog-standard messaging app: None.
-
For majority of users who don’t break laws (and yes, we believe that absolute majority of SimpleX users fall in this category) usernames are a much bigger issue than IP addresses, as they enable long term mass surveillance for the commercial reasons at low cost, while using IP addresses for the same reason would be both against the privacy policy and also much more expensive. Given the economics of mass surveillance, it’s not necessary to make building connection graph impossible - it’s enough to make it more expensive.
-
I am also of the opinion that given a high budget any security solution can be compromised. I think that compromising Tor security model for most users would require running 100-200 Tor nodes - you can estimate the budget. So we as an organisation are much more interested in raising the baseline security for ordinary users than protecting from high budget attacks.
-
See above comments on private message routing - it solves the problem of IP address protection much better than most, as it also solves the problem of session protection by using per-packet anonymity (unlike Tor), that only does it per-circuit, so all activity that happens within the circuit can still be used for correlation.
First HN. Now PrivacyGuides. You’re running out of hills to run with your snake oil. Please stop running and address these issues.
I am not sure what causes your inappropriate and bitter tone, but if you want to suggest some improvements we are very open to change. But please stop selling solutions that have known limitations as perfect or as the best - it would put lives at risk.
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. But this doesn’t justify your absolutist stance about SimpleX threat model being bad for all users, which is what you say, literally, and Cwtch threat model being good for all users. 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. We will continue building and improving what we think is better for most users. The time and the userbase will be the ultimate judge on who is right.
5 Likes
I could be wrong, but your GitHub headline does state (emphasis mine):
SimpleX - the first messaging network operating without user identifiers of any kind - 100% private by design! iOS, Android and desktop apps
!
This can be interpreted, and often is interpreted by end users, as no identifiers at all, instead of no user identifiers. At best this is dubious marketing (intentional or unintentional), especially with the “100% private by design” line following it.
Website is also full of interesting claims. For example the comparison with signal table is very misleading. It marks SimpleX as secure on MitM attacks because:
SimpleX relays cannot compromise e2e encryption. Verify security code to mitigate attack on out-of-band channel
But it then says signal is vulnerable to Mitm and you should:
If operator’s servers are compromised. Verify security code in Signal and some other apps to mitigate it
This is again just ridiculous. One system is secure because you can do some action XYZ. But the other system is insecure, therefore you should do XYZ to mitigate it.
Do point me where is it “transparent”. Here is your website from:
- 2021: SimpleX chat: private, secure, de-centralised
- 2022: SimpleX Chat: private, secure, no user identitifiers
- 2023: SimpleX Chat: private and secure messenger without any user IDs (not even random)
In fact, the website has claims like “You have complete privacy” (emphasis mine), stating:
SimpleX protects the privacy of your profile, contacts and metadata, hiding it from SimpleX platform servers and any observers.
Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users — not even random numbers.
Here is Signal’s website: https://signal.org/ ,can’t seem to find any false marketing or dubious claims against reputable competitors.
Signal funders seem to not be pushing for the kind of aggressive and murky marketing SimpleX funders seem to push for.
Hopefully people smarter than me on messenger protocols can also verify your technical claims, since your transparency claims don’t inspire confidence so far.
2 Likes
There is a very large difference between optional mitigation that requires user action every time the device of the contact changes, so most users just ignore “security code changed” notices (Signal), and non-optional protection against MITM that requires no user action, and is part of default connection process (SimpleX).
So the claim that Signal by default does not protect against MITM by operator, and SimpleX does protect it by default is factual.
The website says:
-
To protect your IP address you can access the servers via Tor or some other transport Overlay network.
-
To use SimpleX via Tor please install Orbot app and enable SOCKS5 proxy (or VPN on iOS).
This site exists from 2022.
It still needs to be amended to account for private routing that does not require Tor to protect IP addresses from your contacts servers.
1 Like
So there is a large difference in optional opt in for security code verification and security code verification by default, but not when you claim 100% privacy but your default config leaks IP?
Also can share where exactly on the website frontpage does it say what you say it is? I might have missed it. Specifically I am looking for the part of the frontpage that has the quote, preferably someplace near where SimpleX claims protecting all metadata and user identity:
1 Like
Here is Signal’s website: https://signal.org/ ,can’t seem to find any false marketing or dubious claims against reputable competitors.
Signal is commonly advertising component qualities as pertaining to the whole system. That relates to:
- break-in recovery property of Signal algorithm, that is undermined by multi-device support: https://eprint.iacr.org/2021/626.pdf
- “sealed sender” that does not protect the whole system because initial key bundle requests are authenticated and are also vulnerable to statistical attacks allowing to determine senders after 5 messages according to this paper that proposed improvements: https://cs-people.bu.edu/kaptchuk/publications/ndss21.pdf
- post quantum key agreement that is promoted as improving Signal algorithm security (Signal >> Blog >> Quantum Resistance and the Signal Protocol), while in reality it is used only in the initial key agreement, and not in Signal algorithm ratchet steps like SimpleX and iMessage do.
That’s just off top of my head.
Signal funders seem to not be pushing for the kind of aggressive and murky marketing SimpleX funders seem to push for.
“Aggressive” - we are doing very little marketing, and if by “aggressive” you mean “comparative” and critical of the competition, for Signal being the biggest player this would have been counter productive at their current stage. Not only Signal ignores the competition (which is sensible), they also censor mentions of any competitors, including Molly, and censor any criticism of Signal in their forums.
“Murky” - again, not sure what you mean by that, but Signal positioning of their security qualities is misleading.
All you are picking it is our taglines. Our technical communications aim to be very precise in disclosing the limitations.
2 Likes
It does seem there is a disconnect between what SimpleX popularly claims to be, and what it actually does. Expecting end users to read technical docs while creating a product for mass adoption seems to be a unique mistake to make. Thanks for the replies, but they don’t help in clarifying why SimpleX chose to position its taglines on promises it hasn’t kept.
When browser companies paste “most private browser” across their websites and then hide data collection in implementation docs, I look at them in disdain. The same is applied to any service that claims stuff like 100% privacy, which WILL mislead common end users.
1 Like
Default configuration protects the IP addresses, as I explained. That it did not protect it in the past was disclosed in all technical documentation - the website, GitHub readme, threat model.
If you are saying that tagline or hero section of the website should disclose all limitations then this is not possible for many reasons:
- hero page section is limited to include all limitations.
- everybody talks about positive aspects.
Signal tagline, for comparison, is “Private messenger”, which can be seen as a false advertising given that Signal requires phone numbers and has full visibility of who communicates with whom. “Content security” is not “privacy”.
But everybody understands that it means that privacy is the objective, and there are some limitations, and you need to read on to understand them.
Likewise, nobody takes “100% private by design” as anything other than aspiration. So this consciously exaggerated claim you accuse us of is unlikely to be misleading to anyone.
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.
6 Likes
The exchange between @maqp and @epoberezkin has significantly eroded my confidence in Simplex. It appears that Simplex’s value proposition is predominantly tailored for high-risk individuals, highlighting a substantial marketing misalignment that may be exacerbated by VC funding pressures. I question whether this issue will be effectively addressed.
Separately, I’d appreciate a nuanced discussion on why some might prefer Cwtch over other options, notwithstanding its:
- Lack of a public audit, which raises legitimate security concerns.
- Relatively short operational history, introducing uncertainty about long-term viability.
Understanding the rationale behind potentially favoring Cwtch despite these drawbacks would help bridge the apparent disconnect in its perception.
3 Likes
SimpleX has potential to be a decent alternative to Signal. It should advertise itself as pseudonymous: You can register without a phone number. You can connect to people without giving your email and/or phone number to them. You don’t have to rotate username like with Signal. It can advertise itself as reduced trust required per server in terms of metadata, now that work is being done towards that. Large part of my criticism has been from period from before this improvement, when single server was able to accumulate IP-to-IP type comms metadata.
But SimpleX should not sell itself as having no identifiers whatsoever. Because it can’t be done practically. There must always be something that tells Alice’s client how to get the message to Bob and not Charlie. The only way to avoid doing that, is to use an architecture similar to network hubs (as opposed to switches), where every message is broadcast to everyone. This is impossible for practical reasons (like bandwidth) alone.
As for Cwtch, the security protocol operates around Tor Onion Services, so majority of the security critical code is in Tor’s domain. Applications will always have vulnerabilities, and it’s enough the project is maintained and fixes are deployed fast. And based on my UI bug reports, even low priority bugs like those are handled really well.
It’s important to develop with adversarial mindset, and from what I’ve seen, they’re taking security quite seriously. I haven’t looked at the code in detail (I’m not familiar with Go) but there seems to be unittests, and inputs are being fuzzed
which shows testing is done with best practices.
But I agree I’d like to see an audit, as it shows extra pairs of eyes have scanned the code. But note that that’s all it shows, unless it shows something terribly wrong which I doubt.
3 Likes
I agree with your assessment, particularly regarding SimpleX’s marketing approach. As someone with a non-expert technical background, I’m heavily influenced by developer claims when evaluating privacy-focused apps. This makes accurate marketing all the more important, as I rely on clear, honest representations to make informed decisions. Transparent messaging is key to maintaining trust.
Your positive notes on Cwtch’s security practices help boost my confidence in the platform, making it a more appealing option for future consideration.
1 Like
A lot of interesting dialogue here. I appreciate this thread. I don’t really use messaging apps a terribly large amount, but I do like the idea of SimpleX and Cwtch. Never really occurred to me to dive into which is better. I have that annoying friend group who don’t really care much about privacy. I campaign and campaign for them to download Signal and ONLY use that when they need to talk to me. What happens? They send me texts over plain SMS, lmao.