Comment fonctionne Security in a Box ?

Table des matières

...Chargement de la table des matières...

    Comment fonctionne Security in a Box ?

    Security in a Box est une ressource libre et open-source hébergée sur Gitlab.com.

    Security in a Box est constamment mis à jour grâce au travail de l'équipe de protection numérique de Front Line Defenders ainsi qu'à des contributions externes. Toutes les mises à jour et tous les changements sont coordonnés par l'éditrice de Front Line Defenders en charge de la protection numérique.

    Tous les contenus inclus dans Security in a Box sont sélectionnés méticuleusement selon les critères suivants.

    Comment nous développons les stratégies de protection que nous recommandons

    Security in a Box est une ressource qui comprend de nombreuses stratégies de protection numérique. En naviguant sur ce site, vous trouverez des recommandations sur la façon de créer et de gérer des mots de passe forts et sur la façon de protéger vos comptes, vos communications, vos appareils, votre connexion internet et vos informations sensibles.

    Toutes ces stratégies sont axées sur la protection des actifs numériques, mais elles sont développées de manière holistique : même si ce que nous voulons vous aider à protéger est numérique, nous savons que la protection s'étend toujours à différentes sphères, notamment le contexte juridique et psychosocial, ainsi que la nécessité d'examiner le contexte physique. Pour plus d'informations sur ce qu'implique une approche holistique de la protection, nous vous recommandons de lire l'approche holistique dans le Manuel de sécurité holistique.

    Security in a Box vise principalement à aider une communauté mondiale de défenseurs et défenseuses des droits humains (DDH) dont le travail les expose à des risques. En général, nous considérons que cette ressource vise à aider non seulement les DDH, mais aussi d'autres utilisateurs exposés au risque d'attaques numériques, par exemple les activistes, les journalistes et d'autres membres de la société civile, ainsi que les femmes et les personnes LGBTQIA+ qui sont exposées au risque de violence en ligne fondée sur le genre.

    L'un des éléments centraux de notre approche est de permettre à nos utilisateurs cibles d'évaluer les risques auxquels ils sont confrontés et de définir leurs propres besoins. Nous nous efforçons de ne pas nuire aux DDH, à leurs familles et à leurs communautés, ainsi qu'aux autres lecteurs de SiaB. Nous reconnaissons également qu'il est essentiel d'écouter avec empathie les DDH et les autres utilisateurs exposés à la violence numérique et de comprendre les situations dans lesquelles ils se trouvent pour leur apporter un soutien efficace en matière de protection. Les stratégies décrites dans SiaB sont donc développées avec une approche qui vise à renforcer les capacités de nos lecteurs et sont basées sur les besoins et les objectifs réels de nos utilisateurs, conformément à aux [Vision, Mission et Valeurs fondamentales] de Front Line Defenders](https://www.frontlinedefenders.org/fr/mission-vision-values).

    Comment nous choisissons les outils et services que nous recommandons

    Les logiciels sont complexes et ils ne sont pas tous conçus de façon égale en ce qui concerne la sécurité - et la protection de la vie privée. Différents outils et services peuvent être plus ou moins efficaces selon la juridiction dans laquelle vous vous trouvez, ses lois, et les adversaires auxquels vous pouvez faire face.

    Nous tenons compte d’un certain nombre de facteurs lorsque nous choisissons les outils et les services que nous recommandons dans Security in a Box. Chaque facteur est important. Étant donné que différents domaines ont des exigences juridiques différentes pour la technologie et font face à des menaces différentes, il est difficile de classer l’importance de chaque facteur à l’échelle mondiale.

    Ci-dessous, nous dressons la liste des questions qui selon nous sont les plus importantes lorsque nous examinons les outils et services que nous recommandons. Vous pouvez également utiliser ces critères lorsque vous évaluez la sécurité relative d'outils que nous ne listons pas dans Security in a Box .

    Peut-on faire confiance aux personnes qui développent cet outil ou qui gèrent ce service ?

    • Quel est l'historique du développement et de la propriété de l'outil ou du service ? A-t-il été créé par des militants ou par une entreprise ? Ce groupe a-t-il un visage public et quels sont ses antécédents ?
    • Quels sont la mission et le modèle d'entreprise de l'entité qui développe ou exploite cet outil ou ce service ?
    • Y a-t-il eu des problèmes de sécurité, par exemple des fuites de données ou des demandes d'informations de la part des autorités étatiques ? Comment le prestataire de services/les développeurs de l'outil ont-ils réagi face à ces problèmes ? Ont-ils ouvertement réglé les problèmes ou ont-ils tenté de les camoufler ?

    L'outil chiffre-t-il les données ? Avec quel type de technologie de chiffrement ?

    • L’outil chiffre-t-il la connexion entre l'utilisateur et les personnes avec lesquelles il communique (chiffrement de bout en bout), rendant impossible l'accès à leurs informations par les fournisseurs de services ?
    • Si le chiffrement de bout en bout n'est pas disponible, nous donnons la priorité aux outils qui chiffrent les données entre l'appareil de l'utilisateur et l'infrastructure du service (chiffrement vers le serveur). Dans ce cas, nous rappelons toujours à nos lecteurs que si les données ne sont pas cryptées dans les serveurs, ils doivent faire confiance aux personnes qui gèrent ce service, car elles ont potentiellement libre accès aux informations qu'ils y ont stockées.
    • Les paramètres par défaut protègent-ils la vie privée et la sécurité de l'utilisateur ?
    • Si aucun chiffrement de bout en bout n'est disponible, la technologie permet-elle aux utilisateurs d'héberger le service dans leur propre infrastructure, afin qu'ils puissent contrôler qui peut accéder à leurs données ?

    Le code est-il disponible pour inspection ?

    • Autrement dit, est-il open source ?
    • L’outil ou le service a-t-il fait l’objet d’une vérification par des experts en sécurité indépendants du projet de développement du logiciel ou de l'entreprise prestataire de service ?
    • Quand la dernière vérification a-t-elle eu lieu ? Des vérifications régulières sont-elles prévues ?
    • Les vérifications ont-elle porté sur tous les éléments de l'outil ou du service, ou seulement sur certains d'entre eux ? S'il s'agit d'un service, l'infrastructure du serveur a-t-elle été vérifiée, ou seulement l'interface utilisateur ?
    • Que disent les experts indépendants au sujet de l’outil ou du service ?

    Cette technologie est-elle mature ?

    • Depuis combien de temps cette technologie est-elle en opération ? A-t-elle passé l'épreuve du temps ?
    • Y a-t-il une grande communauté de développeurs qui travaillent encore activement à son développement ?
    • Combien y a-t-il d’utilisateurs actifs ?

    Où les serveurs sont-ils situés ?

    • Il peut être difficile de répondre à cette question, compte tenu du nombre croissant de services dans le cloud, mais les développeurs et les fournisseurs de services dignes de confiance ont tendance à publier ces informations sur leur site web ou à les mettre à disposition par le biais d'intermédiaires de confiance.
    • Il nous est également difficile de tirer des conclusions à partir de ces informations, car les serveurs peuvent être situés dans un pays qui protège les DDH et d'autres membres de la société civile dans certains États, mais pas dans d'autres.
    • En général, nous nous demandons si les serveurs sont situés dans un pays qui répondrait à une demande des autorités de pays où il n'y a pas d'État de droit, et si ce pays respecte les droits humains et la protection des consommateurs. En bref, la question est la suivante : les autorités de pays non démocratiques ont-elles le droit de saisir des données, d'accéder à des informations ou de fermer ces services en raison de l'emplacement des serveurs ?

    Quels renseignements personnels demande-t-il à l'utilisateur ? À quoi le propriétaire/l'exploitant a-t-il accès ?

    • L'outil ou le service demande-t-il aux utilisateurs de fournir leur numéro de téléphone, leur adresse électronique, leur surnom ou d'autres informations permettant de les identifier personnellement ?
    • L'outil/le service requiert-il d’installer une application/un programme dédié qui pourrait potentiellement tracer les utilisateurs ?
    • Que dit leur politique de confidentialité ? Protègent-ils la vie privée des utilisateurs et se conforment-ils aux lois sur la protection de la vie privée telles que le règlement général sur la protection des données de l'UE ?
    • Qu’est-ce qui est stocké sur les serveurs ? Les termes et conditions des entreprises donnent-ils au propriétaire le droit d’accéder aux données des utilisateurs ? À quelles fins ?
    • À quoi cette application ou ce programme aura-t-il accès sur un appareil : le carnet d’adresses, l'emplacement, le microphone, l'appareil photo, etc. ? Ces autorisations peuvent-elles être désactivées, ou l'application/le programme cessera-t-il de fonctionner dans ce cas ?

    Quel est le prix ? Est-il abordable ?

    • Lorsque nous envisageons un service ou un outil, nous tenons compte de son coût. Est-il abordable ? Quel est le modèle économique de ses développeurs ou de son fournisseur ?
    • Outre le paiement initial, nous prenons en compte les coûts d'hébergement, les éventuels frais d'abonnement, le coût pour apprendre à utiliser et pour gérer l'outil ou le service, la nécessité d'une éventuelle assistance informatique et/ou d'un équipement supplémentaire, etc.
    • Si l'outil ou le service est fourni gratuitement, nous nous demandons pourquoi. Qui finance le projet si l'outil/le service n'est pas payant ? Est-il gratuit parce qu'il est basé sur le bénévolat ou parce qu'il est financé par des gouvernements ou des entreprises, ou bien l'entreprise gagne-t-elle de l'argent en vendant les données de ses utilisateurs à des tiers ?

    Est-il disponible sur plusieurs systèmes d’exploitation et appareils ?

    • L'outil ou le service peut-il être utilisé à la fois sur des ordinateurs et des appareils mobiles ? Est-il uniquement disponible sur des systèmes d'exploitation propriétaires tels que macOS et iOS ou également sur Linux ? S'il n'est pas disponible sur tous les systèmes d'exploitation, existe-t-il une alternative fiable pour les autres appareils sur lesquels cet outil/ce service ne peut pas être utilisé ?

    Est-il facile à utiliser ? Fonctionnera-t-il pour les personnes à risque ?

    • Est-il difficile ou frustrant d'utiliser cet outil en toute sécurité, ou les développeurs/fournisseurs ont-ils fait un effort pour faciliter son utilisation ?
    • Les DDH et les autres personnes à risque continuent-ils à utiliser cet outil ou ce service, ou ont-ils tendance à l'abandonner ?
    • L'interface utilisateur est-elle intuitive ? Ou, à défaut, une documentation a-t-elle été élaborée pour expliquer clairement comment utiliser l'outil ou le service ?

    Est-il traduit en plusieurs langues ?

    • L’outil ou le service est-il localisé ? En combien de langues est-il disponible ?
    • L'emplacement est-il continuellement mis à jour ?
    • Quelle est la qualité de l'emplacement ?
    • Une documentation multilingue est-elle également disponible pour aider les utilisateurs à comprendre comment l'utiliser en toute sécurité ?