Sustainable development and AI: Last month I attended the AI & Data International Symposium in Berlin, which was a two-day event to place the most pressing issues of our modern world– climate change, economic inequality, health and governance– as the north star for data-driven technology solutions.
Civil society experts, AI companies and foreign service officials from across the globe met, discussed, learned and networked. While data modeling, automation, or even blockchain, have not suddenly arrived, there is hope against hope that AI can help countries achieve sustainable development. When it comes to sustainable development and human rights, the UN's role looms large and many are looking to the development of principles as guardrails within which companies can develop technical solutions to extremely difficult problems.
The fact that these extremely difficult problems are somewhat exacerbated by technology notwithstanding, I found hope in the promise of hashtag-AIforgood not because AI makes development cheaper (it doesn't), but by imagining that technology will be used to solve the easy problems so that strong institutions and people power can be refocussed on solving the hard ones.
That same week, the UN Secretary General's AI Advisory Body published its first major output. It's on AI governance and mercifully mentions "human rights" a lot and "ethics" not at all. https://www.un.org/sites/un2.un.org/files/ai_advisory_body_interim_report.pdf
- News in the consumer-stalking-device market includes some more privacy-respecting ways to track the trackers https://www.wired.com/story/apple-airtag-privacy-stalking-cryptographic-solution/
- Software developer and founder Paul Biggar wrote an emotional piece about tech's role in Gaza's destruction https://blog.paulbiggar.com/i-cant-sleep/
- Excellent WaPo editorial on how the battle for democracy will be fought and won (Spoiler: Internet censorship circumvention) https://www.washingtonpost.com/opinions/2023/12/21/autocracy-democracy-internet-circumvention/
- Delta Chat sits somewhere between encrypted email and messaging (I actually use the mobile app for both) and its features have recently changed quite a bit https://delta.chat/en/2023-12-13-chatmail
It's 2024 and encrypted email (still) so bad (but it can be better): End-to-end encryption (e2ee) has come a long way in the last decade and is now in the hands of billions. But that is largely due to encrypted messaging, not encrypted email. In general, messaging has improved upon email with respect to usability, speed, discovery and security to the point that email is used much less. Setting aside that anecdotal observation, let’s look at the state of end-to-end encrypted email in 2024 and why, I think, it is still too hard to use and how to fix that.
Like most internet connections today, emails that are sent and received by any provider are done so over encrypted transport. But end-to-end encrypted email is required if email users would not like their emails stored on or accessible to the email server (the provider), or someone who could gain access to that server using an attack or a legal order. OpenPGP is the emergent standard for e2ee email and it uses asymmetric encryption, which requires users to each generate a key pair and then exchange their public keys before they can encrypt their communications. This is hard but still much easier than the alternative scheme, S/MIME, that requires overhead administrative installation of a certificate. With OpenPGP, it is largely left up to email applications and email provider webmail interfaces to implement it, along with the necessary management mechanisms for public key cryptography. There also exist server-side implementations of OpenPGP that provide mailing list encryption or support public key sharing.
In review, the critical and ideally independent but interoperable elements of e2ee email are:
- Email delivery service
- Client or webmail that supports OpenPGP to
- Create or import a key pair
- Keep safe the private key
- Encrypt and decrypt messages
- Manage, share, trust others’ public keys
- Public key sharing infrastructure.
With e2ee messaging here to stay, all information exchange platforms should integrate many aspects of a functional, usable, and accessible e2ee because the privacy of users depends on the developments in platforms, where digital literacy is being addressed. The ubiquitous and established use of e2ee messaging is teaching us all a little something about usable e2ee.
But e2ee email has lagged behind in adoption; very few people use e2ee email. Those people are using it even less today, because e2ee messaging can be used for most things.
In an attempt to change that, there have emerged three categories of modernised encrypted email solutions that use OpenPGP: Incremental changes to improve usable software, central web services for context-specific secure messaging, and app-controlled services. They all fall short.
Incremental changes in email clients isn’t enough
There are clients but even the two popular ones are, frankly, not how users choose to read email, opting instead for webmail. Mozilla put Thunderbird in the hands of an open source community that is driven by donations because it was unsustainable. And Outlook is a market-consolidated, enterprise-first product. These email clients– with encryption treated as an “advanced” feature– are also primarily built for desktops and the future is mobile.
The mobile-friendly clients seem to be trying a hybrid situation in which they are walled gardens of app users, even though you can sometimes with great effort BYOK (bring-your-own-key), meaning you can email other same-app users with encryption seamlessly, but this doesn’t easily interoperate with other encrypted messaging such that users can communicate with one another no matter who their service provider is, eg the major defining feature of email.
It seems that the calculus for client developers has been: email users don’t care about encryption, but if they do it must be because they have attained a high level of technical experience or their employer requires it. Therefore solutions are technically challenging to implement for end-users or tailored for enterprise environments.
Some industries need encrypted email to communicate with everyday folks
S/MIME is great if you have lots of everyday folks who are using the same enterprise email solution to do their jobs. It’s good for institutional security where email can be such a massive vulnerability, from attachments containing malware to phishing. However, a central authority is in charge of certificate management, send/receive settings, revoking access, controlling ingress and egress with filters, and even controlling the forwarding, printing or copying/pasting of emails. This does not work for everyday folks who need encrypted email for everyday things.
(Sidenote that there’s like a whole other weird version of corporate encrypted email that involves an asymmetry when internal and external people need to email one another, like the messages that come from your bank or your doctor. The required user behaviours here, eg “click to read this secure message”, are not what security experts would recommend. This is not e2ee, obviously, but it is important to mention these modalities because their universality indicates that there are various industries, contexts and needs for actual e2ee email to be ubiquitous.)
Centralized e2ee email services aren’t healthy
Eight years after Signal made e2ee messaging apps ubiquitous, we’ve seen e2ee email like Protonmail, pEp, Tutanota and others replicate this central control in all three critical ways.
First, many use OpenPGP encryption schemes but not interoperably. They all make up for this by allowing both the app’s encryption and OpenPGP key imports but not integrating them.
Second, they hide from the users all key related functions to the point that exporting one’s private key is done with app-specific “sync” features.
Third, you only get the security benefits if you’re talking to users on the same platform. This is probably the biggest insult to injury given email is fundamentally designed to be interoperable.
We need e2ee email that leverages standards, is not centralized, that interoperates, that presents both a streamlined interface by default and advanced features for customisation. This is the part where we start to learn something from e2ee messaging apps while preserving email interoperability.
Email is worth saving
There exists a crucial inevitability of the use of email. It is a more formal and professional manner of exchanging information. Email sits somewhere between your DMs and document writing. It is asynchronous. It is rich. It is what Marshall McLuhan would call “hot.” Making email end-to-end encrypted for everyone is what we would call *fire emoji*.
The most important reason we need easier e2ee email is that email is federated and messaging isn’t. Anyone with an email address can send an email to anyone else with an email address, for better or worse. E2ee messaging might just catch up to email in terms of interoperability, if the EU’s Digital Markets Act proves to be effective, which means we find ourselves in the luckiest timeline: messaging and email are growing together to become the best, most encrypted, versions of themselves.
Better: Easy end-to-end encrypted email for everyone
As a reminder, when you download an e2ee messaging app the elements I mentioned above are not revealed to the user, by default, making them highly usable. This is achieved by controlling all key-related functions within the app as a service. E2ee messaging users have keys, the e2ee messaging app exchanges users’ keys for them, and keys are automatically tied to the e2ee messaging users’ accounts. The scheme requires the user to only interface with one thing: An app that asks them to login to use the service.
- E2ee messaging
- User application
- Keeps keys safe
- Manages contacts and contacts’ keys
- Encrypts and decrypts messages
- User account
- Creates key
- Authenticates user
- Message delivery service
- User application
We can re-express this architecture into a list of principles derived from from the usability of e2ee messaging apps, that don’t yet exist in e2ee email clients:
- Make keys invisible BUT also make them accessible. Generate them, export them, share them, and consider key transparency.
- Make contact key discovery easy BUT also keep things usable with or without contact import or keys. TOFU (Trust on First Use) is the way!
- Make it email BUT make it sexy. Email should be feature rich and mobile first.
- Make it interoperable BUT make it encrypted. Email should keep doing the most, but with OpenPGP.
Especially with the specter of hard problems in interoperabile encryption hovering over our precious walled garden e2ee messaging apps, encryption is email’s crucial opportunity to come back and be relevant again.