[HN Gopher] Delta Chat is a decentralized and secure messenger app
___________________________________________________________________
Delta Chat is a decentralized and secure messenger app
Author : Bluestein
Score : 227 points
Date : 2025-06-21 06:29 UTC (16 hours ago)
(HTM) web link (delta.chat)
(TXT) w3m dump (delta.chat)
| fouronnes3 wrote:
| 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.
| chrisldgk wrote:
| 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).
| Bluestein wrote:
| ... 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| ... And SIMs are available from vending machines, which I
| find amusing :)
| radiospiel wrote:
| afaik no businesses are required by the gdpr to collect phone
| numbers, and would like to see evidence otherwise
| progval wrote:
| 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.
| chrisldgk wrote:
| 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
| v5v3 wrote:
| 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.
| XorNot wrote:
| 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).
| msgodel wrote:
| 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 wrote:
| 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.
| immibis wrote:
| 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.
| ravdeepchawla wrote:
| 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
|
| ---
|
| [^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/
| em-bee wrote:
| 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.
| sixtiethutopia wrote:
| 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 wrote:
| The way to have guaranteed encryped is creating two user
| encrypted group chat.
|
| https://delta.chat/en/help#how-can-i-ensure-message-end-to-e...
| deknos wrote:
| did you look into their spec? perhaps they used the updated
| openpgp standard which has authenticated encryption. or perhaps
| they just sign everything.
|
| and it's not just pgp with email, it's more akin to an
| overlaysystem.
| maqp wrote:
| >No forward secrecy and supports sending unencrypted messages
| as well for people who don't have pgp.
|
| JFC. There's a reason Signal dropped SMS support. What an
| insane design decision.
| joecool1029 wrote:
| FWIW textsecure (signal's SMS predecessor) did provide
| forward secrecy. Details are here:
| https://signal.org/blog/asynchronous-security/
| maqp wrote:
| 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.
| HelloUsername wrote:
| Previous discussions:
|
| 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
| data_maan wrote:
| Great source of info.
|
| I wonder why this was downvoted
| hkt wrote:
| 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.
| singpolyma3 wrote:
| 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 wrote:
| 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.
| rlue wrote:
| 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.
| em-bee wrote:
| 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.
| shark_laser wrote:
| 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.
|
| https://www.0xchat.com/
| data_maan wrote:
| 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?
| rpdillon wrote:
| 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.
| AJ007 wrote:
| 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.
| promptdaddy wrote:
| Apologies for any nativity here, but wouldn't storing
| encrypted messages on a blockchain be a robust solution for
| this?
| heavyset_go wrote:
| 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
| maqp wrote:
| >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 wrote:
| 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.
| maqp wrote:
| >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.
| em-bee wrote:
| 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 wrote:
| >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 wrote:
| _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.
| lxgr wrote:
| 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 wrote:
| 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.
| maqp wrote:
| https://github.com/0xchat-app states it doesn't have desktop
| clients.
|
| 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.
| heavyset_go wrote:
| Doesn't Nostr expose the fact that you sent messages to certain
| people via its blockchain?
| data_maan wrote:
| 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).
| johnisgood wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| maqp wrote:
| A standardized protocol without forward secrecy is worse
| than standardized protocol with forward secrecy. Just use
| Signal.
| em-bee wrote:
| 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 wrote:
| >messages encrypted with forward secrey can still be sent
| over SMTP. deltachat devs are working on that.
|
| 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 :)
| johnisgood wrote:
| 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.
| JimDabell wrote:
| > 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
|
| -- https://delta.chat/en/help#security-audits
| tcfhgj wrote:
| first of all, it's not a walled garden
| em-bee wrote:
| 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 wrote:
| Delta Chat has the option of using chatmail servers that they
| host themselves.
| josephb wrote:
| 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.
| singpolyma3 wrote:
| 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
| blancotech wrote:
| Anyone else immediately think of delta airlines? I was excited to
| read an analysis of a seat-to-seat chat implementation
| Bluestein wrote:
| Like those gaggles of girls chatting each other up while
| walking shoulder-to-shoulder down the street.-
| seydor wrote:
| seat29@flight7822.delta.com slaps seat34@flight7822.delta.com
| with a large trout :: stop snoring
| seydor wrote:
| 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
| lclc wrote:
| Has anyone used that with their Protonmail account?
|
| Maybe something Proton should build on for its own chat app.
| kseistrup wrote:
| DeltaChat is incompatible with ProtonMail:
|
| https://providers.delta.chat/protonmail
| floren wrote:
| 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
| b0a04gl wrote:
| 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
| heavyset_go wrote:
| 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 wrote:
| 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.
| heavyset_go wrote:
| I agree from that perspective.
| lima wrote:
| Source: https://delta.chat/en/help#pfs
|
| It's basically GPG with better UX.
| newsclues wrote:
| PGP?
| __MatrixMan__ wrote:
| GPG is gnu privacy guard, it's an open source
| implementation of the same ideas that are PGP (pretty
| good privacy).
| singpolyma3 wrote:
| Specifically we're supposed to call it OpenPGP these days
| 47282847 wrote:
| 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.
| em-bee wrote:
| 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 wrote:
| > deltachat devs are working on forward secrecy
|
| That's great, but I'm not holding my breath. PGP isn't
| architecturally well-equipped to provide forward secrecy.
| In the mean time, I think it's borderline negligent to put
| this in the category of secure messaging; the world's
| expectations for security baselines have moved on beyond
| the mid-2000s.
|
| (My reference point here is Keybase, which built a very
| user-friendly and misuse-resistant encrypted chat on top of
| PGP in the mid-2010s. They couldn't get to forward secrecy
| either with PGP as their substrate.)
|
| > as for metadata, as long as the messages are sent from my
| personal email server to the destinations email server
| using a TLS connection, the metadata is accessible only on
| those two servers.
|
| To the best of my knowledge, MTA-STS adoption rates are
| still abysmal[1]. It's a move in the right direction, but
| this kind of shambolic jigsaw approach to communication
| security isn't appropriate in 2025. Sensitive messages
| should go over protocols designed to carry them.
|
| [1]: https://www.uriports.com/blog/mta-sts-survey-
| update-2025/
| em-bee wrote:
| _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 wrote:
| > 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 wrote:
| 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.
| repeekad wrote:
| 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 wrote:
| 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 wrote:
| 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.
| klabb3 wrote:
| > 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.
| woodruffw wrote:
| 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.
| tptacek wrote:
| 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.
| bastawhiz wrote:
| 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.
| umanwizard wrote:
| > It's also only decentralized as much as public email
| infrastructure is decentralized.
|
| So... entirely? What am I missing about your point?
| binary132 wrote:
| Public email infrastructure is almost entirely dominated by
| Google. This is worth looking into if you're not familiar
| with the state of affairs
| heavyset_go wrote:
| 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.
| singpolyma3 wrote:
| 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 wrote:
| 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.
|
| [1] https://docs.cwtch.im/
| johnisgood wrote:
| Differences between Cwtch, and SimpleX? Which are you
| leaning towards to and why?
|
| According to https://github.com/simplex-
| chat/simplexmq/blob/stable/protoc...:
|
| > identify that and when a user is using SimpleX.
|
| Does this apply to Cwtch?
|
| Also, is it not possible to obfsucate this traffic? Tor
| with obfs4?
|
| Related:
|
| #1 - https://security.stackexchange.com/questions/241730/tr
| affic-...
|
| #2 - https://github.com/simplex-chat/simplex-
| chat/issues/4300
|
| #3 - https://github.com/tst-race/race-docs/blob/main/race-
| channel...
| heavyset_go wrote:
| > _Which are you leaning towards to and why?_
|
| Heavily sandboxed SimpleX that's firewalled to block any
| non-Tor traffic. Chose this one because it allows for
| offline message sending/receiving, despite privacy
| implications, and because it has clients people will
| actually use.
|
| Cwtch doesn't let you send messages when the recipient is
| offline by virtue of how it works, which is more secure,
| but inconvenient.
|
| When evaluating Cwtch, I think I read somewhere it might
| send identifying metadata to your recipient, or something
| similar, but I might just be making that up. I'll have to
| look up what I was reading.
|
| > > _identify that and when a user is using SimpleX._
|
| > _Does this apply to Cwtch?_
|
| With Cwtch you're running two hidden services, one on
| either end of the chat, and that happens over Tor with no
| middleman service, so no. A passive network observer can
| tell when you're connecting to Tor, but you can attempt
| to obfuscate that with transports.
| johnisgood wrote:
| > 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.
| maqp wrote:
| "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."
|
| 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.
| Valodim wrote:
| 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 wrote:
| 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.)
| Valodim wrote:
| The difference is the collateral. Are you really going to
| shut down a country's most popular local email service? Or
| gmail?
| woodruffw wrote:
| 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 wrote:
| 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 wrote:
| > 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 of 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.
| tcfhgj wrote:
| you don't have to use email to federate between servers,
| there are other protocols such as Matrix, XMPP, probably many
| more
| Valodim wrote:
| 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 wrote:
| "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 wrote:
| _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 wrote:
| 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 wrote:
| _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.
| em-bee wrote:
| forward secrecy is under discussion:
|
| https://support.delta.chat/t/autocrypt-key-rotation/2936
| zaik wrote:
| Modern XMPP clients implement the Signal protocol for
| encryption and are decentralized like Delta Chat.
| iqandjoke wrote:
| Which party the developer associated with? Hopefully not CIA.
| exe34 wrote:
| Why not just create a group chat and invite FBI and Shin Bet?
| monkaiju wrote:
| 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.
|
| https://briarproject.org/
| kingkawn wrote:
| Pretty Good Protection ain't good enough anymore
___________________________________________________________________
(page generated 2025-06-21 23:00 UTC)