summaryrefslogtreecommitdiff
path: root/pages
diff options
context:
space:
mode:
authorelijah <elijah@riseup.net>2013-02-20 00:40:25 -0800
committerelijah <elijah@riseup.net>2013-02-20 00:40:25 -0800
commit6fb2358c8f41491dd3c4848ac5e353eac7dab411 (patch)
treedc4ed12c24563469036e2257918c61140bf413ce /pages
parent10038e58efe3aa3c1725e2b5b0a0b7b2ce060df7 (diff)
minor page edits.
Diffstat (limited to 'pages')
-rw-r--r--pages/about-us/jobs/en.haml4
-rw-r--r--pages/about-us/news/en.haml2
-rw-r--r--pages/menu.txt1
-rw-r--r--pages/services/technology/client-app/en.haml (renamed from pages/services/technology/client/en.haml)68
-rw-r--r--pages/services/technology/nickid/en.md3
5 files changed, 41 insertions, 37 deletions
diff --git a/pages/about-us/jobs/en.haml b/pages/about-us/jobs/en.haml
index 80a33ed..1b61102 100644
--- a/pages/about-us/jobs/en.haml
+++ b/pages/about-us/jobs/en.haml
@@ -13,9 +13,9 @@
* Everything we do is licensed as free software (GPL whenever possible).
* People of color, women, and queer people are strongly encouraged to apply.
- Contact: mcnair@leap.se
+ h1. Open Positions
- Currently, we have no open positions, but we would love to hear from you anyway.
+ Currently, we have no open positions, but we would love to hear from you anyway. Please contact mcnair@leap.se
-#
h1. Open Positions
diff --git a/pages/about-us/news/en.haml b/pages/about-us/news/en.haml
index 87eaac5..6478a74 100644
--- a/pages/about-us/news/en.haml
+++ b/pages/about-us/news/en.haml
@@ -1,3 +1,3 @@
- @layout = 'blog'
- @path_prefix = '2012'
-= recent_blog_summaries('about-us/news') \ No newline at end of file
+= recent_blog_summaries('about-us/news')
diff --git a/pages/menu.txt b/pages/menu.txt
index ffb3971..426c514 100644
--- a/pages/menu.txt
+++ b/pages/menu.txt
@@ -5,6 +5,7 @@ services
chat
technology
infosec
+ client-app
nickid
routing
critiques
diff --git a/pages/services/technology/client/en.haml b/pages/services/technology/client-app/en.haml
index 0bc365e..995ec40 100644
--- a/pages/services/technology/client/en.haml
+++ b/pages/services/technology/client-app/en.haml
@@ -1,12 +1,14 @@
-%h1.first Client-server integration
+- @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.
-%h1 Client crypto, cloud assistance
+%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. For example, if you simply want to backup files, you just need a program like Duplicity which can be pointed at the storage provider of your choice.
+%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.
@@ -32,7 +34,7 @@
Except in the case of EIP, all LEAP services are designed to place little or no trust in the service provider.
-%h1 Crypto for mere mortals
+%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:
@@ -44,7 +46,7 @@
%b The best UI is no UI &mdash;
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.
-%h1 Software updates
+%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.
@@ -52,58 +54,56 @@
%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.
-%h1 Cross platform
+%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.
-%h1 Branded and unbranded
+-# %h2 Branded and unbranded
-%p The LEAP client will come in two flavors: 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 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.
+ %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.
-%h1 Trust issues
+%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 passes through the service provider. A nefarious provider could sniff this traffic, if it was using a cleartext protocol like plain HTTP.
- %li
+ 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' => 'nickid'}. 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 client builds and code updates.
-
+ 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
-%h1 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 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 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 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 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.
+ %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/nickid/en.md b/pages/services/technology/nickid/en.md
index 817f46e..f763af1 100644
--- a/pages/services/technology/nickid/en.md
+++ b/pages/services/technology/nickid/en.md
@@ -1,3 +1,6 @@
+@title = 'NickID'
+@toc = true
+
The sad, sorry state of cryptographic identity
==============================