Responsible Publishing of Privacy Software
In the months since we went public with plans for the Privly Project, numerous commercial and non-profit open source projects have launched that ostensibly provide their users with online privacy. In many cases, these projects have launched for users with such poor implementations that they compromise a system's reason for existence. Unfortunately, the trend of "too soon" publishing is likely to continue for privacy software targeted at the general public. The problem is that although these projects fail to meet their basic requirements, the exposure they gain from launching is typically more valuable than the reputation loss incurred by faults. After years of Patch Tuesdays, non-sophisticated users don't understand the breach of trust of premature privacy software.
We consider the bare minimum threshold for reaching a Beta version of a system to be:
- Full test coverage of the code
- An in-depth security review of the system with numerous parties attacking the implementation
Privly's work on meeting these objectives is ongoing.
Privly Security Review Status: The Privly Foundation is pursuing several options for a full security review of the Privly Project. Informal reviews of the system's concept have come back supporting the base concept of the system, but the code base is still changing too quickly for a full review of the implementation. To date, we have opened more than 200 issues on Privly Project repositories. We currently stand with 161 closed issues and 66 open issues. While the code base stabilizes, we have been building relationships with organizations that often perform pro-bono reviews of open source software. We are also working on publishing a Privly paper in a peer-reviewed publication.
Putting Trust in your Users
Although Privly development has always been open to contributors, Privly has remained closed to users out of an abundance of caution. Privly is beginning to open its development servers to backers with the requirement that all content creation pages contain ample warnings. Although we cannot make strong security and privacy claims on the current system, we can at least empower our eventual users to appropriately experiment with the development versions of the system. Building usable cryptographic infrastructure requires user input during development so they can test the software and influence the requirements of the system.