PGP isn’t architecturally well-equipped to provide forward secrecy
i have no insight into the development, but i suppose that swapping out PGP for something entirely different should technically be possible.
they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. seems a bit wierd given the premise, but the devs are at least not limiting themselves to SMTP and PGP.
> but i suppose that swapping out PGP for something entirely different should technically be possible.
That would probably be good, but email is still a terrible substrate for secure messaging. Clear metadata is security poison; you want as little of it revealed to participant servers as possible.
> they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely.
That’s great, but in that case: what’s the value proposition relative to Signal or even Matrix?
the peer to peer protocol at this point is only for realtime communication at which both parties have to be present. like IRC, those messages are not saved. it does not replace regular messaging which is stored. i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. as someone else stated, deltachat's value is that it is able to reuse existing infrastructure and does not require (but allow) a new set of servers to be able to work.
> i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction.
I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design.
(It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)
the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts.
and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat)
the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.
You are not expected to use your regular email address, you get assigned a random email address that gets tied to your account (and your chosen username, but I think that can be changed) and the servers that store uncollected messages are only accepting properly encrypted emails. All this is completely transparent to users, it looks like Signal, but doesn't require a phone number, and it uses proven technologies where server managers would only have access to the randomized email addresses and the message size and times (but those are not logged in the standard setup).
There is an inbuilt drive for decentralization, as "anybody" could run a server (I just set one up).
getting a random email address from a dedicated deltachat server is a new, optional feature. it didn't exist when i signed up. no matter. i am not using deltachat in a way that i need to stay anonymous. i am using it to talk to my friends. and if i wanted to i could create another account on the new servers. the ability to use a semi-anonymous email was always there. it's just a matter of finding a server for that. i am afraid though that the anonymity of the deltachat servers will be abused and they become targets of law enforcement.
Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata.
> and what are reasonable security expectations?
End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that.
> for most people sending encrypted emails would already be a win.
I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal.
There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear!
> the goal here is to raise the general use of encryption in messages.
No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards.
true, i wasn't thinking about security here but reuse of infrastructure. signal doesn't reuse infrastructure because it needs its own servers.
End-to-end encryption that the user can’t accidentally downgrade from
that's a fair point.
that doesn’t spray valuable metadata across the Internet
i find that a gross exaggeration. yes. metadata can be read by every server the mail passes through. but in practice most mails are only touching the sending and the receiving mail server. if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
also, where i use deltachat, the alternative is to use email.
I think the average person doesn’t know what an encrypted email is
which is why we need more encryption by default.
adoption outside of corporate S/MIME is marginal.
because it is to hard to use. deltachat makes it easy to use. next possible step: delta mail. a more traditional mail client that makes encryption as easy as deltachat does.
The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people
there is a long road to get to that. more encryption is just one step, but a necessary one. i agree with you, but the goal can't be reached if we don't work on multiple fronts. one of those is helping people to learn about encryption and privacy, which only happens by slowly getting them to use better tools and by improving those tools.
rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some. sometimes that makes sense, especially if the solution promises more than it holds. and deltachat would fall into this if it were to promise complete privacy. but i don't think it does that.
i have friends who outright refuse to sign up to a new service. but deltachat is ok because they can use their existing email for it. technically that sounds the same as saying that with signal you can reuse your existing phonenumber, but people already have much higher privacy expectations to sharing their phone number, and also deltachat doesn't share your email address except with recipients so it really isn't the same thing.
> if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
Why are we entertaining this hypothetical? It isn’t true in practice; the average user doesn’t control their mail server. The average user is using Gmail or Outlook, where their metadata is a single subpoena away.
And again, it just isn’t true: you need not just control over the server but also strict transport security for this property. This is not widely true of mail servers on the Internet.
> rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some.
I don’t agree. I think the average user has multiple high-quality E2EE messaging technologies available to them, and that Delta Chat effectively muddies the water by providing a worse security posture with the trappings of a familiar-but-unsecurable ecosystem (email).
(I also don’t know why people think Signal shares your phone number with people other than recipients. To my knowledge, that has never been the default and presumably never will be, even with their private contact discovery protocol.)
The point of Delta Chat is that the email system IS securable, and E2EE is possible within the Delta Chat ecosystem while they use well-established and understood technology, software and infrastructure. The idea is sound and charming, and completely open source and people can run their own servers to contribute to the infrastructure.
the average user doesn’t control their mail server
fair point. there are options however. you are not locked into trusting a specific entity.
but the critical point is that even signal is able to figure out who is talking to whom:
https://sanesecurityguy.com/articles/signal-knows-who-youre-...
sure, for SMTP the contact details are directly in the messages, which is worse, but i don't know of any service that works completely without metadata. but signal is at least trying.
also strict transport security for this property. This is not widely true of mail servers on the Internet
since gmail requires TLS i highly doubt that there are many servers out there that don't support it.
the average user has multiple high-quality E2EE messaging technologies available to them
available and willing to switch are different. as i said, my friends are not willing to sign up to yet another messaging service. it's a social media fatigue.
why people think Signal shares your phone number with people other than recipients
that's not the point, at least for me. i am hesitant share my number with signal or any other service, and worse, i do not want to share my number with the people i talk to. i refused to use signal until the later was fixed. i refused whatsapp too, but to many people that i need to reach demand it, so i had no choice.
these are all trade-offs. not everyone agrees on the same, and while i understand and principally agree with your arguments, for me they don't work because i can't convince my friends. i also have other friends who do run their own mail servers. i have contacts who require whatsapp and others who can only use wechat. most often i don't have a choice. i am using whatever i can get people to agree to, and for that deltachat is a good option. signal could have been a better option but unfortunately their requirement to share phone numbers until recently made them a worse option than deltachat or even telegram for anything but 1:1 communication with trusted friends (those who i trusted to have my number). that has changed now, and i started to use it. but it will take time to build up my contacts there. btw, in some countries it is not even possible to sign up to signal. the number gets rejected.
> since gmail requires TLS i highly doubt that there are many servers out there that don't support it.
Gmail doesn’t require TLS, unless by that you mean that their webmail interface is TLS only. Like every other mail provider, they do opportunistic TLS on external delivery, and TLS on MUA connections (SMTP and IMAP) is largely at the mercy of user configuration.
The fact that people seem to think that TLS is a mainstay of the email ecosystem is clearly part of the problem here.
As for the rest of this: I’ve hammered on about Signal because it’s the naive right choice, but it’s ultimately up to you to decide whether your phone number is an acceptable public identifier. But even if it isn’t, there is so much out there that’s indisputably better than this mess: Matrix or even iMessage (with an email identifier instead of a phone) would be better.
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.)
the client is fluffychat 1.26.1. server A and B below are both synapse 1.132.0, server C i don't know.
the situation is as follows:
there are multiple servers and users involved. let me name the servers A, B, C and matrix.org.
i have accounts on A and B, and my friend has an account on C. others have accounts on matrix.org. all of us are in a group on matrix.org (i am in the group with both of my accounts from A and B).
with both my accounts i can see but not decrypt messages from before i joined. yet the groups chat history setting is "visible for all participants" and not "visible from joining"
on account A i can read messages since joining, except for those from my friend on C.
my friend on C also can not read messages from A in the group. nor can we talk to each other directly.
now, A is a very restricted server that blocks many other servers as a spam protection measure. as far as i can tell, it does block server C but it does not block B. B doesn't have any blocks.
that i am unable to open a direct connection to C from server A is expected because of the block.
from server B this is not a problem. B can also read all messages in the group (after the join date)
what bothers me is this: even if server A blocks server C, why does it block messages that C sends into a group on matrix.org? groups should either be allowed fully or not allowed at all. it doesn't make sense that groups break for members on blocked servers.
now, A blocking C is not intentional and i could ask the admin to remove the block, but lets assume that it is intentional because maybe there are many spammers on C and my friend is an exception.
what i wonder is why even allow blocking in this form at all?
i am the only member from server A in the group. what benefit does server A have from blocking users from C in the group i joined on matrix.org? i could understand if A doesn't want people from C to join groups on server A, or connect to people on server A. so block directly incoming connections. but why block messages in a group that's not on server A? i joined that group. dealing with C should only be my problem. also, the messages aren't even blocked. they just can't be decrypted. so traffic is not even reduced. this is not encryption randomly breaking. this looks more like a problem with how blocking works to me.
also i think it would make sense that despite blocks, individual members from A should be allowed to initiate connections to users on blocked servers. it's connections from C to A we don't trust, but connections from A to C should be fine, because everyone on A is trusted.
the way i see it, if i am allowed to join a group, i should be able to see all messages in the group, and everyone should be able to see my messages, even from people on blocked servers and no blocking rule should be able to prevent that. if i should not see those messages then i should not even be allowed into the group. once i am in a group, there should be no blocks getting in the way.
users from blocked servers should not be able to access groups or contact people on the blocking server. and maybe users from the blocking server should not be allowed to join groups or talk to people on blocked servers. but that would ideally be a separate permission.
another issue is the key handling. i find it confusing as to what i need to back up so that i can reopen a connection from another device. deltachat has a simple export profile. i save that and i import it on another device and i am done.
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.