Skip directly to content

On the Chopping Block

on Thu, 10/10/2013 - 19:19

Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away... -Antoine de Saint-Exupery

After many hours of development, we have a flexible foundation for privacy and security on the web. While the technical foundation is strong, there are several ill-conceived or poorly implemented features which must now be removed. Much of this functionality will be coming back in one form or another.

Compiled Library: Cross-browser extensions are a bizarre world, built upon the web stack but without a web standard. Privly's "Injectable Application" abstraction simplifies much of this work, but shipping a cross-platform compiled cryptography library on top of Privly's base architecture is a logistical nightmare that will be unnecessary by the time it is completed for all platforms. Already we are beginning to see the fruits of a W3C working group writing the standard for JavaScript web cryptography.

In order to layer several planned features on top of Privly, including a peer-to-peer network, Privly may need a compiled library built on top of the extension stack. However, from this point forward the goal of the library is not to provide a large cryptography API for use by injectable applications, but it is to fix security problems as-necessary with the JavaScript runtime.

Private Posts: The Rails content server allows users to mark posts as "private." If a user marks a post "private," only the user who created the post and anyone the user shares the content with will have access to it. Including this functionality in the server is contrary to the "Don't Trust Us" philosophy because it relies on the service provider to reliably enforce the access rule. Future versions of the injectable applications will support private posts as a side effect of cryptography, rather than the fidelity of the online service provider.

Access Control Lists: The Rails content server has functionality for permissioning content by password, email, domain, and IP address but this permissioning was based on rules implemented on the server rather than with strong cryptography. This functionality will be making a comeback in subsequent versions -- only with better usability and cryptographic foundations. For instance, instead of using Facebook API requests to authorize access to content, we can share content with Facebook accounts via cryptographic strings posted to publicly accessible areas of Facebook profiles. Nearly every online identity type could be distributed in this manor.

Passive and Burnt Messaging: An early concern in Privly Project development was the capacity for links to be used for tracking user page views. A solution placed cleartext content onto the link's parameter string so it would not require any network requests. This functionality is no longer necessary and presented complexity that reduced Privly's usability. The use case has been incorporated directly into the "injectable application" paradigm since the injectable application can define its own API that includes additional parameters for situations where the user does not want to generate a network request.