On the Chopping Block
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.
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.