Note: I had previously opened this issue as https://github.com/deltachat/deltachat-android/issues/3902. I hereby open it as a feature request in the forum, suggesting that the UX described below be improved.
tl;dr
I onboarded a friend to Delta Chat a couple of days back and have two major grievances:
- Autocrypt didn’t kick in. (Not sure if this is intentional or a bug, though.)
- After performing SecureJoin, instead of upgrading our existing conversation to verified end-to-end encrypted, Delta Chat gave both FRIEND and MYSELF two versions of each other. One encrypted and one non-encrypted. I strongly dislike that UX. We just went through the trouble of performing out-of-band verification of our respective credentials; none of us wants to have Delta Chat send unencrypted messages by accidentally selecting the wrong version of two identical names in our chat lists.
The full story
A couple of days back, I onboarded a friend to Delta Chat and found the experience a lot less comfortable than I had anticipated. Some background: FRIEND and MYSELF have been in contact via email for some time. FRIEND is a non-technical user but strongly interested in using end-to-end encryption. I recommended Delta Chat (which I myself have also been using for some time now), expecting that Delta Chat would make end-to-end encryption easy for her. Unfortunately, this was not what I experienced.
Expectation:
- FRIEND installs Delta Chat and enters her email credentials.
- End-to-end encryption between FRIEND and MYSELF just works.
Reality:
- FRIEND installs Delta Chat and enters her email credentials. (Some trial and error here, but in the end we get it working; not much Delta Chat can do about that, obviously.)
- We do the QR scan to set up verified end-to-end encryption. I suddenly have two instances of FRIEND in my chat list.
- We delete the chat from both apps in order to start again.
- We have another look at FRIEND’s settings to ensure that the display name is set to the same string she used for sending regular email.
- We do the QR scan again to set up verified end-to-end encryption. Again I have two instances of FRIEND in my chat list.
- We delete the chat from both apps in order to start again.
- I use Delta Chat to send FRIEND a regular email, hoping that her Delta Chat will pick up my Autocrypt header.
- FRIEND replies using Delta Chat, but the reply is not end-to-end encrypted.
- I MYSELF reply using Delta Chat, but this reply is not end-to-end encrypted either. (This might have been caused by a missing settings migration strategy, see below.)
- We do the QR scan again to set up verified end-to-end encryption. Now we both have two instances of each other’s contact in our respective chat lists. Note that both versions of FRIEND I now have in my chat list have the exact same display name and email address. The only visible cue about their difference is the profile picture, which is an envelope in one case and a colored letter in the other. The same is true about the chat list in FRIEND’s Delta Chat.
- I now need to explain the concept of encrypted vs. unencrypted chats in Delta Chat to FRIEND.
- I start to wonder if it would have been easier to teach FRIEND how to use
gpgfrom the command line and pipe her emails intosendmail.
What I would have hoped for would have been this:
- FRIEND installs Delta Chat and enters her email credentials.
- As we continue writing emails to each other, our conversation is automatically upgraded to end-to-end encryption by the power of Autocrypt.
- Once we do the QR scan, our conversation is automatically upgraded to verified end-to-end encryption by the power of SecureJoin.
Note that step 1 worked well enough, but steps 2 and 3 did not work nearly as well as I had hoped for. I feel that this is a huge usability issue and arguably a huge regression when it comes to UX. I do not have that much experience with onboarding new users; but I vaguely remember that it was easier once. I also remember that conversations were once automatically upgraded to end-to-end encryption by the power of Autocrypt. This was slightly unexpected for me at the time, but in retrospect that was the nudge I needed to finally enable end-to-end encryption on my laptop as well.
Key takeaways
I believe that the subpar experience I had with onboarding FRIEND is a very serious usability issue. As I already mentioned, I even started to wonder if I can keep recommending Delta Chat to my peers. I believe that Delta Chat needs to figure out what it wants to be. Does it want to be an email client that looks like XYZ but does regular email behind the scenes? Or does it want to be an email client that looks like XYZ but does (opportunistically) end-to-end encrypted email behind the scenes? Currently, it tries to do both; and therefore achieves neither. Having two versions of the same contact in the chat list simply transfers the complexity of whether or not to use end-to-end encryption to the user. If you ask me, this is not acceptable. Delta Chat, in the spirit of Autocrypt, used to remove complexity from end-to-end encryption by making good choices for the user. (Which key format? Which hash algorithm? Which curve? Sign with the primary key or use a dedicated signing subkey? How to handle multiple user ids?) With the UI switch from the padlock to the envelope, Delta Chat apparently started adding complexity. And what is more: UI complexity of the sort that to me seems outstandingly inconsequential. If I need to explain the difference between RSA and cv25519 to someone, at least they learn something useful in the process. If I need to explain the difference between envelope-emoji-me and colored-initial-me in some chat list, this is simply a waste of time.
I strongly hope that this issue will be addressed. I also believe that being opinionated about enabling end-to-end encryption is the way to go. Delta Chat already mandates end-to-end encryption for users on chatmail servers. I would argue that it should take a similar stance for other users. If people decide to use Delta Chat for Android with their regular email account, that is already a strong indication that they wish to use end-to-end encryption. (Keep in mind that installing a third-party email client on your phone is hardly a commonplace thing to do in today’s tech landscape.) I therefore believe that Delta Chat should at the very least automatically enable end-to-end encryption for those 1:1 conversations where it is easily possible. Such as those where both chat partners use Autocrypt-capable email clients or where they even did a QR scan. I do not believe that Delta Chat should cater for the use case of: I did a QR scan with PEER, but I still want the ability to turn end-to-end encryption on or off on a per-message basis.
Sorry about the strong feelings. In general, I am deeply grateful that Delta Chat exists and I am strongly aligned with what you guys are trying to achieve. Also: I want to see you succeed.
Additional things that may be of interest
I have a feeling that my Autocrypt prefer-encrypt setting might be broken. I had once adjusted my settings to prefer unencrypted email; but it has been a while that I can not find that toggle in Delta Chat’s settings anymore. However, inspecting the mails generated while onboarding FRIEND, I realize that FRIEND sends Autocrypt headers like this:
Autocrypt: addr=[FRIEND's address]; prefer-encrypt=mutual; keydata=[[ base64
<tab><space>encoded public key, spanning multiple lines ]]
while I MYSELF send Autocrypt headers like this:
Autocrypt: addr=[MY address]; keydata=[[ base64
<tab><space>encoded public key, spanning multiple lines ]]
What’s the policy here? Did I simply fail to figure out where the prefer-encrypt setting is located? Was prefer-encrypt made non-configurable for Delta Chat? And if so, why does my client continue to use the deprecated setting – that I can’t even change anymore – instead of migrating my settings to match the new way of doing things (i.e. to always send prefer-encrypt=mutual)? Did someone simply forget to add a database migration rule for that case?