rewrite of email page.

2 files changed, 69 insertions, 22 deletions

diff --git a/pages/services/email/en.haml b/pages/services/email/en.haml
deleted file mode 100644
index 4c79e8e..0000000
--- a/pages/services/email/en.haml
+++ /dev/null
@@ -1,22 +0,0 @@
-:textile
-
-  h1(first). Email and its discontents
-
-  !>/img/gif/animated-gifs-email-007.gif!
-
-  Email continues to be a vital communication tool. Unfortunately, the email protocol was designed in the Paleocene era of the internet and is unable to cope with the security threats common today.
-
-  For example, there is no standard for ensuring secure relay between mail providers (StartTLS is easily thwarted) and email encryption technology (PGP and S/MIME) has proven to be too cumbersome to reach beyond a very small audience. Even PGP and S/MIME, however, offer no protection against association mapping since the email headers remain unencrypted. Finally, email providers have an unfortunate habit of handing over users' data to non-democratic regimes.
-
-  h1. Email for the modern era
-
-  The LEAP approach to email is to support communication with the legacy email infrastructure while also adding optional layers to the protocol that bring email more in line with modern security practices.
-
-  *Opportunistic Content Encryption:* Whenever possible, all outgoing email will be encrypted to all the recipients. Encryption keys will be automatically discovered and verified using the #{link 'LEAP Identity' => 'nicknym'} service.
-
-  *Client-encrypted Mail Storage:* Incoming clear-text mail will get encrypted to the user's public key, stored in their cloud storage space, and sync'ed locally for direct access by a mail client.
-
-  *Secure Routing:* When possible, if both recipient and sender are using #{link 'LEAP Secure Routing' => 'routing'}, then neither the sender's service provider nor the recipient's service provider will be able to map the pattern of communication between sender and recipient.
-
-  *Required TLS:* We will develop a protocol for discovery of mail relays that support TLS as a requirement. In cases where the other server supports it, this will protect the email from social network analysis when in transit from server to server. It is important to have required TLS, and not just include support for StartTLS, because StartTLS can be easily downgraded to cleartext by an attacker.
-
diff --git a/pages/services/email/en.md b/pages/services/email/en.md
new file mode 100644
index 0000000..e333c56
--- /dev/null
+++ b/pages/services/email/en.md
@@ -0,0 +1,69 @@
+@title = "Email and its discontents"
+@nav_title = "Email"
+
+<img src="/img/gif/animated-gifs-email-007.gif" align="right" />
+
+Email continues to be a vital communication tool. Unfortunately, the email protocol was designed in the Paleocene era of the internet and is unable to cope with the security threats common today.
+
+For example, there is no standard for ensuring secure relay between mail providers (StartTLS is easily thwarted) and message encryption technology (OpenPGP and S/MIME) has proven to be too cumbersome to reach beyond a very small audience. Even these existing methods, however, offer no protection against meta-data analysis since the email headers remain unencrypted. Finally, email providers have an unfortunate habit of handing over users' data to non-democratic regimes.
+
+## Email for the modern era
+
+The LEAP approach to email is to support communication with the legacy email infrastructure while also adding optional layers to the protocol that bring email more in line with modern security practices. This strategy allows for a gradual transition from existing email to secure email. In the short term, there are immediate benefits to a user's security when they adopt LEAP email. In the long term, as more service providers adopt the LEAP platform, email among these service providers gains even more protection.
+
+Above all else, our focus is on creating a user experience that is as easy and troublefree as possible while still ensuring a very high level of security.
+
+### How it works
+
+When a service provider runs the LEAP platform, their users can access secure email in three steps:
+
+1. Download and install the Bitmask application.
+2. Run the Bitmask application to log in or sign up with the service provider.
+3. Configure the user's mail client to connect to the local Bitmask application. In case of the Thunderbird email client, this configuration is semi-automatic.
+
+The Bitmask application acts as a "proxy" between the service provider and the mail client. It handles all the encryption and data synchronization.
+
+### Immediate benefits of using LEAP email
+
+Email features include:
+
+* LEAP encrypted email is easy to use while still being backward compatible with the existing OpenPGP protocol for secure email.
+* All incoming email is automatically encrypted before being stored, so only you can read it (including meta-data).
+* Whenever possible, outgoing email is automatically encrypted so that only the recipients can read it (if a valid OpenPGP public keys can be discovered for the recipients). This encryption takes place on the user's device.
+* OpenPGP public keys are #{link 'automatically discovered and validated' => 'nicknym'}, allowing you to have confidence your communication is confidential and with the correct person (without the headache of typical key signing).
+* The user does not need to worry about key management. Their keys are always kept up-to-date on every device.
+* The user is able to use any email client of their choice (e.g. Thunderbird, Apple Mail, Outlook).
+* When disconnected from the internet, the user can still interact with a local copy of all their mail. When the internet connect is available again, all their changes will get synchronized with the server storage and to their other devices.
+
+General security features of the Bitmask application include:
+
+* All stored data is encrypted, including local data and cloud backups. This encryption always #{link "takes place on the user's device" => 'soledad'}, so the service provider cannot read your stored data.
+* Although you specify a username and password to login, your #{link 'password is never communicated to the provider' => 'https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol'}.
+* If you download the Bitmask application from #{link 'downloads.leap.se' => 'https://downloads.leap.se'}, your service provider cannot add a backdoor to compromise your security.
+* The Bitmask application is always kept up to date with the latest security patches (coming soon).
+
+### Long term benefits when two LEAP compatible providers talk to one another
+
+One of the fundamental problems with email is that the meta-data routing information is exposed as cleartext. Encrypting a message with OpenPGP or S/MIME does nothing to help with this.
+
+The email protocol does support an optional method of securely relaying messages using TLS to encrypt the connection. This method, called StartTLS, is easily undermined by attackers and there is no good way for email providers to validate the authenticity of other servers (without relying on the problematic CA certificate authority system).
+
+For now, LEAP addresses these problems with two enhancements when two compatible providers are talking to one another:
+
+* When relaying email, server keys are discovered and validated using DNSSEC/DANE.
+* For these providers, TLS with validated keys becomes required for all communication.
+
+This approach is effective against external network observers, but does not protect the meta-data from the service providers themselves. Also, it does not, by itself, protect against more advanced attacks involving timing and traffic analysis.
+
+In the long term, we plan to adopt one of several different schemes for #{link 'securely routing meta-data' => 'routing'}.
+
+## Limitations
+
+* You cannot use LEAP email from a web browser. It requires the Bitmask application to run.
+* The Bitmask application currently requires a compatible provider. We have plans in the future to semi-support commercial providers like gmail. This would provide the user with much less protection than when they use a LEAP provider, but will still greatly enhance their email security.
+* Because all data is synced, if a user has one of their devices compromised, then the attacker has access to all their data. This is obvious, but worth mentioning.
+* The user must keep a complete copy of their entire email storage on every device they use. In the future, we plan to support partial syncing for mobile devices.
+* We do not plan to support key revocation. Instead, we plan to migrate to shorter and shorter lived keys, as practical.
+* With the current implementation, a compromised or nefarious service provider can still gather incoming messages that are not encrypted and meta-data routing information. As more users and providers adopt secure email, many of these problems will go away.
+
+For more details, please see #{link 'known limitations' => 'limitations'}.
\ No newline at end of file