moved pages from app/view/pages to pages

4 files changed, 132 insertions, 0 deletions

diff --git a/pages/services/chat/en.haml b/pages/services/chat/en.haml
new file mode 100644
index 0000000..e27dcf3
--- /dev/null
+++ b/pages/services/chat/en.haml
@@ -0,0 +1,27 @@
+:textile
+
+  h1(first). Small messages, big hearts
+
+  Short messages and chat have proven to be indispensable tools for mobilization for activists around the world, particularly on mobile devices. Unfortunately, very few options exist that are both secure and easy to use. Even solutions that people rely on for high security, such as OTR, are vulnerable to association mapping and do not work with asynchronous communication (where both parties do not need to be online at the same time).
+
+  Experimental secure peer-to-peer messaging does exist, but adoption rates have been low because these protocols are incompatible with existing message networks and typically require both parties to be running the application at the same time. When asynchronous messaging is supported, it is slow and lacks the reliability users have come to rely on.
+
+  h1. Secure and federated chat
+
+  The LEAP approach to instant message and chat is to build on stable, federated chat technologies and add support for greatly enhanced security. The goal is to allow users to communicate with existing messaging networks, as well as enjoy a higher degree of protection when communicating with networks that support the enhanced protocols.
+
+  h3. Open protocols, improved
+
+  The primary open protocol for chat is called XMPP. It provides a good foundation for federated chat, but it is sorely lacking key security safeguards and standards for asynchronous messaging. Our additions to XMPP address these limitations:
+
+  *Secure identity:*
+
+  *Client-encrypted cloud data:* Chat applications work much better with a cloud component. For example, this allows you to have the same roster, chat history, and account information on all your clients. There is currently no provision in XMPP for client-encrypting this data. We will create one, and implement it on the client and server.
+
+  *Asynchronous messages:* Currently, patchy adoption of different methods of handling offline messaging result in confusing situations where you often have no indication if a message will be delivered to its recipient or not.
+
+  *Anonymous rosters:* XMPP requires that the server is aware of your list of contacts. This part cannot be client-encrypted, but it can be made highly resistant to association mapping by adding one-time aliases. If a friend on another server wants to add me to their roster, I will give them a unique alias for my actual chat address. Only my server will know that the alias belongs to me.
+
+  *Secure groups:*
+
+  *Required TLS:* As with email, there is no mechanism in XMPP for requiring TLS (the server can advertise that TLS is required, but this is easily thwarted by an attacker). We will add one.
diff --git a/pages/services/eip/en.haml b/pages/services/eip/en.haml
new file mode 100644
index 0000000..538deca
--- /dev/null
+++ b/pages/services/eip/en.haml
@@ -0,0 +1,62 @@
+:textile
+
+  h1(first). Encrypted Internet Proxy (EIP)
+
+  Around the world VPN and Tor technologies are essentially for protecting network traffic, bypass network monitoring, and circumventing censorship. Unfortunately, both VPN and Tor can be very difficult to set up and to configure correctly in a manner that actually provides high security.
+
+  The LEAP platform includes an Encrypted Internet Proxy (EIP) service that is hassle-free, automatically self-configuring, and provides an enhanced level of security. Initially, this EIP service will be built using OpenVPN, but we may include the option of using Tor as an alternate transport in the future.
+
+  h1. Features
+
+  LEAP's EIP client will:
+
+  * Automatically self-configure.
+  * Prevent unencrypted network traffic while the EIP is down (by default).
+  * Automatically starts on startup (by default).
+  * Prevent security leaks caused by problems with DNS, IPv6, and other common misconfigurations.
+
+  h1. Benefits
+
+  Traditional VPN or Tor provide a user with considerable benefit. These technologies allow a user to bypass network-based censorship and surveillance by the local ISP. They also aid in safe browsing by preventing web sites from capturing a user’s IP address, and thus geographic location. In the case of VPN, using a VPN can also give you a secure connection to a DNS server.
+
+  LEAP's Encrypted Internet Proxy provides additional benefits when paired with other communication services.
+
+  Current vulnerabilities in TLS and the x.509 certificate authority system make it nearly impossible to establish a secure internet connection with a website or a service provider. New initiatives, like Convergence and Sovereign Keys, hold long-term potential for solving this problem, but are either not available today or work only in limited circumstances.
+
+  By connecting to the internet through an EIP that is part of the LEAP platform, a user will be able to effectively establish out-of-band validation of their network encryption with the service provider.
+
+  h1. Future plans
+
+  h2. Tor
+
+  In the long run, we hope to offer both OpenVPN and Tor as possible transports for the EIP service.
+
+  Tor is an incredibly important project, but it makes different trade-offs than traditional VPN service does. For example, Tor affords the user greater anonymity, but at the cost of slower speed. The user should be able to make this choice. Currently, Tor does not include support UDP traffic, but when it does, we hope to allow the user to substitute Tor for OpenVPN via the LEAP client.
+
+  In the short run, our goal is to make all the LEAP services also work under well under Tor (as Tor hidden services), should a user decide to use Tor instead of LEAP's EIP.
+
+  h2. Darknet
+
+  We plan to eventually create a system to allow service providers who are deploying the LEAP platform to easily establish IPSec encryption of all network traffic with other service providers.
+
+  This will provide nearly complete end-to-end encryption of all the network traffic sent from one user to any other user. Each service provider, however, will still have cleartext access to the traffic of their users. The LEAP "darknet" protects against outside threats, not a compromised service provider.
+
+  h2. Anonymous Client Certificates
+
+  The LEAP platform is designed to de-couple a user's identity from the client certificate they use to connect to the EIP. The service provider will not know what user corresponds to which EIP network connection.
+
+  However, a compromised or nefarious provider could modify the LEAP platform to record a correspondence between username and EIP certificate. In the future, we would like to make this impossible.
+
+  Unfortunately, this is not an easy problem. The problem essentially boils down to this:
+
+  * Time 1: User authenticates with the provider to prove they are a valid user and receives a token.
+  * Time 2: User redeems this token to get services in a way that does not reveal their identity.
+
+  This is theoretically possible using various #{link_to 'zero-knowledge proofs', 'https://en.wikipedia.org/wiki/Zero_knowledge_proof'}. In the long run, we hope to support this capability.
+
+
+  h2. Friend in the middle
+
+  We plan to explore the feasibility of adding a "friend in the middle" to the EIP service. The idea is that the service provider can filter traffic in a way that benefits the privacy and security of the user. For example, the EIP gateway could filter advertising or third party behavioral tracking companies. More ambitiously, the friend in the middle could terminate TLS connections with compromised certificates using a server-side implementation of something like #{link_to 'convergence', 'http://convergence.io/'}.
+
+
diff --git a/pages/services/email/en.haml b/pages/services/email/en.haml
new file mode 100644
index 0000000..af2eb67
--- /dev/null
+++ b/pages/services/email/en.haml
@@ -0,0 +1,22 @@
+: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' => 'identity'} 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/en.haml b/pages/services/en.haml
new file mode 100644
index 0000000..94f8a01
--- /dev/null
+++ b/pages/services/en.haml
@@ -0,0 +1,21 @@
+%h1.first User Services
+
+%p LEAP's multi-year plan to secure everyday communication breaks down into discrete services, to be rolled out one at a time. When we introduce a new service, integrated support will be added to both the user-facing #{link 'client'} and the server-side #{link 'platform'}. All communication content will be client-side encrypted, and as much of the metadata as possible. Most importantly, all LEAP services will be based on our plan for #{link 'federated secure identity' => 'identity'} and #{link 'unmappable routing' => 'routing'}.
+
+%h2 Roadmap
+
+%h3 Phase 1 - Encrypted Internet Proxy
+
+Our first service will be #{link 'eip'}, providing circumvention, location anonymization, and traffic encryption that is hassle-free, automatically self-configuring, and has an enhanced level of security.
+
+%h3 Phase 2 - Email
+
+Our second service will be #{link 'client-encrypted email' => 'email'}. 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. Encryption and decryption will take place transparently via local IMAP and SMTP proxies, allowing the user their choice of mail client.
+
+%h3 Phase 3 - Chat
+
+Our third service will be #{link 'secure chat' => 'chat'}. We plan to build on top of XMPP, but modify the protocol to allow for higher security and greater usability (while being able to fall back to traditional XMPP when necessary).
+
+%h3 Phases 4, 5, 6
+
+In the long term, we plan to develop and deploy client-encrypted file sync/backup, voice communication, and document collaboration.