with Delta Chat’s invite links there is warrantied e2e encryption without MITM, and encryption can never drop or change in Delta Chat since v2, if someone write from a different encryption key, it will appear as a totally different/new contact request, so even if the email server tries to fake messages from a contact using a new key, they can’t take over the contact’s chat
using classic email to send unencrypted email and wait that the reply upgrades to encryption have the MITM problem and it is good we moved away from that approach, it was a plain vulnerability an source of criticism, what we have today might not be the easiest way to get on contact on earth but is a pretty good compromise between security, usability and independence of a central server
There are others who have made a similar point. In fact there is a discussion about this here:
Delta Chat developers often take design cues from other popular messaging apps like Signal and implement features from other apps at their discretion, so it’s reasonable to point to what other apps are doing while discussing the pros and cons of that approach.
It’s clear that there are situations where an “easily remembered username” could be very useful, and since we know there are some security drawbacks to that approach, perhaps that discussion can take place in the wider context of trust design.
This is good to know. I think there is an opportunity here to improve and update the onboarding sections of the FAQ so people in Sandra’s situation are aware of all their options. I just took a look at the help section here and it doesn’t mention at all that you can use other clients to open the invite links. And there is another section of the FAQ which still says “If you create a chat profile with a classic e-mail address you may manually create a contact if you know their e-mail address”, but that’s no longer true if your contact uses chatmail.
There will always be ignorant people. We shouldn’t let their opinions affect us.
This makes sense due to the ease of instant onboarding and the added convenience like support for Apple/FCM push notifications.
Thanks for replying. I understand that Delta Chat’s current approach using SecureJoin with guaranteed E2EE prevetns MITM.
I understand that the old approach with Autocrypt has a MITM problem, but I assumed that was due to TOFU not TOEU like Sandra said and I am trying to understand why in that case it would be trust on every use instead of trust on first use. I’m just trying to understand this to have better knowledge about Autocrypt, even if Delta Chat doesn’t use it any more.
This is only true if the invite link isn’t intercepted and possibly altered. That is why the current always trusted never expiring invite link design bothers me a little.
Autocrypt includes public keys in its headers in each e-mail. If the keys change the change is expected to be silently accepted.
This is TOEU, and obviously it is fairly rubbish security, and obviously the designers knew this. The idea of Autocrypt was a universal encryption standard that never broke anything. Autocrypt level one is only intended to protect against passive adversaries where there is no risk of the encryption breaking anything. The idea is to make level one really easy to adopt, then gradually ratchet up the security level in subsequent versions. See: Autocrypt Level 1: Enabling encryption, avoiding annoyances — Autocrypt 1.1.0 documentation
Deltachat does not allow the lower-security aspects of the Autocrypt standard. All Chatmail messages (incoming or outgoing) must have Autocrypt headers or the Chatmail servers will reject them. And when you add a new contact, the Deltachat client reads the headers and checks that the header key matches the fingerprint in the QR code or invite link. But if the header key changes, the message is dropped. This is not TOEU. It isn’t even TOFU; if the header key did not match the invite link, the message would also be dropped.
I came to Deltachat because I was looking for an e-mail client (for mobile Linux, encryption-capable). To me, the biggest selling point of Deltachat is actually compliance with open standards and interoperability.
Ease-of-use is second (there are lots of easy-to-use proprietary systems). Deltachat means I can swap encrypted mails with people who do not know what an encryption key is.
The chat format is a mild downside to me: it discourages long-form letters and encourages short chat messages. Which is fine, but I like long-form letters, so I’m not using DC for a lot of mails, especially if my correspondant does know what an encryption key is . Many mailclients also now have more chatlike threaded views.
I think Deltachat could absorb the e-mail community if it had a client with a more traditional UI:
I also suspect that a traditional mailclient implementing free Chatmail accouts, plus SecureJoin and/or WKD, would see a strong increase in popularity. Though the entire DC backend offers much more than just that!
Incidentally, it looks as though Autocrypt may by returning to Thunderbird as an extension. Thunderbird is popular, and the more popular a client is, the more important standards-compliance and compatibility become.
This is unmaintained and is not compatible with Thunderbird. Maybe works with SeaMonkey, but definitely not with the latest Thunderbird that has native OpenPGP support.
I did not know about Public Key Bot. That’s really useful, actually. A TOFU bot would presumably also be possible; I think it’s basically the same as a public invitation bot. Posting a QR code publicly is also TOFU.
manually exchanging key files (.asc or VCard) or QR codes or invite links 6a. including downloading them from keyservers and sending them in plaintext, even over horribly insecure networks
Six is moderately easy but not obvious in the UI.
It makes sense to favour the method that is easiest to do securely, and steer users to it. There are those who need another method, usually because they can’t physically meet friends, but they seem to be a minority. We could think about what the UI should steer them to (since I think “screenshot my QR and send it, often insecurely” is the current default).
Other methods are not hard to do, but not obvious in the UI. They require that the user understand them.
I agree that DC shouldn’t replace a classic email client, but it makes sense to allow reasonable communication with non-DC contacts within a chat interface. At least as long as there is technical compatibility with email.
In my opinion, only two changes are necessary to achieve this goal:
The ability to change the subject WITHIN a 1:1 chat. As it is now, it quickly becomes very confusing. A while ago, I made a suggestion on how this could be achieved without having to change the UI, because I consider it important that chats with non-DC contacts differ as little as possible from chats with DC-contacts. Otherwise, you might as well just use a traditional email client. Subject of emails - #110 by Raiden
Furthermore, I think that groups with non-DC contacts are superfluous. They often don’t work well in reality, as non-DC users quickly become confused. Even with normal email apps, I rarely send one email to multiple recipients and rarely receive such emails.
. Many mailclients also now have more chatlike threaded views.
the situation.