Note that while it might be decentralized and "secure", it is not anonymizing as IMAP + SMTP are far from anonymous. Email is a legacy system that was never designed with privacy or anonymity in mind.
This is useful if you want to keep the content of your messages secure, but if you need to keep your identity, social graph and the fact that you conversed with certain people obfuscated, I don't think Delta Chat via email is a good solution.
It's also only decentralized as much as public email infrastructure is decentralized.
I would go a step further: this is not secure. Forward secrecy and metadata privacy are table stakes in any modern secure messaging design, and Delta Chat has neither.
Today I learned: table stakes is borrowed from poker referring to the minimum size bet needed to participate in a hand, I’ve heard it so many times
That is not correct. Table stakes are not a "bet size", they are the minimum you have to bring to have a seat at the table. For example you might have to bring $300 to sit a table where the minimum bet size (big blind) is $5. You only have to bet the blinds 2 out of 10 hands (or more, if short-handed), which would be much smaller.
As a side note, despite its popularity, Texas hold'em is just one type of poker game. In most poker games (5 draw, 7 stud, etc..) you ante every hand.
Because poker variants are so popular basically everything varies, but yes there's often an ante (a forced bet every player makes each round), and that's even present in some Hold 'Em structures.
The first N times I came across someone use "table stakes", I dyslexically read it as "table steaks". Still came to the same meaning because, yeah -- I get it -- I too would only be coming over for dinner if there are steaks at the table.
Source: https://delta.chat/en/help#pfs
It's basically GPG with better UX.
PGP?
GPG is gnu privacy guard, it's an open source implementation of the same ideas that are PGP (pretty good privacy).
Specifically we're supposed to call it OpenPGP these days
There is PGP, OpenPGP, and GnuPG, and they’re all parts of a shared ecosystem but not the same. They never were, so it’s not like anything changed over time about this.
- [deleted]
deltachat devs are working on forward secrecy. and as for metadata, as long as the messages are sent from my personal email server to the destinations email server using a TLS connection, the metadata is accessible only on those two servers. sure, if i use gmail then google has my social graph. but so do whatsapp and telegram and others. yes, more private options exist, but for example in one group of friends right now the choice now is between whatsapp and deltachat. whatsapp because most people in the group already use it. deltachat because most people already have email. signal or matrix are not under consideration.
> deltachat devs are working on forward secrecy
That’s great, but I’m not holding my breath. PGP isn’t architecturally well-equipped to provide forward secrecy. In the mean time, I think it’s borderline negligent to put this in the category of secure messaging; the world’s expectations for security baselines have moved on beyond the mid-2000s.
(My reference point here is Keybase, which built a very user-friendly and misuse-resistant encrypted chat on top of PGP in the mid-2010s. They couldn’t get to forward secrecy either with PGP as their substrate.)
> as for metadata, as long as the messages are sent from my personal email server to the destinations email server using a TLS connection, the metadata is accessible only on those two servers.
To the best of my knowledge, MTA-STS adoption rates are still abysmal[1]. It’s a move in the right direction, but this kind of shambolic jigsaw approach to communication security isn’t appropriate in 2025. Sensitive messages should go over protocols designed to carry them.
[1]: https://www.uriports.com/blog/mta-sts-survey-update-2025/
OpenPGP is a message format standard, not an architecture standard. Since they are doing a instant messaging thing, there is no particular reason they couldn't do forward secrecy. They could even do a hash ratchet and call the result a double ratchet if they really wanted to. It would probably be more reasonable to do something a bit less obsessive and just make it so that the user can more securely delete their messages in the face of device compromise in an instant messaging environment.
"Architecturally" refers to the architecture of OpenPGP's message and certificate formats, not some kind of architectural standard. You can see Delta Chat's own community struggle with this[1]: unbounded certificate growth doesn't mesh well with acceptable rotation periods for ephemeral keys. There's also the problem of OpenPGP implementations encrypting to all subkeys instead of the "latest" one, which of course blows a hole in the FS property.
[1]: https://support.delta.chat/t/autocrypt-key-rotation/2936
The Delta Chat issue with subkeys seems to be an Autocrypt thing. Most OpenPGP implementations will encrypt with the latest encryption key.
Which brings up a point I suppose. Delta Chat is not really doing OpenPGP. They are mostly doing Autocrypt. Autocrypt was an attempt to do encrypted email without the bother of identity verification. It has always seemed like a bad idea to me. The Delta Chat project ended up adding identity verification on top of Autocrypt.
They don’t seem to think it’s an Autocrypt thing; they seem to think it’s an issue with certificates being de facto append-only. Also, “most” is not acceptable —- if even a small percentage of Signal clients had this kind of FS-breaking bug it’d be considered a significant vulnerability. We should demand better than “most.”
PGP isn’t architecturally well-equipped to provide forward secrecy
i have no insight into the development, but i suppose that swapping out PGP for something entirely different should technically be possible.
they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. seems a bit wierd given the premise, but the devs are at least not limiting themselves to SMTP and PGP.
> but i suppose that swapping out PGP for something entirely different should technically be possible.
That would probably be good, but email is still a terrible substrate for secure messaging. Clear metadata is security poison; you want as little of it revealed to participant servers as possible.
> they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely.
That’s great, but in that case: what’s the value proposition relative to Signal or even Matrix?
the peer to peer protocol at this point is only for realtime communication at which both parties have to be present. like IRC, those messages are not saved. it does not replace regular messaging which is stored. i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. as someone else stated, deltachat's value is that it is able to reuse existing infrastructure and does not require (but allow) a new set of servers to be able to work.
> i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction.
I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design.
(It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)
exactly why Signal uses phone numbers
the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts.
and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat)
the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.
You are not expected to use your regular email address, you get assigned a random email address that gets tied to your account (and your chosen username, but I think that can be changed) and the servers that store uncollected messages are only accepting properly encrypted emails. All this is completely transparent to users, it looks like Signal, but doesn't require a phone number, and it uses proven technologies where server managers would only have access to the randomized email addresses and the message size and times (but those are not logged in the standard setup).
There is an inbuilt drive for decentralization, as "anybody" could run a server (I just set one up).
getting a random email address from a dedicated deltachat server is a new, optional feature. it didn't exist when i signed up. no matter. i am not using deltachat in a way that i need to stay anonymous. i am using it to talk to my friends. and if i wanted to i could create another account on the new servers. the ability to use a semi-anonymous email was always there. it's just a matter of finding a server for that. i am afraid though that the anonymity of the deltachat servers will be abused and they become targets of law enforcement.
Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata.
> and what are reasonable security expectations?
End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that.
> for most people sending encrypted emails would already be a win.
I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal.
There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear!
> the goal here is to raise the general use of encryption in messages.
No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards.
[1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...
Centralization is not a security property
true, i wasn't thinking about security here but reuse of infrastructure. signal doesn't reuse infrastructure because it needs its own servers.
End-to-end encryption that the user can’t accidentally downgrade from
that's a fair point.
that doesn’t spray valuable metadata across the Internet
i find that a gross exaggeration. yes. metadata can be read by every server the mail passes through. but in practice most mails are only touching the sending and the receiving mail server. if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
also, where i use deltachat, the alternative is to use email.
I think the average person doesn’t know what an encrypted email is
which is why we need more encryption by default.
adoption outside of corporate S/MIME is marginal.
because it is to hard to use. deltachat makes it easy to use. next possible step: delta mail. a more traditional mail client that makes encryption as easy as deltachat does.
The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people
there is a long road to get to that. more encryption is just one step, but a necessary one. i agree with you, but the goal can't be reached if we don't work on multiple fronts. one of those is helping people to learn about encryption and privacy, which only happens by slowly getting them to use better tools and by improving those tools.
rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some. sometimes that makes sense, especially if the solution promises more than it holds. and deltachat would fall into this if it were to promise complete privacy. but i don't think it does that.
i have friends who outright refuse to sign up to a new service. but deltachat is ok because they can use their existing email for it. technically that sounds the same as saying that with signal you can reuse your existing phonenumber, but people already have much higher privacy expectations to sharing their phone number, and also deltachat doesn't share your email address except with recipients so it really isn't the same thing.
> if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
Why are we entertaining this hypothetical? It isn’t true in practice; the average user doesn’t control their mail server. The average user is using Gmail or Outlook, where their metadata is a single subpoena away.
And again, it just isn’t true: you need not just control over the server but also strict transport security for this property. This is not widely true of mail servers on the Internet.
> rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some.
I don’t agree. I think the average user has multiple high-quality E2EE messaging technologies available to them, and that Delta Chat effectively muddies the water by providing a worse security posture with the trappings of a familiar-but-unsecurable ecosystem (email).
(I also don’t know why people think Signal shares your phone number with people other than recipients. To my knowledge, that has never been the default and presumably never will be, even with their private contact discovery protocol.)
The point of Delta Chat is that the email system IS securable, and E2EE is possible within the Delta Chat ecosystem while they use well-established and understood technology, software and infrastructure. The idea is sound and charming, and completely open source and people can run their own servers to contribute to the infrastructure.
the average user doesn’t control their mail server
fair point. there are options however. you are not locked into trusting a specific entity. but the critical point is that even signal is able to figure out who is talking to whom: https://sanesecurityguy.com/articles/signal-knows-who-youre-... sure, for SMTP the contact details are directly in the messages, which is worse, but i don't know of any service that works completely without metadata. but signal is at least trying.
also strict transport security for this property. This is not widely true of mail servers on the Internet
since gmail requires TLS i highly doubt that there are many servers out there that don't support it.
the average user has multiple high-quality E2EE messaging technologies available to them
available and willing to switch are different. as i said, my friends are not willing to sign up to yet another messaging service. it's a social media fatigue.
why people think Signal shares your phone number with people other than recipients
that's not the point, at least for me. i am hesitant share my number with signal or any other service, and worse, i do not want to share my number with the people i talk to. i refused to use signal until the later was fixed. i refused whatsapp too, but to many people that i need to reach demand it, so i had no choice.
these are all trade-offs. not everyone agrees on the same, and while i understand and principally agree with your arguments, for me they don't work because i can't convince my friends. i also have other friends who do run their own mail servers. i have contacts who require whatsapp and others who can only use wechat. most often i don't have a choice. i am using whatever i can get people to agree to, and for that deltachat is a good option. signal could have been a better option but unfortunately their requirement to share phone numbers until recently made them a worse option than deltachat or even telegram for anything but 1:1 communication with trusted friends (those who i trusted to have my number). that has changed now, and i started to use it. but it will take time to build up my contacts there. btw, in some countries it is not even possible to sign up to signal. the number gets rejected.
> since gmail requires TLS i highly doubt that there are many servers out there that don't support it.
Gmail doesn’t require TLS, unless by that you mean that their webmail interface is TLS only. Like every other mail provider, they do opportunistic TLS on external delivery, and TLS on MUA connections (SMTP and IMAP) is largely at the mercy of user configuration.
The fact that people seem to think that TLS is a mainstay of the email ecosystem is clearly part of the problem here.
As for the rest of this: I’ve hammered on about Signal because it’s the naive right choice, but it’s ultimately up to you to decide whether your phone number is an acceptable public identifier. But even if it isn’t, there is so much out there that’s indisputably better than this mess: Matrix or even iMessage (with an email identifier instead of a phone) would be better.
Gmail doesn’t require TLS
according to this article it does:
https://www.valimail.com/blog/the-new-requirements-for-email...
and for one i think this is a good thing.
otoh, according to this it doesn't:
https://support.google.com/mail/answer/6330403
but https://transparencyreport.google.com/safer-email/overview shows that by now almost all emails sent and received by google go through TLS which i believe can be used as a proxy to assume that most servers out there now support TLS.
signal fixed their phone number problem, so that is no longer an issue.
matrix is not reliable enough. the encryption can break in the sense that messages can no longer be read. i am basically required to have a second unencrypted backchannel (or use a different app, but then why even bother) to make sure i can reach someone. (the issue i experienced could be due to a misconfiguration of a matrix server, but that's a bug in itself. it should not be possible to change the configuration of a server in such a way that my messages arrive but can not be decrypted anymore.)
matrix encryption reliability should be fixed (at least on element x/web + synapse combos) as of Sept 2024.
what server & client are you using?
the client is fluffychat 1.26.1. server A and B below are both synapse 1.132.0, server C i don't know.
the situation is as follows:
there are multiple servers and users involved. let me name the servers A, B, C and matrix.org.
i have accounts on A and B, and my friend has an account on C. others have accounts on matrix.org. all of us are in a group on matrix.org (i am in the group with both of my accounts from A and B).
with both my accounts i can see but not decrypt messages from before i joined. yet the groups chat history setting is "visible for all participants" and not "visible from joining"
on account A i can read messages since joining, except for those from my friend on C. my friend on C also can not read messages from A in the group. nor can we talk to each other directly.
now, A is a very restricted server that blocks many other servers as a spam protection measure. as far as i can tell, it does block server C but it does not block B. B doesn't have any blocks.
that i am unable to open a direct connection to C from server A is expected because of the block. from server B this is not a problem. B can also read all messages in the group (after the join date)
what bothers me is this: even if server A blocks server C, why does it block messages that C sends into a group on matrix.org? groups should either be allowed fully or not allowed at all. it doesn't make sense that groups break for members on blocked servers.
now, A blocking C is not intentional and i could ask the admin to remove the block, but lets assume that it is intentional because maybe there are many spammers on C and my friend is an exception.
what i wonder is why even allow blocking in this form at all?
i am the only member from server A in the group. what benefit does server A have from blocking users from C in the group i joined on matrix.org? i could understand if A doesn't want people from C to join groups on server A, or connect to people on server A. so block directly incoming connections. but why block messages in a group that's not on server A? i joined that group. dealing with C should only be my problem. also, the messages aren't even blocked. they just can't be decrypted. so traffic is not even reduced. this is not encryption randomly breaking. this looks more like a problem with how blocking works to me.
also i think it would make sense that despite blocks, individual members from A should be allowed to initiate connections to users on blocked servers. it's connections from C to A we don't trust, but connections from A to C should be fine, because everyone on A is trusted.
the way i see it, if i am allowed to join a group, i should be able to see all messages in the group, and everyone should be able to see my messages, even from people on blocked servers and no blocking rule should be able to prevent that. if i should not see those messages then i should not even be allowed into the group. once i am in a group, there should be no blocks getting in the way.
users from blocked servers should not be able to access groups or contact people on the blocking server. and maybe users from the blocking server should not be allowed to join groups or talk to people on blocked servers. but that would ideally be a separate permission.
another issue is the key handling. i find it confusing as to what i need to back up so that i can reopen a connection from another device. deltachat has a simple export profile. i save that and i import it on another device and i am done.
> Forward secrecy and metadata privacy are table stakes in any modern secure messaging design
I think this is counter-productive, limiting the adoption of meaningful security improvements. The engineering and UX implications of PFS and full metadata encryption (in particular social graphs) are severe. Not even signal has that, and they are above and beyond for a mass consumer product.
From the physical world, it’s like saying that having addresses on the letter is the same as the government opening and scanning the contents of every letter. Of course I don’t like the indiscriminate metadata collection, but there are worse things.
If you’re a spook or dissident, by all means, take extra precautions. You’re gonna need to anyway, in many more disruptive ways than your messaging app. Personally I just want to share shitposts with friends and speak freely without second guessing if I’m gonna be profiled by a data broker, or someone is gonna scan and store the pictures I send forever. Keep in mind that the status quo (Gmail, DM on social media) is incredibly bad.
No. Unless your messenger is at pains to make sure people don't use it in life-or-death situations (for instance: because they're being targeted by ICE, or the law enforcement and security apparatus of their country), the exact opposite thing is true.
These kinds of message board discussions invariably pose a dilemma: "send messages in plaintext using normal email, or use whatever secure messaging tool is available regardless of its strength". That's false. People always have a third option: not sending the message electronically. Most of us here have messages they wouldn't send even with their most trusted messaging tools; people who are at serious risk from message interception have much more dangerous messages than that.
Recommending that at-risk people use weak secure messaging as a "better than nothing" step towards real secure messaging isn't just bad advice. It's malpractice.
This conversation is important, and weighing these aspects against each other is critical in order to form better opinions. We clearly both agree there are subtle and counter-intuitive effects at play. I don't think there's anything wrong with debating them, and I'm happy to be convinced otherwise.
> Unless your messenger is at pains to make sure people don't use it in life-or-death situations [...] the exact opposite thing is true
Right, this is the false-sense-of-security effect. It exists and it's real. But there are more aspects that weigh in.
> People always have a third option: not sending the message electronically.
I challenge this assumption. In reality the effect is not about what they can do if they listen to the advice of Bruce Schneier, but what they will do. Navel-gazing on security and throwing your hands up if people don't act "the way they should" is what's really irresponsible, imo. I.e. if your contacts are not physically close, they won't (or even can't) schedule a flight to send a message. They'll generally use what's socially convenient, even if they're discussing something like abortion in an oppressive state. If you're lucky non-techies will say "Hey, maybe we should try that app Signal, I heard it's more secure". That's as good of a win as it gets.
The counter-example would be going around saying Signal is worthless because they collect phone numbers, they don't enforce public key validation, and they don't use onion routing to protect your social graph. I don't think we disagree about how ridiculous that would be, even if we disagree on which aspects are most important.
Basically, if set the weight of all security properties to ∞, you will get something that's so wildly inconvenient that nobody would use it. Even PGP that's relatively easy to use was at its peak about as popular as starting a yak farm.
> I challenge this assumption. In reality the effect is not about what they can do if they listen to the advice of Bruce Schneier, but what they will do. Navel-gazing on security and throwing your hands up if people don't act "the way they should" is what's really irresponsible, imo. I.e. if your contacts are not physically close, they won't (or even can't) schedule a flight to send a message. They'll generally use what's socially convenient, even if they're discussing something like abortion in an oppressive state. If you're lucky non-techies will say "Hey, maybe we should try that app Signal, I heard it's more secure". That's as good of a win as it gets.
I disagree, people will end up in prison or dead if they let a false sense of security compromise themselves. It should be stressed that certain sensitive activities should not involve computers, phones, etc because of the very real possibility of dire consequences. If someone is desperate enough where they have to resort to using computers to do sensitive activities, they should be given the best advice, caveats emphasized, and not just what someone feels is "good enough".
Advising people to use messaging systems that you know to be faulty because they optimize in some other non-personal-safety area like "federation" or "open standards" or "compatibility with email" means that you are putting your own aesthetic preferences above other people's safety. It's simply malpractice.
I really think people would be safer communicating their sensitive messages on Delta Chat than on Signal. Both are encrypted securely enough, and the endpoints being compromised is probably the biggest threat in both cases, but with Signal there is more metadata (the phone number) and you're almost certain this is being farmed on a massive scale (as opposed to Delta Chat).
Wildly false. This is the problem with advice for activists and at-risk people; there's no way to distinguish the stuff that is just nerd LARPing from the stuff that is actually based on educated risk analysis.
Metadata security isn't table stakes? I guess just pray your app's UX isn't good enough that the US Secretary of Defense decides to use it.
I don’t understand how asking for things that are bog-standard is somehow counter-productive. I think the really counter-productive thing here is flogging the dead horse of encrypted email; ordinary people deserve better than that.
> Not even signal has that, and they are above and beyond for a mass consumer product
What parts of this do you think are missing from Signal? Signal has had PFS for as long as it’s been called Signal, and has famously minuscule metadata on users.
> famously minuscule metadata
Famously minuscule? They demand a phone number, which blows up any possible anonymity story.
Compare with Telegram which also expects to correlate the number to an IMEI
> What parts of this do you think are missing from Signal?
The social graph isn’t e2ee in any app that works because the server needs to route the message. And the social graph is metadata.
>Personally I just want to share shitposts with friends and speak freely without second guessing if I’m gonna be profiled by a data broker
You are welcome to live your privileged life with your privileged friends using any software you feel is good enough. Just don't assume everyone can afford that luxury.
https://pressgazette.co.uk/news/rsf-moves-downgrades-global-... is a decent index to assess in what kind of country you're living in.
I agree from that perspective.
> but if you need to keep your identity, social graph and the fact that you conversed with certain people obfuscated
Does Signal, the current "privacy respecting, secure default" for mainstream people, provide this?
"It's also only decentralized as much as public email infrastructure is decentralized."
That's already a lot more decentralized than most web services we use on a daily basis
In what sense? I think in practice there are significantly fewer widely used email service providers than there are web service providers. If you threw a rock at a crowd of people, you'd probably hit someone with a Gmail or Outlook-managed inbox.
> In what sense?
Email is an open interoperable standard, owned by nobody.
You can run your own email infrastructure just fine (I do, many do).
So it is fundamentally different from all the proprietary walled gardens which have a single owner that controls everything.
Signal is notably not proprietary. And email is de-facto owned by a small handful of service providers.
Telling Joe Shmoe that he should run his own email infrastructure instead of using literally anything actually built for E2EE is an ideological argument, not one grounded in Joe’s message security expectations.
> Signal is notably not proprietary.
See parallel response. Open source is not the same as an open interoperable standard.
> And email is de-facto owned by a small handful of service providers.
No, not really. Yes there are large providers who manage a lot of people, but it is not owned by anyone.
> Telling Joe Shmoe that he should run his own email infrastructure
That's not necessary either. Joe can get his email from any of thousands of providers ranging from large to tiny if he doesn't want to run it. Service can also be delegated in various ways depending on comfort and convenience. For instance, one mixed setup is to manage receiving by one provider (which could be oneself, to guarantee you can't get locked out) and delegating sending to a different provider (self or others).
It's also easy to delegate to a tech-savvy friend or family member. I run email for my own domains but also for most family members and a few consulting businesses in our circle.
This is the power of open standards codified in RFCs. It is what the Internet was meant to be. Walled gardens was never part of the plan.
All of which is true and praiseworthy.-
Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...
The Delta Chat ecosystem runs on systems that only accept encrypted emails. You access it through a Delta Chat client, you don't use a Gmail or Outlook-managed inbox.
people exist that run their own mailserver
It is not possible to hide the fact that you conversed with a certain person from your service provider. That's part of why being able to choose a service provider is so important.
Theoretically, Cwtch[1] would afford you this obfuscation assuming Tor is secure and your adversary isn't nation-state level.
Similarly, using SimpleX private message routing via .onion message relays and the fact that the system has no identifiers can also afford you that obfuscation.
Differences between Cwtch, and SimpleX? Which are you leaning towards to and why?
According to https://github.com/simplex-chat/simplexmq/blob/stable/protoc...:
> identify that and when a user is using SimpleX.
Does this apply to Cwtch?
Also, is it not possible to obfsucate this traffic? Tor with obfs4?
Related:
#1 - https://security.stackexchange.com/questions/241730/traffic-...
#2 - https://github.com/simplex-chat/simplex-chat/issues/4300
#3 - https://github.com/tst-race/race-docs/blob/main/race-channel...
> Which are you leaning towards to and why?
Heavily sandboxed SimpleX that's firewalled to block any non-Tor traffic. Chose this one because it allows for offline message sending/receiving, despite privacy implications, and because it has clients people will actually use.
Cwtch doesn't let you send messages when the recipient is offline by virtue of how it works, which is more secure, but inconvenient.
When evaluating Cwtch, I think I read somewhere it might send identifying metadata to your recipient, or something similar, but I might just be making that up. I'll have to look up what I was reading.
> > identify that and when a user is using SimpleX.
> Does this apply to Cwtch?
With Cwtch you're running two hidden services, one on either end of the chat, and that happens over Tor with no middleman service, so no. A passive network observer can tell when you're connecting to Tor, but you can attempt to obfuscate that with transports.
> obfuscate that with transports.
Such as obfs4, I presume.
I read about RACE just now, seems interesting:
- https://github.com/tst-race/race-quickstart?tab=readme-ov-fi...
- https://github.com/tst-race/race-destini
Have you heard about it, or have you used it before?
> Cwtch doesn't let you send messages when the recipient is offline by virtue of how it works, which is more secure, but inconvenient.
I agree. How much more secure is that? In the case of Ricochet, this only applies to friend requests. You have to be online to be able to receive friend requests, which I am fine with.
>How much more secure is that?
It's much more secure wrt metadata. There is no third party server that's able to amass metadata about the two users conversing. SimpleX doesn't hide your IP-address from the server, and given that there's exactly two parent companies hosting ALL of the official servers, it's not too hard for Akamai or https://runonflux.com/ or anyone who compromises their OOBM systems to perform end-to-end correlation between two users.
https://discuss.privacyguides.net/t/simplex-vs-cwtch-who-is-... has a lot of discussion about Simplex vs Cwtch.
Agree with your post, but do want to point out that using private message routing on SimpleX theoretically hides your IP address from the server[1].
Similarly, built-in routing over Tor can make performing correlation attacks difficult for some adversaries, and if you elect to use your own .onion servers instead of the official ones, it adds another layer of obfuscation.
[1] https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
What do you mean by "own .onion servers" here specifically? It is ambiguous for me. Your own hidden service? Your own bridge? As for hidden services, that would be up to SimpleX to do so (just like how Ricochet does it), otherwise I have no idea how one would do it with SimpleX or configure SimpleX to use "mine". You would need Orbot on Android to begin with to use SimpleX with Tor, and I do not know if there is such an option to "use own hidden service", as hidden services do not work this way at all.
How do you configure SimpleX on Android to use your own SMP servers BTW?
By "your" I mean your chosen 3rd party servers
Could you clarify with regarding to .onion? How would I set this up for SimpleX and how would I configure SimpleX to use it, on, say, Android and Linux? I believe to use Tor with SimpleX, you would have to use Orbot, for example. What would I have to set up and how, on Linux? Genuine question. I would much prefer to self-host it.
I would also like to know how I would configure SimpleX on Android to use my own SMP servers.
Edit: I found this: https://simplex.chat/docs/server.html.
And I found:
In any case, I believe what I was looking for is https://simplex.chat/docs/server.html.# `socks_mode` can be 'onion' for SOCKS proxy to be used for .onion destination hosts only (default) # or 'always' to be used for all destination hosts (can be used if it is an .onion server). # socks_mode: onionYeah, I figured it out. I think I am supposed to do this: run a hidden service and a SimpleX server that uses the hidden service's port, and then use the hidden service's hostname as my SMP server that I set within the app.
On Android, however, this is not as easy or straightforward and I cannot think of a way to do this, to be honest. That is why I prefer these programs to have Tor bundled and run the hidden service by themselves with a hardened-enough torrc. Ricochet does this on desktop, which I think is the right way to go about this. SimpleX's server (https://github.com/simplex-chat/simplexmq) should do this.
> On Android, however, this is not as easy or straightforward and I cannot think of a way to do this, to be honest. That is why I prefer these programs to have Tor bundled and run the hidden service by themselves with a hardened-enough torrc. Ricochet does this on desktop, which I think is the right way to go about this. SimpleX's server (https://github.com/simplex-chat/simplexmq) should do this.
What I do is run Wireguard on my server with a Tor daemon, connect to the WG network on my phone and then access the SOCKS and DNS proxies the Tor daemon exposes.
That way there is no need for Orbot or running Tor on Android at all.
From the SimpleX doc you linked
"To mitigate this problem SimpleX Messaging Protocol servers support 2-hop onion message routing when the SMP server chosen by the sender forwards the messages to the servers chosen by the recipients, thus protecting both the senders IP addresses and sessions, even if connection isolation and Tor are not used."
The thing is, like I said, there are only two main companies running all the servers. Akamai and RunOnFlux. So unless Tor is used, it's a 50-50 chance that both users are connecting on to servers run by Akamai. Doesn't matter if the two servers don't share with each other the information about the IP-adderss of the user's peer. It's enough the parent VPS company has access to all traffic coming into the infrastructure. There's nothing "onion" about that routing. It's much closer to just traffic between two nodes of a server farm. Which is what practically any scalable IM server does.
> Such as obfs4, I presume.
Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.
At the end of the day, the transport lists are public, but sharded, so it's truly just obfuscation no matter what transport protocol you use. Someone observing your connection with the resources to map out transport relays can tell if you're using Tor.
> Have you heard about it, or have you used it before?
I haven't, but it looks interesting. It seems they're doing a similar mixnet approach to SimpleX.
> I agree. How much more secure is that?
If you don't to rely on a third party to queue and relay your messages when your recipient comes online, it's one less party that you're sharing information with.
I also believe it opens you up to Tor correlation attacks, like what happened with Ricochet. Maybe an overlay mixnet can add some further obfuscation, as with SimpleX and RACE, but I assume those overlays are vulnerable to correlation attacks, as well.
> Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.
Such as?
I know about those, but scramblesuit and meek and snowflake came before obfs4 I believe and they do not achieve the same thing obfs4 does, so I do not see a better obfs4 alternative here.
Definitely not for threat models where anonymity is critical
> It's also only decentralized as much as public email infrastructure is decentralized.
So… entirely? What am I missing about your point?
I run my own email servers, but 99% of mail goes over Google/Microsoft/AWS/etc email servers anyway.
In practice, it's quite centralized and you're always at risk of one of the big providers locking your servers out of their network or putting you on a blocklist they all use.
Public email infrastructure is almost entirely dominated by Google. This is worth looking into if you’re not familiar with the state of affairs