We plain a private payment mechanism for the servers that will utilize blockchain for valid reasons - we call it Community Vouchers. But they are not coins, they are service credits that cannot be created out of nothing (as coins) and cannot be sold - they can only be used to pay for the servers.
I understand that servers need to be paid for but that's why I run my own matrix server. So I pay for that and for the users on it. Much nicer than having to trust another party to run them.
> "SimpleX has no identifiers" only means "SimpleX does not add additional identifiers"
These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers. All other application-level networks have identifiers of their own, in addition to IP addresses.
The goal of the design is:
- to prevent correlation of which IP address communicates with which,
- to prevent IP address from servers not chosen by the users.
It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either, as Tor relays are servers too.
>These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers.
You are promoting SimpleX as an metadata-privacy improvement over Tor Onion Service based messengers like Cwtch, that hides the IP address by default. IP-addresses can be linked to users, and users will have to blindly trust the server is not collecting them. TelCos and ISPs keep logs of those as per data retention laws, so it's not hard to determine who a SimpleX user is if SimpleX wants to disclose that information.
>to prevent correlation of which IP address communicates with which
Which Akamai can do, and Runonflux can do. With 50% probability on per-target basis I might add.
>It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either
Tor relays actively mask the IP of previous node from the next node.
Tor relays do not have access to internal protocol of SimpleX queues etc. SimpleX servers do, so they can collaborate with better efficiency.
Tor relays are chosen at random by the user, and random collaborating entry/exit nodes expose 10 minute windows for ciphertext-only metadata collection without access to IPs. SimpleX has 50% chance same company runs the server of both users.
>Tor does not achieve that either, as Tor relays are servers too.
This is ridiculous. You're effectively arguing, that because Tor isn't literally magical in being able to send TCP packets without IP addresses in headers, it's not significant improvement. As I showed you last time, the NSA itself has admitted they will NEVER be able to deanonymize all Tor users all the time, and that nor are they able to do that on-demand. Which is quite different from your "we run servers on two VPS companies ourselves, but pinky promise, they don't aggregate and correlate information."
>I designed SimpleX network, and the founder of SimpleX Chat.
I know. We two have had a looong conversation about this, first in Reddit, then here, then in privacyguides forum, and now again, here. Every single time you run to the hills.
Link your open, honest, non-misleading threat model to your front page. Make sure it makes it extremely clear that "Unless you install and configure Tor, SimpleX client does not take actions to hide your IP-address from the server".
I mean, look how professional https://tryquiet.org/ looks when the treat model is up there in the title bar, and not as a fine print behind menus.
Do that and we're done. I won't call you out anymore.
Either you didn't understand the design, or this is not genuine criticism.
Every server that user connects to of course knows IP address of the user, be it Tor relay, VPN provider, Nym node, or SimpleX relay - the user chooses which server to trust.
Neither of the approaches guarantees transport anonymity.
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
That you don't like the design is well known. But this is not the reason to lie.
You understand the design quite well, from our past conversations, you simply don't like the fact that we don't recognise user IP address as a permanent user identifier on the protocol level. It is indeed a transport identifier, not a protocol-level identifier that all other messaging networks have for the users (in addition to transport identifiers).
Message routing protocol has anonymous pairwise identifiers for the connections between users (graph edges), but it has no user identifiers - messaging servers have no concept of a user, and no user accounts.
In general, if you want to meaningfully engage in the design criticism, I would be happy too, and it will help, but simply spitting out hate online because you don't like something or somebody, is not a constructive approach – you undermine your own reputation and you also mislead people.
> You ask the authors how they solved the problem of server needing to know to which client connection an incoming ciphertext needs to be forwarded, and they'll run to the hills
This is very precisely documented, and this design was recently audited by Trail of Bits (in July 2024), we are about to publish their report. So either you didn't understand, or your are lying.
> They're lying by omission about their security, and misleading about what constitutes as a permanent identifier.
You would have to substantiate this claim, as otherwise it is slander. We are not lying about anything, by omission or otherwise. You, on another hand, are lying here.
That you are spiteful for some reason is not a good enough reason.
>> You ask the authors how they solved the problem of server needing to know to which client connection an incoming ciphertext needs to be forwarded, and they'll run to the hills
> This is very precisely documented, and this design was recently audited by Trail of Bits (in July 2024), we are about to publish their report.
I’ve looked at SimpleX in the past and am also curious about this. Is there a high-level summary?
>you simply don't like the fact that we don't recognise user IP address as a permanent user identifier on the protocol level
So how exactly are all those DMCA letters finding themselves to the correct household if IP address doesn't deanonymize you?
>Message routing protocol has anonymous pairwise identifiers for the connections between users
I'm so tired of you avoiding the obvious question. What does this identifier look like?
Given that you say its anonymous, its probably not a username. So.
Is it a random string, an RSA/DH/ed25519/ed448/ECDSA key-pair?
Is it permanent? If not, how often does it change? How is it changing, are the identifiers advancing in a hash-ratchet etc. Can it change while the IP address stays the same?
Give me an example of the identifier. If it is a collection of data, explain every single segment of it.
It's clear the server does not tell one user connection from another by its IP address. So, until you explain what information exactly the server uses to tell one user's connection apart from another, it makes no sense to discuss this further.
>You would have to substantiate this claim, as otherwise it is slander.
As per above, IPv4 addresses have been used to identify individual subscriptions, and you're not making it clear that if the users wants ambiguity about the identity of who's behind an IP-address, they should not live in a single person household. You're also not defaulting to Tor so by default every single-household user not behind a NAT can be determined by their IPv4 address. You pretending that IPv4 addresses don't matter doesn't change reality.
Also as for your vague threats of SLAPP lawsuits, let me give you a quick lesson on the Finnish law:
"Edellä 1 momentin 2 kohdassa tarkoitettuna kunnianloukkauksena ei pidetä arvostelua, joka kohdistuu toisen menettelyyn politiikassa, elinkeinoelämässä, julkisessa virassa tai tehtävässä, tieteessä, taiteessa taikka näihin rinnastettavassa julkisessa toiminnassa ja joka ei selvästi ylitä sitä, mitä voidaan pitää hyväksyttävänä."
or
"Defamation as referred to in subsection 1, point 2 above is not considered to be criticism directed at another person's conduct in politics, business, public office or task, science, art or similar public activities and which does not clearly exceed what can be considered acceptable."
SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a server
* IP address / host name [alice-land.net or similar]
* port
* and hash of the long-lived offline certificate*
* a queue ID
* Alice's E2EE public key.
"""
The queue ID is of interest here. The text also says
"""
When setting up a queue, the server will create separate sender and recipient queue IDs (provided to Alice during set-up and Bob during initial connection)."
"""
---
So the queue is basically a pair of port numbers generated by the server. The server gives Alice queue number pair (a11cea11ce, b0bb0bb0b0b).
Alice's introduction message tells Bob that if Bob puts messages to server's port number a11cea11ce, they are sent to her. And upon 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.
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.
You should understand that you cannot have the cake and eat it.
The logic here is very simple:
1) Any scanning messages of children and their parents means providing access to them, effectively removing the protection provided by the encryption.
2) If these messages are accessible to any algorithm or systems, however secure, there is no way to guarantee that the bad actors will be prevented from accessing these messages - it's only the question of time until this information is leaked.
3) If these messages are accessible to bad actors, it will enable more grooming - because they will be used to train language models to more effectively manipulate children and other people.
So while politicians can engage in their wishful and magical thinking about some wonderful technology that will allow, what they call, a "lawful access" but at the same time will somehow prevent unlawful access by bad actors, everybody with a bit of technical knowledge understands that it is simply impossible - it's either e2e encrypted and nobody other than the communicating parties can access it, or it is not - and then anybody with resources can access it, including bad actors.
It was never about protecting children - it is simply about eradicating the privacy as we know it, and preventing any dissent from being formed, and criminalising private conversations in the same way free speech is being criminalised. These ideas are not new - it's just now that they try to weaponise "let's protect the children" narrative to achieve it.
The only way to protect children and vulnerable people online is to reduce their discoverability on online platforms, not to expose their communications to enable more efficient grooming - which would be the effect of the scanning.
Of course it stays encrypted - if it is sent e2e encrypted, it cannot be decrypted by the servers in the middle - it's the whole point of e2e encryption.
"Proposed", not "incoming". We will react appropriately IF it is passed and IF it applies to us. The UK as a jurisdiction has many advantages over alternatives.
> but leaves some important security aspects under-specified
Not sure what you mean by underspecified - it is specified to the level of wire encodings. Possibly you looked at the wrong doc?
> There is nothing immediately wrong about it, but it's hardly state-of-the-art either: there's no CBOR to reduce overhead, no JSON-LD to improve extensibility, no MIME types to account for different types of attachment.
We considered all that, and it seems that they all offer a bad value, compared with lower ubiquity. Also given that messages are padded to fixed 16kb size, there is no value in reducing JSON overhead, and files are sent as binary anyway. Being boring where it doesn't matter is good.
> avoid what has happened to Matrix
Messaging clients are hard to implement indeed, and forking the UI is usually easier than rebuilding it. We purposefully don't want to encourage the development of alternative clients too early, before the spec stabilised, to avoid the fragmentation that happened both with XMPP and with Matrix.
> to avoid the fragmentation that happened both with XMPP and with Matrix.
what fragmentation are you thinking of with Matrix? to my knowledge, we have zero fragmentation so far. some clients implement more features than others, but we don’t have any classic “my client sends different reactions to yours” or “my client archives messages differently” or “my encryption is incompatible” style problems. otherwise this smells a bit FUDy…
> we have zero fragmentation so far. some clients implement more features than others
The Matrix spec has many versions and many features. Clients implement and keep up with varying parts of it due to varying reasons usually involving varying amounts of manpower and funding. Same as with XMPP. I don't see the difference.
The difference is that Matrix is curated as a single spec (currently at v1.7: https://matrix.org/blog/2023/05/25/matrix-v-1-7-release/), which ensures that competing implementations for new features don’t fragment incompatibly but only a single one-true-way to talk a given feature exists. Anything else is a transient experiment. Meanwhile, we’ve never yet broken backwards compatibility in the spec, meaning that in theory any client can talk to any other client as long as it has implemented the required features. The inspiration here is HTML5 (albeit with versioned releases, and a clearer spec proposal process).
In other words, I’m defining fragmentation to be incompatible features - not just clients/servers which haven’t yet implemented a given feature (which is inevitable, just like browsers lag behind specced HTML and CSS features)
One way of putting this is that we’ve traded off the risk of fragmentation (but with free-for-all governance) for the risk of more centralised governance by the Matrix.org Foundation, with associated high drama when folks don’t agree with the curation decisions we make in what gets merged into the official spec.
Both are valid approaches with different tradeoffs; I was just trying to flag the confusion upthread accusing Matrix of being fragmented when it really isn’t (to a fault!)
Yes, we know that (I'm the founder). The large groups support is coming, currently the largest group I know of approaches 600 people and is not too usable. We've just released an experimental directory service for finding user groups.
I generally believe that for-profit, venture funded company, will some IP help in non-profit, has much better chances of delivering privacy preserving service.
Initially, in 2020, I thought that SimpleX Chat should be non-profit, but then after a long chat with Joseph Jacks in April 2020, who is evangelising VC investment in decentralized open-source tech for a long time, he both convinced me that 1) a dual model is better both for the users and for the scale of change that can be achieved 2) to make a dive into it - the idea at the time seemed too crazy to do something about it for real.
So here we are, with a for-profit company building a privacy-preserving communication network, that will have more than one provider by design.
We do not plan any coins.
We plain a private payment mechanism for the servers that will utilize blockchain for valid reasons - we call it Community Vouchers. But they are not coins, they are service credits that cannot be created out of nothing (as coins) and cannot be sold - they can only be used to pay for the servers.
It's covered here: https://simplex.chat/vouchers
Whitepaper on that design will be published in early 2026.
Disclaimer: I designed SimpleX network