privacyguides.org/docs/about/criteria.md

title
General Criteria

!!! example "Work in Progress"

The following page is a work in progress, and does not reflect the full criteria for our recommendations at this time. Past discussion on this topic: [#24](https://github.com/privacyguides/privacyguides.org/discussions/24)

Below are some things that must apply to all submissions to Privacy Guides. Each category will have additional requirements for inclusion.

Financial Disclosure

We do not make money from recommending certain products, we do not use affiliate links, and we do not provide special consideration to project donors.

General Guidelines

We apply these priorities when considering new recommendations:

• Secure: Tools should follow security best-practices wherever applicable.
• Source Availability: Open source projects are generally preferred over equivalent proprietary alternatives.
• Cross-Platform: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in.
• Active Development: The tools that we recommend should be actively developed, unmaintained projects will be removed in most cases.
• Usability: Tools should be accessible to most computer users, an overly technical background should not be required.
• Documented: Tools should have clear and extensive documentation for use.

Developer Self-Submissions

We have these requirements in regard to developers which wish to submit their project or software for consideration.

• Must disclose affiliation, i.e. your position within the project being submitted.

• Must have a security whitepaper if it is a project that involves handling of sensitive information like a messenger, password manager, encrypted cloud storage etc.

  • Third party audit status. We want to know if you have one, or have one planned. If possible please mention who will be conducting the audit.

• Must explain what the project brings to the table in regard to privacy.

  • Does it solve any new problem?
  • Why should anyone use it over the alternatives?

• Must state what the exact threat model is with their project.

  • It should be clear to potential users what the project can provide, and what it cannot.

--8<-- "includes/abbreviations.en.txt"