epoberezkin
Joined 13 years ago
Karma
62
Submissions
59
Member since
Feb 19
http://www.github.com/epoberezkin
View on Hacker NewsRecent submissions
Comment · 6 months ago
And btw Tor is 100% compliant with all laws - don't you know that? :)
It's a US-based organization, with transparency and compliance.
Comment · 6 months ago
You are just naive. Read the comment below - the main Tor's security assumption does not hold for years.
Comment · 6 months ago
This is both incorrect and misleading.
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.
Comment · 10 months ago
That is untrue.
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
Comment · 10 months ago
> "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.
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.
Comment · 2 years ago
> 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 ;)
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...
Comment · 2 years ago
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.
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.
Comment · 2 years ago
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.
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...
Comment · 2 years ago
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.
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.
Comment · 2 years ago
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.
The privacy policy is very explicit about it.
Comment · 3 years ago
"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.
Comment · 3 years ago
> 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.
Comment · 3 years ago
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.
Comment · 3 years ago
Disclaimer: I'm the founder.
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.
Comment · 3 years ago
There was an audit of critical parts in November 22: https://simplex.chat/blog/20221108-simplex-chat-v4.2-securit...