diff options
| -rw-r--r-- | pages/about-us/grantwriter.md | 65 | ||||
| -rw-r--r-- | pages/about-us/jobs/en.haml | 63 | ||||
| -rw-r--r-- | pages/about-us/jobs/en.text | 17 | ||||
| -rw-r--r-- | pages/docs/get-involved/project-ideas.md | 152 | ||||
| -rw-r--r-- | pages/services/technology/critiques/en.haml | 57 | ||||
| -rw-r--r-- | pages/services/technology/critiques/en.text | 56 |
6 files changed, 145 insertions, 265 deletions
diff --git a/pages/about-us/grantwriter.md b/pages/about-us/grantwriter.md deleted file mode 100644 index 394a1b4..0000000 --- a/pages/about-us/grantwriter.md +++ /dev/null @@ -1,65 +0,0 @@ -@title = "Job posting for grant writer" - -Overview -======================== - -LEAP Encryption Access Project (https://leap.se) is looking for a grant writer with a high-level understanding of the grant writing process, extensive experience writing successful proposals for highly competitive grants, excellent time management, and project management skills along with excellent communication skills. The Grant Writer will be expected to build and maintain relationships with foundations and other organizations offering grant opportunities, and must be highly self motivated. Experience and interest in online communication and internet freedom a big plus. - -* Start Date: ASAP -* Rate: Competitive non-profit -* Time: Min 4 months, 50% time preferred. -* Please contact mcnair@leap.se - -Responsibilities -====================== - -* Researching, developing and writing inquiries, letters an proposals requesting state and federal funds. - -* Tracking and monitoring assigned proposals, including their deadlines, requirements and written reports. - -* Identify potential funding sources including, but not limited to governmental programs, private foundations, corporation. - -* Contact potential funding sources to discuss eligibility requirements, criteria, interest, and potential programs, and maintain ongoing relationships with funding contacts. - -* Write grants and thoroughly compile required attachments for submission. - -* Help develop grant calendar for each year based on research and past funding history. - -* Create compelling, persuasive, well-structured grant narratives through the use of effective storytelling and superior prose--tying LEAP's needs to funder priorities. - -* Research, develop, write, package and submit grant proposals. - -* Effectively perform all aspects of grant development and submission, including tracking of information, soliciting and collecting support letters and memoranda of understanding, board resolutions, developing funder-compliant budgets, and coordinating with internal sources to elicit necessary data. - -* Undertake research for the purposes of gathering statistical, analytical and anecdotal data, analyzing those data, and using such data strategically to create compelling grant proposal narratives--which use current, evidence-based, peer-reviewed models, when appropriate. - -* Undertake research related to identification of funding sources to meet specific programmatic needs through use of internal resources (e.g., newsletters, grant indexes, Internet resources) and external resources (e.g., training opportunities, bidders' conferences). Determine "goodness of fit" based on funder & internal priorities. - -* Collaborate with finance, programs and compliance to ensure grant reporting and tracking grant compliance. - -Qualifications -====================== - -The ideal candidate will: - -* Ability to interface with personnel in a professional manner. -* 3+ years of successful grant writing experience with federal and government grants, as well as private foundation experience. -* Ability to demonstrate accomplishments and success in grants being awarded. -* Reporting experience with OMB Circular A-133 preferred. -* Strong organizational and interpersonal skills. -* Ability to write accurate, compelling narrative that uses grammar and spelling correctly. -* Ability to perform under deadlines and tight schedules. -* Ability to digest and comply with detailed instructions a must as is the ability to prioritize in the context of multiple projects. -* Experience developing program budgets for grant submissions. -* Experience with free and open source software a big plus. - -About LEAP -====================== - -LEAP Encryption Access Project 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). -* Everything we do is licensed as free and open source software (GPL whenever possible). -* People of color, women, and queer people are strongly encouraged to apply. diff --git a/pages/about-us/jobs/en.haml b/pages/about-us/jobs/en.haml deleted file mode 100644 index 1b61102..0000000 --- a/pages/about-us/jobs/en.haml +++ /dev/null @@ -1,63 +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. - - h1. Open Positions - - Currently, we have no open positions, but we would love to hear from you anyway. Please 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/pages/about-us/jobs/en.text b/pages/about-us/jobs/en.text new file mode 100644 index 0000000..aa7c359 --- /dev/null +++ b/pages/about-us/jobs/en.text @@ -0,0 +1,17 @@ +- @title = 'Jobs' + +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. + +h1. Open Positions + +Currently, we have no open positions, but we would love to hear from you anyway. Please contact mcnair@leap.se + diff --git a/pages/docs/get-involved/project-ideas.md b/pages/docs/get-involved/project-ideas.md index 5da5dd8..ff725d7 100644 --- a/pages/docs/get-involved/project-ideas.md +++ b/pages/docs/get-involved/project-ideas.md @@ -20,7 +20,8 @@ Email We have an extension for Thunderbird to autoconfigure for use with Bitmask. It would be great to do the same thing for Apple Mail. [Some tips to get started](http://blog.adamnash.com/2007/09/17/getting-ready-to-write-an-apple-mailapp-plug-in-for-mac-os-x/) and a "links to many existing Mail.app plugins"[http://www.tikouka.net/mailapp/] * Contact: drebs -* Difficulty: Medium +* Priority: Low +* Difficulty: Low * Skills: MacOS programming, Objective-C or Python (maybe other languages too?) ### Microsoft Outlook plugin @@ -28,16 +29,21 @@ We have an extension for Thunderbird to autoconfigure for use with Bitmask. It w We have an extension for Thunderbird to autoconfigure for use with Bitmask. It would be great to do the same thing for Outlook. * Contact: drebs -* Difficulty: Medium +* Priority: Low +* Difficulty: Low * Skills: Windows programming -### Mailpile fork +Soledad Client +--------------------------- -[Mailpile](http://www.mailpile.is/) is a new mail client written in Python with an HTML interface. Mailpile is interesting, because it is one of the few actively developed cross platform mail clients. Since the Bitmask application is also in Python, it would be nice to distribute a version of Mailpile with Bitmask that is preconfigured to work with whatever email accounts you have in Bitmask. Additionally, you would need to modify Mailpile so that it does not cache a copy of all email itself (since Bitmask app already keeps a copy in a client-encrypted database), and remove the OpenPGP parts of Mailpile (since this is already handled by Bitmask). +### Soledad port -* Contact: chiiph -* Difficulty: Medium -* Skills: Python +[[Soledad]] is our synchronized, client-encrypted, searchable database. It is written in Python, based on the Python implementation of U1DB (U1DB has similar features to Soledad, but has no encryption). There is also a C version of U1DB called libu1db. This project would be incrementally replace portions of the Python implementation with a version that can be compiled in order to make binding available on Android and iOS. + +* Contact: drebs +* Difficulty: Hard +* Priority: High +* Skills: C/C++, using crypto libraries correctly, test driven development. Linux --------------------------- @@ -46,7 +52,7 @@ Linux The Bitmask client application is entirely ported to Debian, with every dependency library now submitted to unstable. However, many of these packages are not in other flavors of linux, including RedHat/Fedora, SUSE, Arch, Gentoo. -* Contact: kali, micah, chiiph +* Contact: kali, micah, ivan * Difficulty: Medium * Skills: Linux packaging @@ -54,7 +60,7 @@ The Bitmask client application is entirely ported to Debian, with every dependen The Bitmask client application is entirely ported to Debian, with every dependency library now submitted to unstable. However, many of these packages are not in *BSD. -* Contact: chiiph +* Contact: ivan * Difficulty: Medium * Skills: BSD packaging @@ -65,7 +71,7 @@ Mac OS We are currently running openvpn through cocoasudo to run OpenVPN with admin privs, we should not depend on a third party app and handle that ourselves. The proper way to do this is with [Service Management framework](https://developer.apple.com/library/mac/#samplecode/SMJobBless/Introduction/Intro.html). -* Contact: chiiph, kali +* Contact: ivan, kali * Difficulty: Medium * Skills: Mac programming @@ -73,18 +79,10 @@ We are currently running openvpn through cocoasudo to run OpenVPN with admin pri Currently, we block DNS leakage on the OpenVPN gateway. This works, but it would be better to do this on the client. The problem is there are a lot of weird edge cases that can lead to DNS leakage. See [dnsleaktest.com](http://www.dnsleaktest.com/) for more information. -* Contact: kali, chiiph +* Contact: kali, ivan * Difficulty: Medium * Skills: Mac programming -### Support for older Mac OSs - -We support OSX 64bits x86 >= 10.7, but in order to support versions <10.7 there are a list of libraries that need to be built compatible with the specific SDK version and with PPC support (basically, boost and certain python modules). - -* Contact: chiiph, kali -* Difficulty: Medium to hard -* Skills: Mac programming - Windows ------------------------------- @@ -92,7 +90,7 @@ Windows The bundle needs to be a proper signed application in order to make it safer and more usable when we need administrative privileges to run things like OpenVPN. -* Contact: chiiph +* Contact: ivan * Difficulty: Easy to medium * Skills: Windows programming @@ -100,7 +98,7 @@ The bundle needs to be a proper signed application in order to make it safer and Right now we are building OpenVPN with a manifest so that it's run as Administrator. Perhaps it would be better to handle this with User Account Control. -* Contact: chiiph, kali +* Contact: ivan, kali * Difficulty: Medium * Skills: Windows programming @@ -108,7 +106,7 @@ Right now we are building OpenVPN with a manifest so that it's run as Administra Currently, we block DNS leakage on the OpenVPN gateway. This works, but it would be better to do this on the client. The problem is there are a lot of weird edge cases that can lead to DNS leakage. See [dnsleaktest.com](http://www.dnsleaktest.com/) for more information. -* Contact: kali, chiiph +* Contact: kali, ivan * Difficulty: Medium * Skills: Windows programming @@ -116,7 +114,7 @@ Currently, we block DNS leakage on the OpenVPN gateway. This works, but it would We dropped Windows support because we couldn't keep up with all the platforms, Windows support should be re-added, which means making sure that the gpg modules, Soledad and all the other components are written in a proper multiplatform manner. -* Contact: chiiph, drebs +* Contact: ivan, drebs * Difficulty: Easy to Medium * Skills: Windows programming, Python @@ -124,7 +122,7 @@ We dropped Windows support because we couldn't keep up with all the platforms, W We are aiming to distributing bundles with everything needed in them, but an amount of users will want a proper Windows installer and we should provide one. -* Contact: chiiph, kali +* Contact: ivan, kali * Difficulty: Medium * Skills: Windows programming @@ -132,7 +130,7 @@ We are aiming to distributing bundles with everything needed in them, but an amo All the python modules tend to be built with migw32. The current Windows bundle is completely built with migw32 for this reason. Proper Windows support means using Visual Studio (and in our case, the Express edition, unless the proper licenses are bought). -* Contact: chiiph +* Contact: ivan * Difficuty: Medium to Hard * Skills: Windows programming @@ -140,7 +138,7 @@ All the python modules tend to be built with migw32. The current Windows bundle We have support for Windows 32bits, 64bits seems to be able to use that, except for the TAP driver for OpenVPN. So this task is either really easy because it's a matter of calling the installer in a certain way or really hard because it involves low level driver handling or something like that. -* Contact: chiiph +* Contact: ivan * Difficulty: Either hard or really easy. * Skills: Windows programming @@ -151,25 +149,26 @@ Android Currently the Android app chooses which VPN gateway to connect to based on the least difference of timezones and establishes a configuration for connecting to it by a biased selection of options (port, proto, etc) from the set declared by the provider through the API. For cases where a gateway is unavailable or a network is restricting traffic that our configuration matches (e.g. UDP out to port 443), being able to attempt different configurations or gateways would help finding a configuration that worked. -* Contact: meanderingcode, parmegv, or richy -* Difficulty: Easy to medium +* Contact: parmegv +* Difficulty: Easy * Skills: Android programming ### Ensure OpenVPN fails closed For enhanced security, we would like the VPN on android to have the option of blocking all network traffic if the VPN dies or when it has not yet established a connection. Network traffic would be restored when the user manually turns off the VPN or the VPN connection is restored. Currently, there is no direct way to do this with Android, but we have a few ideas for tackling this problem. -* Contact: meanderingcode, parmegv, or richy -* Difficulty: Hard (Medium but meticulous, or harder than we think) -* Skills: Android programming, applicable linux skill like iptables +* Contact: parmegv +* Difficulty: Easy +* Skills: Android programming -### Port libraries to Android +## Improved UX -Before we can achieve full functionality on Android, we have a lot of Python libraries that need to either be ported to run directly on Android or to rewrite them natively in Java or JNI. We have been pursing both strategies, for different libraries, but we have a lot more work to do. +There are several areas where the user experience could be improved, particulary where it comes to our attempts to block unencrypted traffic. -* Contact: richy, meanderingcode, parmegv -* Difficulty: varies -* Skills: Android programming, compiling, Python programming. +* Contact: parmegv +* Priority: Medium +* Difficulty: Depends +* Skills: Android programming Installer and Build Process ---------------------------------------------- @@ -178,25 +177,24 @@ Installer and Build Process We rely on a group of binary components in our bundles, these include libraries like boost, Qt, PySide, pycryptopp among many others. All these should be built in a reproducible way in order to be able to sign the bundles from many points without the need to actually having to send the bundle from the main place it gets built to the rest of the signers. This will also allow a better integration with our automatic updates infrastructure. -* Contact: chiiph +* Contact: ivan * Difficulty: Medium to hard ### Automatic dependency collector for bundle creation The bundles are now used as a template for new versions, the first bundle was basically built by hand, adding one dependency after the other until it all worked. We would like to automate this process completely, since new dependencies tend to be added at certain points. One possibility would be to use PyInstaller dependency recollection code, another would be to use some of Python's module introspection to recursively collect dependencies. -* Contact: chiiph, kali +* Contact: ivan, kali * Difficulty: Medium to hard ### Lightweight network installer The bundles are big. It would be great if we could reduce its size, but that's not always possible when you are providing so many different things in one application. One way to work around this would be to have a really tiny application that runs Thandy, has the proper certificates and has a tiny lightweight UI so that the user can install the bundle's packages one by one and even pick parts that the user might not want. Just want to run Email? Then there's no need to download OpenVPN and all the chat and file sync code. -* Contact: chiiph -* Difficulty: Medium to hard +* Contact: ivan +* Difficulty: Medium * Skills: C/C++, Python - New Services ---------------------------------- @@ -204,15 +202,17 @@ New Services There are multiple password keepers that exist today, but they don't necessarily have a way to sync your passwords from device to device. Building a Soledad backed password keeper would solve all these problems implicitly, it's only a matter of UI and random password generation. -* Contact: drebs, chiiph, elijah -* Difficulty: Easy to medium. +* Contact: drebs, ivan, elijah +* Priority: Low +* Difficulty: Easy to medium * Skills: Python ### Notepad app This idea is basically a simple note pad application that saves all its notes as Soledad documents and syncs them securely against a Soledad server. -* Contact: chiiph, kali, drebs +* Contact: ivan, kali, drebs +* Priority: Low * Difficulty: Easy to medium * Skills: Python @@ -224,7 +224,7 @@ Miscellaneous The idea is to allow or require tokens in the new user signup process. These tokens might allow to claim a particular username, give you a credit when you sign up, allow you to sign up, etc. * Dependency: token-based signup in webapp API. -* Contact: elijah, chiiph +* Contact: elijah, ivan * Difficulty: Easy * Skills: Python @@ -232,21 +232,21 @@ The idea is to allow or require tokens in the new user signup process. These tok One thing that we really need is a team of people that is constantly updating their versions of the code and testing the new additions. Basic knowledge of Git would be needed, and some really basic Python. -* Contact: mcnair, elijah, chiiph +* Contact: mcnair, elijah, ivan * Difficulty: Easy to medium, depending on the QA team that is managed. ### Translations Do you speak a language that's not English? Great! We can use your help! We are always looking for translators for every language possible. -* Contact: ivan, kali, chiiph +* Contact: ivan, kali, ivan * Difficulty: Easy ### Support for OpenPGP smart cards A really nice piece of hardware is OpenPGP smart cards. What would be needed is a way to save the generated key in the smart card instead of in Soledad (or both, should be configurable enough) and then migrate the regular OpenPGP workflow to support these change. -* Contact: chiiph, drebs +* Contact: ivan, drebs * Difficulty: Medium ### Device blessing @@ -261,23 +261,15 @@ Add the option to require a one-time code in order to allow an additional device There are situations where the service provider you are using through the bitmask client might want to notify some event to all its users. May be some downtime, or any other problems or situations. There should be an easy way to push such notifications to the client. -* Contact: chiiph, elijah -* Difficulty: Easy to medium +* Contact: ivan, elijah +* Difficulty: Easy * Skills: Python ### Quick wipe of all data Some users might be in situations where being caught with software like OpenVPN is illegal or basically just problematic. There should be a quick way to wipe the existence of the whole bundle and your identity from provider. -* Contact: chiiph, kali, ivan, elijah -* Difficulty: Medium to hard -* Skills: Python - -### Add support for obfsproxy to Bitmask client - -After obfsproxy support is added to the platform, it needs to be enabled in the client. - -* Contact: chiiph, ivan, kali +* Contact: ivan, kali, ivan, elijah * Difficulty: Easy * Skills: Python @@ -285,22 +277,24 @@ After obfsproxy support is added to the platform, it needs to be enabled in the LEAP Platform =========================== -Soledad +Soledad Server --------------------------- ### Add support for quota Soledad server only handles authentication and basic interaction for sync, it would be good to have a way to limit the quota each user has to use and enforce it through the server. -* Contact: chiiph, drebs -* Difficulty: Medium to hard +* Contact: ivan, drebs +* Priority: Medium +* Difficulty: Medium * Skills: Python ### Add support for easier soledad server deployment Currently Soledad relies on a fairly complex CouchDB setup. It can be deployed with just one CouchDB instance, but may be if you are just using one instance you might be good enough with SQLite or other easy to setup storage methods. The same applies to authentication, may be you want a handful of users to be able to use your Soledad sever, in which case something like certificate client authentication might be enough. So it would be good to support these non-scalable options for deploying a Soledad server. -* Contact: chiiph, drebs +* Contact: ivan, drebs +* Priority: Low * Difficulty: Medium * Skills: Python @@ -308,13 +302,14 @@ Currently Soledad relies on a fairly complex CouchDB setup. It can be deployed w Bootstrapping Soledad and being able to sync with it is not a necessarily easy task, you need to take care of auth and other values like server, port, user id. Having an easy to use command line interface application that can interact with Soledad would ease testing both on the client as on the server. -* Contact: chiiph, drebs -* Difficulty: Easy to medium +* Contact: ivan, drebs +* Priority: Low +* Difficulty: Easy * SKills: Python ### Federated Soledad -Currently, each user's Soledad database is their own and no one else ever has access. It would be mighty useful to allow two or more users to share a Solidad database. +Currently, each user's Soledad database is their own and no one else ever has access. It would be mighty useful to allow two or more users to share a Solidad database. This would allow us to use Soledad for a shared calendar, for example. * Contact: drebs, elijah * Difficult: Hard @@ -353,26 +348,24 @@ OpenVPN Currently, OpenVPN gets configured to use a non-ECC DH cipher with perfect forward secrecy, but it would be nice to get it working with an Elliptical Curve Cipher. This greatly reduces the CPU load of the OpenVPN gateway. * Contact: elijah, varac -* Difficulty: Medium +* Priority: Low +* Difficulty: Low * Skills: OpenVPN, X.509 -### Add support for obfsproxy to the platform - -Sometimes OpenVPN will be blocked by firewalls or governments if the protocol is detected. Obfsproxy 3 is the most advanced tool available for circumventing this detection. Obfsproxy was concieved as a tool to reach the Tor network, but it can be used for other protocols too. We want to have the ability to use this for our Encrypted Internet solution. For more information, see [OpenVPN and Obfsproxy howto guide](http://www.dlshad.net/?p=135) and the [Obfsproxy project page](https://www.torproject.org/projects/obfsproxy.html.en). - -* Contact: varac, elijah -* Difficulty: Easy -* Skills: OpenVPN, Linux, networking - Email -------------------------- ### Mailing list support -Adapt the PSELS mailing list for use with the LEAP platform. PSELS uses OpenPGP in a novel way to achieve proxy re-encryption, allowing for a mailing list in which the server does not ever have access to messages in cleartext, but subscribers don't need to encrypt each message to the public key of all subscribers. For more information, read the [paper](http://www.ncsa.illinois.edu/people/hkhurana/ICICS.pdf). +Managing an encrypted mailing list is too difficult for most users. Even worse, existing solutions store a private key for the list on the server. It would be very useful to have a simple, end-to-end encrypted mailing list system that anyone could use. + +Our idea is a simple API that allows the client to query the subscriber list and set a new subscriber list. This command would include the addresses that should be subscribed to the list, and the full fingerprint of the key to use for each address. So long as this command was signed by a subscriber's private key, the list server accepts the new subscriber list. As an next iteration, the software could support the ability to designate that only "admins" have this ability. The client application would then include a simple form for modifying the list of subscribers. There would be no archives and no web interface. + +Another possibility is something like, [PSELS](http://www.ncsa.illinois.edu/people/hkhurana/ICICS.pdf). PSELS uses OpenPGP in a novel way to achieve proxy re-encryption, allowing for a mailing list in which the server does not ever have access to messages in cleartext, but subscribers don't need to encrypt each message to the public key of all subscribers. However, the setup is incredibly complex, and requires special keys. * Contact: elijah -* Difficulty: Extremely hard +* Priority: Medium +* Difficulty: Hard * Skills: Cryptography, Python @@ -390,7 +383,7 @@ The webapp has a payment infrastructure setup (Braintree), but it only supports Sometimes simple push notifications aren't enough, you may want to mail a newsletter to your users or more descriptive notifications, it should be possible for an administrator of a provider to use the webapp to quickly send mail to all its users. -* Contact: chiiph, azul, elijah +* Contact: jessi, azul, elijah * Difficulty: Easy ### Add support for quota @@ -407,6 +400,5 @@ Description: Once the Soledad server quota enforcement code is in place, it woul The idea is to allow or require tokens in the signup process. These tokens might allow to claim a particular username, give you a credit when you sign up, allow you to sign up, etc. * Contact: azul, jessi, elijah -* Difficulty: Easy to medium +* Difficulty: Easy * Skills: Ruby and Javascript - diff --git a/pages/services/technology/critiques/en.haml b/pages/services/technology/critiques/en.haml deleted file mode 100644 index 06fccdd..0000000 --- a/pages/services/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/pages/services/technology/critiques/en.text b/pages/services/technology/critiques/en.text new file mode 100644 index 0000000..acde975 --- /dev/null +++ b/pages/services/technology/critiques/en.text @@ -0,0 +1,56 @@ +@title = 'Critiques' + +h2. Isn't LEAP too ambitious? + +Yes. However, someone needs to be working on a long term plan to add real security and usability to federated messaging architectures. It will not be easy, but we think it is possible. + +h2. Isn't LEAP just like FreedomBox? + +LEAP and FreedomBox share a similar goal of ensuring that everyone has the right to communicate securely and without censorship. However, the projects use different strategies for achieving this goal. + +* *FreedomBox:* Empower every user to control the hardware on which all their data is stored. Users become their own service providers, running their own hardware. +* *LEAP:* Allow service providers to deploy a cloud-based infrastructure that can scale and is easily maintained. In addition to the performance and usability found in traditional cloud services, LEAP services are also designed to bring a very high level of security to everyday users. + +FreedomBox is an important project. It faces, however, some significant hurdles. Most users demand high availability, but current technology does not allow for hardware or software that is self healing. If it did, sysadmins would be out of work. Things go wrong all the time. Take, for example, email: it is very common for an email server to get spam-bombed, or added to a blacklist, or any number of other problems that require manual intervention by a system administrator to fix. Also, most ISPs block the port needed for email rely. + +In the long run, FreedomBox has a lot of potential. But for the foreseeable future, we think it is important to also pursue the LEAP strategy. + +h2. We should not encourage users to store any data in the cloud, encrypted or not + +Even the best encryption is no guarantee of confidentiality; data in the cloud always has the potential to be decrypted by a determined attacker. + +The entire issue boils down to a matter of degree. Although there is no necessary trade off between security and convenience, you can usually achieve a higher level of security in any system by sacrificing some convenience. But what level of protection and convenience is appropriate for a particular user? + +There are very few people for whom client-encrypted data stored in the cloud will be the weakest link in the confidentiality of their communication and stored data. Most likely, there will be many aspects of their communication that are much more attractive targets to a determined adversary. + +If a person has a threat model that includes an adversary with the resources to both acquire the user's cloud data and to decrypt it, then there is little that LEAP or any other third party can do for them. They will need to become highly proficient at managing and protecting all their own data. + +There are many tools and projects out there to help a user do this. LEAP is designed for a different audience, one not adequately addressed by existing technology: people who want high security but don't have the capacity to become highly skilled in self-managing their encryption. There is room--and need--for both approaches, and it is likely that the amount of people who want high security but do not have the time or skills to adequately self-manage their own environment is already large and increasingly rapidly. + +h2. If you make your system architecture public, then you have given adversaries a blueprint to attack you + +This is, of course, similar to the arguments about the security of FLOSS. Openness can indeed lead to attacks, but more eyes leads to better security. + +In the case of an entire service provider infrastructure, however, it could be argued that things are different. We are not talking about a single piece of software, but the whole integration across many servers and services. A related critique is the potential problem of monoculture: if LEAP is successful, then a high percentage of the secure service providers will be using systems with the same vulnerabilities. + +Monoculture and openness are both interesting issues that could pose problems for the future. We can only be diligent in assessing LEAP once it is deployed by a variety of organizations. With enough flexibility in configuration, it may be that each LEAP deployment is sufficiently distinct from the others to mitigate these concerns. + +h2. Users will not be willing to download a custom client + +This will indeed be the case for a large number of potential users. Because meaningful levels of security cannot be achieved using current technology without a custom client, our hope is that a critical mass of users can be induced to use one. There are two parts to this inducement: increasing awareness as to why an extra step to ensure security is worthwhile, and decreasing the difficulty in actually taking this step. With sufficient education and an improved user experience, many users should be willing to install a custom client. + +On the other hand, rapid developments in Javascript and web browser technology have raised the possibility of running advanced client applications within the browser itself. In this case, a user would not have to install any additional software. However, in-browser crypto is still an area of active research but is currently not safe for deployment, with some areas still to be worked out (like sufficient entropy). LEAP does not depend upon the presence of cryptography in the browser, but would benefit from this should it become viable. The lead W3C employee who began the standardization of Javascript Cryptography is on the board of LEAP, and he will liaise tightly with LEAP as the work matures. + +h2. Users who need security often don't have their own device or access to the internet + +This is absolutely true. The digital divide is alive and well, and LEAP does nothing to bridge the gap between the technological haves and have-nots. However, in the long run, IP-based communication--dependent upon advanced devices such as smart phones--is likely to replace most other forms of communication. The cost of such IP-based communication devices and their connectivity is declining rapidly. It behooves us to lay the groundwork now for a secure IP-based communication infrastructure, both for the people who currently rely on the internet and for the next billion who will gain access to the internet in the near future. + +h2. Client encryption is excessive for most people + +The argument against client encryption is something like this: a secure connection is good enough, so long as the service provider is located in a country with adequate legal protection and without repressive laws. + +There are many reasons why users should be put in control of their data and should not be made to rely on a third party to safeguard it. Third parties have proven to be highly undeserving of trust--They might close shop, bow to pressure from local government, become compromised by external attacks, or accidentally leak sensitive data due to carelessness. + +Our goal is to make secure communication the default for a critical mass of users worldwide. A vital part of this strategy is cooperation with ISPs and service providers who speak the local language of their users and who are attuned to the needs of a particular context. These local service providers don't have the luxury of determining which government's jurisdiction they fall under. However, so long as encryption technology itself is not outlawed, local providers using the LEAP platform will be able to provide a high level of security for their users. + +By requiring client encryption for all services, LEAP also helps to mitigate against the myriad vulnerabilities inherent with most devices. While the LEAP client cannot defend against keyloggers, malware, or penetration of the host OS, it can ensure that all the LEAP cloud data synced by the device is stored in an encrypted format.
\ No newline at end of file |