[HN Gopher] Delta Chat is a decentralized and secure messenger app
___________________________________________________________________
Delta Chat is a decentralized and secure messenger app
Author : Bluestein
Score : 293 points
Date : 2025-06-21 06:29 UTC (1 days 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.
| nottorp wrote:
| 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.
| 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.
| kassner wrote:
| 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.
|
| 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.
| woodruffw wrote:
| 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.)
|
| [1]: https://signal.org/blog/private-contact-discovery/
| sudahtigabulan wrote:
| > Signal does not have access to your social graph
|
| 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...
| godelski wrote:
| > 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)
| 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.
| em-bee wrote:
| _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 wrote:
| 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 wrote:
| well, that depends on your threat model. for me, an
| acquaintance finding out who i am talking to isn't a
| threat. a threat is profiling by big companies. and
| already by either running my own server or using a
| smaller paid email service, that threat is drastically
| reduced.
|
| in fact this particular threat that you describe is more
| likely to happen at a university server where a rogue
| admin may use their privilege to snoop on people they
| want to stalk for whatever reason, as opposed to the
| friend that i chose because i trust them, like say the
| admin of the server of the local linux user group or the
| hackerspace that i am a member of.
|
| in fact i am more likely to trust anyone that i know in
| person, simply because even if that person decides to
| snoop on me we can work that our in person, and the
| likely hood for it happening is low because it would
| affect our friendship. and i would guess that this is
| true for most people.
|
| at some point you have to trust someone, and the closer
| you are to that person, the easier it will be to resolve
| problems.
| nottorp wrote:
| > 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.
|
| 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.
| eMPee584 wrote:
| 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 wrote:
| 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.
| 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?
| unboxingelf wrote:
| 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 wrote:
| 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._
|
| [1] https://ron.stoner.com/nostr_Security_and_Privacy/
| styanax wrote:
| 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).
| unboxingelf wrote:
| 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".
| emptysongglass wrote:
| Is it just me or does the website render poorly on mobile?
| 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.
| woodruffw wrote:
| > 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 wrote:
| _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 wrote:
| Centralization is _not_ a security property in the
| context of E2EE. You can _want_ decentralization (I often
| do), but it's essentially an ideological demand rather
| than a security preference when the server provably has
| no access to your messages or metadata.
|
| > and what are reasonable security expectations?
|
| End-to-end encryption that the user can't accidentally
| downgrade from and that doesn't spray valuable metadata
| across the Internet. That's table stakes; I'm not
| interested in lowering my standards below that.
|
| > for most people sending encrypted emails would already
| be a win.
|
| I don't think this is even remotely true. I think the
| average person doesn't know what an encrypted email is.
| We're now in at _least_ the third decade of encrypted
| email techniques, and adoption outside of corporate S
| /MIME (another can of worms) is marginal.
|
| There's almost too much to even say here; it's a
| disservice to even accept the implicit assumption that
| users _would_ use encrypted email correctly if they
| _could_ be made to: the single most common breakage point
| for all of this stuff is still people replying or
| forwarding previously encrypted messages in the clear!
|
| > the goal here is to raise the general use of encryption
| in messages.
|
| No. The goal is security. "General use of encryption"
| goes back to putting ideology before security. The goal
| is to _actually_ put users in a position where
| adversaries struggle to collect the kinds of data and
| metadata that would allow them to harm people. The US
| famously kills people based on metadata[1], and we're the
| "strict" ones in terms of evidentiary standards.
|
| [1]: https://www.nybooks.com/online/2014/05/10/we-kill-
| people-bas...
| em-bee wrote:
| _Centralization is not a security property_
|
| true, i wasn't thinking about security here but reuse of
| infrastructure. signal doesn't reuse infrastructure
| because it needs its own servers.
|
| _End-to-end encryption that the user can't accidentally
| downgrade from_
|
| that's a fair point.
|
| _that doesn't spray valuable metadata across the
| Internet_
|
| i find that a gross exaggeration. yes. metadata can be
| read by every server the mail passes through. but in
| practice most mails are only touching the sending and the
| receiving mail server. if both of those servers are in
| control of the sender and recipient and the connection
| between them is encrypted then the metadata remains
| private.
|
| also, where i use deltachat, the alternative is to use
| email.
|
| _I think the average person doesn't know what an
| encrypted email is_
|
| which is why we need more encryption by default.
|
| _adoption outside of corporate S /MIME is marginal._
|
| because it is to hard to use. deltachat makes it easy to
| use. next possible step: delta mail. a more traditional
| mail client that makes encryption as easy as deltachat
| does.
|
| _The goal is to actually put users in a position where
| adversaries struggle to collect the kinds of data and
| metadata that would allow them to harm people_
|
| there is a long road to get to that. more encryption is
| just one step, but a necessary one. i agree with you, but
| the goal can't be reached if we don't work on multiple
| fronts. one of those is helping people to learn about
| encryption and privacy, which only happens by slowly
| getting them to use better tools and by improving those
| tools.
|
| rejecting deltachat is rejecting something that improves
| the current state for something better that is not
| obtainable by some. sometimes that makes sense,
| especially if the solution promises more than it holds.
| and deltachat would fall into this if it were to promise
| complete privacy. but i don't think it does that.
|
| i have friends who outright refuse to sign up to a new
| service. but deltachat is ok because they can use their
| existing email for it. technically that sounds the same
| as saying that with signal you can reuse your existing
| phonenumber, but people already have much higher privacy
| expectations to sharing their phone number, and also
| deltachat doesn't share your email address except with
| recipients so it really isn't the same thing.
| woodruffw wrote:
| > 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 wrote:
| _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 wrote:
| > 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.
| em-bee wrote:
| _Gmail doesn't require TLS_
|
| according to this article it does:
|
| https://www.valimail.com/blog/the-new-requirements-for-
| email...
|
| and for one i think this is a good thing.
|
| otoh, according to this it doesn't:
|
| https://support.google.com/mail/answer/6330403
|
| but https://transparencyreport.google.com/safer-
| email/overview shows that by now almost all emails sent
| and received by google go through TLS which i believe can
| be used as a proxy to assume that most servers out there
| now support TLS.
|
| signal fixed their phone number problem, so that is no
| longer an issue.
|
| matrix is not reliable enough. the encryption can break
| in the sense that messages can no longer be read. i am
| basically required to have a second unencrypted
| backchannel (or use a different app, but then why even
| bother) to make sure i can reach someone. (the issue i
| experienced could be due to a misconfiguration of a
| matrix server, but that's a bug in itself. it should not
| be possible to change the configuration of a server in
| such a way that my messages arrive but can not be
| decrypted anymore.)
| Arathorn wrote:
| matrix encryption reliability should be fixed (at least
| on element x/web + synapse combos) as of Sept 2024.
|
| what server & client are you using?
| upofadown wrote:
| 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 wrote:
| "Architecturally" refers to the architecture of OpenPGP's
| message and certificate formats, not some kind of
| architectural standard. You can see Delta Chat's own
| community struggle with this[1]: unbounded certificate
| growth doesn't mesh well with acceptable rotation periods
| for ephemeral keys. There's also the problem of OpenPGP
| implementations encrypting to _all_ subkeys instead of
| the "latest" one, which of course blows a hole in the FS
| property.
|
| [1]: https://support.delta.chat/t/autocrypt-key-
| rotation/2936
| upofadown wrote:
| 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 wrote:
| 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."
| 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.
| tialaramex wrote:
| 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 wrote:
| 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.
| 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.
| jjav wrote:
| > famously minuscule metadata
|
| Famously minuscule? They demand a phone number, which
| blows up any possible anonymity story.
| klabb3 wrote:
| > 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.
| 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.
| klabb3 wrote:
| 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.
| tptacek wrote:
| 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.
| heavyset_go wrote:
| > _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".
| 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.
| maqp wrote:
| >Personally I just want to share shitposts with friends and
| speak freely without second guessing if I'm gonna be
| profiled by a data broker
|
| You are welcome to live your privileged life with your
| privileged friends using any software you feel is good
| enough. Just don't assume everyone can afford that luxury.
|
| https://pressgazette.co.uk/news/rsf-moves-downgrades-
| global-... is a decent index to assess in what kind of
| country you're living in.
| 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.
| heavyset_go wrote:
| > _Such as obfs4, I presume._
|
| Yep, but the author of obfs4 says not to use it, there
| are more modern transports with less flaws.
|
| At the end of the day, the transport lists are public,
| but sharded, so it's truly just obfuscation no matter
| what transport protocol you use. Someone observing your
| connection with the resources to map out transport relays
| can tell if you're using Tor.
|
| > _Have you heard about it, or have you used it before?_
|
| I haven't, but it looks interesting. It seems they're
| doing a similar mixnet approach to SimpleX.
|
| > _I agree. How much more secure is that?_
|
| If you don't to rely on a third party to queue and relay
| your messages when your recipient comes online, it's one
| less party that you're sharing information with.
|
| I also believe it opens you up to Tor correlation
| attacks, like what happened with Ricochet. Maybe an
| overlay mixnet can add some further obfuscation, as with
| SimpleX and RACE, but I assume those overlays are
| vulnerable to correlation attacks, as well.
| johnisgood wrote:
| > Yep, but the author of obfs4 says not to use it, there
| are more modern transports with less flaws.
|
| Such as?
| heavyset_go wrote:
| Check out
| https://torproject.github.io/manual/circumvention/ and
| https://obfuscation.github.io/
| johnisgood wrote:
| 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.
| maqp wrote:
| >How much more secure is that?
|
| It's much more secure wrt metadata. There is no third
| party server that's able to amass metadata about the two
| users conversing. SimpleX doesn't hide your IP-address
| from the server, and given that there's exactly two
| parent companies hosting ALL of the official servers,
| it's not too hard for Akamai or https://runonflux.com/ or
| anyone who compromises their OOBM systems to perform end-
| to-end correlation between two users.
|
| https://discuss.privacyguides.net/t/simplex-vs-cwtch-who-
| is-... has a lot of discussion about Simplex vs Cwtch.
| heavyset_go wrote:
| Agree with your post, but do want to point out that using
| private message routing on SimpleX theoretically hides
| your IP address from the server[1].
|
| Similarly, built-in routing over Tor can make performing
| correlation attacks difficult for some adversaries, and
| if you elect to use your own .onion servers instead of
| the official ones, it adds another layer of obfuscation.
|
| [1] https://github.com/simplex-
| chat/simplexmq/blob/stable/protoc...
| johnisgood wrote:
| 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 wrote:
| By "your" I mean your chosen 3rd party servers
| johnisgood wrote:
| Could you clarify with regarding to .onion? How would I
| set this up for SimpleX and how would I configure SimpleX
| to use it, on, say, Android and Linux? I believe to use
| Tor with SimpleX, you would have to use Orbot, for
| example. What would I have to set up and how, on Linux?
| Genuine question. I would much prefer to self-host it.
|
| I would also like to know how I would configure SimpleX
| on Android to use my own SMP servers.
|
| Edit: I found this:
| https://simplex.chat/docs/server.html.
|
| And I found: # `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
|
| In any case, I believe what I was looking for is
| https://simplex.chat/docs/server.html.
| maqp wrote:
| From the SimpleX doc you linked
|
| "To mitigate this problem SimpleX Messaging Protocol
| servers support 2-hop onion message routing when the SMP
| server chosen by the sender forwards the messages to the
| servers chosen by the recipients, thus protecting both
| the senders IP addresses and sessions, even if connection
| isolation and Tor are not used."
|
| The thing is, like I said, there are only two main
| companies running all the servers. Akamai and RunOnFlux.
| So unless Tor is used, it's a 50-50 chance that both
| users are connecting on to servers run by Akamai. Doesn't
| matter if the two servers don't share with each other the
| information about the IP-adderss of the user's peer. It's
| enough the parent VPS company has access to all traffic
| coming into the infrastructure. There's nothing "onion"
| about that routing. It's much closer to just traffic
| between two nodes of a server farm. Which is what
| practically any scalable IM server does.
| agnishom wrote:
| "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 wrote:
| 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 wrote:
| > 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.
| Bluestein wrote:
| All of which is true and praiseworthy.-
|
| Sadly, as with many things, Gmail effectively controls it
| _de facto_ , nowadays ...
| woodruffw wrote:
| 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.
| SwtCyber wrote:
| Definitely not for threat models where anonymity is critical
| 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 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 wrote:
| > _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.
| jjav 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.
|
| 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 wrote:
| 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 wrote:
| 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.
| 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.
| maqp wrote:
| 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.
| 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.
| heavyset_go wrote:
| XMPP is riddled with privacy pitfalls even when you bolt on
| encryption to it. Like email, it was not designed with
| privacy in mind.
| 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/
| Tmpod wrote:
| 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.
| kingkawn wrote:
| Pretty Good Protection ain't good enough anymore
| upofadown wrote:
| 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.
| raybb wrote:
| 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 wrote:
| 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.)
| ZoomZoomZoom wrote:
| 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.
|
| 1. https://ems.element.io/tools/matrix-migration
|
| 2. https://arewep2pyet.com/
| Arathorn wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-22 23:01 UTC)