moved tech pages to leap_docs

5 files changed, 1 insertions, 458 deletions

diff --git a/pages/about-us/infosec/en.haml b/pages/about-us/infosec/en.haml
deleted file mode 100644
index 19ce908..0000000
--- a/pages/about-us/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. Some squares get low marks because of user error. For example, peer-to-peer systems have a hard time with user friendly keys, leading to high user error and low effective authenticity.
-
-%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 still in practice have many authenticity problems.
-
-%h1 The LEAP strategy
-
-%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/about-us/infosec/table-style.haml b/pages/about-us/infosec/table-style.haml
deleted file mode 100644
index c9a3495..0000000
--- a/pages/about-us/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/about-us/infosec/table.haml b/pages/about-us/infosec/table.haml
deleted file mode 100644
index f2de6bf..0000000
--- a/pages/about-us/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/menu.txt b/pages/menu.txt
index b11a4dc..7c9e4ef 100644
--- a/pages/menu.txt
+++ b/pages/menu.txt
@@ -3,16 +3,10 @@ services
   eip
   email
   chat
-#  technology
-#    infosec
-#    client-app
-#    routing
-#    critiques
 about-us
   vision
   jobs
 #  people
   contact
   news
-  partners
-  infosec
\ No newline at end of file
+  partners
\ No newline at end of file
diff --git a/pages/services/technology/routing/en.haml b/pages/services/technology/routing/en.haml
deleted file mode 100644
index 9ea5671..0000000
--- a/pages/services/technology/routing/en.haml
+++ /dev/null
@@ -1,58 +0,0 @@
-%h1.first A social graph is highly sensitive data
-
-%p As the field of network analysis has advanced in recent years, the social graph has become highly sensitive and critical information. Knowledge of the social graph can give an attacker a blueprint into the inner workings of an organization or reveal surprisingly intimate personal details, such as sexual orientation or even health status.
-
-%p Unfortunately, existing technologies for secure routing, such as StartTLS for email or chat, are insufficient in today's environment and easily thwarted. StartTLS also does little to protect a service provider from being required to keep association records of its users.
-
-%h1 Graph Resistant Routing (Grr!)
-
-%p One of the major goals of LEAP is to make message routing that is resistant to social graph mapping.
-
-%p How would this work? Imagine users Alice and Bob. Alice wants to correspond with Bob but doesn't want either her service provider or Bob's service provider to be able to record the association. She also doesn't want a network observer to be able to map the association.
-
-%p When Alice first sends a message to Bob, Alice's client will initiate the following chain of events on her behalf, automatically and behind the scenes.
-
-%ol
-  %li Alice's client requests a new alias from her service provider. If her normal address is alice@domain.org, she receives an alias hjj3fpwv84fn@domain.org that will forward messages to her account.
-  %li Alice's client uses automatic key discovery and validation to find Bob's public key and discover if Bob's service provider supports map resistant routing.
-  %li If Bob does support it, Alice's client will then send a special message, encrypted to Bob's key, that contains Alice's public address and her private alias.
-  %li When Bob's client encounters this special message, it records a mapping between Alice's public address (alice@domain.org) and the private alias she has created for Bob's use (hjj3fpwv84fn@domain.org).
-  %li Bob's client then creates an alias for Bob and sends it to Alice.
-  %li Alice's client receives this alias, and records the mapping between Bob's public address and his private alias.
-  %li Alice's client then relays the original message to Bob's alias.
-
-%p Subsequently, whenever Alice or Bob want to communicate, they use the normal public addresses for one another, but behind the scenes their clients will rewrite the source and recipient of the messages to use the private aliases.
-
-%p This scheme is backwards compatible with existing messaging protocols, such as SMTP and XMPP.
-
-%h1 Limitations
-
-%p There are five major limitations to this scheme:
-
-%ol
-  %li
-    %b Alias unmasking attacks:
-    because each service provider maintains an alias map for their own users, an attacker who has gained access to this alias map can de-anonymize all the associations into and out of that particular provider, for the past and future.
-  %li
-    %b Timing attacks:
-    a statistical analysis of the time that messages of a particular size are sent, received, and relayed by both service providers could reveal the map of associations.
-  %li
-    %b Log correlation problem:
-    a powerful attacker could gain access to the logs of both service providers, and thereby reconstruct the associations between the two providers.
-  %li
-    %b Single provider problem:
-    this scheme does not protect associations between people on the same service provider.
-  %li
-    %b Client problem:
-    if the user's device is compromised, the record of their actual associations can be discovered.
-
-%p At this point, we feel that it is OK to live with these limitations for the time being in order to simply the logic of the user's client application and to ensure backward compatibility with existing messaging protocols.
-
-%p Possible future enhancements could greatly mitigate these attacks:
-
-%ol
-  %li We could use temporarily aliases that rotate daily, perhaps based on an HMAC counter, based on a shared secret between two users.
-  %li The 'alias service' could be run by a third party, so that associations within a single provider are also resistant to mapping.
-  %li A service provider with sufficient traffic could be in a very good position to be able to aggregate and time-shift the messages it relays in order to disrupt timing attacks.
-
-%p Ultimately, however, most of these attacks are a problem when faced with an extremely powerful adversary. This scheme is not designed for these situations. Instead, it is designed to prevent the casual, mass surveillance of all communication that currently takes place in repressive and democratic countries alike, by both governments and corporations. It greatly reduces the capacity for association mapping of both traffic over the wire and in stored communication. It is not designed to make a particular user anonymous in the face of a powerful adversary.