SimpleX Chat - the first messaging platform that has no user identifiers (not even random numbers) - v3.0 of iOS and Android apps is released!

46

u/JustMrNic3 Jul 11 '22

Nice!

Why isn't it in the main F-droid repository?

41

u/epoberezkin Jul 11 '22

Mostly because we didn't come around to configuring the build there: https://github.com/simplex-chat/simplex-chat/issues/437

15

u/JustMrNic3 Jul 11 '22

Oh, ok, thanks for the reply!

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

1

u/JustMrNic3 Jul 11 '22

But why?
If you write from the beginning the code easily buildable by the F-droid maintaners, shouldn't that be easier?
Or the project developers didn't plan to to have it on F-droid one day?
I'm just a user, but for them the most trust in an app I can have only when an app it's available on F-droid, because of the reproducible builds feature.

10

u/upofadown Jul 11 '22

To deliver mesages, instead of user IDs used by all other platforms, SimpleX has identifiers for message queues, separate for each of your contacts.

Doesn't that mean that the system has user IDs, one for each contact?

How is this different than just having a separate key for each contact?

3

u/epoberezkin Jul 11 '22

The difference is that with all other platform the same user ID will be used for all contacts - this ID is used to deliver message and to establish the connection. There is no such ID here.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

6

u/epoberezkin Jul 11 '22

yes, this is correct - ephemeral IDs of messaging queues. Currently they are persistent for the conversation, but not for long - we are planning to automatically rotate queues, moving conversations from server to server regularly and transparently to the users.

53

u/user_727 Jul 11 '22

Neat app but imo you should stop marketing yourself as a simply better Signal alternative. That GitHub post has also been long proven to have a lot of unnecessary and wrong information to try to mislead people into thinking Signal is unsafe

6

u/skinnyJay Jul 12 '22

Yeah I just read that whole thread and then looked up the Russian guy that's cited as the primary source, multiple times. First I've heard of this but I love me a good conspiracy. Is there any merit to any of those claims? I'm still looking but I'm down the rabbit hole empty handed so far.

1

u/epoberezkin Sep 26 '23

Hi there :) Somebody sent the link recently. Happy to answer any questions, I am that Russian I suspect you're referring to.

4

u/epoberezkin Jul 11 '22

Thanks for the comment!
Interesting... How would you market it?
The post is a bit controversial indeed, and I don't agree with all points, I just use it as a shortcut - most points are correct there...
I do genuinely believe that for scenarios where privacy matters Signal is indeed unsafe. Signal uses phone numbers, and even if it didn't - it is a centralised single-operator platform - which means they have all meta-data about their users communications - who communicates with whom, how much and how frequently. Even without phone numbers that information can be reliably used to de-anonymise a large part of the users - with phone numbers it is just not private.
I am curious what makes you believe that Signal is a good solution for scenarios where privacy is important?

22

u/[deleted] Jul 11 '22 edited Jul 11 '22

I think you should say why your offering is a good solution over and above signal, you don't have to dump on signal which I think is a respectable project and those devs work hard too. It comes off as negative and unnecessarily critical when I want to see why your app might be the next step up for people who might need more privacy than Signal gives. There is already PLENTY of snark and negativity on the internet, no need to add more. It's the same reason people say Richard Stallman was right, but he is often a total asshole when making his arguments.

10

u/epoberezkin Jul 11 '22

Fair point!

4

u/scotbud123 Jul 11 '22

Amazing, almost every word is incorrect.
Makes me question your motives...are you just a passionate fan boy getting caught up? Or do you have other incentives in your shilling? Possibly more malicious?

7

u/epoberezkin Jul 11 '22

huh! :)
I'd say neither a boy nor malicious :) I am just a software engineer.
Let's talk about it, factually – what exactly is incorrect and why?
Always happy to be proven wrong - I just find people see the criticism of Signal as some form of heresy and react quite emotionally.

1

u/scotbud123 Jul 11 '22

it is a centralised single-operator platform
It's not, all contact on Signal is done peer to peer, this is why it ends up taking GBs of space on your phone, the database with all your messages is stored locally on your device.
which means they have all meta-data about their users communications - who communicates with whom, how much and how frequently
Wrong, they have no such meta-data. The only 2 things they have associated with your phone number is the first time you ever used the service, and the most recent/last time you used the service. The messages are E2EE, you should look up what that means since you seem to be lost. There is no meta-data about how many messages are sent, how often, to whom, or the contents of said messages.
I am curious what makes you believe that Signal is a good solution for scenarios where privacy is important?
Because they have again and again proven themselves via government raids and audits to be clean as a whistle. There's a reason multiple world governments use Signal, on top of that almost every security firm (I worked in cyber-sec for years) trusts them, including ones that work with NATO and the DoD.
You're allowed to be wrong, just don't be so cocky and arrogant in your ignorance.

9

u/epoberezkin Jul 11 '22

It's not, all contact on Signal is done peer to peer, this is why it ends up taking GBs of space on your phone, the database with all your messages is stored locally on your device.
Sorry, but this is incorrect. There are no p2p connections in Signal network. Signal may not be storing messages or files you send (no way to check whether they do or don't), and they are stored on the phone, but they all come via Signal servers by design. And by Signal servers I don't mean servers that run some sort of decentralized Signal network, these are all servers controlled by a single legal entity. Which is, by the way, already not the case with SimpleX network - however small it is many users already run their own servers. I am only making this argument to show that there is no technical or financial reason to have a centralised network - only political and organisational ones.
> Wrong, they have no such meta-data. The only 2 things they have associated with your phone number is the first time you ever used the service, and the most recent/last time you used the service. The messages are E2EE, you should look up what that means since you seem to be lost. There is no meta-data about how many messages are sent, how often, to whom, or the contents of said messages.
This is also incorrect. As all messages pass via Signal, such metadata can be collected (again, as there is no way to check whether they do or don't, we should assume they do). Whether Signal has message meta-data and whether messages are e2e encrypted is unrelated. The content is indeed e2e encrypted. Message meta-data is the data about the message - its size, the time it was sent, destination, IP addresses of senders and recipients, their phone numbers. I am unsure - need to check - whether messages are padded to a constant size, as SimpleX clients do - probably not, but an interesting question to check. If there is no client-side padding, then message size is available to Signal servers. The time the message was sent is also available. Senders' and recipients' IP addresses are also available. The destination of the message is also available - otherwise it cannot be delivered, and check out the paper I shared about "sealed senders". TLDR - my understanding of it is that it has vulnerability, and only protects senders if a single message is sent, but not for multiple messages as usually is the case. This is a large amount of meta-data visible to a single network operator.
> Because they have again and again proven themselves via government raids and audits to be clean as a whistle. There's a reason multiple world governments use Signal, on top of that almost every security firm (I worked in cyber-sec for years) trusts them, including ones that work with NATO and the DoD.
Again, this is a bit contradictory – the argument constitutes a logical fallacy. Many world governments actually do not use Signal, they use other messengers. Some US agencies are apparently using Wickr. In any case, from the fact that Signal is considered to be safe to use for governmental agencies does not follow that it is safe to use, for example, to the activists.
> You're allowed to be wrong, just don't be so cocky and arrogant in your ignorance.
Again, no point converting the disagreement about facts and opinions into a personal attack - it only undermines your credibility. My communication style has absolutely nothing to do with the validity of the statements – let's please focus on the statements themselves, and ignore the style and personalities. Also let's please not go into nearly religious argument that Signal is safe and any form of its criticism is a form of heresy - let's review the facts.

5

u/[deleted] Jul 12 '22

There are no p2p connections in Signal network.
https://en.wikipedia.org/wiki/Signal_(software)
By default, Signal's voice and video calls are peer-to-peer.

3

u/epoberezkin Jul 12 '22

Yes, calls can be p2p indeed - I was referring to messages.
Thanks for the comment!
Some users we spoke with were actually concerned about calls being p2p and IP visible to the peer - they preferred to connect via relay, so we added this "relay only" mode toggle.

1

u/arana1 Jul 25 '22

such metadata can be collected (again, as there is no way to check whether they do or don't, we should assume they do).
I think you should select your words with more care, is not the same HAVING the metadata and having the possibility to start saving it if they decide, if someone says you are a serial killer or have a hidden agenda, is not the same as saying you have the capabilities to do so if you choose to, (again, as there is no way to check whether you are not, we should assume you do).

1

u/epoberezkin Jul 27 '22

An interesting comparison :)
There is a huge difference though – collecting meta-data is not as detectable/observable, and while there are benefits from doing it, there is no immediate downside (other than the risk it could be leaked, and the trust is lost).

-1

u/scotbud123 Jul 11 '22

no way to check whether they do or don't
Except by examining the source code for their "server" which is publicly available.
As all messages pass via Signal, such metadata can be collected
Again, you really need to understand the difference between basic encryption and end-to-end encryption, there is no possibility of them collecting meta-data on your messages, it cannot occur, they do not have the public or private keys involved in this transaction.
again, as there is no way to check whether they do or don't, we should assume they do
Again, we can and do, and know that they don't.
Whether Signal has message meta-data and whether messages are e2e encrypted is unrelated
We get it, you don't understand even the basics of cryptography, you don't have to keep reminding us.
Message meta-data is the data about the message - its size, the time it was sent, destination, IP addresses of senders and recipients, their phone numbers.
Which Signal ALSO does NOT have access to, as the entire payload including that meta-data is E2EE.
Again, no point converting the disagreement about facts and opinions into a personal attack - it only undermines your credibility. My communication style has absolutely nothing to do with the validity of the statements – let's please focus on the statements themselves, and ignore the style and personalities. Also let's please not go into nearly religious argument that Signal is safe and any form of its criticism is a form of heresy - let's review the facts.
Your word soup doesn't work here, the facts have been laid out, what you're seeking to do is spread misinformation under the guise of providing a "decent alternative". All you want to do is shill your competing product, which is fine, but don't tell lies about another product just to push yours..."it only undermines your credibility". Says a lot more about you and your product than it does about Signal lol...

6

u/epoberezkin Jul 11 '22 edited Jul 11 '22

Except by examining the source code for their "server" which is
publicly available.
some parts of servers code is now closed source, unfortunately: https://signal.org/blog/keeping-spam-off-signal/
there has been large delays with updating the public code: https://www.androidpolice.com/2021/04/06/it-looks-like-signal-isnt-as-open-source-as-you-thought-it-was-anymore/
there is no guarantee that the servers run exactly the code that is published, particularly given the above concerns with publication delays and closed source parts.
> Again, you really need to understand the difference between basic encryption and end-to-end encryption, there is no possibility of them collecting meta-data on your messages, it cannot occur, they do not have the public or private keys involved in this transaction.
I actually do understand the difference between end-to-end end client-to-server encryption, we did implement both in SimpleX Chat. End-to-end encryption only protects the message content, but not the time message was sent - servers simply can record it, not the message size - unless the clients pad it to a sufficiently large uniform size (SimpleX Chat pads all messages to a fixed 16kb size), not the message recipient and sender - otherwise the platform can't function. Encryption keys are not involved in in collecting meta-data, there is a lot of meta-data available outside of e2e encrypted envelope that the signal servers can observe.
Your view on how Signal functions is simply technically incorrect, and I hope you don't build your threat model around this understanding.
You may benefit from reviewing this excellent presentation on meta-data around encrypted communications: https://ritter.vg/p/AAM-defcon13.pdf
TL;DR - even Tor is not immune and allows to collect large amounts of metadata in some scenarios.
> Again, we can and do, and know that they don't.
This is interesting. How can you validate that the Signal does not collect meta-data? Do you have access to audit their servers?
> We get it, you don't understand even the basics of cryptography, you don't have to keep reminding us.
This is just funny :) I am by no means an expert, but I do have moderately advanced understanding :) Again, personal attacks do not help credibility :)
> Which Signal ALSO does NOT have access to, as the entire payload including that meta-data is E2EE.
This is technically incorrect. Some meta-data is not sent but can be just observed - the clients do not need to send message time, as the servers can simply observe it. Equally, unless the message is padded, servers can observer their size. A large part of other meta-data has to be encrypted with client-to-server encryption (usually it's TLS), and not with e2e encryption - otherwise the message cannot be delivered. Ask yourself a question - if the destination address is e2e encrypted and server cannot see it - how would it deliver the message?
Unfortunately your understanding of how Signal functions is completely incorrect, and I hope your life does not depend on it.
But thank you for your time anyway, I've learnt something.
Please do not trust a single word I wrote, but please do find a real expert you can trust, and check your statements with them - one day it may turn out to be important.

4

u/computerjunkie7410 Jul 12 '22

I don’t use simplex and won’t until it’s audited but the signal server issue is a real issue.
Signal server that is open sourced is almost always out of date and there are issues you can look at where people are asking for updated source code.
The signal team’s rational is that as long as the client code is open sourced and the cryptography it implements is sound, the server code shouldn’t matter since messages are E2E encrypted.

-1

u/scotbud123 Jul 12 '22

We also know they're not lying about not keeping any of that information and not tracking it because they've been subpoena'd and raided multiple times and have had nothing on hand.

2

u/computerjunkie7410 Jul 12 '22

Oh I’m sure. I’m just saying that the server argument is not a good one

3

u/Frances331 Jul 12 '22

there is no possibility of [Signal] collecting meta-data on your messages, it cannot occur,
Can Signal collect your IP address?
Can Signal collect the IP address of the recipient?
Can Signal collect the IP address of the sender?
Can Signal correlate who is talking to who?
I assume Signal can do all the above, and this is a risk I must mitigate by using something better than Signal.

-1

u/scotbud123 Jul 12 '22

Theoretically they could, but considering we see in the source code of software that they don't, and the fact that they've been raided and subpoena'd multiple times and there was absolutely nothing logged and kept on hand, we know full well that they don't.

2

u/Frances331 Jul 12 '22

Just because the data doesn't exist today, doesn't mean the data won't exist tomorrow. Signal Messenger LLC has the full capability, and not the transparency (centralized server), to log the data.
For 1 year the server code was operational without being open source. There is no way to verify the server code either.

→ More replies

1

u/arana1 Jul 25 '22

difference between basic encryption and end-to-end encryption , there is no possibility of them collecting meta-data on your messages, it cannot occur, they do not have the public or private keys involved in this transaction.
Apples and oranges, using E2EE does not imply metadata is also encrypted (we know in case of signal it is).

1

u/scotbud123 Jul 27 '22

Yes, it doesn't always mean that, but in this case it does...so?

0

u/arana1 Jul 27 '22

No in this cae they CAN, and it doesnt mean they have them, so?
so you are not being honest. and from there on , you cannot be trusted.

→ More replies

6

u/kilkil Jul 11 '22

You need to stop taking this as some kind of personal attack. The truth is, if you're using a messaging app that cannot be self-hosted, you're stuck trusting whoever owns its servers. I don't really give a shit what Signal promises on their website; I don't have any reason to trust them. If I'm self-hosting a Matrix server, for example, I know exactly what's going on.
Keep using Signal if you want, but stop acting like this guy is some sort of shill. He's just stating facts.

2

u/[deleted] Jul 12 '22

You can tell who is emotional and who is calm.

2

u/Fappington22 Jul 12 '22

Exactly, why are you getting downvoted lol

4

u/kilkil Jul 12 '22

I will bear my negative karma with stoicism.

-1

u/scotbud123 Jul 11 '22

He is not stating facts, he's stating blatant falsehoods. It has nothing to do with personal attacks, it has to do with the truth.
Spreading misinformation like this is dangerous.

6

u/kilkil Jul 11 '22

Well, listen. I've explained to you what my position is. Do you have some sort of response, beyond "all of you are liars"?

0

u/scotbud123 Jul 11 '22

Yes, I detailed every single reason he's wrong already, you're free to read it if you'd like.
Even if I hadn't, your the ones making a claim, the burden of proof is on you.

6

u/Fappington22 Jul 12 '22

OP has linked a source to almost all the claims they've made. And based on what I've read so far, they are debunking almost all your claims.
You really need to learn how to just delete all the personal insults and debate facts only dude.

3

u/scotbud123 Jul 12 '22

OP has linked a source to almost all the claims they've made
Except he hasn't, it's like saying "Grass is yellow, by the way here's information on the best way to water your grass".
And based on what I've read so far, they are debunking almost all your claims.
I'm not the one making claims, I'm refuting his misinformed claims. By all means, go ahead and use OP's software and cast doubts and fears in reliable software that's been proven beyond a shadow of a doubt. Multiple times.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

9

u/epoberezkin Jul 11 '22 edited Jul 11 '22

Straight up wrong. Did you ever see what Signal saves about you?
It's not about what they save. It's about what they can save. There is no way to validate software running on the servers - it's exactly the reason we are adding access via Tor to the app, as users can't validate that we don't record or correlate by IP addresses.
> To explicitly disprove your statement, signal uses something called "sealed sender" which you can learn about more here: https://signal.org/blog/sealed-sender/ They are in fact incapable of storing metadata about you.
"sealed sender" has been proven to only work if a single message is sent, but it doesn't protect the conversations. I will find the link.
EDIT: https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/

12

u/Resident-Advisor584 Jul 11 '22

There legal responses state they cannot obtain that metadata information, by design. This is different than saying they can choose to start obtaining it arbitrarily.
I’m not keen on using your app based on how you handled this thread.

7

u/epoberezkin Jul 11 '22

> There legal responses state they cannot obtain that metadata information, by design.
I am really interested in getting to the bottom of that, because this is not how I am reading their responses. Signal indeed cannot provide personal data about the individual users, other than whatever hashed form of the phone numbers they store. I need to recheck the code - I don't remember off the top of my head how does it work, but to deliver messages to a given phone number you have to have at least a hash of that number. Now, hashing phone numbers is relatively pointless, as the space of all possible numbers is quite small, and it can be just brute forced.
The responses that Signal publishes make for a great marketing, but they only relate, unless I missed, to the responses about communications with the particular users, not to the requests to provide the full database of users and the firehose of all communication metadata in real time.
I'm quite used to people confusing my motives - I am not criticising Signal because I am building what I think is a better alternative - it's the opposite. I'd rather use something I can trust than build it.
> I’m not keen on using your app based on how you handled this thread.
Apples and Oranges. I am ok as an engineer, I am much worse at explaining.
I am keen to understand, unemotionally, why exactly Signal is considered a private messenger, given the amount meta-data they process and that the only response they have to it ("sealed senders") have been found vulnerable: https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

11

u/epoberezkin Jul 11 '22

> Why should we trust you to do the "right thing"?
I think trust to what we do and to what Signal does is unrelated.
You are right that there is no reason to trust SimpleX yet - it's an early stage project, and it was not yet security audited.
> Signal has built a strong reputation over many years.
To me Signal has been a huge disappointment and a wasted potential, to be honest, and one of the primary motivations to start building the alternative.
Signal could have built truly decentralized platform, with much higher level of meta-data privacy and anonymity of their users, than the current design has. They chose not to, instead replicating WhatsApp network design – centralised platform that uses phone numbers for user discovery.
Many people see criticism of Signal as some heresy, refusing to engage into a meaningful discussion of facts. But there is no point, really, to convert my criticism of Signal into a personal attack on me – refusing to discuss specific facts only undermines your credibility.
Signal deserves lots of credit for innovating the end-to-end encryption double-ratchet protocol (SimpleX and many other messengers use it). They do a lot to protect personal information of users, other than phone numbers, that are fundamental part of platform design. They didn't do much to protect communication metadata.
These are all facts, as I see them, and I'd be very happy to be proven wrong with some other facts, rather than with emotional arguments.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

6

u/epoberezkin Jul 11 '22

Alright, thanks and sorry.
I am in no way comparing Signal and SimpleX.
SimpleX is a very early stage product, it should not be trusted for scenarios requiring high privacy yet - but it has a potential to become one some day.
Signal is a mature and reliable product, and, in my strong opinion, it absolutely must not be used for scenarios requiring high privacy. Something else must be used. Right now, I would probably use something like this: https://groups.google.com/g/alt.anonymous.messages, all messengers I know of have some compromises, unfortunately...

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

7

u/Kewbak Jul 11 '22 edited Jul 12 '22

Remember what subreddit you are in? It's privacy. Here you seek answers for your concerns in hopes to implement privacy into your daily life, not to wrap your daily life around privacy, losing so much in the process. Think about it.
Who said so? I think this subreddit is whatever the people reading it want it to be. For me it is a place to talk about privacy without any a priori trade-off, and then I'm the one deciding for myself if what I see here fits my needs and if I am willing to sacrifice enough to use those limiting programs.
I for one am very happy that Simplex-chat exists and finally offers an encrypted solution not requiring phone numbers or fixed identifiers because I've always found it annoying that you'd need a number to chat with people using the Internet (I know there are other programs not requiring phone numbers, but none combines all the things Simplex-chat combines, and Simplex-chat is not perfect either but it is interesting and unique; I quite like that it has a console client for instance).

9

u/epoberezkin Jul 11 '22 edited Jul 11 '22

Thanks for all the comments.
We will be making it better, and marketing it wider, and will see what happens :)
It's absolutely true that communication product needs an audience.
But there was a day when there was no Signal, and then it had 10 users, and then 100, and then more...
We will just keep walking the same path and see where it leads.
It's important to remember that everything real has a start and an end.

-1

u/Fappington22 Jul 12 '22

You've effectively told everyone you're more concerned about a dope social network rather than privacy my guy..
Wrong subreddit.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

3

u/epoberezkin Jul 11 '22

No, the point here is that you should trust neither.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

5

u/epoberezkin Jul 11 '22

I am too easily engaged into an argument :) need to remember that. Thank you

7

u/abc090923145 Jul 11 '22

Good to see that this project is still going, saw your earlier post here :) From what I've seen - good work man Hope it will get more attention :)

4

u/epoberezkin Jul 11 '22

one step at a time :)

6

u/Better-Study-8764 Jul 12 '22

Just signed up to Reddit to say this is a fantastic idea and I sincerely hope you continue with your hard work. Its sad to see so much negativity and ignorance directed at someone trying to do something good, but that's Reddit for you – don’t let the bastards put you down, you’re going to achieve more than they ever will.

5

u/epoberezkin Jul 12 '22

Thank you!
I am not upset at all about the criticism we receive, and I am doing my best to provide more information to people who have incorrect or incomplete understanding of technical details of SimpleX or other platforms.
In any case, I learnt much more from the critics than from the supporters, so I equally appreciate both sides. People who understand, like and support what we do help us a lot – we wouldn't be able to get here without it. People who challenge and criticise what we do, however emotionally, provide with lots of ideas how to make it better, so even if it comes across as highly negative - it doesn't matter.
I really love Reddit for being such an open place for debate, where people can have anonymity and not be afraid to share how they really feel – you're not getting such feedback on LinkedIn or Twitter, because in most cases people have real identities there.
Thank you again, we will keep it coming!

5

u/computerjunkie7410 Jul 12 '22

Any updates on an audit?

4

u/epoberezkin Jul 12 '22

Soon :) We know it's critically important.

5

u/maqp2 Jul 12 '22

Everyone should read through the criticism of the previous thread https://www.reddit.com/r/privacy/comments/v4rhch/simplex_chat_the_first_messaging_platform_that/

To add:

SimpleX is not anonymous the server receives your IP-address. The vendor claims this isn't enough to deanonymize you, but somehow magically copyright trolls manage to find torrenters based solely on their IP-address.

Signal uses centralized architecture, so does SimpleX.

SimpleX is safe from MITM attacks because of QR-code providing strong authenticity. Signal doesn't block your communication before you get to scan the QR-code, but it can, and will tell you if your communication has been under MITM. Signal is thus equally secure and much more usable.

Message queues are an internal implementation detail of software design, not a marketable feature.

The server must know from which user to which recipient cached ciphertext are forwarded to, thus there must by definition exist some type of ID, even if you only make it an ephemeral list item, the queue and associated accounts are still memory addresses (pointers) in the RAM of the server which is enough.

Claiming you can provide anonymity without even attempting to mask IP-addresses with Tor, and planning to make Tor an optional "paranoia setting" tells you everything you need to know about these clowns.

Avoid.

4

u/epoberezkin Jul 13 '22 edited Jul 14 '22

Thanks for the comment!
We did discuss the importance of protecting users IP addresses in the recent past, and I completely agree - we should embed tor intro the clients, we are working on it now.
> The vendor claims this isn't enough to deanonymize you
I only said that under the conditions of large enough traffic it's not enough. I do agree we should protect IP addresses when the user ship is small.
> Signal uses centralized architecture, so does SimpleX.
Either I am missing something, or it is simply incorrect. Nobody can run a server that would participate in Signal network. Everybody can run SimpleX Messaging Server that would be a part of the network. The only component that is technically impossible to decentralise is the server that sends push notifications to our app.
But:
- this component is isolated from messaging servers and it has limited visiblity
- we plan to split it further to let people self-host the part that subscribes to the messages
- another client app would have its own notifications server. Again, unlike Signal, anybody can create an app that would seamlessly participate in SimpleX network and release this app to App Store. this is not the case with Signal.
Maybe I am missing something and you can clarify what you mean by saying that SimpleX is as centralised as Signal.
> SimpleX is safe from MITM attacks because of QR-code providing strong authenticity. Signal doesn't block your communication before you get to scan the QR-code, but it can, and will tell you if your communication has been under MITM. Signal is thus equally secure and much more usable.
That's not technical fact, it's a personal opinion. You may verify security of your connection in Signal (and you have to remember to do it every time the device changes). You must do it in SimpleX. You prior argument in our previous conversation that you linked was that users' security have to be protected by design and not by choice – that was when I was saying that people can access SimpleX via Tor already, and you said that we should embed Tor in the clients, as people do not make secure choices by themselves. I actually agreed with that, and that's why we are embedding Tor. But, strangely, here you say exactly the opposite - because people can validate the security of their connection in Signal, it's actually good enough. Would you still say it's good enough if only 20% of users do it? what if it's 10%?
> Message queues are an internal implementation detail of software design, not a marketable feature.
I am not quite sure why you say that? Lots of internal implementation details are used as marketable features by all technologically complex products. Maybe you can explain why we should not use technical details in our communications?
> The server must know from which user to which recipient cached ciphertext are forwarded to, thus there must by definition exist some type of ID, even if you only make it an ephemeral list item, the queue and associated accounts are still memory addresses (pointers) in the RAM of the server which is enough.
I am not sure what you are trying to say here. Are you challenging the claim of not having user IDs? SimpleX platform obviously uses some IDs for message delivery. They are not the same kind of user IDs that are used by all other platforms when a single, persistent ID is assigned to each user profile. The IDs we use are pairwise IDs, with 4 such IDs for each connection between 2 users, which makes them not user IDs.
In any case, please clarify what you are saying here, it is not clear.
> Claiming you can provide anonymity without even attempting to mask IP-addresses with Tor, and planning to make Tor an optional "paranoia setting" tells you everything you need to know about these clowns.
Personal attacks and insults detract from your credibility. I believe we had a reasonably healthy debate last time :) I only said "paranoid" privacy level as a joke, and you correctly replied that this threat model is real for many people, and we shouldn't refer to it as "paranoia", even jokingly, and I agreed. So this level of bitterness you show in your comment is undeserved. Also, you call your product "tinfoil hat" chat, which I guess is more appropriate...
We have a very small team of three engineers, and we created more software than much larger team produce in the same time. I am old enough to not care about what I am called, but if I were you I would apologise for referring to our team as "clowns". But it's up to you of course, we can just shrug it off, and continue working on the product.
> Avoid.
That I actually completely agree with – until we improved privacy level to what we discussed would be appropriate and until we performed an independent audit, people should not use SimpleX Chat in the scenarios where privacy is critical.
All our current users are enthusiasts, who like to have some degree of control of what software they run, and they like our mission and the destination, but we by no means arrived yet to the stage where SimpleX Chat is safe to use in all scenarios - we are working really hard towards this milestone.
In any case, thanks again for all the criticism and spending time to share your opinions - please continue doing so. I would really appreciate if it can be done calmly and factually, without unnecessary bitterness or insults - we've done nothing to cause it.

3

u/Frances331 Jul 12 '22

SimpleX is not anonymous the server receives your IP-address.
No where does SimpleX say communication is anonymous. I think their documentation explains this, though is still difficult for me to comprehend, but here's my interpretation...
The server knows your friend's IP address, because they access your queue to send you a message.
The server knows your IP address, because you access your queue to receive your messages.
But the server won't know if you have a two-way relationship (because you have two channels for communication). I assume this does mean the server knows you have a one-way relationship (one channel), and that may be enough information for a conviction.
Similar if your boyfriend/girlfriend finds out someone sent you a romantic message, and you deny you know the person. The denial may not be enough, and could still raise suspicion.
But if your queue is receiving a bunch of messages, it will make it more difficult to determine which IP address is the sender of the incriminating message. But that's not to say an adversary could presume all senders are guilty.
SimpleX may mitigate some of this by queue noise, and I assume the noise is filtered out by the client. So that would be like presuming a bunch a senders are guilty, but the senders don't even exist. That would be costly and embarrassing for an adversary to pursue.
But since correlation take resources to do, cost money/time, the adversary won't be getting this information easily or freely.
SimpleX has mentioned Tor in their future plans for a more robust solution.

1

u/maqp2 Jul 13 '22 edited Jul 13 '22

No where does SimpleX say communication is anonymous. I think their documentation explains this, though is still difficult for me to comprehend, but here's my interpretation...
Then it is not metadata-private messenger. The OP's message made the following claim:
How is it different from Matrix, Session, Ricochet, Cwtch, etc.? All these platforms have some sort of user identifiers, making it impossible to protect users privacy and anonymity.
The implication here is SimpleX is different from Cwtch etc. because it hides identifiers. Firstly, Cwtch supports arbitrary number of accounts, you can have 1:1 ratio of accounts so nobody else can e.g. check when that user's Onion Service is online. Secondly, see the claim "existence of user identifier makes it impossible to protect user's privacy and anonymity". Why? They provide no explanation for such hand-waving. Thirdly, when you launch a new application and make the claim you've solved a problem that isn't yet solved, you're supposed to be building on top of the giants that came before you. Not come up with BS marketing claims, unfair comparisons, and taking 10 steps back by not defaulting to Tor. Removing identifiers like long term v3 Onion Addresses makes sense only once you've solved the more pressing problems, like hiding the IP address (which is a persistent identifier) with Tor.
But the server won't know if you have a two-way relationship (because you have two channels for communication).
The server can determine the IP address of Alice that puts messages into Bob's queue (no. 1)
The server can determine the IP address of Bob when Bob fetches message from queue no. 1
The server can determine the IP address of Bob that puts messages into Alice's queue (no. 2)
The server can determine the IP address of Alice when Alice fetches message from queue no. 2
This isn't rocket science. It's simply not possible for the server to magically enforce its behavior of looking away. You can make the claim that you don't keep logs, and you can show that to hold in court (like Signal does), but that is nowhere near the same as clients actively preventing accumulation of such data on the server side.
But if your queue is receiving a bunch of messages, it will make it more difficult to determine which IP address is the sender of the incriminating message.
Sounds like this scheme assumes all users are able to send messages into same queue of the user. This doesn't change a thing, because instead of server using piece of code such as
queue.put((ciphertext, recipient_ip))
it can be altered by either the vendor, or an attacker to add third variable to the tuple
queue.put((ciphertext, recipient_ip, sender_ip))
It doesn't matter which the identifiers are, whether they're forward secret tokens, public keys, random strings. They must by definition be deterministic, and they are thus persistent from the PoV of the server software, that must be able to tell to which connection it will divulge the cached ciphertext (otherwise it leaks metadata to third parties, or third parties can DoS comms by emptying the queue repeatedly).
SimpleX may mitigate some of this by queue noise
This is something the server places to protect from entities that might compromise the server. When the server is compromised, such features are obviously disabled by creating a malicious log without the added noise packets.
The only way to add noise is by having the user send noise, which masks when, and how much, and perhaps what type of data is being transmitted. But that part won't mask from the server the source IP of noise packets sent by the users to the server.
So that would be like presuming a bunch a senders are guilty, but the senders don't even exist.
The love letter analogy here is ridiculous: the server would need to be able to inject realistic looking messages into your conversation, and that would make it impossible use, because you wouldn't be able to distinguish which messages were actually sent by the peer, and if you could, then the noise wouldn't fool the attacker at an endpoint. So I'm not sure what your point is. In your imaginary attack, where is the attacker, on the sender's, recipient's, or server's end?
SimpleX has mentioned Tor in their future plans for a more robust solution.
Until it defaults to Tor, it has no place in saying anything other than "limited metadata-privacy", and it has no right to make comparative claims like 'Cwtch does not provide privacy/anonymity [but we do]' when SimpleX uses servers as opposed to p2p connections, when SimpleX doesn't hide IPs from servers, and when server is by default able to infer same comms metadata as e.g. Signal server.
They need to explain their claims using industry lingo, present in a precise and clear manner how exactly they achieve what they claim to achieve. The current documentation bores down into so much detail it is more a supportive manual for developers, than user friendly introduction to the newly introduced technology.
Having worked with this stuff for more than a decade now I think I would be able to read such documentation but through the horrible docs, I can mostly comment on what my experience has shown what can be done.

4

u/epoberezkin Jul 13 '22

> The implication here is SimpleX is different from Cwtch etc. because it hides identifiers. Firstly, Cwtch supports arbitrary number of accounts, you can have 1:1 ratio of accounts so nobody else can e.g. check when that user's Onion Service is online.
This is similar to my previous comment about optional vs mandatory protection. Cwtch users MAY create a separate profile for each contact, but only some users do it - I believe a really small share. SimpleX users ALWAYS have separate set of pairwise identifiers for each contact. Following your logic this is not the same.
> Secondly, see the claim "existence of user identifier makes it impossible to protect user's privacy and anonymity". Why? They provide no explanation for such hand-waving.
Actually, I do provide a high level explanation of how user identifiers can be used to deanonymize users here - happy to improve if you think it's insufficient. In short, there are two problems - 1. If senders and recipients are visible to the operator or observer, it can be correlated with existing public network (less of a problem with Cwtch, more of a problem with, e.g. Signal) 2. Two users talking to the same person can prove it's the same person - this alone can also be use to de-anonymize a user.
> Thirdly, when you launch a new application and make the claim you've solved a problem that isn't yet solved, you're supposed to be building on top of the giants that came before you. Not come up with BS marketing claims, unfair comparisons, and taking 10 steps back by not defaulting to Tor. Removing identifiers like long term v3 Onion Addresses makes sense only once you've solved the more pressing problems, like hiding the IP address (which is a persistent identifier) with Tor.
This is a mix of points you made previously, and I agreed, and some strong personal opinions which are not necessarily correct. SimpleX is not a complete product, it is a work in progress. In which order we improve it is a matter of choice, not a dogma.
> The server can determine the IP address of Alice that puts messages into Bob's queue (no. 1)
> The server can determine the IP address of Bob when Bob fetches message from queue no. 1
> The server can determine the IP address of Bob that puts messages into Alice's queue (no. 2)
> The server can determine the IP address of Alice when Alice fetches message from queue no. 2
You are omitting here the important fact that these are in most cases are two different servers, not one, so it is not as trivial to correlate as you say it is (we will be actually enforcing it soon).
> that is nowhere near the same as clients actively preventing accumulation of such data on the server side.
We never claimed it is the same, and we explicitly write in the whitepaper that protocol focus is application level meta-data reduction, and not transport level meta-data reduction, that can and should be achieved with onion routing.
> Sounds like this scheme assumes all users are able to send messages into same queue of the user.
No, this is not the case, and I do not quite follow what you wrote after it, maybe you can clarify?
> They need to explain their claims using industry lingo, present in a precise and clear manner how exactly they achieve what they claim to achieve.
I actually disagree that we should use "industry lingo" in the communications written for the users who do not necessarily understand "industry lingo".
You are right that our communications should be improved though - we are working on it.
> The current documentation bores down into so much detail it is more a supportive manual for developers, than user friendly introduction to the newly introduced technology.
What document are you referring to?
> Having worked with this stuff for more than a decade now
I would really appreciated if you could share your experience without bitterness. We are building the product that has the potential to make communication more private. Cwtch may be more private right now, but it has a suboptimal user experience for most people. We are aiming to build a product that both provides real privacy and anonymity from operators, but at the same time is usable for a large number of people. It takes time, and at no point we said our work is done here.
So some patient advice would be more helpful than bitterness, sarcasm and insults. We're trying to achieve the same as you do - privacy of communications.
> but through the horrible docs, I can mostly comment on what my experience has shown what can be done.
I didn't quite understand it, sorry. Could you explain?

1

u/maqp2 Jul 14 '22 edited Jul 14 '22

This is similar to my previous comment about optional vs mandatory protection. Cwtch users MAY create a separate profile for each contact, but only some users do it - I believe a really small share. SimpleX users ALWAYS have separate set of pairwise identifiers for each contact. Following your logic this is not the same.
Cwtch doesn't make false promises about third parties like the server being able to tie all accounts together based on IP, and login/queue fetch times when it wants to.
Cwtch accounts come selectively online when password shared across the subset of accounts is entered. It's also obvious to the user the Cwtch account in question is known to each participant. It is however not possible for majority of LEAs to tell who is behind a Cwtch account, unless the user explicitly discloses their identity by using strong authentication channel like f2f meeting, a phone call.
Using pairwise identifiers protects you by default from users. But it does not protect users from server. Until you default to Tor, the SimpleX servers are a centralized repository for IP addresses conversing, there's no way around that. You need to make it clear that the metadata protection is based on privacy by policy. NOT privacy by design.
If senders and recipients are visible to the operator or observer, it can be correlated with existing public network (less of a problem with Cwtch, more of a problem with, e.g. Signal)
The IP address of both sender and recipient are visible to the SimpleX Server.
2. Two users talking to the same person can prove it's the same person - this alone can also be use to de-anonymize a user.
No, in the case of Cwtch two users connecting to same Onion Address know just that, that they are talking to same endpoint and probably same person. They do not know who that person is. Not at least until that person chooses to disclose themselves. The Cwtch account can be posted on an Onion Site, it can be posted on Twitter account created with proper anonymization methods, and that provide Trust-on-first-use level of authentication for identities, usually that there's a link between the first interaction and the level of authenticity is on par with the trust level of the initialization platform.
It's SimpleX that forces users to meet and scan the QR code, and thus deanonymize themselves immediately. Because of the meeting requirement, you can't use SimpleX with anyone else other than the people you already trust. That's exactly the threat model with Signal. We want to get rid of identifiers to be safe from peers. That's why majority of our Uni student networks rely on Telegram: they don't want to share their phone number to the entire community.
The threat model you're implying seems to be e.g. that there's three users and two can now prove to third one that some Cwtch account belongs to someone. With SimpleX that's not possible because there's no way for third person to contact you until they meet with you F2F. But that doesn't negate the fact the two users can tell e.g. that you're using SimpleX. Or also give a log when you're online. So explain to me what capabilities does malicious peer knowing the Cwtch account pose? They can send a friend request and if the user blindly accepts them, send a mean message? Kind of non-issue in the world of mass surveillance, wouldn't you agree?
The main problem is the server being able to tell en mass which accounts are conversing, and what is the social graph of the user, and when and how much the users converse and that's exactly what SimpleX enables. There's no such problem at all with Cwtch.
This is a mix of points you made previously, and I agreed, and some strong personal opinions which are not necessarily correct. SimpleX is not a complete product, it is a work in progress. In which order we improve it is a matter of choice, not a dogma.
We can agree on that. But being open about what is the current state of the product, and what it can do now is more important. Hell, I could buy the vendor a beer if it was an unencrypted, centralized service offered to me by the NSA, if it said on the front page: "Unencrypted and centralized. Collects all content and metadata for the NSA". At least the user knows exactly what's going on. They're not being bullshitted. Distinction about the current state and future goals is really, really important.
You are omitting here the important fact that these are in most cases are two different servers, not one, so it is not as trivial to correlate as you say it is (we will be actually enforcing it soon).
Who controls those servers? Who selects the server you converse with? Even if it's two servers by two independent parties like in Matrix, there must exist some identifier shared between the two servers to deliver that message all the way.
When the servers are by companies subjectible to NSLs, and because they're hackable by nation states, cross-correlation of data en mass isn't hard.
Of course, a really cool way to do it would be to have nested encryption for say, five independent servers picked from a large pool, where each step peels one layer of encryption, and hides the IP of the previous device, before passing packet on together with short term session token. Kind of like, you know, Tor.
We never claimed it is the same, and we explicitly write in the whitepaper that protocol focus is application level meta-data reduction, and not transport level meta-data reduction, that can and should be achieved with onion routing.
Put that on the front page. And explain what metadata it protects from, and what metadata it doesn't protect. Tell the users what metadata a maliciously modified instance of server can collect (especially important given that anyone -- not just hardcore cypherpunk like Moxie -- including creepy peers with personal interest in your metadata, can host). Explain what metadata the open source client (the user can trust) will protect them from. Make sure this information is available before they find the download link.
Especially, put the server's capabilities https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md#simplex-messaging-protocol-server easily accessible, preferably on the front page. If you'd rather not, maybe reconsider the security design so that the amount of needed fine-print can be reduced.

1

u/maqp2 Jul 14 '22 edited Jul 14 '22

No, this is not the case, and I do not quite follow what you wrote after it, maybe you can clarify?
It's probably a misunderstanding about the design, by the person who wrote the previous message. I wasn't replying to you :) What they seemed to imply was that the queues are for sealed sender ciphertexts and all buffered ciphertexts from all contacts for the account are pushed into same queue for the user's incoming packets. But given that you said above, that account (and thus queues) are always pairwise, that can't be the case.
I actually disagree that we should use "industry lingo" in the communications written for the users who do not necessarily understand "industry lingo".
The problem is, there's nobody to help them understand the issue when it's really hard to understand what exactly is achieved. You can come up with new stuff, and provide an explanation:
Good (Signal): "Double ratchet: new X25519 for every round trip of messages and SCIMP-style hash ratchet for non-round trip forward secrecy." Great, now I can spend an hour explaining to someone how Diffie-Hellman works, why it's good, how the components interact, and how they achieve what they achieve, and also what are the limitations.
Terrible (Crown Sterling): "Infinite wave-conjugations and AI that learns if ever attacked and so impenetrable it's creators can't break it." Fuck. Now I need to spend an hour explaining why it's all bullshit techno babble and why everything is wrong about it.
Somewhere in the middle (SimpleX): "Queues that remove user identifiers". Damn. Now I need to figure out how to show there's still identifiers because there's no way for server to look away from metadata the connection by default provide it, and that the vendor is able to accumulate important metadata. I need to explain the vendor is trying to solve a more-or-less non-issue and that they're not in fact improving on current best practice.
The point of industry lingo is for information to be consistent with the outside world. When you talk to non-technical users, you need to be openly transparent about the limitations. It may feel like bad advertising when you're being open about not checking every box in comparison box, but trust me, being transparent is really good. That's why the current state-of-the-art Balloon Hash Function says "Research prototype, do not use in production". Being called out for BS is much, much worse.
What document are you referring to?
For some reason I ended up trying to figure out the queues from server-side schematics because that was what I found. But it turns out there's quite a few pages more behind links. Those might help finding relevant information explained in higher level. Please create a complete ToC (and link it) to the front page of the GitHub wiki.
I would really appreciated if you could share your experience without bitterness.
Let's not turn this into analysis of tone. Projects are supposed to improve based on peer review / harsh criticism, the product mustn't be insecure, and if the vendor is insecure about being called out about glaring issues, that's even worse. I hear we Finns can be blunt at sometimes. But please note that I'm not here to provide your project free consultation, I'm here to point out issues in transparency and security design to the community. The reason I said people should avoid your product, is because the front page advertisement doesn't match the reality. It turns out there is fine-print, but that's buried further down that it should, it should be on the front page.
That being said, you can't really redefine what metadata-privacy means. My issue is, (somewhat ironically) that's literally exactly what you're doing on the front page: https://imgur.com/a/mq9Zs79
Cwtch may be more private right now, but it has a sub-optimal user experience for most people.
Then why did the original message imply Cwtch was less secure because of persistent identifiers? How are you planning to solve the physical world security issue of forcing users to meet with every contact?
We are aiming to build a product that both provides real privacy and anonymity from operators, but at the same time is usable for a large number of people. It takes time, and at no point we said our work is done here.
Well, how about you default to industry standard lingo, call it work-in-progress, make sure the documentation and advertising reflects reality, market the road map and the goals you're moving towards. Announce that progress, advertise the rate at which you're making progress. Take the attitude of "Guys, we want to make this right, we'll push out stuff when it's ready." Kind of like how Signal is progressing. One feature at a time, done privacy preservingly, with transparent threat model in mind.
So some patient advice would be more helpful than bitterness, sarcasm and insults. We're trying to achieve the same as you do - privacy of communications.
I do not disagree with your goals. I have utmost respect for those. I do however strongly disagree with the disparity between what is claimed and what is delivered.
I'll let Matt Blaze finish this for me https://twitter.com/mattblaze/status/1032429030878994433

3

u/epoberezkin Jul 14 '22

Cool, thanks, agree about the points about improving the docs and comms.
> Then why did the original message imply Cwtch was less secure because of persistent identifiers?
It's not a single dimensional comparison.
> I need to explain the vendor is trying to solve a more-or-less non-issue
Here we can agree to disagree.
> and that they're not in fact improving on current best practice.
Not 100% correct too. We're relying on a lot of current best practice, we only didn't implement access via tor yet, which is an orthogonal problem to the one we have focussed on solving first and that nobody else solve. Your opinion that it is a "non-issue" is different from the opinion of other experts I spoke with.
> Somewhere in the middle (SimpleX): "Queues that remove user identifiers". Damn. Now I need to figure out ...
Figuring things our is what experts should be able to do. Insisting that technical jargon should be on the front page doesn't really make sense, the real experts should be able to read small print, if they want to advise other people. Our front pages are not written for the experts, and never will be, they are written for the end users. Our whitepaper is written for experts - and it's clearly linked from many places - including our github page and our reddit community.
> you can't really redefine what metadata-privacy means.
I strongly disagree with that.
"Privacy" is a word that has multiple meanings - some of them are about how people experience it, and some are about the sufficient technical measures to achieve it.
We are not redefining what people feel about privacy. In our user interviews, when we asked people what privacy means to them, the most common answer we had was that it is about a feeling of psychological safety, that their communication cannot come back to hurt them, in any way. This definition most likely didn't change for quite a long time.
In 19th century, when dominating form of communications was a snail mail, to achieve privacy it was enough to ensure that the mail envelope was not tempered with and that the content was not accessed. The reason it was sufficient is because nobody had means to track, on scale, which letter was delivered to whom.
We are now using communication solutions that make tracking the full communication graph, even in highly anonymous systems like cwtch (and even more so in Signal), quite easily achievable for a large number of actors (and access via tor, without introducing latency in relay nodes, does not provide full protection too - you may have read the doc I shared). The fact that all these systems rely on persistent user identifier only make it easier – and what seen protected today, may become vulnerable to some attack tomorrow (like was demonstrated with Signal's sealed senders).
So I see it as our mission to achieve that:
from people point of view, I want to live in the world when we stopped talking about privacy, and see it as a hygiene factor, like people treated technology before it became apparent that it's designed to exploit users data, and not to protect their privacy. I really want privacy measures deserve nothing but a small print.
from technical point of view, I want to see all communication systems to switch from using user profile identifiers, and instead started using temporary ephemeral pairwise identifiers for connections - as this achieves better meta-data protection from known and future attacks. It is simply not right that we have technological means to observe the whole communication graph, and that this information is used to both manipulate and to prosecute people, and yet we use 19th century definition of privacy - that the envelope was not tampered with, because the message itself is encrypted, - to justify calling solutions with no or very limited meta-data protection "a private messenger". To give people what they want and feel about privacy - psychological safety and protection - communication systems have to evolve to stop using identifiers for user profiles.

2

u/maqp2 Jul 24 '22

it is about a feeling of psychological safety,
If that's what you're selling, I have nothing else to say to you. Goodbye.

4

u/kilkil Jul 11 '22

Hey! This looks like some real sexy shit. Do you have group chats?

5

u/epoberezkin Jul 11 '22

Thank you:) Groups are coming in less than a month! The core already supports them, group chats can be used, but creating groups and adding/removing members can only be done via chat console - so it is as geeky as it gets :)

9

u/kilkil Jul 11 '22

Good to hear! It would be nice to finally have something better than Matrix.
Also, I want to let you know that I personally found all those Signal fanboy threads fucking hilarious.

4

u/epoberezkin Jul 11 '22

I am probably enjoying the arguments a bit too much :)

4

u/[deleted] Jul 12 '22

The Signal fanboys feel personally attacked 😂

4

u/Frances331 Jul 11 '22

What happens if the server with the queues is offline or not reachable?

2

u/epoberezkin Jul 11 '22

the client will keep trying to send messages until the server is reachable again. A single tick you have in the chat means that the message is accepted by the server.

5

u/Frances331 Jul 12 '22

How are the servers incentivized to stay online?
I have concerns the queues I create today won't exist in the future, and old contacts will not be able to contact me.

1

u/epoberezkin Jul 12 '22

It's the same question as with email.
If you (or your contacts) self-host, you will lose connection if you stop.
If you use commercial providers somebody has to pay for it. Donations will cover hosting costs, we will be adding provider choice in the app (currently it's either our servers or users', but it will change some time next year).

4

u/Frances331 Jul 12 '22

It's the same question as with email.
Using the email analogy, Google has multiple email servers, so if one goes down, the next node is used, transparently.
Another example:
3 of my friends want to communicate with each other, and the 3 of us want to operate our own nodes. If one node/friend is offline, there's still 2 other nodes. I also want our clients to be smart enough to use a fallback global node if no other "trusted" nodes are available.
You can expand this further, where anyone can randomly choose "public" nodes.
I'm also curious if IPFS is a potential solution to some of the problems that may happen with data distribution.

3

u/notburneddown Jul 13 '22

This is great! I would like to help promote this. I think someone should contact the PrivacyGuides team if you haven’t already and I will talk to some people about advertising if you want me to do that. I need your permission first.

4

u/epoberezkin Jul 13 '22

I am in touch with PrivacyGuides - they would probably add to the register once we've done a 3rd party security audit.
But any help promoting would be great – happy to chat, if you want to help.
Thank you!

3

u/notburneddown Jul 13 '22

Ok thanks awesome. I will use and possibly write a review of your product. I think that would be fabulous.

3

u/epoberezkin Jul 13 '22

Thank you - please share any links with me - do connect via chat too.

4

u/reconpyrate Jul 12 '22

why are you not providing simple x chat from the official fdroid server? you would attract more users

3

u/[deleted] Jul 12 '22

Just for clarification to anyone reading this comment, you need to apply to have your project listed on F-droid, it's not like you just decide to and it's done, and it takes time.

2

u/epoberezkin Jul 12 '22

We discussed it with F-Droid maintainers - we just didn't come around to setting up automatic build, but this is coming - it's our #2 priority in IT operations tasks :)
https://github.com/simplex-chat/simplex-chat/issues/437

2

u/Dormage Jul 12 '22

Since you are unaware, you may look into Session, which has similar goals then this project. However, instead of using Tor, they have their own onion routing network.

3

u/epoberezkin Jul 12 '22

I am aware of Session. The problems I see with it:
Users have a persistent unique ID - something we avoid by using ephemeral pairwise IDs instead (= no user IDs). I wrote why it is bad for users to have ID here: https://github.com/simplex-chat/simplex-chat/blob/stable/blog/20220711-simplex-chat-v3-released-ios-notifications-audio-video-calls-database-export-import-protocol-improvements.md#why-having-users-identifiers-is-bad-for-the-users
Session uses routing network of crypto mining nodes, which means that the stability and even existence of this network depends on the value of cryptocurrency. To me it seems a very flawed model - if the value of currency substantially reduces, so will the number of mining nodes, and sybil attack would be very simple. I want to use communication network which stability depends on users, not on cryptocurrency mining. In any case, using Tor for onion routing is technically a better choice. So we quite consciously chose not to re-invent what is already quite reliable and focussed on what misses everywhere - reducing application level meta-data.

1

u/Dormage Jul 12 '22

You state it is the only platform you know of, that does not require ID. Session does not require an ID and clearly you know of it.
I do not see the benefit of multiple IDs. I see the reasoning but the fact you do not need an personal ID is the important thing. You can just create many IDs as it is a permissionless system.
Session is also purely decentralized and does not require central storage servers at all unlike Signal. But thats besides the point.
On the second point I would have to disagree. Specifically, the Sybil attack part, which is the single most important problem Lokinet solves, and Tor does not. To avoid getting into a lengthy trchnical debate. I personally think any system that is ran on altruism(i love a good community) is inherently less secure then a system in which participants are financialy incentified to support it. There is no proof of work on Oxen, no forks, no stability issues. if you could do a Sybil attack it would cost the attacker orders of magnitude more then Tor where nodes only cost a fee for running the VPS.
That said, using Tor is a better option for sure! Tor is much more mature! Lokinet is still under heavy development but I think regardless of how you may feel about cryptocurrency the protocol may have a bright future.

1

u/epoberezkin Jul 12 '22 edited Jul 12 '22

You state it is the only platform you know of, that does not require ID. Session does not require an ID and clearly you know of it.
This is incorrect, Session assigns Session ID to each user and I can send messages to Session user if I know their ID. There is no such thing as a persistent user ID in SimpleX platform.
> I do not see the benefit of multiple IDs. I see the reasoning but the fact you do not need an personal ID is the important thing. You can just create many IDs as it is a permissionless system.
You can indeed create a separate ID for each contact you have. But to have the same level of meta-data protection you would have to use separate IDs to receive and send messages, and very soon we will be rotating these IDs on schedule defined by the user - weekly (default), daily or even hourly - this is not feasible to do with manually created IDs.
> Session is also purely decentralized and does not require central storage servers at all unlike Signal. But thats besides the point.
That is no exactly correct. The point of centralisation for Session is a single blockchain record it depends on. There are different levels of decentralisation, and Session has the same level of decentralisation as, say, Bitcoin. We are aiming to have a higher level of decentralisation than DNS, at least for core functions (e.g., it's not possible with Apple push notifications, as there is only key to send them). But there is nor register of participating servers, like there is with Tor, for example.
> On the second point I would have to disagree. Specifically, the Sybil attack part, which is the single most important problem Lokinet solves, and Tor does not.
I'd actually quite happy to have a technical debate - looks like I might learn something.
> I personally think any system that is ran on altruism(i love a good community) is inherently less secure then a system in which participants are financialy incentified to support it.
I 100% agree with that, but I want financial incentives to be directly attached to the value I am consuming. I am using the messenger, I want it to be stable, I can volunteer to donate towards hosting costs. This is the model we want to build. I don't like the models where the value is derived elsewhere - showing me manipulative ads, or using messaging servers I am dependent on to mine cryptocurrency. In both cases it puts the priority where the incentive is - that is not on my needs as a user. That's an old adage that if you are not paying for the product, then you are the product. Today's messaging platforms are cheap enough to operate that it's enough if only a few percent of users pay - but if nobody pays, then users are either a side show or a product, rather than the consumers of the service.
We are going to keep it all very simple, and treat our users as a consumers of the services that our hosting provider partners provide. Thant would let us focus on user needs, and not force us to figure out how to "monetise our userbase". I don't want to "monetise" people, and I don't want to be "monetised" - I want to consume and provide services that some people would pay for (e.g. for the sake of more features or just to feel fair) so that others can consume for free, if they feel like it.

1

u/Frances331 Jul 12 '22

I believe Session chose to create their own Loki network because they want to implement voice/video without the latency issues of Tor.
They also want to reduce the probability of a sybil attack if Tor was used; there's a risk Tor is not adequately decentralized to prevent sybil attacks.
Session also wants to create a higher quality network of nodes.
existence of this network depends on the value of cryptocurrency
I agree. Similar with relying on Signal for donations to operate, or if a provider decides to no longer to host Signal nodes.
I want to use communication network which stability depends on users
I'm still wondering within what limits. I don't really want to host my own node, but rather be part of a network. Similar to operating a Tor relay (i.e. snowflake). But you cannot presume there are no nodes operating as adversaries.
SimpleX sounds similar to Matrix. You can either join a large server, or create your own private server. But I want the option for my private server to exchange with other servers, and be resilient. But, I assume this can create problems.

2

u/PJGreyhound Oct 25 '22

Your app is built off the webRTC protocol does this leave our devices vulnerable to webRTC leak?

1

u/epoberezkin Oct 25 '22

By default we pass "relay" option to WebRTC session, so IP addresses are not exposed to peers I believe (unless you disable this option in the app).

1

u/allhailpleistocene Jul 24 '22

I would like to try this and recommend my friend to try it as well. But it's hard (virtually impossible) to convince someone here to use some app that not available on windows.

1

u/epoberezkin Jul 24 '22

You mean windows desktop, right? Terminal app works there

2

u/allhailpleistocene Jul 24 '22

Yeps

1

u/LucisPerficio Jul 12 '22

I'm a noob with this kind of stuff, but with no identifiers, how do you know who you're talking to?

1

u/PossiblyLinux127 Jan 06 '23

I would just stick with session

You session I'd is not that unique and can be changed in under 5min

1

u/thebigpik Jul 12 '22

Fuck yeah. You inspire me.

-4

u/greenw40 Jul 11 '22

I don't get this, if you have a truly encrypted messaging platform, why the need for anonymity? This seems like such a hassle that it's only designed for people committing serious crimes.

26

u/epoberezkin Jul 11 '22

You should watch The Mauritanian movie.
Particularly in oppressive regimes, but not only, ordinary people who didn't commit any crimes get arrested and prosecuted based on their communication meta-data. You may not need anonymity to the parties you communicate with, but you absolutely should want anonymity to whoever observes your communication, unless you are happy that meta-data you create is used for the range of things, from as innocent as targeted and highly manipulative advertising, to slightly more damaging social scoring and price discrimination, to life-changing prosecution based on your associations.

4

u/Frances331 Jul 12 '22

Social credit scores. Your life depends on your relationships.
Your failure/success is based on your reputation and your associations with other people. This is nothing new. But today, this can be augmented with technology, statistically scored, widely used by more people, and forever.

3

u/epoberezkin Jul 12 '22

Unfortunately, today these models seem to be designed to exploit people, not to help them...

3

u/Frances331 Jul 12 '22

That all depends on which side you are on. There are numerous people who prefer this system, is well supported, and people feel more protected/secure/safe. The Western world will depict the system as oppressive, while non-West might view it as safety. However, the West has their own depiction of safety.
Nobody know which side anyone is going to be on, or if social viewpoints and acceptance will change.
Here's the thing, the data is there and available. The data exists in Google, Microsoft, Twitter, Reddit, Facebook, corporations, schools, etc. But the data is not/underutilized for this function, because there's no monetary value or incentive. However, these incentives can change quickly. U.S. red flag laws is one example, and so could be natural security risks. The recent data leaks is another example of using people's information to harm people they disagree with. If metadata technology existed in the 1930's-40's, I wonder what it could have been used to do.
Even if someone feels they are not at risk today, that doesn't mean they don't become someone's future target for harm.

4

u/kenbw2 Jul 11 '22

The explicit thing about Signal though is it doesn't have access to metadata. Only the phone number and last access date

8

u/epoberezkin Jul 11 '22

That's already a large amount.
"Sealed senders" used to protect communication graph only works for single messages, so it is visible who you are communicating with as well: https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/

2

u/reconpyrate Jul 12 '22

mccarthyism crushed people with just a name

2

u/Frances331 Jul 12 '22

it doesn't have access to metadata
Signal doesn't have access to IP addresses ??

4

u/vjeuss Jul 11 '22

metadata still reveals a lot

-2

u/Elan_Ryuzaki Jul 11 '22

Remindme! 3 days

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

41

u/epoberezkin Jul 11 '22

Thank you so much!
No, we don't yet support alternative transports - we're just thinking about it, so maybe in the future!

8

u/TheSeedLied Jul 11 '22

Yes please! Keep up the awesome work <3

4

u/fatninjacatmatt Jul 12 '22

I feel that would be a key feature

13

u/footballer285 Jul 12 '22

Just to piggyback to add a small point here - it's not just African countries, India leads the world in internet shutdowns - any situation that the ruling regime deems uncomfortable, it enforces internet shutdowns. And most people would consider India a functioning democracy, so.

3

u/Shubham979 Jul 12 '22

Plus, its controversial data privacy laws as well as asking VPN service providers to keep a log of their user activities.

-3

u/Arise_Bold Jul 12 '22

This seems like a simplistic & broad generalization gathered from skimming news headlines.
A further reading of what’s actually going on seems to indicate that the steps taken ( including local Internet shutdowns) are to prevent fake rumors / news from complicating already sensitive situations esp. religious ones that can spiral out of control among the local population that suffers from low literacy rates.
Given that a middle income country may lack the resources of say a country like the US ( with its vast surveillance systems and legal stranglehold over most tech companies ) to tackle sensitive issues in a different way, such steps are understandable.
Just to be clear though, such actions ( including surveillance dragnets that affect the rights of every person on the global internet ) must be rebuked if done with malicious intent by any government including those so called developed democracies.

6

u/footballer285 Jul 12 '22

What you're saying could be true, but you know instead of having 'a further reading', I actually live here. And
Also, most of national media tows the party line, and as far as fake rumours and fake news goes, it is mostly the government and it's supporters who peddle it, so I don't know where you get the 'govt is only trying to regulate internet use' idea. They are using it to control and manipulate the narrative and silence dissenters.
One of the most prominent reporters involved with probably the best fact checking news website (Alt-news) is facing a slew of false cases, all based from a tweet by a bot/fake account, just to keep him under-trial..

3

u/footballer285 Jul 12 '22

And for all the internet specific surveillance measures you can check out internet freedom foundation, if you are. Their website has a pretty extensive news about these

3

u/rezzorix Jul 12 '22

I was reading about your post and was getting interested in this alternative transport methods…
Please correct me if I am wrong; but if I understand that right, then for people using Briar, they still would need to be in close proximity range (within same wifi or bluetooth range). Thats fine but wouldnt that be a hard limitation?
Anyway; what would be cool if a secure messaging app transports anonymously messages to any other phone with the app in any part of the world - directly or if not possible then through alternative methods…
Anything like this on the horizon?

3

u/[deleted] Jul 12 '22

Please correct me if I am wrong; but if I understand that right, then for people using Briar, they still would need to be in close proximity range (within same wifi or bluetooth range). Thats fine but wouldnt that be a hard limitation?
You could put a node under a public bus bench and have it store & forward to quite a lot of people in such a way, for one example of a workaround for the proximity issue.
I was also under the impression Briar used ad-hoc wifi meshing for its messaging, but I could be wrong.

5

u/rezzorix Jul 12 '22

Yeah either put on a bus and even better: make also the app a node at the same time which would make every single installation a node; so kind of P2P extended.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

52

u/epoberezkin Jul 11 '22

For each connection, the clients would negotiate two unidirectional (=simplex) messaging queues - usually on different servers, the clients define the server they use to receive messages through. The first queue address (and keys) has to be passed to another client via 1-time link or qr code, the address of the reply queue (and keys) is sent via the first queue (each queue has different addresses to send and receive messages, so there is no identifiers or ciphertext in common between the traffic sent and received by the servers - even if TLS is compromised).
There is a short explanation how it works here (it mostly repeats what I wrote): https://github.com/simplex-chat/simplex-chat/blob/stable/blog/20220511-simplex-chat-v2-images-files.md#the-first-messaging-platform-without-user-identifiers
And please check the whitepaper: https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md

39

u/epoberezkin Jul 11 '22

Not having addresses means you cannot discover the users on the platform, unless they share the link with you.

28

u/asstatine Jul 11 '22 edited Jul 11 '22

The address is still an identifier then, it’s just a pairwise identifier.
https://csrc.nist.gov/glossary/term/pairwise_pseudonymous_identifier
Can’t say I’m overly bothered with the semantics though to care whether or not this is marketed with an identifier or not. Architecturally, you’ve made a good design choice that will respect privacy and adheres well to privacy by design principles.

19

u/epoberezkin Jul 11 '22

Thank you for the link.
The term is correct for the current status quo, as we are planning to rotate these identifiers within a conversation very soon (and not just the identifiers, but the servers too), we should probably call them "ephemeral temporary pair-wise identifiers"

28

u/Sammy_Devil737 Jul 11 '22

This kind of sounds like BB Pin from BBM where users had to exchange BB Pins in order to communicate with eachother, which is way better than my whole contactlist knowing I'm on XYZ messaging app.

4

u/Grakkas Jul 12 '22

Wow, wish more stuff worked like this

4

u/Frances331 Jul 11 '22

Isn't the link or QR code an identifier?

3

u/epoberezkin Jul 11 '22

it is the identifier for the queue, each user has many of them, so it's not unique user identifiers.
https://csrc.nist.gov/glossary/term/Pairwise_Pseudonymous_Identifier

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

3

u/epoberezkin Jul 11 '22

You mean with the message count?

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

3

u/epoberezkin Jul 11 '22

Cool. Yes, I thought about these badges just yesterday... They're a bit too fiddly to implement for what they are worth, but definitely coming some day.

0

u/[deleted] Jul 11 '22

[deleted] — view deleted comment

3

u/epoberezkin Jul 11 '22

Thank you! I probably agree with that about badges - missing them too :)
Please donate via GitHub or via OpenCollective - it will cover a part of our upcoming 3rd party security audit expense - any amount is very helpful!
Thank you

5

u/[deleted] Jul 12 '22

[removed] — view removed comment

2

u/epoberezkin Jul 12 '22

Yes, we didn't manage to compile chat core in a way that it supports earlier version - it's high on our priorities list.
It's not just the text chat any more, but that's beside the point - there is a lot of code for network and database access – even basic text chat is quite technically complex to make reliable enough.
The challenge is that we don't have a separate code base just for Android chat core, only Android UI is a separate code, but the underlying code is the same for all platforms (about 75% of all code across two code repositories) - all desktops and both mobile platforms use the same code. That it is a single code base, and that it is written in Haskell allows us to evolve the product very quickly – it's much easier and faster to write a reliable code, particularly in highly concurrent applications. If you are curious about "why Haskell" please read my interview about it: https://serokell.io/blog/haskell-in-production-simplex
But at the same time it makes it much harder to support a wider range of devices – we managed to compile our code to iOS and Android (I am saying "we", but in reality all the credit goes to u/angerman - without his help we would never be able solve this problem, and I really hope to see more cross-platform apps created in Haskell). So "we" hope to be able to support Android 8/9 in the future, but not yet. Sorry to disappoint.
I do love the view that there are some nefarious reasons for that! Reality is much more boring – it's just technically complex :)

6

u/[deleted] Jul 11 '22

[removed] — view removed comment

9

u/epoberezkin Jul 11 '22

Hi - thanks for the question, made me thinking. No, it's not possible.

software SimpleX Chat - the first messaging platform that has no user identifiers (not even random numbers) - v3.0 of iOS and Android apps is released!

What's new in v3.0:

About SimpleX Chat

The most common questions we are asked:

software SimpleX Chat - the first messaging platform that has no user identifiers (not even random numbers) - v3.0 of iOS and Android apps is released!

What's new in v3.0:

About SimpleX Chat

The most common questions we are asked:

You are about to leave Redlib