mirror of
https://github.com/privacyguides/privacyguides.org.git
synced 2024-09-16 22:43:23 +00:00
43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
|
---
|
||
|
|
title: Criterios generales
|
||
|
|
---
|
||
|
|
|
||
|
|
!!! example "Trabajo en Progreso"
|
||
|
|
|
||
|
|
La siguiente página se encuentra en construcción, y no refleja todos los criterios para nuestras recomendaciones en este momento. Discusión anterior sobre este tema: [#24](https://github.com/privacyguides/privacyguides.org/discussions/24)
|
||
|
|
|
||
|
|
Abajo se encuentran algunos aspectos que deben cumplir todos los envíos a Privacy Guides. Cada categoría puede tener requisitos adicionales.
|
||
|
|
|
||
|
|
## Información financiera
|
||
|
|
|
||
|
|
No obtenemos dinero al recomendar ciertos productos, nosotros no utilizamos enlaces de afiliados, y no realizamos alguna consideración especial a los patrocinadores del proyecto.
|
||
|
|
|
||
|
|
## Lineamientos generales
|
||
|
|
|
||
|
|
Aplicamos estas prioridades al considerar nuevas recomendaciones:
|
||
|
|
|
||
|
|
- Herramientas **seguras**: Las herramientas deben seguir las mejores prácticas de seguridad cuando sea necesario.
|
||
|
|
- **Disponibilidad del código**: Proyectos de código abierto son preferidos sobre alternativas similares de código cerrado.
|
||
|
|
- **Multiplataforma**: Preferimos que las recomendaciones sean multiplataforma para evitar la dependencia de un sistema.
|
||
|
|
- **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.es.txt"
|