diff options
| author | elijah <elijah@riseup.net> | 2013-02-12 21:28:21 -0800 |
|---|---|---|
| committer | elijah <elijah@riseup.net> | 2013-02-12 21:28:21 -0800 |
| commit | 54d7ba2cd31030d66886d450bd7c77b9e62dcaa0 (patch) | |
| tree | 05ea7341de3eb561440f09e2b2b23ab48f62f482 /app | |
| parent | 75b89d6666e2cd24c5253e409653c01f89e6aae3 (diff) | |
moved pages from app/view/pages to pages
Diffstat (limited to 'app')
26 files changed, 0 insertions, 1340 deletions
diff --git a/app/views/pages/about-us/contact/en.haml b/app/views/pages/about-us/contact/en.haml deleted file mode 100644 index e96323e..0000000 --- a/app/views/pages/about-us/contact/en.haml +++ /dev/null @@ -1,32 +0,0 @@ -%h3 IRC - -Probably the fastest and most reliable way to contact anyone involved with LEAP. Don't despair if you don't get a reply right away, we are all in different time zones and we all are able to read the scrollback history, so someone will reply eventually. - -.well - \#leap-dev on freenode.net - -%h3 Email - -Email is pretty good too. - -.well - info@leap.se - -%h3 Postal Address - -It may take us a very long time to respond to postal mail. - -.well - PO Box 4422 - %br - Seattle, WA 98194 USA - -%h3 Phone (Voice Mail) - -Leave us a message, bonus points if you sing your message. - -.well - +1 (206) 420-6613 - - - diff --git a/app/views/pages/about-us/en.haml b/app/views/pages/about-us/en.haml deleted file mode 100644 index efca933..0000000 --- a/app/views/pages/about-us/en.haml +++ /dev/null @@ -1 +0,0 @@ -= act_as('vision')
\ No newline at end of file diff --git a/app/views/pages/about-us/jobs/en.haml b/app/views/pages/about-us/jobs/en.haml deleted file mode 100644 index d0e7fd1..0000000 --- a/app/views/pages/about-us/jobs/en.haml +++ /dev/null @@ -1,60 +0,0 @@ -- @title = 'Jobs' - -:textile - - h1(first). About LEAP - - "LEAP Encryption Access Project":https://leap.se/en is a non-profit dedicated to giving all internet users access to secure communication. Our focus is on adapting encryption technology to make it easy to use and widely available. - - * We are a team of 10 dedicated and experienced anti-surveillance hackers. - * We started development in earnest on June 1 2011. - * We are globally distributed in Europe, South America, North America, and South Korea (Yep, it is hard to schedule meetings). - * We have an established agile development process that works. - * 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 - - h2. Lead Python Developer - - !>/img/pages/python-logo.png! - - We are hiring a lead Python programmer to shepherd the development of the LEAP Client. The LEAP Client is a desktop application that connects to a larger cloud-based system to provide end-to-end client-side encryption over many different protocols (like email and chat). The app is mostly headless, speaking to the servers via a client-encrypted sync to distributed databases and to local clients via traditional protocols like IMAP, SMTP, and XMPP. We are looking for someone who can take a leading role in overall design of the client (and related protocols), provide direction for development, work collaboratively with a small team of hackers, and assure clean code. - - <!-- This position presents some unique challenges! The team is globally distributed and comprised of independent people who generally prefer collective and non-hierarchical systems. Ideally we would find someone who is excited about thinking creatively and non-traditionally about a lead role. --> - - What we are looking for, via a list of many bullets: - - * Many years of experience with Python - * Clear understanding of public key cryptography and experience using cryptographic libraries - * Burning desire to secure communications from prying eyes and snooping algorithms - * Uncontrolled obsession with free and open source software - * Experience with architecture of large applications - * Love of clean code - * Ability to take on a leadership role - * Enthusiasm for working collaboratively - * Good testing practices - * Experience with cross-platform development - * Ability to understand and work with complex distributed systems - * Self-motivated and able to effectively work remotely - - Compensation rates are high for US non-profits and low for the US tech industry. This could be a full-time or part-time position, as desired. - - h2. Android Developer - - !>/img/pages/android-logo.jpg! - - We are hiring a programmer for ongoing Android development, including porting the LEAP Client to Android and writing a client-encrypted sync provider that integrates with the LEAP data storage. Many of the key components on which the client will depend have already been ported to Android, such as openvpn, sqlcipher, and u1db. Like its desktop counterpart, the goal with the Android client is to have a minimal UI that auto-configures itself with the service provider. We will only support Android 4.0 and above (earlier releases don't have "VpnService":http://developer.android.com/reference/android/net/VpnService.html API). - - What we are looking for, via a list of many bullets: - - * Experience with Android application development - * Familiarity with public key cryptography and (ideally) experience with BouncyCastle - * Enthusiasm for working collaboratively - * Good testing practices - * Burning desire to secure communications from prying eyes and snooping algorithms - * Uncontrolled obsession with free and open source software - - Compensation rates are high for US non-profits and low for the US tech industry. This could be a full-time or part-time position, as desired.
\ No newline at end of file diff --git a/app/views/pages/about-us/news/2012/access-prize/en.haml b/app/views/pages/about-us/news/2012/access-prize/en.haml deleted file mode 100644 index 35c61f6..0000000 --- a/app/views/pages/about-us/news/2012/access-prize/en.haml +++ /dev/null @@ -1,14 +0,0 @@ -- @title = "Big thanks to Access for supporting LEAP" -- @author = "Mcnair" -- @posted_at = "2012-12-11" -- @preview = capture_haml do - Last night I attended the awards party for Access Innovation Prize, not knowing what to expect. The prize is for people and organizations using <a href="https://www.accessnow.org/blog/2012/12/11/first-annual-access-innovation-awards-prize-winners-announced">"information technology to promote and enable human rights and deliver social good"</a>. It turns out, geeks on a mission know how to do good and have a good time! - - %div{:style => 'float:left; margin: 8px; margin-left: 0;'} - %img{:src => "/img/pages/access-prize-small.jpg"} - %span{:style => "font-size: 80%; line-height: 0.8em; display: block; margin-top: 4px;"} - My, that disc is shiny. - - %br - - LEAP was a finalist in the "Making Crypto Easy" category, but the competition was impressive and deserving. I nearly popped a blood vessel when I heard LEAP called as the winner! Big thanks to <a href="https://www.accessnow.org">Access</a> and all the techies and innovators they assembled. It was an excellent party, and a stellar collection of dedicated technologists. On behalf of LEAP, I am humbled and extremely thankful for this prize. Now we get down to putting the prize money to work... diff --git a/app/views/pages/about-us/news/2012/en.haml b/app/views/pages/about-us/news/2012/en.haml deleted file mode 100644 index dc68ad5..0000000 --- a/app/views/pages/about-us/news/2012/en.haml +++ /dev/null @@ -1 +0,0 @@ -= recent_blog_summaries('news/2012') diff --git a/app/views/pages/about-us/news/2012/first-post/en.haml b/app/views/pages/about-us/news/2012/first-post/en.haml deleted file mode 100644 index 164092c..0000000 --- a/app/views/pages/about-us/news/2012/first-post/en.haml +++ /dev/null @@ -1,10 +0,0 @@ -- @title = "Tada! A website." -- @author = "Elijah" -- @posted_at = "2012-08-24" -- @tags = [''] -- @categories = [''] -- @preview = capture_haml do - :textile - I just put up the official and uncensored LEAP website. Everything needs a beginning, and I suppose this is our beginning--not with a whimper or a bang, but with a "tada!" Poke around, check us out, and please <a href="/about-us/contact">send us</a> your questions, angry tirades, or love letters. More updates to follow shortly. - - diff --git a/app/views/pages/about-us/news/2012/security-bingo/en.haml b/app/views/pages/about-us/news/2012/security-bingo/en.haml deleted file mode 100644 index f2b6fe5..0000000 --- a/app/views/pages/about-us/news/2012/security-bingo/en.haml +++ /dev/null @@ -1,194 +0,0 @@ -- @title = "Let's play security bingo! (Updated)" -- @author = "Elijah" -- @posted_at = "2012-08-28" -- @more = true -- @preview = capture_haml do - :textile - To be honest, this is might be the least satisfying game of bingo ever--but let's play anyway. The rules are simple: make a grid cross referencing OS platform and communication toolset. In each cell, put the name of an open source software package with reasonable security properties. If this exercise doesn't make you break down in tears, then you have won. - -%style - :sass - table.table - border: 1px solid #ccc - td - background: white - width: 12.5% - font-size: 0.9em - border-right: 1px solid #ccc - td.section - border-right: 0 - -= @preview - -:textile - - The rules probably need some adjustment if this game is to catch on. - - Here is my attempt at playing: - -%table.table - %tr - %th - %th - %th Windows - %th Mac - %th Linux - %th iOS - %th Android - %th Web - %tbody - %tr - %td.section{:rowspan => 3} Messages - %td Short Message - %td{:colspan => 3} #{link 'Pidgin' => 'http://pidgin.im'}, #{link 'Gajim' => 'http://gajim.org'}, #{link 'OTR' => 'http://www.cypherpunks.ca/otr/'} - %td #{link 'ChatSecure' => 'https://chatsecure.org/'} - %td #{link 'Gibberbot' => 'https://guardianproject.info/apps/gibber/'}, #{link 'Beem' => 'http://beem-project.com'}, #{link 'TextSecure' => 'https://github.com/WhisperSystems/TextSecure'} - %td #{link 'Cryptocat' => 'https://crypto.cat'} - %tr - %td Long Message - %td #{link 'Enigmail' => 'http://enigmail.mozdev.org/'}, #{link 'Gpg4win' => 'http://www.gpg4win.org/about.html'} - %td #{link 'Enigmail' => 'http://enigmail.mozdev.org/'}, #{link 'GPGMail' => 'https://www.gpgtools.org/gpgmail/index.html'} - %td #{link 'Enigmail' => 'http://enigmail.mozdev.org/'} - %td - %td #{link 'AGP' => 'http://www.thialfihar.org/projects/apg/'} - %td - %tbody - %tr - %td.section{:rowspan => 5} Files - %td Storage - %td #{link 'DiskCryptor' => 'http://diskcryptor.net'} - %td - %td #{link 'EncFS' => 'http://www.arg0.net/encfs'}, #{link 'eCryptfs' => 'http://ecryptfs.org/'}, #{link 'DMCrypt' => 'http://en.wikipedia.org/wiki/Dm-crypt'} - %td - %td #{link 'AOSP' => 'http://source.android.com/'}, #{link 'Cryptonite' => 'https://code.google.com/p/cryptonite/'} - %td #{link 'SafeWith.me' => 'https://SafeWith.me'} - %tr - %td Backup - %td #{link 'Duplicati' => 'http://duplicati.com/'} - %td - %td #{link 'Déjà Dup' => 'https://launchpad.net/deja-dup'} - %td - %td #{link 'FlashBack' => 'http://www.whispersys.com/flashback.html'} - %td - %tr - %td Synchronization - %td{:colspan => 3} #{link 'Syncany' => 'http://www.syncany.org/'}, #{link 'git-annex' => 'http://git-annex.branchable.com/assistant/'}, #{link 'SparkleShare' => 'http://sparkleshare.org/'} - %td - %td - %td - %tr - %td Data Wipe - %td #{link 'Eraser' => 'http://eraser.heidi.ie/'}, #{link 'BleachBit' => 'http://bleachbit.sourceforge.net/'}, #{link 'DBAN' => 'http://www.dban.org/'} - %td #{link 'DBAN' => 'http://www.dban.org/'} - %td #{link 'BleachBit' => 'http://bleachbit.sourceforge.net/'}, #{link 'DBAN' => 'http://www.dban.org/'}, wipe - %td - %td #{link 'InTheClear' => 'https://github.com/SaferMobile/InTheClear'} - %td N/A - -# %tr - %td Collaboration - %td - %td - %td - %td - %td - %td - %tbody - %tr - %td.section{:rowspan => 3} Audio/Video - %td Direct Calling - %td{:colspan => 3} #{link 'Jitsi' => 'https://jitsi.org/'} - %td - %td #{link 'RedPhone' => 'https://github.com/WhisperSystems/RedPhone'}, #{link 'CSimpleSip' => 'https://code.google.com/p/csipsimple/'} - %td - %tr - %td Conference - %td{:colspan => 3} #{link 'Mumble' => 'http://mumble.sourceforge.net/'} - %td - %td #{link 'Mumble' => 'http://mumble.sourceforge.net/'} - %td - %tr - %td Capture & Reporting - %td - %td - %td - %td - %td #{link 'ObscuraCam' => 'https://guardianproject.info/apps/obscuracam/'} - %td - %tbody - %tr - %td.section{:rowspan => 2} Network - %td Availability - %td{:colspan => 5} #{link 'Commotion' => 'http://commotionwireless.net/'} - %td N/A - %tr - %td Confidentiality & Anonymity - %td{:colspan => 5} #{link 'Tor' => 'https://torproject.org'}, #{link 'OpenVPN' => 'http://openvpn.net'} - %td N/A - %tbody - %tr - %td.section{:rowspan => 3} Identity - %td Passwords - %td{:colspan => 3} #{link 'KeePassX' => 'http://www.keepassx.org/'} - %td - %td #{link 'KeePassDroid' => 'http://www.keepassdroid.com/'} - %td - %tr - %td Validation - %td{:colspan => 6} OpenPGP, #{link 'OTR' => 'http://www.cypherpunks.ca/otr/'} - %tr - %td Authentication - %td{:colspan => 6} #{link 'Mozilla Persona' => 'https://login.persona.org/'}, #{link 'WebID' => 'http://www.w3.org/2005/Incubator/webid/spec/'} - -# %tbody - %tr - %td.section{:rowspan => 2} Anti-intrusion - %td Firewall - %td - %td - %td Many - %td - %td DroidWall - %td N/A - %tr - %td Anti-virus - %td - %td ClamXav - %td ClamAV - %td - %td - %td N/A - -# %tbody - %tr - %td.section{:rowspan => 3} Productivity - %td Events & Scheduling - %td - %td - %td - %td - %td - %td - %tr - %td Tasks & Planning - %td - %td - %td - %td - %td - %td - -:textile - Looking at this table, it is immediately obvious that there are a lot of empty cells. Unfortunately, most of the cells that are filled in contain software that is unfriendly or even sadistic toward the user. Trying to use many of these tools can feel like developing a BDSM relationship with your computer, and you are not the top. - - What is missing might be more revealing than what is listed. These toolsets are entirely absent from my 'security bingo' game card: - - * *Social Networking:* When I excluded software that I think is unfeasible (SecureShare) or has no security (Diaspora, etc), then you end up with zero projects. - * *Document Collaboration:* I have high hopes for an encrypted etherpad, but so far no one has started work on it. - * *Photos/Vidoes & Galleries:* Nothing I have heard of. - * *Events & Scheduling:* Nothing I have heard of. - * *Tasks & Planning:* Nothing I have heard of. - - I also excluded a few obvious categories: - - * *Firewall:* Reasonable firewall support is now built into most operating systems. - * *Anti-virus:* Viruses are still mostly a problem on Windows. Other platforms have just gotten lucky so far. - - If you have suggestions for how I can fill in my game card, please write elijah@leap.se.
\ No newline at end of file diff --git a/app/views/pages/about-us/news/en.haml b/app/views/pages/about-us/news/en.haml deleted file mode 100644 index 87eaac5..0000000 --- a/app/views/pages/about-us/news/en.haml +++ /dev/null @@ -1,3 +0,0 @@ -- @layout = 'blog' -- @path_prefix = '2012' -= recent_blog_summaries('about-us/news')
\ No newline at end of file diff --git a/app/views/pages/about-us/partners/en.haml b/app/views/pages/about-us/partners/en.haml deleted file mode 100644 index 15446c0..0000000 --- a/app/views/pages/about-us/partners/en.haml +++ /dev/null @@ -1,10 +0,0 @@ -%p <b><a href="https://www.calyxinstitute.org/">Calyx Institute</a></b> is a research, education and legal support group devoted to researching and implementing privacy technology and tools to promote free speech, free expression, civic engagement and privacy rights on the Internet. Calyx plans to be an early adopter of the #{link 'LEAP platform' => 'platform'}. - -%p <b><a href="http://dyne.org">Dyne.org</a></b> is a nonprofit network of hackers committed to development of free and open source software. Our international network works to support broad access to technology and knowledge with practices, tools and narratives for community empowerment. - -%p <b><a href="http://f2c.rfa.org/">Freedom2Connect</a></b> program is designed to ensure secure communication tools exist for millions of individuals whose online interactions are being monitored or obstructed by repressive governments. Through support of research, development, and implementation of globally-accessible secure communications, freedom2connect champions the goals of Article 19 of the Universal Declaration of Human Rights. - -%p <b><a href="http://giip.org">Global Information Internship Program</a></b> (GIIP) is an educational and service-learning program at the University of California, Santa Cruz. GIIP is creating a new generation of “info-savvy” advocates who use information technology to promote civic participation and social justice. Since 1998, hundreds of GIIP undergraduate student interns have worked to democratize globalization, support world peace, raise environmental awareness, and promote gender equity by upgrading the informational capacity of non-governmental organizations (NGOs) and community groups around the world. GIIP will work with LEAP to conduct usability studies of LEAP software in various contexts around the world. - -%p <b><a href="https://riseup.net">Riseup Networks</a></b> is major provider of email, chat, and lists for thousands of activist organizations around the world. Riseup plans to be an early adopter of the #{link 'LEAP platform' => 'platform'}. - diff --git a/app/views/pages/about-us/vision/en.haml b/app/views/pages/about-us/vision/en.haml deleted file mode 100644 index c6c7a3b..0000000 --- a/app/views/pages/about-us/vision/en.haml +++ /dev/null @@ -1,26 +0,0 @@ -%h1.first The Right to Whisper - -%p LEAP fights for the right to whisper. - -%p Like free speech, the right to whisper is an <b>necessary precondition for a free society</b>. Without it, civil society and political freedom become impossible. As the importance of digital communication for civic participation increases, so does the importance of the ability to digitally whisper. - -%p Unfortunately, advances in surveillance technology are <b>rapidly eroding the ability to whisper</b>. This is a worldwide problem, not simply an issue for people in repressive contexts. Acceptance of poor security in the West creates a global standard of insecure practice, even among civil society actors who urgently need the ability to communicate safely. - -%p The stakes could not be higher. Activists are dying because their communication technologies betray their identity, location, and conversations. When activists attempt to secure their communications, they face confusing software, a dearth of secure providers, and a greater risk of being flagged as potential troublemakers. In other words, <b>problems of usability, availability, and adoption</b>. - -%h1 Our vision - -%p The LEAP vision is to attack these problems of usability, availability, and adoption head on. - -%p - %b To address usability, - we are creating a complete system where the user-facing client software is tightly coupled with the cloud-base components of the system. All our software will be auto-configuring, prevent users from practicing insecure behavior, and primarily limit the configuration options to those moments when the user is placing their trust in another entity. - -%p - %b To address availability, - LEAP will work closely with service providers to adopt our open source, #{link 'automated platform' => 'platform'} for running high-availability #{link 'communication services' => 'services'}. By lowering the barriers of entry to become a reliable provider, we can increase the supply and decrease the cost of secure communications. - -%p - %b To address adoption, - the LEAP platform #{link 'layers higher security' => 'infosec'} on top of existing protocols to allow users a gradual transition path and backward compatibility. Our goal is to create services that are attractive in terms of features, usability, and price for users in both democratic and repressive contexts. - diff --git a/app/views/pages/development/en.haml b/app/views/pages/development/en.haml deleted file mode 100644 index bfbf8c5..0000000 --- a/app/views/pages/development/en.haml +++ /dev/null @@ -1,67 +0,0 @@ -%h1.first IRC - -Join us on freenode at #leap-dev. - -%h1.topgap Source Code - -%h3 Client - -%table.table.table-bordered - %tr - %td leap_client - %td Easy-to-use client for Linux, Mac, and Windows. - %td git://leap.se/leap_client - %td= link 'github' => 'https://github.com/leapcode/leap_client' - -%h3 Service provider platform - -%table.table.table-bordered - %tr - %td leap_platform - %td Turn-key automation for communication service providers - %td git://leap.se/leap_platform - %td= link 'github' => 'https://github.com/leapcode/leap_platform' - - %tr - %td leap_ca - %td Client certificate generation daemon - %td git://leap.se/leap_ca - %td= link 'github' => 'https://github.com/leapcode/leap_ca' - - %tr - %td leap_cli - %td Command line interface to setup and manage servers running the LEAP platform - %td git://leap.se/leap_cli - %td - -%h3 Web applications and libraries - -%table.table.table-bordered - %tr - %td leap_web - %td Web application for the LEAP platform, providing user management, tickets, billing, and REST API - %td git://leap.se/leap_web - %td= link 'github' => 'https://github.com/leapcode/leap_web' - %tr - %td leap_website - %td This website - %td git://leap.se/leap_website - %td - %tr - %td srp_js - %td Secure Remote Password (SRP) library for javascript - %td git://leap.se/srp_js - %td= link 'github' => 'https://github.com/leapcode/srp_js' - %tr - %td ruby_srp - %td Secure Remote Password (SRP) library for ruby - %td git://github.com/leapcode/ruby_srp - %td= link 'github' => 'https://github.com/leapcode/ruby_srp' - -%h1 Mailing List - -%p Coming soon. - -%h1 Wiki - -%p Coming soon. diff --git a/app/views/pages/home/en.haml b/app/views/pages/home/en.haml deleted file mode 100644 index ff266d0..0000000 --- a/app/views/pages/home/en.haml +++ /dev/null @@ -1,63 +0,0 @@ -%p.bigger.first - %b Bring fire to the people. - LEAP is a non-profit dedicated to giving all internet users access to secure communication. Our focus is on adapting encryption technology to make it easy to use and widely available. #{link 'More about LEAP »' => 'about-us'} - -.row-fluid.p - .span4 - .well - .heading For Users - %p We are working to create a suite of high security communication tools that are reliable and easy to use. - = link(:read_more => 'services', :class => 'btn') - .span4 - .well - .heading For Providers - %p We are working on tools to automate the deployment of a secure service provider infrastructure. - = link(:read_more => 'platform', :class => 'btn') - .span4 - .well - .heading For Hackers - %p Got skills? We need them. Fork, contribute, pentest, and patch our software. Always 100% Free/Libre. - = link(:read_more => 'development', :class => 'btn') - -.row-fluid - -# .span6 - -# %h2.invert LEAP Blog - -# = recent_blog_summaries('blog') - .span6 - %h3.first - Recent News - = news_feed_link - = recent_blog_summaries('news') - .span6 - %h3 LEAP Development Roadmap - - %table.timeline - %tr - %td Jan - %td 2013 - %td Automated deployment of #{link 'eip'} service, with client support on Windows, Linux, and Mac. - %tr - %td June - %td 2013 - %td Android client for #{link 'eip'}. - %tr - %td Jan - %td 2014 - %td Initial release of #{link 'secure email' => 'email'} as part of the LEAP platform. - %tr - %td June - %td 2014 - %td #{link('email')} with #{link 'federated trust' => 'identity'} identity validation. - %tr - %td - %td 2015 - %td Initial release of #{link 'secure chat' => 'chat'} as part of the LEAP platform. - %tr - %td - %td 2016 - %td Initial release of secure file sync as part of the LEAP platform. - %tr - %td - %td 2018 - %td Initial release of secure voice conference as part of the LEAP platform. - diff --git a/app/views/pages/menu.txt b/app/views/pages/menu.txt deleted file mode 100644 index 5576e2b..0000000 --- a/app/views/pages/menu.txt +++ /dev/null @@ -1,25 +0,0 @@ -home -services - eip - email - chat - #files - #voice -technology - infosec - platform - client - #cloud - identity - routing - critiques - #sync - #authentication -development -about-us - vision - jobs - #people - contact - news - partners diff --git a/app/views/pages/services/chat/en.haml b/app/views/pages/services/chat/en.haml deleted file mode 100644 index e27dcf3..0000000 --- a/app/views/pages/services/chat/en.haml +++ /dev/null @@ -1,27 +0,0 @@ -: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/app/views/pages/services/eip/en.haml b/app/views/pages/services/eip/en.haml deleted file mode 100644 index 538deca..0000000 --- a/app/views/pages/services/eip/en.haml +++ /dev/null @@ -1,62 +0,0 @@ -: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/app/views/pages/services/email/en.haml b/app/views/pages/services/email/en.haml deleted file mode 100644 index af2eb67..0000000 --- a/app/views/pages/services/email/en.haml +++ /dev/null @@ -1,22 +0,0 @@ -: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/app/views/pages/services/en.haml b/app/views/pages/services/en.haml deleted file mode 100644 index 94f8a01..0000000 --- a/app/views/pages/services/en.haml +++ /dev/null @@ -1,21 +0,0 @@ -%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. diff --git a/app/views/pages/technology/client/en.haml b/app/views/pages/technology/client/en.haml deleted file mode 100644 index c4f82b5..0000000 --- a/app/views/pages/technology/client/en.haml +++ /dev/null @@ -1,109 +0,0 @@ -%h1.first 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 - -%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 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. - -%h1 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. - -%h1 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. - -%h1 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 - -%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. - - -%h1 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 - %b Notary Keys: - The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'identity'}. 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. - - - -%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 - %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/app/views/pages/technology/critiques/en.haml b/app/views/pages/technology/critiques/en.haml deleted file mode 100644 index 06fccdd..0000000 --- a/app/views/pages/technology/critiques/en.haml +++ /dev/null @@ -1,57 +0,0 @@ -%h1.first Anticipated Critiques - -:textile - 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/app/views/pages/technology/en.haml b/app/views/pages/technology/en.haml deleted file mode 100644 index bc60a94..0000000 --- a/app/views/pages/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 'Secure Identity' => 'identity'}: - Federated system to automate 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/app/views/pages/technology/identity/en.haml b/app/views/pages/technology/identity/en.haml deleted file mode 100644 index 27c8b8b..0000000 --- a/app/views/pages/technology/identity/en.haml +++ /dev/null @@ -1,45 +0,0 @@ -%h1.first The sad, sorry state of cryptographic identity - -%p 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. - -%p 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. - -%h1 NickID - -%p 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 NickID, 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. - -%p NickID is based on a federated structure where the difficult work is pushed to the service providers. Each provider is responsible for the due diligence of properly signing the keys of other providers, akin to the distributed web of trust model of OpenPGP. Providers also are responsible for signing the keys of their users, akin to the Certificate Authority model. - -%p When a user sends or receives a message, their software will discover the other party's key and trace a chain of signature's back to the user's service provider. NickID 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 (e.g. identity in the form user@example.com). - -%h1 Users are not websites - -%p 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? - -%p 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. - -%h1 Attacks and countermeasures - -%p Attacks on this system can be prevented 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. - -%p - %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). - -%p - %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). - -%p - %b Attack 3 - Association Mapping: - A provider tracks all the requests for key discovery in order to build a map of association. - -%p To prevent these attacks, NickID will support independent notaries who sole purpose is to answer a single question: "Do you see the same key that I see?" - -%p 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). - -%p 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. - -%p 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. - -%p For this to work, client software that supports NickID will come pre-seeded with a list of notaries and their public keys. Although this sounds like a repeat of the problems associated with the Certificate Authority system, the notaries are actually quite different. Rather than placing irrevocable trust in an authority, clients are only using the notaries for a very narrowly defined ability to provide network perspective. diff --git a/app/views/pages/technology/infosec/en.haml b/app/views/pages/technology/infosec/en.haml deleted file mode 100644 index 386ce10..0000000 --- a/app/views/pages/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' => 'identity'}. - %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/app/views/pages/technology/infosec/table-style.haml b/app/views/pages/technology/infosec/table-style.haml deleted file mode 100644 index c9a3495..0000000 --- a/app/views/pages/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/app/views/pages/technology/infosec/table.haml b/app/views/pages/technology/infosec/table.haml deleted file mode 100644 index 0f6a92f..0000000 --- a/app/views/pages/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], :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], :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/app/views/pages/technology/platform/en.haml b/app/views/pages/technology/platform/en.haml deleted file mode 100644 index 44bbce9..0000000 --- a/app/views/pages/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. - diff --git a/app/views/pages/technology/routing/en.haml b/app/views/pages/technology/routing/en.haml deleted file mode 100644 index 35d52ed..0000000 --- a/app/views/pages/technology/routing/en.haml +++ /dev/null @@ -1,52 +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 Map resistant routing - -%p One of the major goals of LEAP is to make message routing that is resistant to social graph mapping. - --# The LEAP design includes an improved method of encrypted transport negotiation and an system for aliased message routing to protect the social graph from even the service providers themselves. - -%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. - -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. - -This scheme is backwards compatible with existing messaging protocols, such as SMTP and XMPP. - -%h1 Limitations - -%p There are four major limitations to this scheme: - -%ol - %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 in order to be backward compatible with existing messaging protocols. The first two attacks are only possible by a very powerful adversary. One so powerful that association mapping is probably the least of your worries. - -%p This scheme 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. - -%p However, a service provider using this scheme that has sufficient traffic will be in a very good position to be able to aggregate and time-shift the messages it relays in order to disrupt timing attacks—once researchers have a better understanding of how to effectively counter timing attacks.
\ No newline at end of file |