The Process, Requirements, and Certification - v1.0
For a product to be Openly Operated, it must follow and pass the certification process: fulfill requirements, prove claims, and complete audits. To follow along with an example, follow along with Lockdown Privacy's OpenAudit in a separate window. We're happy to answer questions about any of Openly Operated process — just contact us.
These are the requirements for demonstrating a basic level of transparency, and they can be thought of as the "raw materials" for auditors, security and privacy experts, and the general public to analyze and work with.
Each requirement has a description describing the requirement, rationale or the reason behind the requirement, and verification which contains suggestions on how to verify completion of the requirement. Verification is a bare-minimum suggestion — auditors are free to and encouraged to go well beyond it to find issues and flaws.
| Description | Clearly state what the product is, its purpose, and people who own and build it. Owners and operators of the service must be identified with at least their full name, recent photos, and reachable contact information, including business address. Pseudonyms, placeholders, and nicknames are not acceptable. |
| Rationale | Identifying owners and operators not only creates meaningful accountability, but it also incentivizes more honest product operation and behavior. Millions of users give their personal information to a product in the course of using it — they have the right to know who is behind it. |
| Verification | Manually verify each item (product, purpose, people, location) by appropriate means, whether that's search engine to find references, viewing social profiles, testing contact information, etc. Verifications of these items won't ever be 100% guaranteed, so it's sufficient to document how the operation's items seem reasonably legitimate and has no red flags. |
| Description | All server and client code must be open source and fully documented. All libraries and usage of third party or external APIs must also be noted, leaving no room for unknown behavior. |
| Rationale | The source code determines the behavior of computers and servers, so seeing all the source code (not a partial release) is essential to knowing what is (and isn't) being done with user data, as well as revealing any malicious behavior. |
| Verification | ✓ Completeness - Check that all source code is public and that there are no missing parts. Optionally, build the source code to create the product. No part of the source code should be precompiled binaries (closed source), and note any suspicious third party libraries. |
| ✓ User Data Handling - Find the points where user data enters the server, and follow them to their storage (encryption, security) and handling (third parties APIs and libraries). Be sure to check for logging, such as IPs and other Personally Identifiable Information. | |
| ✓ Security - What measures are used to protect the server from both internal and external threats? Are they sufficient, up-to-date, and complete? Is it possible for employees to steal user data without leaving a trail? | |
| Description | All configuration and infrastructure of the app must be fully documented and public. Any parts of the infrastructure that rely on third parties or opaque services should be noted. This should be detailed enough that an auditor could build a test environment for validation. |
| Rationale | Configuration and infrastructure define the what, when, where, and how of deploying and executing the source code, as well as many crucial aspects relating to user data, such as storage and encryption. It is just as important as source code itself. |
| Verification | ✓ Completeness - Check that all infrastructure is public and there are no missing pieces. Optionally, build the infrastructure to create a test environment. |
| ✓ Secrets and Keys - Are operators able to access secrets and keys such as database password, encryption keys, hashes? If so, how can they prove it isn't abused? | |
| ✓ Security - What measures are used to protect the server from both internal and external threats? Are they sufficient, up-to-date, and complete? Is it possible for employees to steal user data without leaving a trail? | |
| Description | Openly Operated products must have one or more trails of logs showing all operator actions from the moment the product is created. Audit trails must be impartial, authentic, and comprehensive. |
| Impartial - Audit trails should be generated by an impartial mechanism, which usually means they're automatically generated by the platform on which the product is built. If the platform's trail doesn't cover all operator actions, any custom audit trails should show proof of impartiality. | |
| Authentic - Audit trails should be impossible or extremely difficult to forge, tamper with, or delete. Auditors and the general public should be able to personally verify authenticity of the audit trails. | |
| Comprehensive - Audit trails should cover the entire time period from the creation of the production environment of the app until the current date. The trail should have a comprehensive record of all potentially dangerous operator actions that could compromise user data. | |
| Rationale | In order to see what code and infrastructure is really running in production and to see what the operator has done with user data, Openly Operated products need to present a reliable "source of truth" — unbiased, verifiable audit trails. Without audit trails, auditors and users are left to rely on blind trust of the operators, defeating the purpose of earning trust transparency. |
| Verification | Verify the Impartial, Authentic, and Comprehensive traits described above. For the Comprehensive trait, pay special attention to these questions: Are all operator actions that could possibly compromise user data logged? Assuming the operator is a malicious actor (or bought out by a malicious actor), could user data be secretly exploited without this behavior being exposed? |
| Description | Provenance means "the origin of something". Openly Operated products establish provenance by proving that the source code and infrastructure presented in the requirements (the "origin") matches the production environment. To do this, follow the code and infrastructure step-by-step, providing proof and explanation on each step for why tampering cannot occur. |
| Rationale | The requirements of Open Source and Open Infrastructure aren't useful if there's no way to verify that the presented code and infrastructure presented are what's actually running in production. Establishing provenance ensures the code and infrastructure evidence that is cited in Proving Claims is reliable and accurate. |
| Verification | Follow the code and infrastructure from the user to the server and back. Are there any gaps that could be compromise the integrity of the source code and infrastructure presented? Check that the servers that the public is connecting to are the servers being audited, not some other server, either by verifying that the DNS nameserver entries in the infrastructure, or by some other means. |
Provide claims regarding the privacy, security, or other important aspects of the product, keeping them as simple as possible, and by referring to content from the Requirements and other resources as necessary. Proof should be reproducible and based on unforgeable evidence. Unsubstantiated assertions such as "Read our Privacy Policy" do not qualify as proof.
Since Privacy Policies and Terms can be lengthy, choose the most relevant points to highlight and explain. This varies depending on the product, but should be what the end user is most likely interested in — for example, a photo sharing app should focus on the handling of user photos, instead of the algorithm used to compress photos.
Questions that may help in choosing privacy and security claims to prioritize:
Proof and explanations should be simple to understand and whenever possible, point to the exact files in the code, infrastructure or audit logs and results for reference. Break down proof into smaller steps when there is a sequence of logic. Auditors, end users, and the community can request clarifications and further proof in the final Complete OpenAudit stage.
Sign up and create a document on OpenAudit that contains the requirements and claims with proof above. Contact us at hi@openaudit.com, and we'll walk you through the rest of the auditing process. After that, your OpenAudit and results are made public for your users and customers to see. Services should be re-audited frequently.
An OpenAudit contains the Requirements and Claims with Proof sections above, and they let auditors or anyone else verify the privacy, security, and other claims of an Openly Operated product. A compelted example is Lockdown Privacy's OpenAudit. Here's what to include:
Once the OpenAudit document is completed, contact us at hi@openaudit.com, and we'll walk you through the rest, including matching you with an auditor to complete the process.
After the OpenAudit is published, users of the product (and the public) can become part of helping improve the product by finding issues that the auditor may not have focused on. Anyone can contact the operator for further questions, clarifications, and feedback. If any changes are necessary, code/infrastructure is updated, or a new revision is released. Establishing a public community such as a Discord channel or moderated subreddit is encouraged, and of course, users can create issues in the product's public repositories.
At the point, the operator can also choose to create a public bounty reward for finding issues or contributing to the product or its OpenAudit. The reward doesn't necessarily have to be cash — in fact, non-cash rewards such as a year's free subscription could build a stronger community around the product.
User BenefitsA deeper look into the many benefits for users, with examples and references.
For CompaniesSee why companies and businesses also benefit from being Openly Operated.
How ToThe requirements for Openly Operated products, and how to get started.
About UsRead about the values, mission, origin, and creators of Openly Operated.
Get InvolvedDiscuss Openly Operated, transparency, the future of the web, and any related topics.