1
0
mirror of https://github.com/privacyguides/i18n.git synced 2025-08-26 08:09:15 +00:00

New Crowdin translations by GitHub Action

This commit is contained in:
Crowdin Bot
2024-04-11 18:32:01 +00:00
parent 00bc040f66
commit d71cfc6363
116 changed files with 2557 additions and 1397 deletions

View File

@@ -42,7 +42,7 @@ schema:
Ces mythes découlent d'un certain nombre de préjugés, mais le fait que le code source soit disponible ou non et la manière dont les logiciels sont concédés sous licence n'affectent en rien leur sécurité. ==Les logiciels open-source ont le *potentiel* d'être plus sécurisé que les logiciels propriétaires, mais il n'y a absolument aucune garantie que ce soit le cas.== Lorsque vous évaluez un logiciel, vous devez examiner la réputation et la sécurité de chaque outil individuellement.
Les logiciels libres *peuvent* être audités par des tiers et sont souvent plus transparents sur les vulnérabilités potentielles que leurs homologues propriétaires. Ils vous permettent également d'examiner le code et de désactiver vous-même toute fonctionnalité suspecte. Cependant, *à moins que vous ne le fassiez*, il n'y a aucune garantie que le code ait jamais été évalué, en particulier pour les petits projets. Le processus de développement ouvert a aussi parfois été exploité pour introduire de nouvelles vulnérabilités même dans des projets importants.[^1]
Les logiciels libres *peuvent* être audités par des tiers et sont souvent plus transparents sur les vulnérabilités potentielles que leurs homologues propriétaires. Ils vous permettent également d'examiner le code et de désactiver vous-même toute fonctionnalité suspecte. Cependant, *à moins que vous ne le fassiez*, il n'y a aucune garantie que le code ait jamais été évalué, en particulier pour les petits projets. The open development process has also sometimes been exploited to introduce new vulnerabilities known as <span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span>, which are discussed further in our [Common Threats](common-threats.md) page.[^1]
Par ailleurs, les logiciels propriétaires sont moins transparents, mais cela ne signifie pas qu'ils ne sont pas sécurisés. Des projets logiciels propriétaires majeurs peuvent être audités en interne et par des agences tierces, et des chercheurs indépendants en sécurité peuvent toujours trouver des vulnérabilités avec des techniques telles que la rétro-ingénierie.
@@ -94,4 +94,4 @@ Les modèles de menace les plus clairs sont ceux où les gens *savent qui vous
Using Tor can help with this. It is also worth noting that greater anonymity is possible through asynchronous communication: Real-time communication is vulnerable to analysis of typing patterns (i.e. more than a paragraph of text, distributed on a forum, via email, etc.)
[^1]: One notable example of this is the [2021 incident in which University of Minnesota researchers introduced three vulnerabilities into the Linux kernel development project](https://cse.umn.edu/cs/linux-incident).
[^1]: A notable supply chain attack occurred in March 2024, when a malicious maintainer added a obfuscated backdoor into `xz`, a popular compression library. The backdoor ([CVE-2024-3094](https://www.cve.org/CVERecord?id=CVE-2024-3094)) was intended to give an unknown party remote access to most Linux servers via SSH, but it was discovered before it had been widely deployed.

View File

@@ -9,13 +9,14 @@ Pour faire simple, nous classons nos recommandations dans ces catégories géné
- <span class="pg-purple">:material-incognito: Anonymat</span> - Séparer votre activité en ligne de votre identité réelle, vous vous protégez des personnes qui tentent de découvrir explicitement *votre* identité
- <span class="pg-red">:material-target-account: Attaques Ciblées</span> - Se protéger contre les pirates informatiques dévoués ou d'autres agents malintentionnés essayant d'accéder spécifiquement à *vos* données ou appareils
- <span class="pg-orange">:material-bug-outline: Attaques Passives</span> - Se protéger des logiciels malveillants, des fuites de données, et autres attaques qui sont faites contre des groupes de personnes
- <span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span> - A vulnerability or exploit introduced into otherwise good software either directly or through a dependency from a third party.
- <span class="pg-teal">:material-server-network: Fournisseurs de Services</span> - Protéger vos données des fournisseurs de services, en utilisant par exemple un chiffrement de bout en bout rendant vos données illisibles par le serveur
- <span class="pg-blue">:material-eye-outline: Surveillance de Masse</span> - Protection contre les agences gouvernementales, organisations, sites web et services qui collaborent pour suivre vos activités en ligne
- <span class="pg-brown">:material-account-cash: Capitalisme de Surveillance</span> - Se protéger des grands réseaux publicitaires comme Google et Facebook, ainsi que d'une myriade d'autres collecteurs de données tiers
- <span class="pg-green">:material-account-search: Exposition Publique</span> - Limiter les informations en ligne vous concernant, accessibles par les moteurs de recherche ou par le grand public
- <span class="pg-blue-gray">:material-close-outline: Censure</span> - Éviter les accès censurés à l'information et d'être soi-même censuré lorsqu'on discute en ligne
Certaines de ces menaces peuvent peser plus que d'autres en fonction de vos préoccupations. Par exemple, un développeur de logiciels ayant accès à des données précieuses ou critiques peut être principalement concerné par les <span class="pg-red">:material-target-account: Attaques Ciblées</span>. Mais de plus, il veut probablement empêcher ses données personnelles d'être récupérées par des programmes de <span class="pg-blue">:material-eye-outline: Surveillance de Masse</span>. De même, une « personne lambda » peut être principalement concernée par l'<span class="pg-green">:material-account-search: Exposition Publique</span> de ses données personnelles, mais devrait tout de même se méfier des problèmes de sécurité tels que les <span class="pg-orange">:material-bug-outline: Attaques Passives</span> comme les logiciels malveillants affectant ses appareils.
Certaines de ces menaces peuvent peser plus que d'autres en fonction de vos préoccupations. For example, a software developer with access to valuable or critical data may be primarily concerned with <span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span> and <span class="pg-red">:material-target-account: Targeted Attacks</span>. They will likely still want to protect their personal data from being swept up in <span class="pg-blue">:material-eye-outline: Mass Surveillance</span> programs. De même, une « personne lambda » peut être principalement concernée par l'<span class="pg-green">:material-account-search: Exposition Publique</span> de ses données personnelles, mais devrait tout de même se méfier des problèmes de sécurité tels que les <span class="pg-orange">:material-bug-outline: Attaques Passives</span> comme les logiciels malveillants affectant ses appareils.
## Anonymat et vie privée
@@ -57,6 +58,31 @@ Les attaques ciblées contre une personne spécifique sont plus difficiles à g
If you are concerned about **physical attacks** you should use an operating system with a secure verified boot implementation, such as Android, iOS, macOS, or [Windows (with TPM)](https://learn.microsoft.com/windows/security/information-protection/secure-the-windows-10-boot-process). Vous devriez également vous assurer que votre disque est chiffré et que le système d'exploitation utilise un TPM, une [Enclave sécurisée](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/1/web/1) ou un [Element sécurisé](https://developers.google.com/android/security/android-ready-se) pour limiter le taux de tentatives de saisie de la phrase de passe. Vous devriez éviter de partager votre ordinateur avec des personnes en qui vous n'avez pas confiance, car la plupart des systèmes d'exploitation de bureau ne chiffrent pas les données séparément par utilisateur.
<span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span>
Supply chain attacks are frequently a form of <span class="pg-red">:material-target-account: Targeted Attack</span> towards businesses, governments, and activists, although they can end up compromising the public at large as well.
<div class="admonition example" markdown>
<p class="admonition-title">Example</p>
A notable example of this occurred in 2017 when M.E.Doc, a popular accounting software in Ukraine, was infected with the *NotPetya* virus, subsequently infecting people who downloaded that software with ransomware. NotPetya itself was a ransomware attack which impacted 2000+ companies in various countries, and was based on the *EternalBlue* exploit developed by the NSA to attack Windows computers over the network.
</div>
There are few ways in which this type of attack might be carried out:
1. A contributor or employee might work their way into a position of power within a project or organization, then abuse that position by adding malicious code.
2. A developer may be coerced by an outside party to add malicious code.
3. An individual or group might identify a third party software dependency (also known as a library) and work to infiltrate it with the above two methods, knowing that it will be used by "downstream" software developers.
These sorts of attacks can require a lot of time and preparation to perform and are risky because they can be detected, particularly in open source projects if they are popular and have outside interest. Unfortunately they're also one of the most dangerous as they are very hard to mitigate entirely. We would encourage readers only use software which has a good reputation and makes an effort to reduce risk by:
1. Only adopting popular software that has been around for a while. The more interest in a project the greater likelihood that external parties will notice malicious changes. A malicious actor will also need to spend more time gaining community trust with meaningful contributions.
2. Finding software which releases binaries with widely-used, trusted build infrastructure platforms, as opposed to developer workstations or self-hosted servers. Some systems like GitHub Actions let you inspect the build script that runs publicly for extra confidence. This lessens the likelihood that malware on a developer's machine could infect their packages, and gives confidence that the binaries produced are in fact produced correctly.
3. Looking for code signing on individual source code commits and releases, which creates an auditable trail of who did what. For example: Was the malicious code in the software repository? Which developer added it? Was it added during the build process?
4. Checking whether the source code has meaningful commit messages (such as [conventional commits](https://conventionalcommits.org)) which explain what the change is supposed to accomplish. Clear messages can make it easier for outsiders to the project to verify, audit, and find bugs.
5. Noting the number of contributors or maintainers a program has. A lone developer may be more susceptible to being coerced into adding malicious code by an external party, or to negligently enable undesirable behavior. This may very well mean software developed by "Big Tech" has more scrutiny than a lone developer who doesn't answer to anyone.
## Protection de ses données des fournisseurs de services
<span class="pg-teal">:material-server-network: Fournisseurs de service</span>