We've got a draft, two posters, a community site, and a coalition + P3P


#1

Over the past few weeks, OpenPD has made several exciting steps forward. We set out with the lofty goal to render the traditional convoluted privacy policy obsolete, and we’re making solid headway: a lawyer has now reviewed a draft of the core legal text, we’ve designed two promotional posters, and our coalition is growing. In this update, I’ll also address the similarities and differences between OpenPD and P3P, a failed W3C initiative in the same arena as OpenPD.

Updates

Core legal text. There is now a preliminary draft of the core legal text. It still isn’t ready for distribution or use, but we’ve made significant advances toward a first complete draft. As with any license, its use will be left to the discretion of the user with the assistance of competent legal counsel. As this project develops, additional changes may be made to the core text. I have made a point of prioritizing thoroughness and quality over speed; haste and legal documents are never a good mix. You can read the most recent copy of the draft here.

Two posters. In order to help spread OpenPD’s project and mature its visual identity, I designed two posters (16x20 inches). Feel free to share these posters however you’d like—all I ask is that you do not remove OpenPD’s branding from the bottom of the documents. (They are licensed CC-BY-SA.) I’d be curious to know which poster you prefer. Images of the posters are included at the end of the update.

Community site. To make the development of OpenPD even more transparent, I launched OpenPD Meta, a discussion board for everything OpenPD related. There, I’ve been documenting the latest changes and updates to OpenPD. When OpenPD launches, the site will also serve as a help forum. If you’d like to provide feedback to OpenPD on a more regular basis, OpenPD Meta is where you want to be.

Coalition. OpenPD has three elements: the technical, the legal, and the sociological. First, we need to understand the technical needs of data privacy standardization and user protection. Then we need to create a legal contract that adheres to those technical needs. Finally, we need to convince people to adopt OpenPD. All these elements are critical to OpenPD’s success, and a strong coalition of contributors is critical to all these elements. If you know someone who would be interested in adopting OpenPD, or someone who might be able to contribute, please connect them to the project by forwarding them this email. Feel free to put me (miles@rmrm.io) on CC.

Thoughts

This week, someone brought a now-defunct W3C project to my attention called P3P. Here is a description of P3P according to Wikipedia:

The Platform for Privacy Preferences Project (P3P) is an obsolete protocol allowing websites to declare their intended use of information they collect about web browser users. Designed to give users more control of their personal information when browsing, P3P was developed by the World Wide Web Consortium (W3C) and officially recommended on April 16, 2002. Development ceased shortly thereafter and there have been very few implementations of P3P. Microsoft Internet Explorer and Edge were the only major browsers to support P3P. Microsoft has ended support from Windows 10 onwards. Microsoft Internet Explorer and Edge on Windows 10 will no longer support P3P.

OpenPD and P3P certainly try to solve similar problems: namely, both try to standardize the privacy policy into a machine-readable format that puts user rights first. Fortunately, OpenPD is fundamentally different from P3P, and most of the criticisms levied at P3P aren’t applicable to OpenPD. Here’s why:

  • OpenPD bites, P3P didn’t. OpenPD is a legal contract between a service and its users. The machine-readable OpenPD configuration—the OpenPD protocol, so to speak—only serves to enable the standardization of that contract. P3P, on the other hand, is only a protocol. There’s no contract that it’s standardizing; the protocol is it. That means there’s no guarantee that a service will uphold its P3P policy, as P3P isn’t a contract.

  • OpenPD isn’t XML. P3P allowed users to specify the threshold of data collection up to which they were comfortable in a complex XML-based format. OpenPD configurations, on the other hand, are just as human-readable as they are machine-readable.

  • OpenPD protects user rights, and P3P didn’t. P3P didn’t require sites to allow users to delete their data, nor did it enforce proper data breach disclosure. It couldn’t! After all, P3P was a protocol, not a policy—it couldn’t enforce such requirements by its nature.

The fundamental difference between OpenPD and P3P is that OpenPD is a policy while P3P was a protocol. P3P helps services communicate their privacy practices, but OpenPD will enable services to actually implement positive privacy practices. Both projects set out to improve user trust and privacy protections online, but they each take entirely different approaches. There’s a lot to learn from the failure of P3P, but there are also meaningful differences between the two projects which cannot be ignored.

Next steps

Over the next week, we’ll be working to:

  1. Complete a preliminary draft of all v1.0 collection and use codes.
  2. Perform another iteration on the legal text.
  3. Expand the coalition.

If you’d like to help in any capacity, please just respond to this message or send me an email at miles@rmrm.io.

Closing notes

Thank you all indicating your interest in OpenPD at such an early stage. If you have any suggestions or contributions, please don’t hesitate to get involved at https://meta.openpd.org, by emailing me at miles@rmrm.io, or by responding to this message.

Regards,
Miles McCain