Overhaul Enncryption Support in Kontact
For a long time I have been fixing issues behind the scenes to support Autocrypt and fixing bugs around encryption.
But the best crypto support does not help if it is too complicated for users to use the system. PGP is complex and a lot of things can go wrong, so the UI should support the user to find solutions, if things are going the wrong way. For me it was obvious that I cannot do this on my own and found Eileen Wagner a UX designer who is experienced in crypto UX. It was a lot fun to work together with Eileen to improve the UX in Kontact ;)
It soon became obvious that the part that needs an overhaul is mostly sending. There is a lot that happens AFTER you press send. You may be faced with information that the keys are not good enough, or that a used key is near expiry. So we tried to improve the UX so that these issues will bubble up earlier so you can fix the issues before pressing send.
At least for me, it is often that I concentrate in order to finish a message before I need to go, and then press send in a hurry. So all dialogs and warnings are facing me while I'm in a hurry and I just want them to disappear. If instead, I know of those things in advance, I will have time to ask for a new key or search for the correct key for a particular recipient.
Here you see a sample of creating a message to several recipients after our improvments.
Eileen created a blog post about the thoughts behind the UX decisions made for Kontact. After several months of working together with Eileen, I realized that for outsiders, it is still hard to distinguish Kontact and KMail. Kontact is a bundle of several applications that are presented together. You are free to start and use every of those applications directly and will see no difference. You only will miss the small left-column to switch between the applications. KMail is the application that Kontact is using for the mail tab.
This work is possible because Eileen and I were funded by nlnet to improve Email Encryption in Kontact.
Near key expiry
I really like the feature that Kontact informs you about keys that will soon expire. Doing this makes it clear that I need to care about a key update and I can trigger it in advance. I know there is a lot of discussion about automatic key updates and several attempts to do this.
I am still using parcimonie for this task. But unfortunately not everyone is using a key server to communicate key updates, and nowadays there are several sources for keys update keyserver, WKD, PKA, DANE, ... Sure it would be easy to try an update in background, but starting a network connection without users consent is a no-go. So the first step is now to show the user that keys are near to expiry. In the second step, we will make it possible for the user to directly trigger an update. This will also be true if no suitable key was found for a recipient.
As I was inside the near-expiry feature code, I also added a fourth category for your own keys. I want to get informed about my own key expiry long before the key expires, to create and upload the key update, so when others are searching for the keys they already find the updated key.
Key cache usage
Until now Kontact always talked to gnupg directly using gpgme. In itself this is not an issue, but this connection is slow. This is why libkleo started to implement a key cache a while ago to cache all keys. Before, we had to wait for gnupg to answer all our requests. In my experience, that means sometimes I wait a minute or longer.
Now Kontact is also using this cache and we now can instantly show that we found PGP keys for all recipients, while typing the mail address. Do you see how fast the "green check mark" toggles while writing in the video? This "green check mark" indicates, that we found keys for all recipients. That's possible because of the key cache.
Trust levels
Gnupg now has the TOFU (trust on first use) feature that creates statistics about key usage and when we seen keys in our messages. When a key is used for a long time, the key is trusted more, and now you can detect a key with no history. This makes it harder for someone to present you with a new fake key. Of course, you get the best security by checking fingerprints and signing the recipient keys. But let’s be honest, who can do this for every key that one is using in our busy lives. For those who do not check every key, TOFU is actually a great improvement, as you build trust while using the keys.
In Kontact we are now display the trust levels instead of just validity, as the trust levels are taking the TOFU history into account.
I personally cannot see any disadvantage to enabling trust-model 'tofu+pgp' in gnupg via (~/.gnupg/gpg.conf) and would highly suggest that everyone enable that in gnupg.
It gives you the best of two worlds: You will be able to build trust on the keys by just using the keys (tofu part) and still can also check fingerprints (pgp part).
After enabling it I actually found out that until now the tofu data is not updated when I sent an encrypted message. However, it is done, if I use gnupg from the command line. I created a upstream bugreport for this. Until this is fixed tofu is a little bit useless, because no statistics are created. Key cache and key resolver also need to learn trust levels, as they are in charge to select the most trusted key to send messages to.
Settings
The settings in Kontact are in some corners a big list of checkboxes and it is not obvious where to find what. For Encryption we decided to merge several tabs together to present one page and name it Encryption.
There is also the signature feature, that is not connected with Cryptography but just about the mail signatures.
The critical point is the defaults for new users and we ended up having default encryption settings that can be overridden for each identity.
As all the work was done with Autocrypt in mind, I also mark Autocrypt support as stable. Now the user can enable Autocrypt within the settings page of the identity.
In the end I think these improvements take Kontact a big step forward and lets us use encryption more easily. I'm proud about the current state, but my To-Do list is still full until we have looked into all the corner cases.