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.
woodruffw 1 days ago [-]
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.
repeekad 1 days ago [-]
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
jeremyjh 1 days ago [-]
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.
post_below 1 days ago [-]
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.
tialaramex 4 hours ago [-]
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.
1659447091 23 hours ago [-]
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.
GPG is gnu privacy guard, it's an open source implementation of the same ideas that are PGP (pretty good privacy).
singpolyma3 1 days ago [-]
Specifically we're supposed to call it OpenPGP these days
47282847 1 days ago [-]
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.
1 days ago [-]
em-bee 1 days ago [-]
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.
woodruffw 1 days ago [-]
> 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.
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.
woodruffw 19 hours ago [-]
"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.
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.
woodruffw 8 hours ago [-]
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.”
em-bee 1 days ago [-]
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.
woodruffw 1 days ago [-]
> 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?
em-bee 1 days ago [-]
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.
woodruffw 23 hours ago [-]
> 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.)
em-bee 8 hours ago [-]
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.
woodruffw 7 hours ago [-]
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.
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.
woodruffw 6 hours ago [-]
> 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.)
em-bee 4 hours ago [-]
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.
woodruffw 3 hours ago [-]
> 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.
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.)
Arathorn 1 hours ago [-]
matrix encryption reliability should be fixed (at least on element x/web + synapse combos) as of Sept 2024.
what server & client are you using?
heavyset_go 1 days ago [-]
I agree from that perspective.
klabb3 24 hours ago [-]
> 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.
tptacek 23 hours ago [-]
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.
klabb3 7 hours ago [-]
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.
heavyset_go 1 hours ago [-]
> 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".
tptacek 3 hours ago [-]
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.
bastawhiz 23 hours ago [-]
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.
woodruffw 23 hours ago [-]
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.
jjav 14 hours ago [-]
> famously minuscule metadata
Famously minuscule? They demand a phone number, which blows up any possible anonymity story.
klabb3 11 hours ago [-]
> 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.
maqp 21 hours ago [-]
>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.
"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
woodruffw 21 hours ago [-]
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.
jjav 14 hours ago [-]
> 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.
woodruffw 7 hours ago [-]
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.
Bluestein 11 hours ago [-]
All of which is true and praiseworthy.-
Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...
singpolyma3 1 days ago [-]
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.
heavyset_go 1 days ago [-]
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.
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.
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.
maqp 21 hours ago [-]
>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.
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.
"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.
johnisgood 10 hours ago [-]
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?
heavyset_go 1 hours ago [-]
By "your" I mean your chosen 3rd party servers
johnisgood 1 hours ago [-]
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.
# `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: onion
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.
johnisgood 21 hours ago [-]
> Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.
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.
SwtCyber 7 hours ago [-]
Definitely not for threat models where anonymity is critical
umanwizard 1 days ago [-]
> It's also only decentralized as much as public email infrastructure is decentralized.
So… entirely? What am I missing about your point?
heavyset_go 1 days ago [-]
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.
binary132 1 days ago [-]
Public email infrastructure is almost entirely dominated by Google. This is worth looking into if you’re not familiar with the state of affairs
"No, Delta Chat doesn’t support Perfect Forward Secrecy (PFS). This means that if your Delta Chat private decryption key is leaked, and someone has collected your prior in-transit messages, they will be able to decrypt and read them using the leaked decryption key."
It's great they're being open about the implications. But given that there's better protocols out there (Signal protocol for example), it makes no sense to use inferior apps.
Valodim 1 days ago [-]
I'm not sure that's fair. It would be if it was otherwise just another messenger app, but Delta uses email as a transport, which gives it a special kind of resilience. It's harder to shut down email than signal.
woodruffw 1 days ago [-]
I don’t think this is true in practice. On the whole, I suspect the ordinary user of email is exactly as centralized as the ordinary user of Signal.
(The response here might be that you could run your own mail server, but you’ve now excluded >99% of the world’s population from the essentially reasonable expectation of secure messaging. Plus, you’re then dealing with the ongoing misery of securing your own mail host.)
jjav 14 hours ago [-]
> I don’t think this is true in practice. On the whole, I suspect the ordinary user of email is exactly as centralized as the ordinary user of Signal.
Not true, because an open standard will always be superior to a company-owned (and controlled) app.
I run all my own email infrastructure. Many of my friends do. We can communicate without any corporate overlord deciding who can say what.
Signal is a company, one that demands a phone number to use their proprietary service and can shut you out in a nanosecond. No thanks.
flaburgan 11 hours ago [-]
Signal is not a company but a non profit, and their service is not proprietary but fully open source including the server side.
That being said, it is centralized and so less resilient, it can be taken down more easily. So you have to pick between more secure (Signal) or more resilient because decentralized (DeltaChat).
Theoretically Matrix has both, but at the moment it is not as secure as Signal, and its UX is clearly worst. And to that you have to add the complexity of decentralization for normal people: which server to pick, how can I know if someone I know has an account... Here the comparison with email should help but still it is not as easy as entering a phone number and immediately you have all your contacts available.
Arathorn 10 hours ago [-]
when you say “Matrix’s UX is clearly worst”, what app are you talking about? Element X is similar if not better to Signal in terms of UX for instance.
Valodim 1 days ago [-]
The difference is the collateral. Are you really going to shut down a country's most popular local email service? Or gmail?
woodruffw 1 days ago [-]
I think the answer to that is resoundingly yes: the kinds of countries that care about curtailing E2EE messaging are also the ones that institute nationwide internet blackouts.
(But also, this isn’t a good argument! Repressive governments love metadata, and email is an amazing source of unbounded metadata even with these kinds of “secure” layers slapped on top. If I was a government looking to snoop on my citizens, I would absolutely push them towards the protocols I can infer the greatest amount of behavior from.)
Valodim 1 days ago [-]
Blocking email or gmail is much closer to a nationwide internet blackout than blocking signal or tor. And even repressive regimes are on a budget there.
I'm not sure your second point holds either - for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail. Correlating senders and receivers from that data sounds technically challenging enough that I wouldn't expect repressive regimes to be capable. But, to be fair, I base that on nothing.
woodruffw 23 hours ago [-]
> Blocking email or gmail is much closer to a nationwide internet blackout than blocking signal or tor.
Yes; the point was not that they’re the same, but that regimes that do the former tend to also do the latter. Moreover, we shouldn’t do insecure things because regimes block the secure things; that’s what the regime wants you to do. The answer might not be Signal if Signal is insufficiently decentralized, but it certainly isn’t email.
> for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail
This alone is a significantly larger amount of metadata than schemes like Signal leak. But it also isn’t true: a country that controls its internet infrastructure can almost certainly pull much more metadata from plaintext IMAP/SMTP than just access times and addresses. And this isn’t hypothetical: STS is not widely adopted in the email ecosystem, so plaintext downgrades are pervasive.
heavyset_go 21 hours ago [-]
> I'm not sure your second point holds either - for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail. Correlating senders and receivers from that data sounds technically challenging enough that I wouldn't expect repressive regimes to be capable. But, to be fair, I base that on nothing.
Nations don't have to do any of that, they can just subpoena the email host for the data, or just ask nicely for it, as companies are wont to work with law enforcement and the regimes they do business with.
The point of many of anonymizing and "private" chat services is the lack of data sitting on third-party hosts that can later be shared with adversaries.
tcfhgj 1 days ago [-]
you don't have to use email to federate between servers, there are other protocols such as Matrix, XMPP, probably many more
Valodim 1 days ago [-]
I was not talking about federation, I was talking specifically about email. It's like the domain fronting feature that signal used to have, but using a service as a front that is business critical.
maqp 1 days ago [-]
"It's harder to shut down email than signal."
It took me two minutes to figure out DeltaChat connects to the server with SNI "nine.testrun.org". Banana dictatorships can trivially write firewall rules to cut those connections. There are other servers, but if those are going to be usable by anyone, they're going to have to be public, and writing block-rules is trivial compared to spinning up new servers.
I'm not saying Signal is much better in this regard, I'm just saying resilience isn't a useful metric to assess messenger security.
em-bee 1 days ago [-]
DeltaChat connects to the server with SNI "nine.testrun.org"
sounds like a bug that can be fixed. it should not need to make that connection unless you create an account on that server.
maqp 1 days ago [-]
No that's just the default behavior of connecting to default server, which is what 99.9% of users are going to do. You want to get rid of SNIs, you run a server dedicated for DeltaChat, and then its the IP-address can be blocked.
em-bee 1 days ago [-]
connecting to default server, which is what 99.9% of users are going to do.
not quite. the default server feature is only a year old. while deltachat itself goes back to at least 2017, so the majority of users will not be on that default server now, and it would be possible to offer a randomized selection to prevent one default server from dominating.
maqp 21 hours ago [-]
Majority of new users will be. It's still a niche product.
Also, I'm unsure if it's smart the client just picks a server for you at random. AFAIK this uses email as back-end so it's not like you can just swap your email address host like you can swap telco while keeping your phone number. One option would be to have the user first whitelist the email providers they'd trust, but most users usually prefer trusting the app vendor as they're trusting it with the client anyway.
zaik 24 hours ago [-]
Modern XMPP clients implement the Signal protocol for encryption and are decentralized like Delta Chat.
heavyset_go 20 hours ago [-]
XMPP is riddled with privacy pitfalls even when you bolt on encryption to it. Like email, it was not designed with privacy in mind.
It's email-compatible and uses pgp for encryption. No forward secrecy and supports sending unencrypted messages as well for people who don't have pgp.
No forward secrecy and will automatically switch to unencrypted messages if you receive an unencrypted message from a contact.
I wonder if it's vulnerable to downgrade attacks from adversaries falsifying the sending address. If an adversary sends an unencrypted email imitating a contact will delta chat reject it or will it silently switch the chat with that contact over to unencrypted email?
folmar 1 days ago [-]
The way to have guaranteed encryped is creating two user encrypted group chat.
Yeah but it later also supported non-E2EE SMSs and those were a security risk and they rightfully dropped the support. It was not ideal your grandma thinks any message sent in Signal is safe, when that wasn't the case.
shark_laser 1 days ago [-]
Why not 0xchat?
Private key login, encrypted private chats and contacts, encrypted group chats, and lightning payments. Decentralised, built on Nostr. Available on all platforms.
1) NIP-04 DM: "Most widely used", but also, "not recommended". Reeks of Telegram that also has non-secret chats being the most popular option
2) Gift-Wrapped DM: Uses different encryption algorithm but no forward secrecy? Forward secrecy has been around for 20 years.
3) Secret DM: Can't be recovered on different devices. Why can't the backup be self-contained database like Signal has?
Also "Secret chat requires consent from peer." Like what :D You have to wait for contact's approval to have a private conversation with them. Sounds like it incentivizes all chats to start with less secure protocols.
The nice part about writing your own chat system is the security agility in that you can bump any security property without having to fight with protocol standardization bodies. Having three DM protocols inside the same app is wild.
rpdillon 1 days ago [-]
I think the point here is that everyone has email. A chat client built on Nostr is fine (and I want to love Nostr), but it just doesn't have the reach or ubiquity of email.
lxgr 1 days ago [-]
Nor does Delta. Nobody will “chat” with me via their Gmail email focused UI, so it’s effectively a separate network anyway.
Using an email address as an identifier for IM is a great idea (I hate that everything uses phone numbers for this, which are not internationally portable and not possible to reasonably “self-custody” the way TLDs are).
But using the actual email protocol as a backing protocol for instant messaging seems like a weird contortion and still makes this effectively a separate protocol, the split being servers that do and don’t support all necessary extensions. The overhead must also be staggering; just look at an email header to see how much is going on for each message these days.
em-bee 1 days ago [-]
you got a point with the overhead in email headers. also an email is sent not only for every message but also status updates. that adds up to a lot of emails.
AJ007 1 days ago [-]
When you start looking at alternative messengers outside of Matrix, XMPP, and IRC, there isn't much where third parties can operate or implement both servers and clients.
Certainly if no one can implement these two things it is functionally a closed source project. It also is a security failure from the standpoint of control, validation, and also future security and vulnerability patching (there's a graveyard of dead "secure" messaging apps.)
Is DeltaChat perfect from a security standpoint? No, but it's certainly well above the hurdle most people are at now. Most people are using non-encrypted communication that is actively scanned & stored, or e2e on paper stuff where one party controls the client, server, application, and storage (trust me e2e security.)
Telegram, Discord, Facebook Messenger, stop using that shit.
maqp 1 days ago [-]
>Is DeltaChat perfect from a security standpoint? No, but it's certainly well above the hurdle most people are at now.
It's less safe compared to Signal, and Signal is the gold standard recommendations for average Joes. "Better than Telegram" is a low bar.
em-bee 1 days ago [-]
telegram is the most user friendly chat out there. the only ones that compete in usability are wechat (yes, the chinese one) and, deltachat. signal just got a bit better by finally allowing me to hide my phone number. of all these, deltachat is the only one that doesn't require a smartphone and a phone number.
eMPee584 11 hours ago [-]
Telegram indeed does have excellent UX, speed and multi-device support.. as all clients are open source, there should be a (convoluted, rocky) way to port them to use the matrix protocol (an idea I've had a couple of months back).. or, instead of one-time porting, insert a protocol bridge running as sidecar in order to be able to keep in sync with upstream TG code (Pavel himself seems to be doing _immense_ amounts of coding on it)..
Anyone up to the challenge?
em-bee 7 hours ago [-]
being able to use a telegram client for matrix would be great, but the problem with matrix is not so much the UI but the complex handling of encryption which can sometimes fail. unlike deltachat which downgrades on failure, which is bad, matrix stops working on failure, which for the average user is worse. a better UI won't fix that unfortunately.
still i like the idea. but deltachat also has a nice UI, and for matrix i use fluffychat which is also quite nice.
maqp 1 days ago [-]
>telegram is the most user friendly chat out there.
Telegram is a walking time bomb with 900 million users' data waiting to be leaked from the servers.
>and, deltachat.
That must be why I've never heard of anyone using it.
>deltachat is the only one that doesn't require a smartphone and a phone number.
It leaks the IP-address to the server, which by default (defaults matter) is nine.testrun.org. That server can amass metadata about users conversing, and any government entity that comes knocking can look at TelCo records about to which user the IP-addr was assigned at the time.
If you're going to try to address metadata privacy against service provider, you're going to have address it properly, and DeltaChat isn't the one at that point. Neither is Signal. You'll want Cwtch for that.
nottorp 13 hours ago [-]
> Telegram is a walking time bomb with 900 million users' data waiting to be leaked from the servers.
Russia probably has all the Telegram data, considering they officially intervened in the recent Romanian presidential elections taking the side of the local MAGAs.
What the article doesn't say is they sent a message in romanian to all romanian telegram users with the above claim, signed Durov.
So I don't think their "security" can be trusted.
em-bee 1 days ago [-]
nine.testrun.org is owned by deltachat developers. it is about as trustworthy as, say, matrix.org. the only better alternative would be self hosting.
the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy. and maybe deltachat is not the best possible, but it is pretty good. remember, when security and privacy are to onerous then you don't have security or privacy because people will refuse to use the tool.
maqp 1 days ago [-]
>the only better alternative would be self hosting.
Which doesn't really work in practice. The closer you move to the user, the more the threat of creepy buddy watching over metadata of people they know grows. Medium sized institution like university or a company might run their own, but that's also somewhat risky.
>the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy.
No. The question is, given an architecture that imposes fundamental limitations on what can be achieved, which tools under that domain have best privacy by design system, where the UX and features are maximized with ingenious design, is the best.
Fundamental architectural limitations:
Does Delta Chat use data diodes? No? Then it can't have key exfiltration security, but it can have message forwarding.
Does Delta Chat use Tor Onion Services? No? Then it can't have proper metadata privacy for users' identity from the server, but it can have offline messages.
These are fundamental trade-offs.
DeltaChat is content-private by design. It might be metadata-private by policy (internal policy that server on nine.testrun.org does not collect metadata), but until that is tested in court like Signal is, we can't know for sure.
Signal is content-private by policy. Cwtch uses Tor Onion Services so it's metadata-private by design.
Now, it's fine to argue which is the best inside one league.
Element/Matrix is E2EE with double ratchet protocol, so it has both forward secrecy and future secrecy, which DeltaChat doesn't have.
It's only once security is more or less exactly on par, that you should be comparing general UX. Really usable but insecure tool might turn into really unusable tool when you sit in prison for your political opinions, or because you revealed your ethnicity and ICE caught on.
>maybe deltachat is not the best possible, but it is pretty good
It's not the worst out there. At least it tries to do things properly. It's just that given that there's insane obstacle of moving people to a safe platform, DeltaChat is just another distraction. Until it does what competition does security wise, and improves on their UX, it doesn't get the top podium.
>when security and privacy are to onerous then you don't have security or privacy
Sure, but when you're in prison for using crap tool, you won't have liberty, security, or privacy.
em-bee 7 hours ago [-]
The closer you move to the user, the more the threat of creepy buddy watching over metadata of people they know grows.
actually i don't follow that argument. it is more likely that my data gets caught up with someone accessing a larger server than my own server. if someone targets my own server they may as well target all my messaging clients and get all the data from there.
maqp 2 hours ago [-]
The thing is, if there's three users that know each other, using one server run by one of the three, then by definition there is one person with access to metadata of the 1:1 conversation between the two other users. If you are the one running the server, then your buddies are taking the risk that you're the creepy buddy.
The proper way to address this is with p2p messaging, like Cwtch, where each user is running server for their own account. Cwtch also experimentally supports caching ciphertexts on a server that's hosting the group chats that all members will have access to anyway, so there's no peer metadata to eavesdrop on.
em-bee 1 days ago [-]
It's only once security is more or less exactly on par, that you should be comparing general UX.
ideally yes, but that is not what the average user will do, and it is not what i can use as an argument to get people to switch to something more secure. convenience over security is still a user preference.
i get your point, but that falls on deaf ears among family and friends. especially using prison as an argument is really not helping. i mean by the same argument we should not be having this conversation on hackernews, because clearly we are trying to subvert the authorities by suggesting that people should keep their communication secret.
promptdaddy 1 days ago [-]
Apologies for any nativity here, but wouldn't storing encrypted messages on a blockchain be a robust solution for this?
heavyset_go 1 days ago [-]
Why would you want that? The last thing I'd want in a secure messenger is a permanent ledger that holds message content and associated metadata which anyone can analyze.
edit: I didn't downvote you and I don't think someone asking an honest question like this should be downvoted
heavyset_go 1 days ago [-]
Doesn't Nostr expose the fact that you sent messages to certain people via its blockchain?
unboxingelf 20 hours ago [-]
Nostr doesn’t have a blockchain or token.
Notes and Other Stuff Transmitted by Relays.
It’s just signed json messages distributed by [websocket] relays.
heavyset_go 20 hours ago [-]
I'm probably mixing up analogies with actual implementations, but I'm basing my question on sentiments like this[1]:
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
The analogy works in the visibility sense and I see why you might assume there’s a blockchain involved in Nostr. But to clarify, there is not.
It’s worth highlighting as there are many affinity scammers spinning up tokens/blockchains called “Nostr”.
styanax 10 hours ago [-]
Your intuition is correct, Nostr objects are stored on relays and can be retrieved by any client with the proper private keypart. In my test runs of trying Nostr proper for a month or two, I had problems deleting objects (clients lack support for the NIP API calls was common) - and you can only delete your end of a DM, not the whole thing. (another frustration - your "chat" or "inbox" can never be cleaned or deleted of the other person's messages).
Effectively nostr objects lay around on relays until they reach some server-side expiry policy and sometimes forever if one can't figure out how to delete them. Nostr clients (web and mobile) are the wild west of good luck with which features and NIPs they support (XMPP all over again). My experience here led to dissatisfaction as well. Relays are another wild west - it's choice paralysis and a helping of good luck with that.
The real problem for IM: Nostr does not ensure all relays sync, instead a user chooses their preferred relays (some you pay for in crypto). It is entirely realistic (I experienced it) that you're on relays other people aren't and you can't share content. This is death for an IM app and just trying to use Nostr became frustrating. (not to mention it's flooded with porn and crypto shills)
Edit: a nostr client has to keep open network connections to all these relays, as objects can be stored on multiple relays and it's up to the client - not the relays - to query all relays and then de-dupe the JSON responses. There are combobouncers in use (who will de-dupe) but they're not the default and tend to be read-only (because you can't choose which relays to post to when using a combobouncer).
data_maan 1 days ago [-]
0xchat on the surface seems better: looks like a professionally maintained codebase, with clear ways to interact with the devs.
But - has there been security audit been done?
emptysongglass 15 hours ago [-]
Is it just me or does the website render poorly on mobile?
ZoomZoomZoom 9 hours ago [-]
Delta chat looks great, and reusing the existing infra is a huge boon. However, it has the same issue of hard reliance on a specific server for connectivity.
Why do every system insists on having persistent names as network identifiers? Practice shows that the main threat for the vast majority of users is state censorship. In case of Delta, Matrix, XMPP and others, once you're cut off your home server, your account is basically toast. The only thing you can do, besides circumventing, is a cumbersome and messy account migration[1], where available.
In case of Matrix, I feel very bitter, as I managed to onboard a considerable chunk of my personal network but most of them can't login anymore without using VPNs. I'm not sure if I have enough social capital to convince them to repeatedly register on different servers as they get blocked. P2P[2] feels still too far away.
Why can't we use key pairs as identifiers and simply request a desired username upon first login? In case of federated networks this would allow seamless server switching and allow users to continue their conversations. Servers shouldn't care what server a particular user's messages are coming from as long as they are verifiably theirs.
You can even add username propagation between servers (a new server requests the username from the old one that's supplied with user's login request). I know about Matrix identity servers but I don't see how it helps in this case.
agreed, lack of account portability in Matrix is a pain. we’re working on it in msc4014 and I expect to see some progress this year.
raybb 21 hours ago [-]
If you want to migrate to a different chatmail server is it possible to keep that same chat alive or do you have to create a new one and the old stays in the history? This is already how it is with whatsapp but it is a pain point.
styanax 10 hours ago [-]
An email address is your Identity; while it's possible for you to maintain the same chat when you migrate, you'll sever the chat for the other person because they have to chat with a new Identity (your new email). (think the email headers to/from, you've kept "to" but changed "from" for them, but it could use the same PGP keys to decrypt etc.)
b0a04gl 1 days ago [-]
this completely sidesteps the infra bootstrapping phase. there's no need for new servers, federation drama or client network lock-in. every user already has a compatible backend = imap + smtp. that shifts the challenge from adoption to UX. that's a very rare position for a comms tool to be in. this's refreshing to me personally, would love to contribute to the mission
blancotech 1 days ago [-]
Anyone else immediately think of delta airlines? I was excited to read an analysis of a seat-to-seat chat implementation
seydor 1 days ago [-]
seat29@flight7822.delta.com slaps seat34@flight7822.delta.com with a large trout :: stop snoring
Bluestein 1 days ago [-]
Like those gaggles of girls chatting each other up while walking shoulder-to-shoulder down the street.-
fouronnes3 1 days ago [-]
I'm curious how spam protection works if you're an alternative, few users, chat app? I hate Meta's monopoly as much as the next guy but one thing you do have to credit them for is the second to none spam protection. I also wonder how much requiring a cell number is part of that strategy.
msgodel 1 days ago [-]
It's just email and gpg so you'll get the same spam you do normally.
IMO people freak out about spam way too much. I'd rather have something that works with occasional spam than have to put up with the insanity of modern IM. Having push notifications from 10 proprietary IM apps is worse spam than a couple of emails a day from some retard trying to get me to download a "pdf." I don't block spam at all in my personal email (although I have a couple of tools automatically label it.) I'd rather have everything delivered.
em-bee 1 days ago [-]
i run my own email server, using a spam filter i set up years ago without explicit blocking (only tagging and filtering) and didn't touch it since. the amount of spam i get is negligible. a few false positives, but nothing serious. in fact it's so little i could probably just leave all the spam in the inbox. it is tagged as spam anyways.
nottorp 13 hours ago [-]
I've just been the target of some spam "campaign" on my own email server. By the time I was annoyed enough to block some IPs and add a custom spamassassin rule for them, they had already stopped. It lasted two days.
Other than that it looks like I get like 4 spams per week.
Mind, i don't publish my email anywhere. If you look at my profile on here you'll get a gmail address.
immibis 1 days ago [-]
I have my own email server with a wildcard address (I still use gmail for anything that's actually important). I put certain addresses in shady forms a few times. I get a couple of spam messages per day to those addresses - always the same spam few spam campaigns. One is offering to sell me electric bicycles or partner with me to sell electric bicycles (didn't really pay attention) and more recently I started getting business proposal advance fee spam. The volume is pretty manageable and if I wanted, a pretty simple filter tuned for the spam I actually get would catch all of it and no ham.
I got spam to postmaster once for some reason. That's a nice way to make admins aware of your spam campaign.
Spam is presumably more of a problem when you're more well-known and you don't have the option to control your own filters.
v5v3 1 days ago [-]
An alternative few users chat app probably won't be a major target for spam untill it has lots of users.
So I would say it's a low priority feature in the backlog.
ravdeepchawla 1 days ago [-]
You can design your way around it
1. Manually screen who can send you messages like Hey[^1] and Apple[^2]
2. Basic filtering to ensure the promotional stuff gets blocked or put in a separate list [^3]
3. Rate-limit senders who are showing robot like behaviour
deltachat distinguishes between normal email and deltachat messages. you can limit to the latter if you only use it to communicate with other deltachat users.
XorNot 1 days ago [-]
If your need is security then really that should be based on in person trust.
Or at least via a proxy.
So contact invitation can just be handled with use-once codes (or at least trivially burnable ones).
chrisldgk 1 days ago [-]
I wouldn’t necessarily agree that WhatsApp‘s spam protection is that great.
I’ve been invited to quite a lot of pyramid scheme/scam WhatsApp groups, however that’s mostly happened after having to expose my private cell number on the internet (thanks to app stores and GDPR requiring some kind of phone number for businesses of any size).
radiospiel 1 days ago [-]
afaik no businesses are required by the gdpr to collect phone numbers, and would like to see evidence otherwise
chrisldgk 1 days ago [-]
Sorry, I should have been more specific. In Europe (or Germany at least) it’s required by law that you provide an imprint with contact information for every site you host, as well as a privacy policy that includes contact information of your GDPR officer if you collect any kind of personalized data. Since I’m a one-person company, that includes my personal phone number since I don’t have a business phone. Also chrome webstore for example requires a phone number if you host an extension on there.
Edit: Also this wasn’t about collecting phone numbers, but about providing one for your business if you host a publically accessible site
progval 1 days ago [-]
There are no occurrences of "cell" or "phone" in GDPR, and the only relevant occurrences of "number" are about "national identification numbers", which phone numbers are not.
Bluestein 1 days ago [-]
... always wondered if the cell phone requirements are not (also) tied to then wanting an actual, physical, person behind each account - as in most EU jurisdictions each SIM card is tied to an actual ID.-
marci 1 days ago [-]
In many EU countries, you can buy sim cards from some vending machine, in a grocery store or places where you can buy international telephone cards. No ID required. But phone plans are often tied to your home internet.
em-bee 1 days ago [-]
are you sure no ID is required to activate the cards? at least in austria and i believe in germany you can't get a sim card without an ID.
marci 1 days ago [-]
If you get a lyca sim card, even there you don't need ID to use it. There might be some restrictions after a month though.
Bluestein 1 days ago [-]
Ah, the EU — land of fine cheeses, indecipherable GDPR popups, and, of course, the iron-fisted grip on your humble little SIM card. In the EU, you can’t even sneeze near a prepaid phone number without showing at least three forms of government-issued ID, a notarized statement of purpose, and possibly a blood sample. Why? Because buying a SIM card anonymously here is about as legal as fencing stolen paintings in the town square.-
You see, most EU countries decided some time ago that allowing people to own mobile numbers without a background check was simply too dangerous. What if someone used a burner phone to commit fraud, or worse — say something mildly controversial on the internet? To prevent such dystopian chaos, SIM registration laws were born. Now, whenever you purchase a SIM card in France, Germany, Spain, or pretty much anywhere with croissants, you have to offer your passport, soul, and, ideally, a letter of recommendation from your local constable.-
The result? Your phone number in the EU is no longer just a string of digits—it’s basically your name, address, and social security number all rolled into one. It’s like a little snitch in your pocket, ready to identify you at the first sign of online mischief. Online platforms know this. That’s why so many of them, from social networks to AI models, insist on a phone number. They’re not just trying to text you cute security codes — oh no, they’re trying to make sure there’s a warm, squishy, legally-recognizable human on the other end. Preferably one without too many fake Twitter accounts.-
Technically, GDPR is supposed to protect your data. That includes your phone number. But there’s a loophole the size of Luxembourg: if the phone number is used to stop terrorism, fraud, bots, or people being mean in the comments, then suddenly it’s all hands on deck. Platforms benefit from the comforting knowledge that EU phone numbers are like digital dog tags: traceable, trackable, and just annoying enough to prevent the average troll from spinning up 50 accounts to yell into the void.-
Of course, this all raises philosophical questions. Like: should your right to privacy hinge on your desire to play Candy Crush in peace? Is a SIM card a person? Could it run for European Parliament? And should we perhaps explore more civilized alternatives to this “one phone number equals one identity” system, like zero-knowledge proofs or just asking nicely?
In the meantime, welcome to the EU: where the cheese is soft, the bureaucracy is hard, and your SIM card knows more about you than your therapist.-
data_maan 1 days ago [-]
Nice post, I smiled.
There are several countries that didn't buy into the madness of registering SIMs, luckily. Most strangely, the UK, the master of CCTV. Apparently they realized that it's a useless measure and will just anger the people.
Bluestein 1 days ago [-]
... And SIMs are available from vending machines, which I find amusing :)
lclc 1 days ago [-]
Has anyone used that with their Protonmail account?
Maybe something Proton should build on for its own chat app.
They mention the bridge but if they're using pgp under the hood it may well just be entirely broken: https://jfloren.net/b/2023/7/7/0
iqandjoke 1 days ago [-]
Which party the developer associated with? Hopefully not CIA.
kingkawn 23 hours ago [-]
Pretty Good Protection ain’t good enough anymore
upofadown 20 hours ago [-]
Yeah, that was a figure of speech. Encrypted email is probably still the most secure thing available to most people, even these days. That's because it as asynchronous and offline. You can do it in your air gapped system in your shielded and guarded basement if you really want to. That is as opposed to some instant messaging scheme running on an inherently insecure device like a smart phone where there is access to the messages all the time.
Delta Chat is an instant messaging scheme. It is still good to use preexisting standards where possible.
seydor 1 days ago [-]
this is my favourite version of decentralization. building on existing widely available infrastructure. The war-proof internet.
Maybe with AI there could be a sort of decentralized antispam filtering . but maybe not
exe34 1 days ago [-]
Why not just create a group chat and invite FBI and Shin Bet?
monkaiju 24 hours ago [-]
Obligatory briar mention...
Briar supports communication over multiple mediums, including wifi & Bluetooth, has forward secrecy, and feels quite 'signal-like' so its not impossible to get people to use it.
Briar cannot do offline delivery unless you setup a stand-in service. Unfortunately that's way to complicated for regular use.
Briar looks really nice for people that really need the extra security and privacy, though.
I've been interested in SimpleX lately, but I don't really have anyone to properly test it with.
hkt 1 days ago [-]
Used it for years, it is great. Webxdc apps work in both android and desktop clients (not sure about iOS) so I can play chess, share calendars and to do lists, and even collaboratively edit documents, all by email, all privately.
Anyone who hasn't tried it really ought to.
To the haters talking about PGP: giving your entire social graph to Meta or even Signal is considerably worse.
woodruffw 20 hours ago [-]
Signal does not have access to your social graph[1].
(Delta Chat markedly does leak your social graph, because it's email and email has no way to protect sender metadata from each user's email provider. That means full social graph recovery is one low-effort subpoena away in your attacker's municipality of choice.)
How is the latency? All mainstream chat apps have low-enough latency that a live conversation feels fluid and natural, whereas I frequently encounter situations where I have to wait up to five or ten seconds for an email to come through. That kind of latency would kill the experience IMO.
kassner 2 hours ago [-]
My findings:
> I’ve tested Delta Chat with my own mail server, which uses Postfix and has everything configured for public e-mail, like DKIM signing, spamd, IP blocklist checks and so on, and each message took about 2 seconds from one device to another. Using a public server it sure feels below 300ms, so there is room for improvement when self-hosting a dedicated chatserver.
In my test, both clients were ~80ms away from the IMAP server, but the server was delivering to itself. I’m also not sure if the port 587 has an idle/keepalive mechanism, or if it has to go around the entire TLS handshake at each message.
I don’t think 2 seconds is bad, most of my contacts will take at least triple that to read and type in an answer, so not a big deal.
em-bee 24 hours ago [-]
in my experience the "latency" for a person to reply to a message is always higher than the latency for a message to arrive. in fact, some latency is good. gives you a break to think.
singpolyma3 1 days ago [-]
Besides the fact that hating on PGP is like hating on TLS. It's a spec and a container for just about anything you want to do. gnupg (the thing most people have come to dislike) isn't even spec compliant anymore and was always a power user tool not something most users should actually touch anyway
Avamander 23 hours ago [-]
Nah, hating on PGP is like hating on SSLv3. The specs are bad, the entire system is very error-prone, and the cryptography itself is also outdated.
godelski 12 hours ago [-]
> giving your entire social graph to Meta or even Signal
1) Signal does not have your social graph
2) you are not required to give the app access to your contacts
Stop spreading this misinformation, it is only making it harder to get people onto secure messaging systems. You need two people using secure systems to communicate and the result of all this horseshit is a bunch of armchair experts who haven't bothered to look into the actual security of the app making strong confident statements. Just stop.
Even if it had half the issues people pretend it does let's be honest, my grandma can use signal. That's a fuck ton better than most of the alternatives out there. Frankly, that's what 99% of people need, the app that everyone can use. Not the app that some techie says is trivial...
Side note) Comparing Signal to WhatsApp is wildly disingenuous.
Side side note) there's a 30 yo pgp hack. If you reply to a gpg email with "could not decrypt" you'll get back the email in clear text. (Joke is older than the average HN user)
m3kw9 1 days ago [-]
[flagged]
data_maan 1 days ago [-]
How does this (or 0xchat) compare to Signal?
Have their been done any third-party security audits by reputable companies?
If not, it's not safe to use - who knows what's buried in the source code (even if the source code is open).
JimDabell 1 days ago [-]
> Have their been done any third-party security audits by reputable companies?
Their FAQ answers this:
> Yes, multiple times. The Delta Chat project continuously undergoes independent security audits and analysis
Biggest advantages are the code is open, the infrastructure is open, and you don't have to hand all your metadata to a single centralized provider
em-bee 1 days ago [-]
deltachat does not have central servers. you get to use your own servers. aka it's federated. and it works with plain SMTP so you can just reuse the server/email account you already have.
heavyset_go 1 days ago [-]
Delta Chat has the option of using chatmail servers that they host themselves.
josephb 23 hours ago [-]
Chatmail relays can be run by anyone, they are designed to be fairly minimal and lightweight, just running what is needed to support the "encrypted chat" part, not regular email.
tcfhgj 1 days ago [-]
first of all, it's not a walled garden
johnisgood 1 days ago [-]
I mean, should probably just use Ricochet Refresh, Briar, Session, Element, etc.
I also built OTR on top of Discord but it requires Nitro because the messages for OTR end up being way too long. :(
progval 1 days ago [-]
Can't they be split into lines? OTR was designed for IRC that limited protocol lines (ie. payload line + command + extra fluff) to 512 bytes, so that ought to work on Discord too.
johnisgood 1 days ago [-]
I have not yet tried, that may work since it does work for IRC (which also has a limit per message). It was just more of a proof of concept, tbh, but it works, just not as usable as it could be.
em-bee 1 days ago [-]
the whole point of deltachat is that it is reusing an already standardized protocol with existing servers.
i am using element/matrix and i have tried briar. the usability of deltachat and the ease of onboarding beats both of those. briar was especially difficult to get started with and only has a very limited usefulness compared to the others. and matrix is simply very complex and easier to misconfigure.
johnisgood 1 days ago [-]
Briar had trade-offs, for example, it is not available for desktop. I do not have use for Briar, personally. I use the rest, but Briar is worth a mention.
maqp 1 days ago [-]
A standardized protocol without forward secrecy is worse than standardized protocol with forward secrecy. Just use Signal.
em-bee 1 days ago [-]
forward secrecy is independent of the transport protocol. it's only dependent on the encryption. messages encrypted with forward secrey can still be sent over SMTP. deltachat devs are working on that.
signal does not use a standardized protocol, and it requires a phone. that's not an alternative. my children have deltachat on their laptop. i can talk to them when i am not at home without needing to give them a phone.
maqp 1 days ago [-]
>messages encrypted with forward secrey can still be sent over SMTP. deltachat devs are working on that.
Why implement something PGP-like, without forward secrecy, 13 years later, beats my understanding. I mean, 13 years is also the time difference between OTR and PGP. I guess some devs don't read cornerstone papers of the field they supposedly specialize in :)
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.
It's basically GPG with better UX.
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/
[1]: https://support.delta.chat/t/autocrypt-key-rotation/2936
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.
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.
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?
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.)
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.
> 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...
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.
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.)
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.
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.
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.)
what server & client are you using?
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.
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.
> 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 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".
> 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? They demand a phone number, which blows up any possible anonymity story.
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.
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.
That's already a lot more decentralized than most web services we use on a daily basis
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.
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.
Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...
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.
[1] https://docs.cwtch.im/
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...
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.
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.
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.
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...
"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.
How do you configure SimpleX on Android to use your own SMP servers BTW?
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.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.
Such as?
So… entirely? What am I missing about your point?
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.
05-mar-2025 https://news.ycombinator.com/item?id=43262510 100 comments
24-jan-2021 https://news.ycombinator.com/item?id=25893626 148 comments
07-jan-2021 https://news.ycombinator.com/item?id=25674894 4 commments
27-feb-2019 https://news.ycombinator.com/item?id=19263357 11 comments
21-feb-2019 https://news.ycombinator.com/item?id=19216827 56 comments
03-feb-2017 https://news.ycombinator.com/item?id=13560279 1 comment
I wonder why this was downvoted
https://delta.chat/en/help#pfs
It's great they're being open about the implications. But given that there's better protocols out there (Signal protocol for example), it makes no sense to use inferior apps.
(The response here might be that you could run your own mail server, but you’ve now excluded >99% of the world’s population from the essentially reasonable expectation of secure messaging. Plus, you’re then dealing with the ongoing misery of securing your own mail host.)
Not true, because an open standard will always be superior to a company-owned (and controlled) app.
I run all my own email infrastructure. Many of my friends do. We can communicate without any corporate overlord deciding who can say what.
Signal is a company, one that demands a phone number to use their proprietary service and can shut you out in a nanosecond. No thanks.
(But also, this isn’t a good argument! Repressive governments love metadata, and email is an amazing source of unbounded metadata even with these kinds of “secure” layers slapped on top. If I was a government looking to snoop on my citizens, I would absolutely push them towards the protocols I can infer the greatest amount of behavior from.)
I'm not sure your second point holds either - for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail. Correlating senders and receivers from that data sounds technically challenging enough that I wouldn't expect repressive regimes to be capable. But, to be fair, I base that on nothing.
Yes; the point was not that they’re the same, but that regimes that do the former tend to also do the latter. Moreover, we shouldn’t do insecure things because regimes block the secure things; that’s what the regime wants you to do. The answer might not be Signal if Signal is insufficiently decentralized, but it certainly isn’t email.
> for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail
This alone is a significantly larger amount of metadata than schemes like Signal leak. But it also isn’t true: a country that controls its internet infrastructure can almost certainly pull much more metadata from plaintext IMAP/SMTP than just access times and addresses. And this isn’t hypothetical: STS is not widely adopted in the email ecosystem, so plaintext downgrades are pervasive.
Nations don't have to do any of that, they can just subpoena the email host for the data, or just ask nicely for it, as companies are wont to work with law enforcement and the regimes they do business with.
The point of many of anonymizing and "private" chat services is the lack of data sitting on third-party hosts that can later be shared with adversaries.
It took me two minutes to figure out DeltaChat connects to the server with SNI "nine.testrun.org". Banana dictatorships can trivially write firewall rules to cut those connections. There are other servers, but if those are going to be usable by anyone, they're going to have to be public, and writing block-rules is trivial compared to spinning up new servers.
I'm not saying Signal is much better in this regard, I'm just saying resilience isn't a useful metric to assess messenger security.
sounds like a bug that can be fixed. it should not need to make that connection unless you create an account on that server.
not quite. the default server feature is only a year old. while deltachat itself goes back to at least 2017, so the majority of users will not be on that default server now, and it would be possible to offer a randomized selection to prevent one default server from dominating.
Also, I'm unsure if it's smart the client just picks a server for you at random. AFAIK this uses email as back-end so it's not like you can just swap your email address host like you can swap telco while keeping your phone number. One option would be to have the user first whitelist the email providers they'd trust, but most users usually prefer trusting the app vendor as they're trusting it with the client anyway.
https://support.delta.chat/t/autocrypt-key-rotation/2936
No forward secrecy and will automatically switch to unencrypted messages if you receive an unencrypted message from a contact.
I wonder if it's vulnerable to downgrade attacks from adversaries falsifying the sending address. If an adversary sends an unencrypted email imitating a contact will delta chat reject it or will it silently switch the chat with that contact over to unencrypted email?
https://delta.chat/en/help#how-can-i-ensure-message-end-to-e...
and it's not just pgp with email, it's more akin to an overlaysystem.
JFC. There's a reason Signal dropped SMS support. What an insane design decision.
Private key login, encrypted private chats and contacts, encrypted group chats, and lightning payments. Decentralised, built on Nostr. Available on all platforms.
https://www.0xchat.com/
Also, the direct messages have three types
1) NIP-04 DM: "Most widely used", but also, "not recommended". Reeks of Telegram that also has non-secret chats being the most popular option
2) Gift-Wrapped DM: Uses different encryption algorithm but no forward secrecy? Forward secrecy has been around for 20 years.
3) Secret DM: Can't be recovered on different devices. Why can't the backup be self-contained database like Signal has?
Also "Secret chat requires consent from peer." Like what :D You have to wait for contact's approval to have a private conversation with them. Sounds like it incentivizes all chats to start with less secure protocols.
The nice part about writing your own chat system is the security agility in that you can bump any security property without having to fight with protocol standardization bodies. Having three DM protocols inside the same app is wild.
Using an email address as an identifier for IM is a great idea (I hate that everything uses phone numbers for this, which are not internationally portable and not possible to reasonably “self-custody” the way TLDs are).
But using the actual email protocol as a backing protocol for instant messaging seems like a weird contortion and still makes this effectively a separate protocol, the split being servers that do and don’t support all necessary extensions. The overhead must also be staggering; just look at an email header to see how much is going on for each message these days.
Certainly if no one can implement these two things it is functionally a closed source project. It also is a security failure from the standpoint of control, validation, and also future security and vulnerability patching (there's a graveyard of dead "secure" messaging apps.)
Is DeltaChat perfect from a security standpoint? No, but it's certainly well above the hurdle most people are at now. Most people are using non-encrypted communication that is actively scanned & stored, or e2e on paper stuff where one party controls the client, server, application, and storage (trust me e2e security.)
Telegram, Discord, Facebook Messenger, stop using that shit.
It's less safe compared to Signal, and Signal is the gold standard recommendations for average Joes. "Better than Telegram" is a low bar.
Anyone up to the challenge?
still i like the idea. but deltachat also has a nice UI, and for matrix i use fluffychat which is also quite nice.
Telegram is a walking time bomb with 900 million users' data waiting to be leaked from the servers.
>and, deltachat.
That must be why I've never heard of anyone using it.
>deltachat is the only one that doesn't require a smartphone and a phone number.
It leaks the IP-address to the server, which by default (defaults matter) is nine.testrun.org. That server can amass metadata about users conversing, and any government entity that comes knocking can look at TelCo records about to which user the IP-addr was assigned at the time.
If you're going to try to address metadata privacy against service provider, you're going to have address it properly, and DeltaChat isn't the one at that point. Neither is Signal. You'll want Cwtch for that.
Russia probably has all the Telegram data, considering they officially intervened in the recent Romanian presidential elections taking the side of the local MAGAs.
https://www.reuters.com/world/europe/telegram-founder-says-h...
What the article doesn't say is they sent a message in romanian to all romanian telegram users with the above claim, signed Durov.
So I don't think their "security" can be trusted.
the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy. and maybe deltachat is not the best possible, but it is pretty good. remember, when security and privacy are to onerous then you don't have security or privacy because people will refuse to use the tool.
Which doesn't really work in practice. The closer you move to the user, the more the threat of creepy buddy watching over metadata of people they know grows. Medium sized institution like university or a company might run their own, but that's also somewhat risky.
>the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy.
No. The question is, given an architecture that imposes fundamental limitations on what can be achieved, which tools under that domain have best privacy by design system, where the UX and features are maximized with ingenious design, is the best.
Fundamental architectural limitations:
Does Delta Chat use data diodes? No? Then it can't have key exfiltration security, but it can have message forwarding.
Does Delta Chat use Tor Onion Services? No? Then it can't have proper metadata privacy for users' identity from the server, but it can have offline messages.
These are fundamental trade-offs.
DeltaChat is content-private by design. It might be metadata-private by policy (internal policy that server on nine.testrun.org does not collect metadata), but until that is tested in court like Signal is, we can't know for sure.
Signal is content-private by policy. Cwtch uses Tor Onion Services so it's metadata-private by design.
Now, it's fine to argue which is the best inside one league.
Element/Matrix is E2EE with double ratchet protocol, so it has both forward secrecy and future secrecy, which DeltaChat doesn't have.
It's only once security is more or less exactly on par, that you should be comparing general UX. Really usable but insecure tool might turn into really unusable tool when you sit in prison for your political opinions, or because you revealed your ethnicity and ICE caught on.
>maybe deltachat is not the best possible, but it is pretty good
It's not the worst out there. At least it tries to do things properly. It's just that given that there's insane obstacle of moving people to a safe platform, DeltaChat is just another distraction. Until it does what competition does security wise, and improves on their UX, it doesn't get the top podium.
>when security and privacy are to onerous then you don't have security or privacy
Sure, but when you're in prison for using crap tool, you won't have liberty, security, or privacy.
actually i don't follow that argument. it is more likely that my data gets caught up with someone accessing a larger server than my own server. if someone targets my own server they may as well target all my messaging clients and get all the data from there.
The proper way to address this is with p2p messaging, like Cwtch, where each user is running server for their own account. Cwtch also experimentally supports caching ciphertexts on a server that's hosting the group chats that all members will have access to anyway, so there's no peer metadata to eavesdrop on.
ideally yes, but that is not what the average user will do, and it is not what i can use as an argument to get people to switch to something more secure. convenience over security is still a user preference.
i get your point, but that falls on deaf ears among family and friends. especially using prison as an argument is really not helping. i mean by the same argument we should not be having this conversation on hackernews, because clearly we are trying to subvert the authorities by suggesting that people should keep their communication secret.
edit: I didn't downvote you and I don't think someone asking an honest question like this should be downvoted
Notes and Other Stuff Transmitted by Relays.
It’s just signed json messages distributed by [websocket] relays.
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
[1] https://ron.stoner.com/nostr_Security_and_Privacy/
It’s worth highlighting as there are many affinity scammers spinning up tokens/blockchains called “Nostr”.
Effectively nostr objects lay around on relays until they reach some server-side expiry policy and sometimes forever if one can't figure out how to delete them. Nostr clients (web and mobile) are the wild west of good luck with which features and NIPs they support (XMPP all over again). My experience here led to dissatisfaction as well. Relays are another wild west - it's choice paralysis and a helping of good luck with that.
The real problem for IM: Nostr does not ensure all relays sync, instead a user chooses their preferred relays (some you pay for in crypto). It is entirely realistic (I experienced it) that you're on relays other people aren't and you can't share content. This is death for an IM app and just trying to use Nostr became frustrating. (not to mention it's flooded with porn and crypto shills)
Edit: a nostr client has to keep open network connections to all these relays, as objects can be stored on multiple relays and it's up to the client - not the relays - to query all relays and then de-dupe the JSON responses. There are combobouncers in use (who will de-dupe) but they're not the default and tend to be read-only (because you can't choose which relays to post to when using a combobouncer).
But - has there been security audit been done?
Why do every system insists on having persistent names as network identifiers? Practice shows that the main threat for the vast majority of users is state censorship. In case of Delta, Matrix, XMPP and others, once you're cut off your home server, your account is basically toast. The only thing you can do, besides circumventing, is a cumbersome and messy account migration[1], where available.
In case of Matrix, I feel very bitter, as I managed to onboard a considerable chunk of my personal network but most of them can't login anymore without using VPNs. I'm not sure if I have enough social capital to convince them to repeatedly register on different servers as they get blocked. P2P[2] feels still too far away.
Why can't we use key pairs as identifiers and simply request a desired username upon first login? In case of federated networks this would allow seamless server switching and allow users to continue their conversations. Servers shouldn't care what server a particular user's messages are coming from as long as they are verifiably theirs.
You can even add username propagation between servers (a new server requests the username from the old one that's supplied with user's login request). I know about Matrix identity servers but I don't see how it helps in this case.
1. https://ems.element.io/tools/matrix-migration
2. https://arewep2pyet.com/
IMO people freak out about spam way too much. I'd rather have something that works with occasional spam than have to put up with the insanity of modern IM. Having push notifications from 10 proprietary IM apps is worse spam than a couple of emails a day from some retard trying to get me to download a "pdf." I don't block spam at all in my personal email (although I have a couple of tools automatically label it.) I'd rather have everything delivered.
Other than that it looks like I get like 4 spams per week.
Mind, i don't publish my email anywhere. If you look at my profile on here you'll get a gmail address.
I got spam to postmaster once for some reason. That's a nice way to make admins aware of your spam campaign.
Spam is presumably more of a problem when you're more well-known and you don't have the option to control your own filters.
So I would say it's a low priority feature in the backlog.
1. Manually screen who can send you messages like Hey[^1] and Apple[^2]
2. Basic filtering to ensure the promotional stuff gets blocked or put in a separate list [^3]
3. Rate-limit senders who are showing robot like behaviour
---
[^1]: https://www.hey.com/features/spam-corps/
[^2]: https://support.apple.com/en-il/guide/iphone/iph203ab0be4/io...
[^3]: https://f-droid.org/en/packages/spam.blocker/
Or at least via a proxy.
So contact invitation can just be handled with use-once codes (or at least trivially burnable ones).
Edit: Also this wasn’t about collecting phone numbers, but about providing one for your business if you host a publically accessible site
You see, most EU countries decided some time ago that allowing people to own mobile numbers without a background check was simply too dangerous. What if someone used a burner phone to commit fraud, or worse — say something mildly controversial on the internet? To prevent such dystopian chaos, SIM registration laws were born. Now, whenever you purchase a SIM card in France, Germany, Spain, or pretty much anywhere with croissants, you have to offer your passport, soul, and, ideally, a letter of recommendation from your local constable.-
The result? Your phone number in the EU is no longer just a string of digits—it’s basically your name, address, and social security number all rolled into one. It’s like a little snitch in your pocket, ready to identify you at the first sign of online mischief. Online platforms know this. That’s why so many of them, from social networks to AI models, insist on a phone number. They’re not just trying to text you cute security codes — oh no, they’re trying to make sure there’s a warm, squishy, legally-recognizable human on the other end. Preferably one without too many fake Twitter accounts.-
Technically, GDPR is supposed to protect your data. That includes your phone number. But there’s a loophole the size of Luxembourg: if the phone number is used to stop terrorism, fraud, bots, or people being mean in the comments, then suddenly it’s all hands on deck. Platforms benefit from the comforting knowledge that EU phone numbers are like digital dog tags: traceable, trackable, and just annoying enough to prevent the average troll from spinning up 50 accounts to yell into the void.-
Of course, this all raises philosophical questions. Like: should your right to privacy hinge on your desire to play Candy Crush in peace? Is a SIM card a person? Could it run for European Parliament? And should we perhaps explore more civilized alternatives to this “one phone number equals one identity” system, like zero-knowledge proofs or just asking nicely?
In the meantime, welcome to the EU: where the cheese is soft, the bureaucracy is hard, and your SIM card knows more about you than your therapist.-
There are several countries that didn't buy into the madness of registering SIMs, luckily. Most strangely, the UK, the master of CCTV. Apparently they realized that it's a useless measure and will just anger the people.
Maybe something Proton should build on for its own chat app.
https://providers.delta.chat/protonmail
Delta Chat is an instant messaging scheme. It is still good to use preexisting standards where possible.
Maybe with AI there could be a sort of decentralized antispam filtering . but maybe not
Briar supports communication over multiple mediums, including wifi & Bluetooth, has forward secrecy, and feels quite 'signal-like' so its not impossible to get people to use it.
https://briarproject.org/
Briar looks really nice for people that really need the extra security and privacy, though.
I've been interested in SimpleX lately, but I don't really have anyone to properly test it with.
Anyone who hasn't tried it really ought to.
To the haters talking about PGP: giving your entire social graph to Meta or even Signal is considerably worse.
(Delta Chat markedly does leak your social graph, because it's email and email has no way to protect sender metadata from each user's email provider. That means full social graph recovery is one low-effort subpoena away in your attacker's municipality of choice.)
[1]: https://signal.org/blog/private-contact-discovery/
Their contact discovery uses SGX, which has a long list of vulnerabilities [1], and is even deprecated by Intel.
With access to the server, my guess is that getting someone's social graph is not entirely impossible.
[1]: https://en.wikipedia.org/wiki/Software_Guard_Extensions#List...
> I’ve tested Delta Chat with my own mail server, which uses Postfix and has everything configured for public e-mail, like DKIM signing, spamd, IP blocklist checks and so on, and each message took about 2 seconds from one device to another. Using a public server it sure feels below 300ms, so there is room for improvement when self-hosting a dedicated chatserver.
https://www.kassner.com.br/en/2025/05/08/delta-chat-encrypte...
In my test, both clients were ~80ms away from the IMAP server, but the server was delivering to itself. I’m also not sure if the port 587 has an idle/keepalive mechanism, or if it has to go around the entire TLS handshake at each message.
I don’t think 2 seconds is bad, most of my contacts will take at least triple that to read and type in an answer, so not a big deal.
2) you are not required to give the app access to your contacts
Stop spreading this misinformation, it is only making it harder to get people onto secure messaging systems. You need two people using secure systems to communicate and the result of all this horseshit is a bunch of armchair experts who haven't bothered to look into the actual security of the app making strong confident statements. Just stop.
Even if it had half the issues people pretend it does let's be honest, my grandma can use signal. That's a fuck ton better than most of the alternatives out there. Frankly, that's what 99% of people need, the app that everyone can use. Not the app that some techie says is trivial...
Side note) Comparing Signal to WhatsApp is wildly disingenuous.
Side side note) there's a 30 yo pgp hack. If you reply to a gpg email with "could not decrypt" you'll get back the email in clear text. (Joke is older than the average HN user)
Have their been done any third-party security audits by reputable companies?
If not, it's not safe to use - who knows what's buried in the source code (even if the source code is open).
Their FAQ answers this:
> Yes, multiple times. The Delta Chat project continuously undergoes independent security audits and analysis
— https://delta.chat/en/help#security-audits
I also built OTR on top of Discord but it requires Nitro because the messages for OTR end up being way too long. :(
i am using element/matrix and i have tried briar. the usability of deltachat and the ease of onboarding beats both of those. briar was especially difficult to get started with and only has a very limited usefulness compared to the others. and matrix is simply very complex and easier to misconfigure.
signal does not use a standardized protocol, and it requires a phone. that's not an alternative. my children have deltachat on their laptop. i can talk to them when i am not at home without needing to give them a phone.
OTR has had forward secrecy for 21 years. The effin headline stated PGP was a faulty model https://dl.acm.org/doi/10.1145/1029179.1029200
Why implement something PGP-like, without forward secrecy, 13 years later, beats my understanding. I mean, 13 years is also the time difference between OTR and PGP. I guess some devs don't read cornerstone papers of the field they supposedly specialize in :)