added platform/services documentation, removed /services (/services text is better on bitmask.net anyway).

4 files changed, 0 insertions, 211 deletions

diff --git a/pages/services/technology/client-app/en.haml b/pages/services/technology/client-app/en.haml
deleted file mode 100644
index 07dfab8..0000000
--- a/pages/services/technology/client-app/en.haml
+++ /dev/null
@@ -1,109 +0,0 @@
-- @title = "Client Application"
-
-%h2 Client-server integration
-
-%p The LEAP Client will run on the user's device and grant the user access to the #{link 'cloud-based services' => 'services'} of the #{link 'LEAP Platform' => 'platform'}. As new services are added to the LEAP Platform, the LEAP Client will be developed in tandem to work with these services.
-
-%h2 Client crypto, cloud assistance
-
-%p For users of cloud-based communication services, there is only one approach that can achieve a reasonable level of security: client-side encryption.
-
-%p The model proposed here is neither peer-to-peer nor pure cloud; rather, it is a hybrid designed to make a client-encrypted cloud function more smoothly. Some client-encrypted communication services do not require cooperation on the part of the cloud provider, like file backup, for example.
-
-%p Most other services, however, will only work if the server-side software is designed to work with client-encrypted data. A hybrid model shares the advantages that a pure cloud model has over peer-to-peer: the service is more reliable, is not subject to data loss, works the same on all devices, is faster, and is much easier to use.
-
--# insert a chart here...
-
-  plain-cloud
-  cloud with no encryption or server-side encryption only
-  pretty much all cloud services fall into this category.
-    Twitter
-    Dropbox
-
-  crypto-cloud
-  cloud with layered client-side encryption
-  some enterprising users have bolted encryption on top of the cloud based services they use. the cloud services are not designed to work with client-side encryption, the the operation is typically awkward, but it can work.
-    Facebook Chat + OTR
-    Amazon S3 + Duplicity
-    gmail + FireGPG
-
-  integrated cloud
-  cloud with integrated client-encryption
-
-  cloud-side encryption is not really any better than cloud without encryption, so it is not listed in this table.
-
-  Except in the case of EIP, all LEAP services are designed to place little or no trust in the service provider.
-
-%h2 Crypto for mere mortals
-
-%p After security, our primary goal with the client is to make it as easy to use as possible. There are several ways we are approaching the problem of usability:
-
-%p
-  %b Auto-configuration —
-  There are a lot of powerful tools for secure communication out there, and most of them are incredibly difficult to set up and configure correctly in a way that ensures you don't compromise your security. Our goal with the LEAP client is to tightly couple the client with the services so that the client will be able to configure itself correctly without user intervention.
-
-%p
-  %b The best UI is no UI —
-  We plan to make the interface for the client as minimal as possible. For EIP, the client will do everything it can to troubleshoot on its own to get a stable encrypted tunnel established. For the messaging services like email and chat, the LEAP Client is a proxy that handles encryption/decryption locally on the user's device, allowing the user to continue to use whatever client software they are comfortable with.
-
-%h2 Software updates
-
-%p We want service providers in repressive and hostile contexts to still be able to adopt the LEAP Platform. In order to protect the service provider, the LEAP Client will accept security patches and code upgrades from the LEAP non-profit organization, not from the service provider.
-
-%p Every LEAP Client will include the public key used to sign updates. When a new client version is available, and the provider supports the API version of the new client, then the new code will be download from LEAP and verified using the keys included with the first download. Alternately, on platforms with good package management, like Debian or Redhat variants of GNU/Linux, updates to the LEAP Client will go through the normal platform specific channels.
-
-%p This system still leaves open the problem of how to distribute the initial client that is first installed. This is a difficult problem, and one which we hope to work on in the future.
-
-%h2 Cross platform
-
-%p Initially, the LEAP Client will support Windows, Mac, and Linux. We are committed to extending support to mobile devices once the desktop version is stable (although currently, Apple's terms of service for the appstore prevent GPL licensed apps, so until this changes we can't distribute on iOS). The mobile version of the LEAP Client will lag behind the desktop version, but our goal is to provide eventual feature parity.
-
-%p Recent advancements in Javascript and HTML have begun to blur the distinction between client applications that a user installs and client applications that run in a web browser environment. Although there are numerous projects actively working on client-encrypted communication that runs inside the browser, such in-browser efforts are currently crippled by a lack of standardized and trusted cryptographic primitives inside the browser and are so vulnerable to a number of common attacks. We plan to work closely with the new W3C Web Cryptography Working Group in order maximize the deployment of client-encrypted applications, both in currently safe clients as well as more experimental native applications in the browser.
-
--# %h2 Branded and unbranded
-
-  %p The LEAP client will come in two flavors: branded and unbranded.
-
-  %p
-    %b The branded client
-    will be customized with the name and graphics of the service provider using the LEAP Platform. It will be pre-configured to work the with service provider.
-
-  %p
-    %b The unbranded client
-    will work with any service provider that runs the LEAP platform. When the user first runs the unbranded client, they will be presented with a list of available service providers and the option to type in the name of a provider that is not in the list. Once the user picks a provider, the client will download a file from the provider that defines the capabilities of the provider and allows the client to autoconfigure itself for use with that provider.
-
-
-%h2 Trust issues
-
-%p As much as possible, our goal is to design a system that requires very little trust of the service provider. However, there are a few areas where the user will need to trust either LEAP or their service provider:
-
-%ul
-  %li
-    %b Encrypted Internet Proxy:
-    If the user chooses to enable the EIP service, then all their internet traffic will pass through the service provider. A nefarious or compromised provider could monitor this traffic.
-  -# %li
-    %b Notary Keys:
-    The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'nicknym'}. If a supermajority of these notaries conspire or get hacked then the security of the identity system will be compromised.
-  %li
-    %b Client Software:
-    Unless the user builds the client software from the source code, the user will trust LEAP Encryption Access Project for the application builds and code updates.
-
--# %h2 Secrets recovery
-
-  %p What should LEAP do when a user has lost their secrets (either human-memorizable or private keys)? There is no right answer for every situation.
-
-  %p
-    %b No recovery:
-    In some situations, it makes the most sense to simply do without the ability to recover lost secrets.
-
-  %p
-    %b Recovery document:
-    The LEAP client will give the user the option to export a text file with a complete copy of their private keys and authorization information, either password protected or not. This "recovery document" can be printed or saved electronically as the user sees fit. If the user needs to recover their data, they can load this recover document into any LEAP client. The user can also type the recovery document in manually, although it will be long and very painful to copy manually.
-
-  %p
-    %b Cloud recovery:
-    The user is presented with a small ten by ten grid of digits (with QR code) that can be printed. To recover, the user types in these 100 digits into any LEAP client (or scans the QR code using a mobile device). This method is like manual recovery, but it is much easier to type in manually. To achieve this, the full recovery document is encrypted and then stored on the server. The user is then presented with a small code that serves as an encoded index and passphrase to retrieve the full recovery document. This method is desirable when the user does not want to be responsible for storing an electronic copy of the full recovery document. It will also serve as an easy way to set up the LEAP client on a mobile device. The disadvantage of this method is that there is potential for attack on the cloud-stored recovery document.
-
-  %p
-    %b Email recovery:
-    The novice user should have the option to recover their secret by a simple email verification. This is less horrible than it sounds. It will work like this: when the user first installs the client, they are given the option to entrust one or more email addresses with the ability to unlock their recovery document. Additionally, they must decide how many of these email addresses must confirm the secret recovery in order for it to succeed. The LEAP client then registers these emails with a third party secret escrow service in such a way that no single party has access to the full secret (unless there is just one email). When the user triggers the reset process, the LEAP client contacts the escrow service and gives it a token to request the release of the recovery document. Once the email accounts have replied to the escrow service with confirmation of assent to the secret recovery, the LEAP client can retrieve the lost secret from the escrow service. This is a complicated process, but from the user's perspective they just hit a "recover" button and then wait for people to reply to the confirmation emails. This is a potential long term enhancement.
diff --git a/pages/services/technology/critiques/en.text b/pages/services/technology/critiques/en.text
deleted file mode 100644
index acde975..0000000
--- a/pages/services/technology/critiques/en.text
+++ /dev/null
@@ -1,56 +0,0 @@
-@title = 'Critiques'
-
-h2. Isn't LEAP too ambitious?
-
-Yes. However, someone needs to be working on a long term plan to add real security and usability to federated messaging architectures. It will not be easy, but we think it is possible.
-
-h2. Isn't LEAP just like FreedomBox?
-
-LEAP and FreedomBox share a similar goal of ensuring that everyone has the right to communicate securely and without censorship. However, the projects use different strategies for achieving this goal.
-
-* *FreedomBox:* Empower every user to control the hardware on which all their data is stored. Users become their own service providers, running their own hardware.
-* *LEAP:* Allow service providers to deploy a cloud-based infrastructure that can scale and is easily maintained. In addition to the performance and usability found in traditional cloud services, LEAP services are also designed to bring a very high level of security to everyday users.
-
-FreedomBox is an important project. It faces, however, some significant hurdles. Most users demand high availability, but current technology does not allow for hardware or software that is self healing. If it did, sysadmins would be out of work. Things go wrong all the time. Take, for example, email: it is very common for an email server to get spam-bombed, or added to a blacklist, or any number of other problems that require manual intervention by a system administrator to fix. Also, most ISPs block the port needed for  email rely.
-
-In the long run, FreedomBox has a lot of potential. But for the foreseeable future, we think it is important to also pursue the LEAP strategy.
-
-h2. We should not encourage users to store any data in the cloud, encrypted or not
-
-Even the best encryption is no guarantee of confidentiality; data in the cloud always has the potential to be decrypted by a determined attacker.
-
-The entire issue boils down to a matter of degree. Although there is no necessary trade off between security and convenience, you can usually achieve a higher level of security in any system by sacrificing some convenience. But what level of protection and convenience is appropriate for a particular user?
-
-There are very few people for whom client-encrypted data stored in the cloud will be the weakest link in the confidentiality of their communication and stored data. Most likely, there will be many aspects of their communication that are much more attractive targets to a determined adversary.
-
-If a person has a threat model that includes an adversary with the resources to both acquire the user's cloud data and to decrypt it, then there is little that LEAP or any other third party can do for them. They will need to become highly proficient at managing and protecting all their own data.
-
-There are many tools and projects out there to help a user do this. LEAP is designed for a different audience, one not adequately addressed by existing technology: people who want high security but don't have the capacity to become highly skilled in self-managing their encryption. There is room--and need--for both approaches, and it is likely that the amount of people who want high security but do not have the time or skills to adequately self-manage their own environment is already large and increasingly rapidly.
-
-h2. If you make your system architecture public, then you have given adversaries a blueprint to attack you
-
-This is, of course, similar to the arguments about the security of FLOSS. Openness can indeed lead to attacks, but more eyes leads to better security.
-
-In the case of an entire service provider infrastructure, however, it could be argued that things are different. We are not talking about a single piece of software, but the whole integration across many servers and services. A related critique is the potential problem of monoculture: if LEAP is successful, then a high percentage of the secure service providers will be using systems with the same vulnerabilities.
-
-Monoculture and openness are both interesting issues that could pose problems for the future. We can only be diligent in assessing LEAP once it is deployed by a variety of organizations. With enough flexibility in configuration, it may be that each LEAP deployment is sufficiently distinct from the others to mitigate these concerns.
-
-h2. Users will not be willing to download a custom client
-
-This will indeed be the case for a large number of potential users. Because meaningful levels of security cannot be achieved using current technology without a custom client, our hope is that a critical mass of users can be induced to use one. There are two parts to this inducement: increasing awareness as to why an extra step to ensure security is worthwhile, and decreasing the difficulty in actually taking this step. With sufficient education and an improved user experience, many users should be willing to install a custom client.
-
-On the other hand, rapid developments in Javascript and web browser technology have raised the possibility of running advanced client applications within the browser itself. In this case, a user would not have to install any additional software. However, in-browser crypto is still an area of active research but is currently not safe for deployment, with some areas still to be worked out (like sufficient entropy). LEAP does not depend upon the presence of cryptography in the browser, but would benefit from this should it become viable. The lead W3C employee who began the standardization of Javascript Cryptography is on the board of LEAP, and he will liaise tightly with LEAP as the work matures.
-
-h2. Users who need security often don't have their own device or access to the internet
-
-This is absolutely true. The digital divide is alive and well, and LEAP does nothing to bridge the gap between the technological haves and have-nots. However, in the long run, IP-based communication--dependent upon advanced devices such as smart phones--is likely to replace most other forms of communication. The cost of such IP-based communication devices and their connectivity is declining rapidly. It behooves us to lay the groundwork now for a secure IP-based communication infrastructure, both for the people who currently rely on the internet and for the next billion who will gain access to the internet in the near future.
-
-h2. Client encryption is excessive for most people
-
-The argument against client encryption is something like this: a secure connection is good enough, so long as the service provider is located in a country with adequate legal protection and without repressive laws.
-
-There are many reasons why users should be put in control of their data and should not be made to rely on a third party to safeguard it. Third parties have proven to be highly undeserving of trust--They might close shop, bow to pressure from local government, become compromised by external attacks, or accidentally leak sensitive data due to carelessness.
-
-Our goal is to make secure communication the default for a critical mass of users worldwide. A vital part of this strategy is cooperation with ISPs and service providers who speak the local language of their users and who are attuned to the needs of a particular context. These local service providers don't have the luxury of determining which government's jurisdiction they fall under. However, so long as encryption technology itself is not outlawed, local providers using the LEAP platform will be able to provide a high level of security for their users.
-
-By requiring client encryption for all services, LEAP also helps to mitigate against the myriad vulnerabilities inherent with most devices. While the LEAP client cannot defend against keyloggers, malware, or penetration of the host OS, it can ensure that all the LEAP cloud data synced by the device is stored in an encrypted format.
\ No newline at end of file
diff --git a/pages/services/technology/en.haml b/pages/services/technology/en.haml
deleted file mode 100644
index 2ca579e..0000000
--- a/pages/services/technology/en.haml
+++ /dev/null
@@ -1,30 +0,0 @@
-%h1.first The Technology of LEAP
-
-%p The long term LEAP plan consists of a set of #{link 'communication services' => 'services'} built upon the core technologies detailed here.
-
-%p
-  %b #{link 'Information Security' => 'infosec'}:
-  An analysis of different approaches to information security and how the LEAP strategy compares.
-
-%p
-  %b #{link 'Provider Platform' => 'platform'}:
-  Turn-key automation for communication service providers.
-
-%p
-  %b #{link 'LEAP Client' => 'client'}:
-  Easy to use client for secure communication.
-
-%p
-  %b #{link 'Nicknym' => 'nicknym'}:
-  A system for automatic discovery and validation of cryptographic identity.
-
-%p
-  %b #{link 'Map Resistant Routing' => 'routing'}:
-  A system for message routing that is resistant to association mapping.
-
-%p
-  %b #{link 'Critiques' => 'critiques'}:
-  Anticipated critiques of the LEAP architecture.
-
-
--# https://guardianproject.info/wiki/Always_Secure_Messaging
\ No newline at end of file
diff --git a/pages/services/technology/platform/en.haml b/pages/services/technology/platform/en.haml
deleted file mode 100644
index 44bbce9..0000000
--- a/pages/services/technology/platform/en.haml
+++ /dev/null
@@ -1,16 +0,0 @@
-%h1.first git clone leap-platform
-
-%p The LEAP Provider Platform is the server-side part of LEAP that is run by service providers. It consists of a set of complementary packages and recipes to automate the maintenance of LEAP services in a hardened GNU/Linux environment. Our goal is to make it painless for service providers and ISPs to deploy a secure communications platform.
-
-%p The LEAP Platform is essentially a git repository of puppet recipes, with a few scripts to help with bootstrapping and deployment. A service provider who wants to deploy LEAP services will clone or fork this repository, edit the main configuration file to specify which services should run on which hosts, and run scripts to deploy this configuration.
-
-%h1 More providers, please
-
-%p We believe that the best way to defend the right to whisper is to bring encryption technology into wider adoption. Despite growing awareness of the importance of communication security, users who attempt to adopt better practices still have few places they can turn.
-
-%p Most people think of lack of security as a problem of insufficient demand. We think that there are actually enough people out there who would like to use communication tools with higher security but who face severe problems of supply.
-
-%p The goal of LEAP is to meet this demand with tools that are usable and secure. But the LEAP architecture is necessarily a #{link 'federated' => 'infosec'} one, and the enhanced security it provides is only possible once there is a health ecosystem of service providers using the LEAP platform.
-
-%p One way to get more service providers is to make the people who run them happy. With the LEAP Platform, we want to reduce the amount of bullshit work. We are not "dumbing down" the work it takes to run a service provider. Rather, our goal is to allow talented sysadmins to focus on the parts that really matter and spend less time wrestling with the frustrating and mundane aspects of system administration.
-