>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
https://news.ycombinator.com/item?id=41364503
and
https://news.ycombinator.com/item?id=41364884