moved pages around.

4 files changed, 0 insertions, 459 deletions

diff --git a/pages/services/technology/infosec/en.haml b/pages/services/technology/infosec/en.haml
deleted file mode 100644
index 8fd1efe..0000000
--- a/pages/services/technology/infosec/en.haml
+++ /dev/null
@@ -1,101 +0,0 @@
-= render_local_template 'table-style'
-
-%h1.first You can't have it all
-
-%p Every messaging architecture makes certain design choices that privilege one property of information security over another. Although there is no intrinsically necessary trade off among different information security properties, when we examine the technical limitations of actual implementations we see clearly that existing architectures are structurally biased toward certain properties and against others.
-
-%h1 A fancy table
-
-%p This table provides a rough comparison of the choices made by common messaging architectures. See #{link 'below for details' => '#table-notes'} regarding the column and row headings.
-
-.p
-  %b Table 1. Information security of common messaging architectures
-  = render_local_template 'table', :table_type => :big
-
-%p Reasonable people may disagree: this table represents one defensible assessment of the various architecture categories. Many people would adjust one or two cells, but on the whole we believe this table is a fair and accurate comparison.
-
-%p In table 2 we see a simplified representation that highlights the relative differences between the encrypted architectures:
-
-.p
-  %b Table 2. Relative trade-offs of encrypted messaging architectures
-  = render_local_template 'table', :table_type => :small
-
-%p Relatively better is not necessarily good. For example, federated and peer-to-peer models have better authenticity than silo models, but usability problems make it so that their authenticity is often poor in practice.
-
-%h1 The LEAP strategy (you can have it all)
-
-%p In a nutshell, the LEAP strategy is this: take a federated architecture and improve the authenticity, unmappability, and usability. In table form, that looks like this:
-
-.p
-  %b Table 3. The LEAP strategy for improving federated architectures
-  = render_local_template 'table', :table_type => :leap
-
-%p Why this focus on authenticity, unmappability, and usability?
-
-%p First, there is a lot of room for improvement. We believe that there is actually no particular structural reason why these properties are so low in existing federated encrypted architectures.
-
-%p Second, these property are extremely important and yet are typically given low priority or are ignored completely.
-
-%ul
-  %li
-    %b Authenticity:
-    Message security rests entirely on a foundation of authenticity. Without proper validation of encryption keys, you cannot be assured of confidentiality or integrity. Unfortunately, current system of establishing message authenticity are so difficult to use that most users simply ignore this step. LEAP will address these problems with a system of #{link 'strong and automatic identity validation' => 'nicknym'}.
-  %li
-    %b Usability:
-    There are plenty of high security tools that are nearly impossible for the common user to use correctly. If the tool is too difficult, it will not be widely adopted and will likely be used incorrectly by those who do adopt it. LEAP with address these problems with the #{link 'LEAP client' => 'client'} that is tightly coupled with the server-side software and is autoconfiguring.
-  %li
-    %b Unmappability:
-    Recent advances in social network analysis and the greatly expanded of ability state and corporate actors to gather social graph information have made unmappability an urgent requirement for any architecture that seeks to address the surveillance situation we face today. LEAP will address these problems with our proposal for #{link 'graph resistant routing' => 'routing'}.
-
-%p Improvement in these areas will come at a price. Although LEAP communication tools will be backward compatible with existing federated standards, a user of the LEAP platform will not have the same degree of choice in client software and provider as does a user of a traditional federated system. Our goal is to actively help providers adopt the LEAP platform, in order to give users more options in the long run.
-
-%h1#table-notes Decoding the table
-
-%h2 Communication architectures (columns)
-
-(to be written)
-
-%h2 Aspects of information security (rows)
-
-%p Classical information security consists of a trio of properties: confidentiality, integrity, availability. To this list, others have added authenticity, control, and anonymity (among many others).
-
-%p For our purposes here, we also add usability, compatibility, and unmappability. What do all these mean? Let's use the example of a single message, and group these nine properties in three categories:
-
-%h3 Message Security
-
-%table.properties
-  %tr
-    %th Confidentiality
-    %td A message has highly confidentiality if only the intended recipients are able to read the message.
-  %tr
-    %th Integrity
-    %td A message has high integrity if the recipient is assured the message has not been altered.
-  %tr
-    %th Availability
-    %td A message has high availability if the user is able to get to the message when they so desire.
-
-%h3 Identity Security
-
-%table.properties
-  %tr
-    %th Authenticity
-    %td A message has high authenticity if the recipient is certain who sent the message and the sender is certain who received it.
-  %tr
-    %th Anonymity
-    %td A message has high anonymity if the identity of the sender cannot be established by examining the message or the pattern of message delivery.
-  %tr
-    %th Unmappability
-    %td A message has high unmappability if the social network that you communicate with cannot be easily discovered. Unmappability is often collapsed under anonymity. This is unfortunate. It is true the anonymity is one of the issue at stake with social network mapping, but it is just one of many. Because of recent advances in social network analysis and the ability to gather social graph information, we feel that unmappability deserves to be highlighted on its own.
-
-%h3 User Freedom
-
-%table.properties
-  %tr
-    %th Control
-    %td If a user is in possession of their own data and can do with it exactly what they want (and others cannot use the data in ways contrary to the wishes of the user), then we say that they have high control.
-  %tr
-    %th Usability
-    %td For a communication system to have high usability, the common user must be able to operate the system in a way that does not compromise their security.
-  %tr
-    %th Compatibility
-    %td For a system to have high compatibility, the user must not be locked into a particular provider or technology, but should have competing and compatible options available to them. In other words, a user's data should be portable and they should have a choice of clients.
diff --git a/pages/services/technology/infosec/table-style.haml b/pages/services/technology/infosec/table-style.haml
deleted file mode 100644
index c9a3495..0000000
--- a/pages/services/technology/infosec/table-style.haml
+++ /dev/null
@@ -1,59 +0,0 @@
-%style
-  :sass
-    table.properties
-      td
-        vertical-align: top
-        padding-bottom: 0.75em
-      th
-        vertical-align: top
-        padding-right: 1em
-        text-align: right
-        font-weight: normal
-        font-style: italic
-
-    table.infosec
-      width: 100%
-      border-collapse: collapse
-      tbody
-        border-top: 1px solid black
-        border-bottom: 1px solid black
-      th span.normal
-        font-weight: normal
-      th.first, th.second, th.cell
-        width: 14.285714286%
-      th.spacer, td.spacer
-        width: 1px !important
-        padding: 0 !important
-        background: black
-        // border: 1px dotted black
-        //border: 0 !important
-      //th.second
-      //  width: 0%
-      //th.cell
-      //  width: 20%
-      td.cell
-        border-top: 1px solid black
-        border-bottom: 1px solid black
-        //border-right: 1px dotted rgba(0,0,0,.1)
-        border-left: 1px dotted rgba(0,0,0,.1)
-        text-align: center
-        padding: 4px
-        &.none
-          //background-color: #ccc
-          background: #888
-        &.low, &.lower, &.worse
-          //background-color: #FFCCCC
-          background: #aaa
-        &.medium, &.higher
-          //background-color: #FFFFCC
-          background: #ccc
-        &.high, &.better
-          //background-color: #CCFFCC
-          background: #e6e6e6
-        &.better, &.worse
-          font-weight: bold
-      tr.footer td
-        border-left: 1px dotted rgba(0,0,0,.1)
-        text-align: center
-        font-size: 0.8em
-
diff --git a/pages/services/technology/infosec/table.haml b/pages/services/technology/infosec/table.haml
deleted file mode 100644
index f2de6bf..0000000
--- a/pages/services/technology/infosec/table.haml
+++ /dev/null
@@ -1,233 +0,0 @@
-:ruby
-
-  if table_type == :small
-    ##
-    ## SMALL TABLE
-    ##
-    columns = [:p2p, :ssilo, :sfed]
-    column_data = {
-      :ssilo  => [:silo, :encrypted],
-      :sfed   => [:federation, :encrypted],
-      :p2p    => [:peer_to_peer, :encrypted]
-    }
-    rows = [:availability, :usability, :compatibility, :authenticity, :control, :anonymity]
-    row_groups = []
-    footer = false
-    cells = {
-      :ssilo => {
-        :control         => [:lower],
-        :compatibility   => [:lower],
-        :usability       => [:higher],
-        :authenticity    => [:lower],
-        :availability    => [:higher],
-        :anonymity       => [:lower]
-      },
-      :sfed => {
-        :control         => [:higher],
-        :compatibility   => [:higher],
-        :usability       => [:lower],
-        :authenticity    => [:higher],
-        :availability    => [:lower],
-        :anonymity       => [:lower]
-      },
-      :p2p => {
-        :control         => [:higher],
-        :compatibility   => [:lower],
-        :usability       => [:lower],
-        :authenticity    => [:higher],
-        :availability    => [:lower],
-        :anonymity       => [:higher]
-      }
-    }
-  elsif table_type == :big
-    ##
-    ## BIG TABLE
-    ##
-    columns = [:silo, :fed, :ssilo, :sfed, :p2p]
-    column_data = {
-      :silo   => [:silo, :cleartext, :silo_example],
-      :fed    => [:federation, :cleartext, :fed_example],
-      :ssilo  => [:silo, :encrypted, :ssilo_example],
-      :sfed   => [:federation, :encrypted, :sfed_example],
-      :p2p    => [:peer_to_peer, :encrypted, :p2p_example],
-      :spacer  => [:spacer, :spacer, :spacer]
-    }
-    rows = [
-      :control, :compatibility, :usability,
-      :anonymity, :unmappability, :authenticity,
-      :availability, :confidentiality, :integrity
-    ]
-    row_groups = [:message_security, :identity_security, :user_freedom]
-    row_groups_data = {
-      :user_freedom      => [:control, :compatibility, :usability],
-      :identity_security => [:authenticity, :anonymity, :unmappability],
-      :message_security  => [:confidentiality, :integrity, :availability]
-    }
-    footer = true
-    cells = {
-      :silo => {
-        :control         => [:none],
-        :compatibility   => [:none],
-        :usability       => [:high],
-        :anonymity       => [:none],
-        :unmappability   => [:none],
-        :authenticity    => [:none],
-        :availability    => [:high],
-        :confidentiality => [:none],
-        :integrity       => [:none]
-      },
-      :fed => {
-        :control         => [:medium],
-        :compatibility   => [:high],
-        :usability       => [:medium],
-        :anonymity       => [:none],
-        :unmappability   => [:none],
-        :authenticity    => [:none],
-        :availability    => [:medium],
-        :confidentiality => [:none],
-        :integrity       => [:none]
-      },
-      :ssilo => {
-        :control         => [:none],
-        :compatibility   => [:none],
-        :usability       => [:high],
-        :anonymity       => [:low],
-        :unmappability   => [:none],
-        :authenticity    => [:none],
-        :availability    => [:high],
-        :confidentiality => [:high],
-        :integrity       => [:high]
-      },
-      :sfed => {
-        :control         => [:medium],
-        :compatibility   => [:medium],
-        :usability       => [:low],
-        :anonymity       => [:low],
-        :unmappability   => [:none],
-        :authenticity    => [:low],
-        :availability    => [:medium],
-        :confidentiality => [:high],
-        :integrity       => [:high]
-      },
-      :p2p => {
-        :control         => [:high],
-        :compatibility   => [:none],
-        :usability       => [:low],
-        :anonymity       => [:medium],
-        :unmappability   => [:medium],
-        :authenticity    => [:low],
-        :availability    => [:low],
-        :confidentiality => [:high],
-        :integrity       => [:high]
-      },
-      :spacer => {
-        :control         => [:spacer],
-        :compatibility   => [:spacer],
-        :usability       => [:spacer],
-        :anonymity       => [:spacer],
-        :unmappability   => [:spacer],
-        :authenticity    => [:spacer],
-        :availability    => [:spacer],
-        :confidentiality => [:spacer],
-        :integrity       => [:spacer]
-      }
-    }
-  elsif table_type == :leap
-    ##
-    ## LEAP TABLE
-    ##
-    columns = [:fed, :sfed, :leap]
-    column_data = {
-      :ssilo  => [:silo, :encrypted],
-      :sfed   => [:federation, :encrypted],
-      :p2p    => [:peer_to_peer, :encrypted],
-      :fed    => [:federation, :cleartext],
-      :leap   => [:leap, :encrypted]
-    }
-    rows = [
-      :control, :compatibility, :usability,
-      :anonymity, :unmappability, :authenticity,
-      :availability, :confidentiality, :integrity
-    ]
-    row_groups = [:message_security, :identity_security, :user_freedom]
-    row_groups_data = {
-      :user_freedom      => [:control, :compatibility, :usability],
-      :identity_security => [:authenticity, :anonymity, :unmappability],
-      :message_security  => [:confidentiality, :integrity, :availability]
-    }
-    footer = false
-    cells = {
-      :fed => {
-        :control         => [:medium],
-        :compatibility   => [:high],
-        :usability       => [:medium],
-        :anonymity       => [:none],
-        :unmappability   => [:none],
-        :authenticity    => [:none],
-        :availability    => [:medium],
-        :confidentiality => [:none],
-        :integrity       => [:none]
-      },
-      :sfed => {
-        :control         => [:medium],
-        :compatibility   => [:medium],
-        :usability       => [:low],
-        :anonymity       => [:low],
-        :unmappability   => [:none],
-        :authenticity    => [:low],
-        :availability    => [:medium],
-        :confidentiality => [:high],
-        :integrity       => [:high]
-      },
-      :leap => {
-        :control         => [:medium],
-        :compatibility   => [:worse],
-        :usability       => [:better],
-        :anonymity       => [:low],
-        :unmappability   => [:better],
-        :authenticity    => [:better],
-        :availability    => [:medium],
-        :confidentiality => [:high],
-        :integrity       => [:high]
-      }
-    }
-  end
-
-%table.infosec
-  %tr
-    %th.first
-    - if row_groups.any?
-      %th.second
-    - columns.each do |column|
-      - if column == :spacer
-        %th.spacer
-      - else
-        %th.cell
-          = I18n.t column_data[column][0], :scope => 'infosec'
-          %br<>
-          %span.normal
-            = I18n.t column_data[column][1], :scope => 'infosec'
-  - if row_groups.any?
-    - row_groups.each do |row_group|
-      %tbody
-        - rows = row_groups_data[row_group]
-        - rows.each do |row|
-          %tr
-            - if rows.first == row
-              %td{:rowspan=>3}= I18n.t(row_group, :scope => 'infosec').sub(' ', '<br/>').html_safe
-            %td= I18n.t row, :scope => 'infosec'
-            - columns.each do |column|
-              %td.cell{:class => cells[column][row]}= I18n.t cells[column][row].first, :scope => 'infosec'
-  - else
-    - rows.each do |row|
-      %tbody
-        %tr
-          %td= I18n.t row, :scope => 'infosec'
-          - columns.each do |column|
-            %td.cell{:class => cells[column][row]}= I18n.t(cells[column][row].first, :scope => 'infosec')
-  - if footer
-    %tr.footer
-      %td{:colspan=>2}= I18n.t :for_example, :scope => 'infosec'
-      - columns.each do |column|
-        %td= I18n.t column_data[column][2], :scope => 'infosec'
-
diff --git a/pages/services/technology/nicknym/en.md b/pages/services/technology/nicknym/en.md
deleted file mode 100644
index 55ff2c8..0000000
--- a/pages/services/technology/nicknym/en.md
+++ /dev/null
@@ -1,66 +0,0 @@
-@title = 'Nicknym'
-@toc = true
-
-The sad, sorry state of cryptographic identity
-==============================
-
-Existing forms of secure identity are deeply flawed. These systems rely on either a single trusted entity (e.g. Skype), a vulnerable Certificate Authority system (e.g. S/MIME), or keys that cannot be made human memorable (e.g. OpenPGP, OTR). When an identity system is hard to use, it is effectively compromised because too few people take the time to use it properly.
-
-The broken nature of existing identities systems (either in security or in usability) is especially troubling because identity remains a bedrock precondition for any message security: you cannot ensure confidentiality or integrity without confirming the authenticity of the other party.
-
-Nicknym
-============================
-
-The cornerstone of the LEAP design is a system to make digital identity for messaging both secure and easy to use. We call this system Nicknym, since the goal is for the individual to be able to think of cryptographic identity in terms of a domain qualified nickname just as they do with email addresses.
-
-With Nicknym, we want to be backward compatible with existing public key infrastructures, like OpenPGP and OTR, but also add additional support for automatic validation that happens invisibly in the background without the need for user intervention. Nicknym does this with three levels of automatic validation:
-
-**Level 1 — TOFU of user keys:** The first and lowest level of validation is to naively accept the key of another user when you first encounter it. This is often called "trust on first use" or TOFU and is used commonly by SSH (and, in common practice, how many people use OTR and OpenPGP). This level of validation is backwards compatible with existing infrastructure, but has many obvious flaws. When you TOFU a user key, you are making a bet that possible attackers against you did not have the foresight to specifically target you with a false key during discovery. TOFU of user keys can be considerably strengthened by using network perspective and by anonymizing the discovery process, but you still have problems with key expiration, ambiguous mapping between email and keys, and with attackers flooding the discovery process (for example, by filling keyservers with bogus keys).
-
-**Level 2 — TOFU of provider keys:** We can improve considerably on Level 1 with a single addition: if a service provider signs the keys of it's users, then we do not need to TOFU user keys for that provider, we just need to TOFU the provider's key. Once we have trusted the provider's key, we know to always choose the key for a user that was most recently signed by the provider. If the provider publishes their key using webfinger or DNS, then we can also piggyback (temporarily) on the X.509 Certificate Authority system to validate the provider's key. A service provider is also much less likely to lose their private key, a significant problem with TOFU of user keys.
-
-**Level 3 — Federated Web of Trust:** Although Level 2 is pretty good, we can do better by adding a Federated Web of Trust (FWOT). The system works like this: each service provider is responsible for the due diligence of properly signing the keys of a few other providers, akin to the distributed web of trust model of OpenPGP, but with all the hard work of proper signature validation placed upon the service provider. When a user communicates with another party who happens to use a service provider that participates in the FWOT, the user's software will automatically trace a chain of signature from the other party's key, to their service provider, to the user's own service provider (with some possible intermediary signatures). This allows for identity that is verified through an end-to-end trust path from any user to any other user in a way that can be automated and is human memorable. Unlike Level 2, a FWOT does not rely, even temporarily, on the X.509 infrastructure. Also, FWOT can include better mechanisms for dealing with revocation of bad actors, renewal of keys, and emergency re-key events if a provider's keys are lost. On the down side, FWOT is more complicated and would need to deploy specific countermeasures to keep an attacker from abusing the system (see below).
-
-The service provider determines what level of automatic validation is possible. If the service provider does nothing, then only Level 1 is possible. If the service provider signs user keys, then Level 2 is possible. If the service provider signs other providers' keys, then Level 3 is possible.
-
-Discovery mechanisms
-==================================
-
-It is important to not collapse concept of discovery with the concept validation. Although there is some overlap, they should be thought of as entirely distinct.
-
-Currently, no single discovery mechanism has emerged as a dominant method for key discovery. There are several proposed standards, but few people are using any of them. Nicknym will take an agnostic approach by allowing providers to use whichever standard they choose.
-
-To discover a key, a Nicknym agent will try these methods, in this order:
-
-* **Nickserver**: Part of Nicknym is a server-side agent called a "Nickserver" that returns JSON encoded key information in response to a simple HTTP GET with a user's address.
-* **Webfinger**: Webfinger includes a standard mechanism for distributing a user's public key via a simple HTTP request. This is very easy to implement on the server, and very easy to consume on the client side.
-* **DNS**: There are multiple competing standards for key discovery via DNS. When and if one of these emerges predominate, Nicknym should attempt to use this method when available. DNS discovery, however, has some problems. DNS discovery of keys is much harder to implement, because the service provider must run their own customized authoritative nameserver. Also, since keys can be too big for domain UDP packets, any future-proof DNS method relies on an HTTP request, thus undermining the potential benefit of decentralization you might get from using DNS rather than webfinger.
-* **Keyservers**: As a fallback, Nicknym agents will try the existing keyservers when other mechanisms are not supported. This should be avoided when possible, because current keyservers are vulnerable to be flooded with bogus keys. This can be improved by prioritizing responses from keyservers that add mailback verification during key registration (although this currently not supported by many keyservers).
-
-Users are not websites
-==============================
-
-What about WebID or BrowserID (Mozilla Personas)? These are both interesting cryptographic identity standards that are gaining support and implementations. So why do we need something new?
-
-These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a Federated Web of Trust could be combined with something like BrowserID/Personas.
-
-FWOT attacks and countermeasures
-==========================================
-
-Most attacks on a FWOT can be mitigated with a simple "network perspectives" approach that keeps each service provider honest. Let's enumerate the attacks and how to prevent them. Suppose two providers, A and B.
-
-**Attack 1 - Intercept Outgoing:** provider A signs an impostor key for provider B and distributes it to users of A (in order to intercept outgoing messages sent to B).
-
-**Attack 2 - Intercept Incoming:** provider A signs an impostor key for one of its own users, and distributes to users of B (in order to intercept incoming messages).
-
-**Attack 3 - Association Mapping:** A provider tracks all the requests for key discovery in order to build a map of association.
-
-To prevent these attacks, Nicknym will support independent notaries who sole purpose is to answer a single question: "Do you see the same key that I see?"
-
-In order to prevent attack 1, the user's client software will not blindly trust that it has encountered the correct provider key for B. Instead, it will get confirmation from the notaries that they also received the same key (or a key signed by the same key).
-
-In order to prevent attack 2, the user's client software will regularly query the notaries for their own key. If the notaries see a different key, the user is alerted that their provider is attempting to intercept their messages.
-
-In order to prevent attack 3, the user's client software will be able to use the response of a notary as the initial key discovery, and to proxy a request to one notary through another. Each notary request will be encrypted to the public key of that notary.
-
-For this to work, client software that supports FWOT will come pre-seeded with a list of some of the notaries and their public keys. New notaries are then discovered and validated using consensus of these root notaries.