mirror of
https://github.com/privacyguides/i18n.git
synced 2025-06-21 18:24:22 +00:00
New Crowdin translations by GitHub Action
This commit is contained in:
Crowdin Bot
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Für jede Kategorie gelten zusätzliche Anforderungen für die Aufnahme.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Verfügbarkeit des Quellcodes**: Open-Source-Projekte werden meist gegenüber gleichwertigen proprietären Alternativen bevorzugt.
|
||||
- **Cross-Platform Availability**: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in.
|
||||
- **Aktive Entwicklung**: Die von uns empfohlenen Tools sollten aktiv weiterentwickelt werden, nicht gewartete Projekte werden in den meisten Fällen entfernt.
|
||||
- **Benutzerfreundlichkeit**: Die Tools sollten für die meisten Computerbenutzer zugänglich sein, ein übermäßig technischer Hintergrund sollte nicht erforderlich sein.
|
||||
- **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.
|
||||
|
||||
## Finanz-Offenlegung
|
||||
@ -19,14 +19,16 @@ Wir verdienen kein Geld mit Empfehlungen bestimmter Produkte, wir verwenden kein
|
||||
|
||||
Wir haben diese Anforderungen an Entwickler, die eigene Projekt oder Software zur Prüfung einreichen möchten.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Muss die Zugehörigkeit offenlegen, d.h. deine Position innerhalb des eingereichten Projekts.
|
||||
|
||||
- Es muss ein Sicherheits-Whitepaper vorliegen, wenn es sich um ein Projekt handelt, das den Umgang mit sensiblen Informationen beinhaltet, wie z. B. ein Messenger, ein Passwortmanager, ein verschlüsselter Cloud-Speicher usw.
|
||||
- Status der Prüfung durch Dritte. Wir möchten wissen, ob eine vorhanden oder geplant ist. Wenn möglich, gib bitte an, wer die Prüfung durchführen wird.
|
||||
- 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. Wenn möglich, gib bitte an, wer die Prüfung durchführen wird.
|
||||
|
||||
- Muss erklären, was das Projekt im Hinblick auf den Schutz der Privatsphäre bietet.
|
||||
- Löst es ein neues Problem?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Warum sollte jemand es den Alternativen vorziehen?
|
||||
|
||||
- Es muss angegeben werden, was das genaue Bedrohungsmodell für das Projekt ist.
|
||||
- Den potenziellen Nutzern sollte klar sein, was das Projekt bieten kann und was nicht.
|
||||
- Den potenziellen Nutzern sollte klar sein, was das Projekt bieten kann und was nicht. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: Γενικά κριτήρια
|
||||
|
||||
Ακολουθούν ορισμένες γενικές προτεραιότητες που εξετάζουμε για όλες τις υποβολές στο Privacy Guides. Κάθε κατηγορία θα έχει πρόσθετες απαιτήσεις για τη συμπερίληψη.
|
||||
|
||||
- **Ασφάλεια**: Εργαλεία θα πρέπει να ακολουθούν τις βέλτιστες πρακτικές ασφάλειας, όπου αυτό είναι εφικτό.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Διαθεσιμότητα πηγής**: Προτιμώνται γενικά τα έργα ανοικτού κώδικα έναντι ισοδύναμων ιδιόκτητων εναλλακτικών λύσεων.
|
||||
- **Διαθεσιμότητα σε όλες τις πλατφόρμες**: Για να αποφύγουμε το κλείδωμα σε έναν προμηθευτή, συνήθως προτιμούμε οι συστάσεις να είναι διαπλατφορμιστικές.
|
||||
- **Ενεργή ανάπτυξη**: Τα εργαλεία που προτείνουμε θα πρέπει να αναπτύσσονται ενεργά, και τα μη συντηρούμενα έργα θα αφαιρούνται στις περισσότερες περιπτώσεις.
|
||||
- **Ευχρηστία**: Δεν θα πρέπει να απαιτείται υπερβολικά τεχνικό υπόβαθρο.
|
||||
- **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.
|
||||
- **Τεκμηρίωση**: Τα εργαλεία πρέπει να διαθέτουν σαφή και εκτενή τεκμηρίωση για τη χρήση τους.
|
||||
|
||||
## Οικονομική Γνωστοποίηση
|
||||
@ -19,14 +19,16 @@ title: Γενικά κριτήρια
|
||||
|
||||
Έχουμε αυτές τις απαιτήσεις όσον αφορά τους προγραμματιστές που επιθυμούν να υποβάλουν το έργο ή το λογισμικό τους για εξέταση.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Πρέπει να γνωστοποιήσετε τη σχέση σας, δηλαδή τη θέση σας στο πλαίσιο του υποβαλλόμενου έργου.
|
||||
|
||||
- Πρέπει να υπάρχει ενημερωτικό δελτίο ασφάλειας, εάν πρόκειται για έργο που περιλαμβάνει χειρισμό ευαίσθητων πληροφοριών, όπως messenger, διαχειριστή κωδικών πρόσβασης, κρυπτογραφημένη αποθήκευση στο cloud κλπ.
|
||||
- Κατάσταση ελέγχου κώδικα (audit) από τρίτους. Θέλουμε να μάθουμε αν έχετε ή σχεδιάζετε ένα. Εάν είναι δυνατόν, αναφέρετε ποιος θα διενεργήσει τον έλεγχο.
|
||||
- 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. Εάν είναι δυνατόν, αναφέρετε ποιος θα διενεργήσει τον έλεγχο.
|
||||
|
||||
- Πρέπει να εξηγήσει τι προσφέρει το έργο όσον αφορά την προστασία της ιδιωτικότητας.
|
||||
- Επιλύει κάποιο νέο πρόβλημα;
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Γιατί να το χρησιμοποιήσει κάποιος αντί για τις εναλλακτικές λύσεις;
|
||||
|
||||
- Πρέπει να δηλώσετε ποιο είναι το ακριβές μοντέλο απειλής με το έργο τους.
|
||||
- Θα πρέπει να είναι σαφές στους δυνητικούς χρήστες τι μπορεί να προσφέρει το έργο και τι όχι.
|
||||
- Θα πρέπει να είναι σαφές στους δυνητικούς χρήστες τι μπορεί να προσφέρει το έργο και τι όχι. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: Criterios generales
|
||||
|
||||
A continuación se encuentran algunas prioridades generales que consideramos para todos los envíos a Privacy Guides. Cada categoría puede tener requisitos adicionales.
|
||||
|
||||
- **Seguridad**: Las herramientas deben seguir las mejores prácticas de seguridad siempre que sea posible.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Disponibilidad del código**: Proyectos de código abierto son preferibles sobre alternativas similares de código cerrado.
|
||||
- **Disponibilidad multiplataforma**: Preferimos que las recomendaciones sean multiplataforma para evitar la dependencia de un sistema operativo.
|
||||
- **Desarrollo activo**: Las herramientas que recomendamos deben ser desarrolladas activamente, los proyectos no mantenidos serán eliminados en la mayoría de los casos.
|
||||
- **Usabilidad**: Las herramientas deben ser accesibles para la mayoría de los usuarios de ordenador, no debe exigirse una formación demasiado técnica.
|
||||
- **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.
|
||||
- **Documentación**: Las herramientas deben tener una documentación clara y extensa.
|
||||
|
||||
## Información financiera
|
||||
@ -19,14 +19,16 @@ No obtenemos dinero al recomendar ciertos productos, nosotros no utilizamos enla
|
||||
|
||||
Estos son los requisitos que exigimos a los desarrolladores que deseen presentar su proyecto o programa informático.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Debe revelar su afiliación, es decir, su cargo dentro del proyecto que se presenta.
|
||||
|
||||
- Debe tener un documento de seguridad si se trata de un proyecto que implica el manejo de información sensible, como un mensajero, un gestor de contraseñas, almacenamiento cifrado en la nube, etc.
|
||||
- Estado de la auditoría de terceros. Queremos saber si tiene una, o tiene prevista una. Si es posible, mencione quién realizará la auditoría.
|
||||
- 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. Si es posible, mencione quién realizará la auditoría.
|
||||
|
||||
- Debe explicar qué aporta el proyecto en materia de privacidad.
|
||||
- ¿Resuelve algún problema nuevo?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- ¿Por qué utilizarlo en lugar de otras alternativas?
|
||||
|
||||
- Deben indicar cuál es el modelo de amenaza exacto de su proyecto.
|
||||
- Los usuarios potenciales deben tener claro qué puede ofrecer el proyecto y qué no.
|
||||
- Los usuarios potenciales deben tener claro qué puede ofrecer el proyecto y qué no. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: Critères généraux
|
||||
|
||||
Vous trouverez ci-dessous quelques priorités générales que nous prenons en compte pour toutes les soumissions à Privacy Guides. Chaque catégorie aura des exigences supplémentaires pour être incluse.
|
||||
|
||||
- **Sécurité** : les outils doivent respecter les bonnes pratiques en matière de sécurité, le cas échéant.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Disponibilité des sources** : les projets open source sont généralement préférés aux solutions propriétaires équivalentes.
|
||||
- **Disponibilité multiplateforme** : nous préférons généralement que les recommandations soient multiplateformes, afin d'éviter d'être coincé chez un fournisseur.
|
||||
- **Développement actif** : les outils que nous recommandons doivent être activement maintenus. Les projets non maintenus seront, dans la plupart des cas, supprimés.
|
||||
- **Facilité d'utilisation** : les outils doivent être accessibles à la plupart des utilisateurs d'ordinateurs, sans qu'un bagage trop technique soit nécessaire.
|
||||
- **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**: les outils doivent être accompagnés d'une documentation claire et détaillée.
|
||||
|
||||
## Divulgation financière
|
||||
@ -19,14 +19,16 @@ Nous ne gagnons pas d'argent en recommandant certains produits, nous n'utilisons
|
||||
|
||||
Nous avons ces exigences à l'égard des développeurs qui souhaitent soumettre leur projet ou logiciel pour examen.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Vous devez indiquer votre affiliation, c'est-à-dire votre position au sein du projet soumis.
|
||||
|
||||
- Vous devez avoir un livre blanc sur la sécurité s'il s'agit d'un projet qui implique la manipulation d'informations sensibles comme une messagerie instantanée, un gestionnaire de mots de passe, un stockage cloud chiffré, etc.
|
||||
- Statut d'audit par une tierce partie. Nous voulons savoir si vous en avez un, ou si vous en prévoyez un. Si possible, veuillez mentionner qui mènera l'audit.
|
||||
- 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. Si possible, veuillez mentionner qui mènera l'audit.
|
||||
|
||||
- Vous devez expliquer ce que le projet apporte en matière de respect de la vie privée.
|
||||
- Cela résout-il un nouveau problème ?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Pourquoi devrait-on l'utiliser plutôt que d'autres solutions ?
|
||||
|
||||
- Vous devez indiquer quel est le modèle de menace exact avec votre projet.
|
||||
- Il doit être clair pour les utilisateurs potentiels ce que le projet peut fournir et ce qu'il ne peut pas fournir.
|
||||
- Il doit être clair pour les utilisateurs potentiels ce que le projet peut fournir et ce qu'il ne peut pas fournir. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. לכל קטגוריה יהיו דרישות נוספות להכללה.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **זמינות מקור**: פרויקטים בקוד פתוח מועדפים בדרך כלל על פני חלופות קנייניות שוות.
|
||||
- **Cross-Platform Availability**: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in.
|
||||
- **פיתוח פעיל**: את הכלים שאנו ממליצים עליהם לפתח באופן פעיל, פרויקטים לא מתוחזקים יוסרו ברוב המקרים.
|
||||
- **שימושיות**: כלים צריכים להיות נגישים לרוב משתמשי המחשב, אין צורך ברקע טכני יתר על המידה.
|
||||
- **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.
|
||||
|
||||
## גילוי פיננסי נאות
|
||||
@ -19,14 +19,16 @@ Below are some general priorities we consider for all submissions to Privacy Gui
|
||||
|
||||
יש לנו דרישות אלה לגבי מפתחים שרוצים להגיש את הפרויקט או התוכנה שלהם לשיקול.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- חייב לחשוף את ההשתייכות, כלומר את עמדתך בפרויקט המוגש.
|
||||
|
||||
- חייב להיות מסמך לבן אבטחה אם מדובר בפרויקט הכולל טיפול במידע רגיש כמו מסנג'ר, מנהל סיסמאות, אחסון מוצפן בענן וכו'.
|
||||
- סטטוס ביקורת של צד שלישי. אנחנו רוצים לדעת אם יש לך אחד, או שיש לך אחד מתוכנן. במידת האפשר נא לציין מי יבצע את הביקורת.
|
||||
- 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. במידת האפשר נא לציין מי יבצע את הביקורת.
|
||||
|
||||
- חייב להסביר מה הפרויקט מביא לשולחן בכל הנוגע לפרטיות.
|
||||
- האם זה פותר בעיה חדשה כלשהי?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- למה שמישהו ישתמש בזה על פני האלטרנטיבות?
|
||||
|
||||
- חייבים לציין מהו מודל האיום המדויק עם הפרויקט שלהם.
|
||||
- למשתמשים פוטנציאליים צריך להיות ברור מה הפרויקט יכול לספק ומה לא.
|
||||
- למשתמשים פוטנציאליים צריך להיות ברור מה הפרויקט יכול לספק ומה לא. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ Nem keresünk pénzt bizonyos termékek ajánlásával, nem használunk affiliat
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Setiap kategori akan memiliki persyaratan tambahan untuk dimasukkan.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Ketersediaan Sumber**: Proyek sumber terbuka umumnya lebih disukai daripada alternatif bersumber tertutup yang setara.
|
||||
- **Cross-Platform Availability**: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in.
|
||||
- **Pengembangan Aktif**: Alat yang kami rekomendasikan harus dikembangkan secara aktif, proyek yang tidak terpelihara akan dihapus dalam banyak kasus.
|
||||
- **Kegunaan**: Alat bantu harus dapat diakses oleh sebagian besar pengguna komputer, latar belakang yang terlalu teknis tidak diperlukan.
|
||||
- **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.
|
||||
|
||||
## Pengungkapan Keuangan
|
||||
@ -19,14 +19,16 @@ Kami tidak menghasilkan uang dari merekomendasikan produk tertentu, kami tidak m
|
||||
|
||||
Kami memiliki persyaratan ini terkait dengan pengembang yang ingin mengajukan proyek atau perangkat lunak mereka untuk dipertimbangkan.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Harus mengungkapkan afiliasi, yaitu posisi Anda dalam proyek yang diajukan.
|
||||
|
||||
- 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.
|
||||
- Status audit pihak ketiga. Kami ingin tahu apakah Anda memilikinya, atau sedang merencanakannya. Jika memungkinkan, sebutkan siapa yang akan melakukan audit.
|
||||
- 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. Jika memungkinkan, sebutkan siapa yang akan melakukan audit.
|
||||
|
||||
- Harus menjelaskan apa yang dibawa oleh proyek terkait privasi.
|
||||
- Apakah ini memecahkan masalah baru?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Mengapa orang harus menggunakannya daripada alternatif lain?
|
||||
|
||||
- Harus menyatakan apa model ancaman yang tepat dengan proyek mereka.
|
||||
- Harus jelas bagi calon pengguna apa yang dapat disediakan oleh proyek, dan apa yang tidak dapat disediakan.
|
||||
- Harus jelas bagi calon pengguna apa yang dapat disediakan oleh proyek, dan apa yang tidak dapat disediakan. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Ogni categoria avrà requisiti aggiuntivi per l'inclusione.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Disponibilità codice sorgente**: i progetti open source sono generalmente preferiti rispetto alle alternative proprietarie.
|
||||
- **Cross-Platform Availability**: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in.
|
||||
- **Sviluppo attivo**: Gli strumenti che consigliamo dovrebbero essere mantenuti attivamente; i progetti non mantenuti, in gran parte dei casi, saranno rimossi.
|
||||
- **Utilizzabilità**: gli strumenti dovrebbero essere accessibili a gran parte degli utenti, senza richiedere un background eccessivamente tecnico.
|
||||
- **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.
|
||||
|
||||
## Comunicazione Finanziaria
|
||||
@ -19,14 +19,16 @@ Non guadagniamo denaro consigliando certi prodotti, non utilizziamo i link d'aff
|
||||
|
||||
Abbiamo questi requisiti per quanto riguarda gli sviluppatori che desiderano inviare i prropri progetti o software, perché siano presi in considerazione.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Deve indicare l'affiliazione, cioè, la sua posizione entro il progetto inviato.
|
||||
|
||||
- Deve disporre di un whitepaper di sicurezza, se si tratta di un progetto che comporta la gestione delle informazioni sensibili, come un'app di messaggistica istantanea, gestore di password, archiviazione su cloud crittografata, etc.
|
||||
- Stato del controllo di terze parti. Desideriamo sapere se ne è già stato svolto uno, o se è nei piani. Se possibile, ti preghiamo di menzionare chi condurrà il controllo.
|
||||
- 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. Se possibile, ti preghiamo di menzionare chi condurrà il controllo.
|
||||
|
||||
- Deve spiegare ciò che il progetto offre in termini di privacy.
|
||||
- Risolve qualche nuovo problema?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Perché qualcuno dovrebbe preferirlo alle alternative?
|
||||
|
||||
- Deve indicare l'esatto modello di minaccia del loro progetto.
|
||||
- Dovrebbe essere chiaro, ai potenziali utenti, ciò che il progetto può fornire, e ciò che non può offrire.
|
||||
- Dovrebbe essere chiaro, ai potenziali utenti, ciò che il progetto può fornire, e ciò che non può offrire. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. 각 분야마다 별도의 추가적인 요구 사항이 존재할 수 있습니다.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **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.
|
||||
- **활발한 개발**: 권장 툴은 유지 관리가 활발하게 이루어져야 합니다. 개발이 중단된 프로젝트는 대부분 제거됩니다.
|
||||
- **사용성**: 툴은 대부분의 컴퓨터 사용자가 사용하는 데에 무리가 없어야 합니다. 지나치게 많은 기술적 배경 지식이 요구되어서는 안 됩니다.
|
||||
- **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.
|
||||
|
||||
## 재무 공시
|
||||
@ -19,14 +19,16 @@ Privacy Guides는 특정 제품을 추천함으로써 수익을 창출하지 않
|
||||
|
||||
개발자가 직접 자신의 프로젝트나 소프트웨어를 Privacy Guides에서 평가할 것을 제안하는 경우, 다음의 요구 사항을 준수해야 합니다.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- 본인이 제안한 프로젝트와 어떤 관계(소속)에 있는지를 공개해야 합니다.
|
||||
|
||||
- 메신저, 비밀번호 관리자, 암호화 클라우드 스토리지 등의 민감한 정보를 다루는 프로젝트인 경우, 보안 백서를 제공해야 합니다.
|
||||
- 외부 감사 정보를 공개해야 합니다. 이미 감사를 받았거나, 예정되어 있다면 이를 알려야 합니다. 가능하다면 감사를 누가 진행하는지도 언질을 해주시면 좋습니다.
|
||||
- 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. 가능하다면 감사를 누가 진행하는지도 언질을 해주시면 좋습니다.
|
||||
|
||||
- 해당 프로젝트가 프라이버시 면에서 어떤 이점을 제공하는지를 설명해야 합니다.
|
||||
- 기존에 해결하지 못하던 새로운 문제를 해결할 수 있나요?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- 다른 대안을 놔두고 해당 프로젝트를 사용해야 하는 이유가 있나요?
|
||||
|
||||
- 해당 프로젝트가 정확히 어떤 위협 모델을 가정하고 목표로 하는지를 명시해야 합니다.
|
||||
- 예비 사용자에게 해당 프로젝트가 무엇을 제공하고 무엇을 제공할 수 없는지를 명확히 알려야 합니다.
|
||||
- 예비 사용자에게 해당 프로젝트가 무엇을 제공하고 무엇을 제공할 수 없는지를 명확히 알려야 합니다. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: Algemene criteria
|
||||
|
||||
Hieronder staan enkele algemene prioriteiten die we in overweging nemen voor alle inzendingen voor Privacy Guides. Elke categorie heeft extra vereisten voor opname.
|
||||
|
||||
- **Beveiliging**: Tools moeten de beste beveiligingspraktijken volgen waar van toepassing.
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **Bronbeschikbaarheid**: Open-source projecten hebben over het algemeen de voorkeur boven gelijkwaardige propriëtaire alternatieven.
|
||||
- **Cross-platform beschikbaarheid**: We geven er gewoonlijk de voorkeur aan dat aanbevelingen platformonafhankelijk zijn, om te voorkomen dat u aan een bepaalde leverancier vastzit.
|
||||
- **Actieve ontwikkeling**: De hulpmiddelen die wij aanbevelen moeten actief worden ontwikkeld, niet-onderhouden projecten zullen in de meeste gevallen worden verwijderd.
|
||||
- **Bruikbaarheid**: Tools moeten toegankelijk zijn voor de meeste computergebruikers, een al te technische achtergrond is niet vereist.
|
||||
- **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.
|
||||
- **Documentatie**: Tools moeten duidelijke en uitgebreide documentatie hebben voor gebruik.
|
||||
|
||||
## Financiële informatie
|
||||
@ -19,14 +19,16 @@ We verdienen geen geld met het aanbevelen van bepaalde producten, we gebruiken g
|
||||
|
||||
Wij stellen deze eisen aan ontwikkelaars die hun project of software in overweging willen geven.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Je moet jouw banden bekendmaken, d.w.z. jouw positie binnen het ingediende project.
|
||||
|
||||
- Moet een security whitepaper hebben als het een project is waarbij gevoelige informatie wordt verwerkt, zoals een messenger, password manager, versleutelde cloudopslag etc.
|
||||
- Auditstatus van derden. We willen weten of je er een hebt, of gepland hebt. Vermeld indien mogelijk wie de controle zal uitvoeren.
|
||||
- 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. Vermeld indien mogelijk wie de controle zal uitvoeren.
|
||||
|
||||
- Moet uitleggen wat het project te bieden heeft op het gebied van privacy.
|
||||
- Lost het een nieuw probleem op?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Waarom zou iemand het gebruiken boven de alternatieven?
|
||||
|
||||
- Moeten aangeven wat het exacte dreigingsmodel is van hun project.
|
||||
- Het moet voor potentiële gebruikers duidelijk zijn wat het project kan bieden, en wat niet.
|
||||
- Het moet voor potentiële gebruikers duidelijk zijn wat het project kan bieden, en wat niet. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Cada uma das categorias tem requisitos adicionais para ser incluída.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **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.
|
||||
- **Desenvolvimento ativo**: as ferramentas que recomendamos devem ser desenvolvidas ativamente. Os projetos que não tenham uma manutenção regular serão removidos, na maioria dos casos.
|
||||
- **Usabilidade**: as ferramentas devem ser acessíveis à maioria dos utilizadores de computadores, não devendo ser necessária uma formação ou conhecimento demasiado técnicos.
|
||||
- **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.
|
||||
|
||||
## Divulgação financeira
|
||||
@ -19,14 +19,16 @@ Não ganhamos dinheiro com a recomendação de determinados produtos, não utili
|
||||
|
||||
Os programadores que pretendam submeter o seu projeto ou software para apreciação devem observar os seguintes requisitos.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Devem indicar a sua afiliação, ou seja, a sua posição no âmbito do projeto apresentado.
|
||||
|
||||
- Devem ter um documento técnico de segurança, se se tratar de um projeto que envolva o tratamento de informações sensíveis, como um serviço de mensagens, um gestor de palavras-passe, um armazenamento encriptado na nuvem, etc.
|
||||
- Estatuto de auditoria de terceiros. Queremos saber se solicitam auditorias ou se estão a planear solicitá-las. Sempre que possível, devem mencionar quem efetuará a(s) auditoria(s).
|
||||
- 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. Sempre que possível, devem mencionar quem efetuará a(s) auditoria(s).
|
||||
|
||||
- Devem explicar qual a mais-valia que o projeto traz às questões relacionadas com a privacidade.
|
||||
- Resolve algum problema novo?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Porque é que alguém deveria optar pelo projeto em vez das alternativas já existentes?
|
||||
|
||||
- Devem indicar de forma precisa qual o modelo de ameaça do seu projeto.
|
||||
- Deve ser claro para os potenciais utilizadores aquilo que o projeto pode fornecer e o que não pode.
|
||||
- Deve ser claro para os potenciais utilizadores aquilo que o projeto pode fornecer e o que não pode. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Каждая категория будет иметь дополнительные требования для включения.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **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.
|
||||
- **Активная разработка**: Инструменты, которые мы рекомендуем, должны активно разрабатываться, не поддерживаемые проекты в большинстве случаев будут удалены.
|
||||
- **Юзабилити**: Инструменты должны быть доступны большинству пользователей компьютеров, не должно требоваться чрезмерной технической подготовки.
|
||||
- **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.
|
||||
|
||||
## Раскрытие финансовой информации
|
||||
@ -19,14 +19,16 @@ Below are some general priorities we consider for all submissions to Privacy Gui
|
||||
|
||||
Мы предъявляем эти требования к разработчикам, которые хотят представить свой проект или программное обеспечение на рассмотрение.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Должны раскрыть связь с проектом, т.е. вашу должность в представляемом проекте.
|
||||
|
||||
- Должен иметь документ по безопасности, если проект предполагает работу с конфиденциальной информацией, например, мессенджер, менеджер паролей, зашифрованное облачное хранилище и т.д.
|
||||
- Статус аудита третьей стороной. Мы хотим знать, есть ли у вас статус аудита или запланирован ли он. Если возможно, укажите, кто будет проводить аудит.
|
||||
- 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. Если возможно, укажите, кто будет проводить аудит.
|
||||
|
||||
- Должен объяснить, что проект дает в плане конфиденциальности.
|
||||
- Решает ли он какую-то новую проблему?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Почему кто-то должен использовать ваш проект, а не альтернативы?
|
||||
|
||||
- Должна быть указана модель угроз, для которой этот проект создан.
|
||||
- Потенциальные пользователи должны легко понять, что проект может предоставить, а что нет.
|
||||
- Потенциальные пользователи должны легко понять, что проект может предоставить, а что нет. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Varje kategori kommer att ha ytterligare krav för inkludering.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **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.
|
||||
- **Aktiv utveckling**: De verktyg som vi rekommenderar bör vara aktivt utvecklade, ounderhållna projekt kommer i de flesta fall att tas bort.
|
||||
- **Användbarhet**: Verktyg bör vara tillgängliga för de flesta datoranvändare, en alltför teknisk bakgrund bör inte krävas.
|
||||
- **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.
|
||||
|
||||
## Finansiell information
|
||||
@ -19,14 +19,16 @@ Vi tjänar inga pengar på att rekommendera vissa produkter, vi använder inga a
|
||||
|
||||
Vi har dessa krav på utvecklare som vill lämna in sitt projekt eller sin programvara för bedömning.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Måste uppge tillhörighet, det vill säga din position inom projektet som lämnas in.
|
||||
|
||||
- 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.
|
||||
- Tredje parts revisionsstatus. Vi vill veta om du har en sådan, eller om du har en planerad sådan. Om möjligt, ange vem som kommer att genomföra revisionen.
|
||||
- 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. Om möjligt, ange vem som kommer att genomföra revisionen.
|
||||
|
||||
- Måste förklara vad projektet tillför när det gäller integritetsskydd.
|
||||
- Löser det något nytt problem?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Varför skulle någon använda det framför alternativen?
|
||||
|
||||
- Måste ange vilken exakt hotmodell som gäller för deras projekt.
|
||||
- Det bör vara tydligt för potentiella användare vad projektet kan erbjuda och vad det inte kan erbjuda.
|
||||
- Det bör vara tydligt för potentiella användare vad projektet kan erbjuda och vad det inte kan erbjuda. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. Her kategorinin dahil edilmesi için ek gereklilikler olacaktır.
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **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.
|
||||
- **Aktif Gelişim**: Tavsiye ettiğimiz araçlar aktif olarak geliştirilmeli, çoğu durumda sürdürülmeyen projeler kaldırılacaktır.
|
||||
- **Kullanılabilirlik**: Araçlar çoğu bilgisayar kullanıcısı için erişilebilir olmalı, aşırı teknik bir altyapı gerekmemelidir.
|
||||
- **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.
|
||||
|
||||
## Finansal Açıklama
|
||||
@ -19,14 +19,16 @@ Belirli ürünleri tavsiye ederek para kazanmıyoruz, bağlı kuruluş bağlant
|
||||
|
||||
Projelerini veya yazılımlarını değerlendirmeye göndermek isteyen geliştiriciler için bu gerekliliklere sahibiz.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- Bağlılığınızı, yani sunulan projedeki pozisyonunuzu açıklamalısınız.
|
||||
|
||||
- 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.
|
||||
- Üçüncü taraf denetim durumu. Bir tane varsa veya planladıysanız bilmek istiyoruz. Mümkünse lütfen denetimi kimin yapacağını belirtin.
|
||||
- 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. Mümkünse lütfen denetimi kimin yapacağını belirtin.
|
||||
|
||||
- Projenin mahremiyet konusunda masaya ne getirdiğini açıklamalıdır.
|
||||
- Yeni bir sorunu çözüyor mu?
|
||||
- What new problem(s), if any, does it solve?
|
||||
- Neden alternatifleri yerine bunu kullansınlar ki?
|
||||
|
||||
- Projelerinde tam tehdit modelinin ne olduğunu belirtmelidir.
|
||||
- Potansiyel kullanıcılar için projenin neleri sağlayabileceği ve neleri sağlayamayacağı açık olmalıdır.
|
||||
- Potansiyel kullanıcılar için projenin neleri sağlayabileceği ve neleri sağlayamayacağı açık olmalıdır. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ 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.
|
||||
- **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.
|
||||
- **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
|
||||
@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
|
||||
|
||||
We have these requirements in regard to developers which wish to submit their project or software for consideration.
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) 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 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 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.
|
||||
- Does it solve any new problem?
|
||||
- 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.
|
||||
- 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)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: 通用標準
|
||||
|
||||
以下是我們在對提交給 Privacy Guides 所考慮的一些優先事項。 每個類別都會有額外的加入要求。
|
||||
|
||||
- **安全性**：工具應遵循適用的最佳安全作法。
|
||||
- **Security**: Tools should follow security best practices wherever applicable.
|
||||
- **來源可用性**：開放原始碼專案通常比同等的商用替代方案更受歡迎。
|
||||
- **跨平台可用性**：我們通常偏好跨平台的建議，以避免廠商鎖定。
|
||||
- **積極開發**：我們推薦的工具應該是積極開發的，未維護的專案在大多數情況下會被移除。
|
||||
- **可用性**：工具應該能讓大多數電腦使用者使用，不需要過度的技術背景。
|
||||
- **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.
|
||||
- **說明文件**：工具應該有清楚且廣泛的使用說明文件。
|
||||
|
||||
## 財務披露
|
||||
@ -19,14 +19,16 @@ title: 通用標準
|
||||
|
||||
我們對希望提交專案或軟體以供考慮的開發人員有以下要求。
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- 必須揭露您的從屬關係，即您在所提交專案中的職位。
|
||||
|
||||
- 如果是涉及敏感資訊處理的專案，例如通訊軟體、密碼管理器、加密雲端儲存等，必須有安全白皮書。
|
||||
- 第三方稽核狀態。 我們想知道您是否有一個，或有一個計劃。 如果可能，請說明由誰執行稽核。
|
||||
- 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. 如果可能，請說明由誰執行稽核。
|
||||
|
||||
- 必須說明專案在隱私權方面所帶來的好處。
|
||||
- 它能解決任何新的問題嗎？
|
||||
- What new problem(s), if any, does it solve?
|
||||
- 為什麼要使用它而不是其他替代方案？
|
||||
|
||||
- 必須說明其專案的確切威脅模式。
|
||||
- 潛在使用者應該清楚知道專案能提供什麼，以及不能提供什麼。
|
||||
- 潛在使用者應該清楚知道專案能提供什麼，以及不能提供什麼。 Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
@ -4,11 +4,11 @@ title: General Criteria
|
||||
|
||||
Below are some general priorities we consider for all submissions to Privacy Guides. 每个类别都会有额外的纳入要求。
|
||||
|
||||
- **Security**: Tools should follow security best-practices wherever applicable.
|
||||
- **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.
|
||||
- **积极开发**：我们推荐的工具应该积极开发，未维护的项目在大多数情况下会被删除。
|
||||
- **可用性**：工具应该是大多数计算机用户可以使用的，不应该要求有过度的技术背景。
|
||||
- **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.
|
||||
|
||||
## 财务披露
|
||||
@ -19,14 +19,16 @@ Below are some general priorities we consider for all submissions to Privacy Gui
|
||||
|
||||
我们对希望提交其项目或软件供审议的开发者有这些要求。
|
||||
|
||||
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
|
||||
|
||||
- 必须披露隶属关系，即您在提交的项目中的职位。
|
||||
|
||||
- 如果是涉及处理敏感信息的项目，如信息软件、密码管理器、加密云存储等，必须有一份安全白皮书。
|
||||
- 第三方审计情况。 我们想知道你是否有一个或计划了一个。 如果可能，请说明谁将进行审计。
|
||||
- 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. 如果可能，请说明谁将进行审计。
|
||||
|
||||
- 必须解释该项目在隐私方面带来了什么。
|
||||
- 它是否解决了任何新问题？
|
||||
- What new problem(s), if any, does it solve?
|
||||
- 为什么有人要使用它而不是其他的东西呢？
|
||||
|
||||
- 必须说明其项目的确切威胁模式是什么。
|
||||
- 潜在的用户应该清楚地知道该项目能提供什么，以及不能提供什么。
|
||||
- 潜在的用户应该清楚地知道该项目能提供什么，以及不能提供什么。 Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.
|
||||
|
||||
Reference in New Issue
Block a user