102693168a
Signed-off-by: Jonah Aragon <jonah@privacyguides.org> Signed-off-by: kimg45 <138676274+kimg45@users.noreply.github.com> Signed-off-by: Daniel Gray <dngray@privacyguides.org>
2.3 KiB
| title |
|---|
| General Criteria |
Below are some general priorities we consider for all submissions to Privacy Guides. Each category will have additional requirements for inclusion.
- Security: Tools should follow security best practices wherever applicable.
- Source Availability: Open-source projects are generally preferred over equivalent proprietary alternatives.
- Cross-Platform Availability: 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.
- Documentation: Tools should have clear and extensive documentation for use.
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.
Developer Self-Submissions
We have these requirements in regard to developers which wish to submit their project or software for consideration.
-
Must undergo our self-submission process as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
-
Must disclose affiliation, i.e. your position within the project being submitted.
-
Must have a security whitepaper if it is a project that involves the handling of sensitive information like a messenger, password manager, encrypted cloud storage, etc.
- Regarding third party audit status, we want to know if you have undergone one, or have requested one. If possible please mention who will be conducting the audit.
-
Must explain what the project brings to the table in regard to privacy.
- What new problem(s), if any, does it solve?
- 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. Ideally, a developer should be able to identify what common threat(s) their project protects against.