So if you don't have any options for Tor, maybe you should just default to Tor.
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. 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.
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
> Yet you provide no options for Tor, as in https://simplex.chat/docs/server.html your idea for anonymizing users is... For the user to hop through roughly 20 page document of dozens of commands to create the equivalent of personal VPN server, and amidst it, to connect anonymously to contacts' servers, you need to install...
You need to understand things you criticise. There is no contradiction here. We don't think Tor should be default, because Tor has bad threat model for many people, and bad usability for most people.
This is a separate conversation, but you think that Tor is panacea for anonymity and that it provides "good enough" anonymity for most people, you need to read this rather old presentation: https://ritter.vg/p/tor-v1.6.pdf, in particular the pages titled "Guards - Math". In short, the conclusion should be that Tor provides 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 ;)
>We don't think Tor should be default, because Tor has bad threat model for many people, and bad usability for most people.
Here's the thing. If you're going to say your system doesn't have identifiers, you better make sure the server can't use the (queue_number, IP-address) tuples it accumulates over time about users as a persistent identifiers it can link all ciphertexts and their send/receive timestamps.
To be able to make your claim, you need to do what's doable. "Tor has bad threat model" is so vaguely put I don't buy it. Bad usability would come at the cost of using p2p architecture like Cwtch/Briar/OnionShare/TFC does. You're still using servers so the only thing Tor is adding is some bandwidth limitations, slight latency, and connection establishment times.
>but it provides really bad anonymity for hidden services, because it is enough to deanonymise one stream to deanonymise the hidden service IP address
Sorry which slide exactly mentions hidden services? All of them talked about exit nodes, i.e. non-onion-service chains. Also, if there's something wrong with Tor, it's in Tor's domain, not yours. Your domain is to use the best option available, and if needed improve it. Feel free to work with Tor so it suits your use case. Do you know about a better option than Tor? Exactly. If Tor fails, it's as good as not using Tor, nothing more terrible comes from that. There's no extra-jailtime awarded for using Tor for your dissident activities in your Banana Republic. If using Tor is itself illegal, it's probably the case encrypted messengers are categorically banned, and the citizens have thus bigger problems.
"...deanonymise the IP address - which is a catastrophic failure of threat model."
So a system that leaks the user's IP-address to a third party fails catastrophically in providing privacy. Got it. Well, SimpleX does that by default. You're switching between two positions without fixed value system. You need to be extremely clear about when the user should not use Tor, and when they should. And most importantly, you should not claim the system has no persistent identifiers, when the server can build one about the user trivially, and if the user who opts-in to use Tor ever fails their manual configuration, their account is deanonymized retroactively. All user activity can be bound together with a list of (QueueID, IP-address) tuples. If any of those tuples contains the user's real IP-address, every session is deanonymized.
>but you really should not be recommending Tor as panacea without understanding limitations of its threat model.
Again, you need to understand there is no better option than Tor. Just because Tor isn't perfect doesn't mean it's not the best option. I'm sure you have seen the top secret NSA Tor Stinks slides. If not, see slide 2 of https://www.theguardian.com/world/interactive/2013/oct/04/to...
>"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"
And? If the user is deanonymized, they are deanonymized. The question is who can do that. Anyone who runs a SimpleX server and a global passive adversary? Or only a global passive adversary.
>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.
So wait what, you're saying you're not even providing Tor because you understand the benefits, but because you want to cater to uninformed peoples' needs. This is comedy gold, you need another shovel do dig yourself even deeper?
>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.
Sending message to someone else's SMP proxy without Tor means SimpleX leaks your IP to that proxy, and that's the problem. That is what you described "catastrophic failure in threat model". If on the other hand you own the SMP proxy, then that's the last hop of your endpoint. The IP-address of that proxy represents you, and it will be traced back to you. You adding complexity to what the user's endpoint client looks like doesn't change the principles underneath.
>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.
His own server? You really need to provide graphs and explain in high level terms what the functions of each node in the chain is, when they should be used, what security do they add, and where Tor should be used, and when. Security-by-nobody-reads-the-RFCs-anyway is not what you want.
>Meta-data is private by default
"We just redefine IP-address to be non-private information." You know, the stuff that if it leaks in Tor, it's catastrophic. But if you don't even try to hide it, then it's ok.
>so it is about better network connectivity, and not about metadata privacy.
And what do you suppose the reason people use Tor for, is? Is it to hide IP-address?
If you're offering single-hop proxy, you're gonna get all the shit you deserve, there's a good reason Tor offers three nodes in the chain. VPNs are considered secondary ISP because they know who you are, and what you do. If you're stating the user runs their own proxy, then the user's proxy IP is tied to the user and tada, there's effectively no proxy in use.
Finally, would you please stop running to he hills every time the Queue aspect is discussed, and answer posts
>We believe that Tor may be the wrong solution for some users for one of the reasons: much higher latency, error rate and resource usage.
Yet you provide no options for Tor, as in https://simplex.chat/docs/server.html your idea for anonymizing users is... For the user to hop through roughly 20 page document of dozens of commands to create the equivalent of personal VPN server, and amidst it, to connect anonymously to contacts' servers, you need to install... Tor https://simplex.chat/docs/server.html#tor-installation-and-c...
So if you don't have any options for Tor, maybe you should just default to Tor.
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. 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.
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...