"No, Delta Chat doesn’t support Perfect Forward Secrecy (PFS). This means that if your Delta Chat private decryption key is leaked, and someone has collected your prior in-transit messages, they will be able to decrypt and read them using the leaked decryption key."
It's great they're being open about the implications. But given that there's better protocols out there (Signal protocol for example), it makes no sense to use inferior apps.
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.
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.)
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.
But, and maybe I'm stating the obvious but it is a critical difference, open source is nice but much inferior to open interoperable standards.
Signal-the-company does not allow any clients other than their proprietary compiled client (I believe they sort of tolerate some, but not supported). So while in theory I could use the open source software to run my parallel signal-protocol network, it won't interoperate with the one run by Signal-the-company which is where most people are. So, not actually useful.
Contrast this with email which is an open standard. I can run any SMTP server I like and any MUA I like (or even write my own for one or both), and interoperate with the whole universe of people who use email.
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.)
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.