Mailpile: A bold approach for email privacy
The roadmap looks too good to be true, but the developers seem to be serious. They have taken the approach through the first months, delivered on their promises and now are trying out how far they can venture. Mailpile Beta is now open for the general public.
These are the goals, they have set for themselves:
- Basics: It should be safe, easy and convenient to read, write, search and organize your e-mail.
- People should be able to communicate privately. For e-mail that means:
- Delivery: Messages are delivered intact and in a timely fashion.
- Privacy: The contents of the messages have not been eavesdropped on.
- Integrity: Messages are authentic (not forged).
- Metadata Privacy: The identities of the people communicating are known only to the people involved in the conversation.
- People should be able to store their e-mail long term, with a strong confidence that:
- Storage Privacy: It cannot be read by unauthorized 3rd parties.
- Storage Integrity: It cannot be modified by unauthorized 3rd parties.
- Availability: They have convenient and reliable access to the contents.
They are taking in some neat ingredients into the development in the future, namely:
- Mailpile will support the OpenPGP and PGP/MIME standards for encryption and digital signatures of e-mail (see below for details).
- These standards are flawed in that they do not protect the message headers (including the subject, from and to lines), but they are the only reasonable standard available to us at the moment.
- This end-to-end encryption should be augmented by using TLS and/or Tor for message delivery whenever possible, as that can provide at least partial protection for metadata (2.4) and information not protected by the standard OpenPGP encryption, and can compensate for situations where end-to-end encryption is infeasible. Industry best practices should be used in all cases, which means using strong ciphers supporting forward secrecy whenever possible.
- When the details of the DIME (Dark Mail) protocol are made public, it should be evaluated as an alternate or complementary strategy, as it aims to also provide Privacy, Integrity and in some cases Metadata Privacy (2.4) as well.
- Another project to integrate with is LEAP, for similar reasons.
The best thing is the ease of use, that the approach promises – getting S/Mime to work is not for everyone, and the approach here is to make it a painless process:
Mailpile’s PGP key strategy is as follows:
- Generate keys for all users when Mailpile is first installed.
- Help users make safe backups of their key material and passphrase.
- Sign mail by default, encrypt when the user requests it or there is a reasonable expectation that the recipient will be able to read it.
- Distribute public keys in an ad-hoc/opportunistic manner by attaching them to outgoing mail.
- Assess key validity using a “Trust upon first use/contact” (TOFU) strategy.
Next, especially the experimental 1st draft of SMTorP peer-to-peer message delivery and the future integration with LEAP sounds quite promising.