And btw Tor is 100% compliant with all laws - don't you know that? :)
It's a US-based organization, with transparency and compliance.
62 karma · joined February 19, 2013
It's a US-based organization, with transparency and compliance.
Application is designed to: - always choose server from configuration to deliver messages via, and not the destination server that is chosen by the recipient. The protocol is designed to provide packet-level anonymity (not circuit-level anonymity, as in Tor) so that neither of the servers can see which IP address talks to which IP address. - always choose server operated by another operator, to mitigate collusion risks.
My problem with Tor is that after all these years it takes zero steps to prevent collusion and data sharing by Tor node operators - even though Tor has a centralized authority over server registry and could have deployed such mitigation. So the main assumption on which Tor security is based on - that independent parties run relays in the circuit - is simply untrue. We are designing the network and the app to ensure exactly that.
If people want to use Tor, it's their choice, and the app supports it. But we won't be integrating it.
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
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.
The reasons not to embed Tor are listed here: https://simplex.chat/faq/#why-dont-you-embed-tor-in-simplex-...
Disclaimer: I designed SimpleX network, and the founder of SimpleX Chat.
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 ;)
https://github.com/simplex-chat/simplexmq/blob/stable/rfcs/d...
It's also included in protocol spec now:
https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
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.
Recently added private message routing protects IP addresses of the users from the destination servers: https://simplex.chat/blog/20240604-simplex-chat-v5.8-private... , which was #1 point of criticism that IP addresses are not protected by default.
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.
Also, recently we added a second step in message routing that protects both user IP addresses and transport sessions: https://simplex.chat/blog/20240604-simplex-chat-v5.8-private...
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.
Factually, at this point SimpleX Chat is one of the most private and secure messengers, see the comparisons of e2e encryption properties in SimpleX Chat and other messengers: https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum...
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.
That's why they want to scan messages of everybody other than themselves: https://www.eureporter.co/business/data/mass-surveillance-da...
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.
The privacy policy is very explicit about it.
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.
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.
There is currently no messaging app other than SimpleX Chat that guarantees metadata privacy - who is talking to whom and when. SimpleX is designed to not use any permanent users identities to protect meta-data privacy. See SimpleX overview for more details: https://github.com/simplex-chat/simplexmq/blob/master/protoc...
SimpleX v1 has big changes in E2E encryption (now with double-ratchet), protocol encoding (overhead in transmitted bytes is reduced from 15% to 3.7%), performance and invitation link size (no more long RSA keys in URLs, we switched to Curve448/25519 keys). See more details via the link.
We really look forward to you playing with it - you can connect to the team via /simplex command in the chat (myself or somebody else will meet you there) - you feedback and questions.
Senior Full-Stack Developer
MailOnline is the world largest newspaper website dailymail.co.uk visited by 230 million people from 200+ countries every month.
You will contribute to the development and delivery of an in-house, cutting-edge news authoring and publishing web/mobile platform used by 800 journalists in London, New York, Los Angeles and Sydney to create 1000+ articles every day.
We have one of the most competitive compensation packages.
Please see full job description and apply at our site: https://dmgmedia.csod.com/ats/careersite/JobDetails.aspx?id=...
You need to reduce what is allowed, and that is more likely to leave vulnerabilities, than explicitly whitelisting what methods can be called.
I think that any abstraction/DSL, not JSONScript specifically, with a specialised interpreter on the server side is more likely to be secure than processing general purpose language instructions received from the client.
JSON-RPC allows simple batching but it doesn't allow any server side logic between calls. Individual calls to external instructions in JSONScript are indeed similar.
The full syntax can be used if you need to evaluate some of the fields, it's also easier to parse. Short syntax is implemented as a macro - it's expanded to full syntax before evolution. Given that it in most cases short syntax is better I was going to hide full syntax a bit...
I may have got used to the syntax I came up with, but all XML based scripts seem more verbose and less readable. I guess, each to its own...
Joking aside, why do you think it is any more untestable than any other batch endpoint out there? The concerns you are listing are all valid and can be addressed.