Campaign to have end to end encryption for email by default

As with other campaigns (eg. what we were discussing for DEPHCOM), I think it is best to provide recommendations depending on peoples' level of comfort and their existing setup.

• People who are used to centralised webmail but are open to switching providers: switch to Aster or Proton (I would not recommend Tuta as there is no option to use other email clients even if people want to in future)

• People who are stuck with their current proprietary webmail interface, such as Gmail, and do not want to switch: set up Mailvelope

• Organisations who use Google Cloud for email on their own domain: switch to Aster, Proton, or Tuta if they allow organisation accounts (need to check this)

• "Power users" who use mail clients (anything other than the default webmail offered by their provider): set up GPG encryption. If the client does not support GPG encryption, switch to Thunderbird on desktop (does it work on mobile?)

• Power users who have GPG set up but are on a proprietary email service: switch to a privacy respecting email service such as Disroot or Riseup. If you are willing to pay, consider providers like Posteo, Soverin, Thundermail, and Mailbox.org (if you use your mail client often) or Aster and Proton (if you need SMTP access but use webmail often and are willing to set up a bridge for SMTP)

• Organisations with power users: encourage your users to set up GPG encryption. If you are dependent on a proprietary service, switch to something privacy friendly such as Posteo or Mailbox.org

• Power users who already have GPG set up: make sure your keys are available on a public keyserver (we should make a list)

• Power users with published, active GPG keys: enable encryption by default on your email client

• Power users with GPG who have a personal website: make the GPG keys available for download from your website

This is just a draft list, suggestions are welcome.

@Badri Sunderarajan that sounds like a good start. I think we should arrange them in a scale explicitly with estimated difficulty level. Proton also support bridges in paid plans - same as aster https://proton.me/support/imap-smtp-and-pop3-setup

Does tuta support bridges in free plan too? I suggest setting a deadline for comments and publishing it at that point. Keeping things open ended will usually just drag on forever.

Could we try to see if as-is e-mail accounts with Delta Chat as the client (with keys managed internally) can do an encrypted round-trip to an account with a GPG key? Or see how to make it work? It could be the solution for all those who don't manage their own keys.

I wonder if it's worth having a webapp that does GPG encryption (like Mailvelope) but with keys stored password-protected on the server (like Aster/Tuta/Proton), connects to your existing Gmail/Outlook account, and tries to automatically fetch keys from keys.openpgp.org (with a warning otherwise about emails not being encrypted).

It would basically a combination of existing technologies, but bundled in such a way that we can tell someone "just open this link" and your emails will magically be encrypted! Without having to explain about copying around PGP keys to each device and stuff. It's lower security, but arguably not lower than anything Aster/Tuta/Proton provide.

Or perhaps it would work better as an addon (so, a fork of Mailvelope)? That way people can continue using the interface they are used to, although since the email provider controls the interface they could be sending the email (eg. via autocomplete queries) before we even have time to encrypt it for sending.

We could apply a similar idea to an app as well: "install this app and use it to check your 'Gmail'".

If we follow some other innovative things like Google Inbox or Hey did/do it would help it catch on, but that would take more effort so maybe it's best to just put together existing stuff initially. If we use Horde, for example, then we can add those Inbox- or Hey-like features to Horde itself as plugins and let everyone benefit from it.

What does the target audience uses e-mail for? Most people don't e-mail non-work contacts, and their work e-mails are not at threat at rest on their organization's storage.

Their e-mail is just a notifications system for financial events: shopping, banking, taxes. GMail reading all that is irrelevant to them when Google gets even more info off their phones.

Maybe the interesting audience is very small and is already using, say, Signal due to shortcomings of e-mail that encryption cannot fix.

Documentation note: Thunderbird has a global end-to-end encryption setting and account-level end-to-end encryption settings. However, the global setting is only to "enable encryption when possible", i.e. if no keys are found it will silently fall back to sending an unencrypted message.

The account-level setting, on the other hand, is to "always enable encryption by default". If keys are not available, you will be forced to either try fetching keys or manually disable encryption. I think this option is better as we have to make a conscious choice about E2EE each time and it will also help with peer pressure.

Somewhat confusingly, the account-level setting is only visible if the global "enable encryption when possible" setting is disabled. If you enable the global option, then the account-level option doesn't show up.

So, if you are using Thunderbird, make sure to disable "encryption when possible" and instead go to the account settings so you can enable encryption even when it is impossible 😉

(If you have multiple identities per account and only some of those identities have PGP keys associated with them, you can find E2EE settings within each identity too, with the option to "always enable encryption" for that identity)

What's the recommended way to handle shared email addresses (eg. for Prav's Treasury and Bursary teams)? Should we create a separate GPG key for the shared ID, or is there some way to indicate that "emails to this address should be encrypted for the following peoples' keys instead"?

We usually generate a key pair and share private keys with all members.

I don't use it because the need never arises. And when it does arise, stop communicating with a friend is easier than getting them to convince the need for privacy.

Most of the communication happens over WhatsApp. And emails are for job applications, complaints, or for short communication with customer support. None of them have GPG keys.

I have created a keypair for Prav's Bursary Team and am trying to get the same done for the Treasury Team. We could similarly set up a key pair for any public email addresses we have (eg. project contact)