2.4 KiB
title, description
| title | description |
|---|---|
| General Criteria | A list of general priorities we consider for all submissions to Privacy Guides. |
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.
Pénzügyi Nyilatkozat
Nem keresünk pénzt bizonyos termékek ajánlásával, nem használunk affiliate linkeket, és nem nyújtunk különleges bánásmódot a projekt adományozóinak.
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 white paper 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.