Guide d'autodéfense numérique

Mises à jour : les logiciels évoluent, c'est pourquoi il est vivement conseillé d'utiliser la version la plus à jour de cet outil, qui est disponible sur le site web https://guide.boum.org/.

Durée : une demi-heure à une heure.

On est parfois amené à choisir un logiciel pour effectuer une certaine tâche, et il est alors courant de se sentir perdu dans la multitude de solutions disponibles. Voici donc quelques critères permettant de prendre une décision adéquate.

L’intérêt d’utiliser des logiciels libres par rapport à des logiciels propriétaires ou open source a d’ores et déjà été expliqué. La suite du texte s’attachera donc uniquement à départager les logiciels libres disponibles.

Mode d’installation

Il est généralement préférable d’installer des logiciels fournis par sa distribution GNU/Linux (par exemple, Debian). Il y a deux principales raisons à ça.

Tout d’abord, une question pratique : la distribution fournit les outils pour installer et mettre à jour, de façon plus ou moins automatisée, un ensemble de logiciels ; elle nous alerte lorsqu’une faille de sécurité affecte l’un des logiciels que l’on utilise. Mais dès lors qu’on installe un logiciel qui n’est pas fourni par sa distribution, on est livré à soi-même : il faut penser à le mettre à jour, se tenir informé des failles de sécurité qui y sont découvertes, gérer les dépendances entre logiciels. Ça demande des efforts, du temps, des compétences.

D’autre part, une question de politique de sécurité : lorsqu’on a choisi sa distribution GNU/Linux, on a implicitement décidé d’accorder une certaine confiance à un ensemble de gens, à un processus de production. Installer un logiciel qui n’est pas fourni par sa distribution implique de prendre une décision similaire à propos d’un nouvel ensemble de gens, d’un nouveau processus de production. Une telle décision ne se prend pas à la légère : lorsqu’on décide d’installer un logiciel n’appartenant pas à sa distribution, on élargit l’ensemble des personnes et processus à qui on accorde de la confiance, et on augmente donc les risques.

Maturité

L’attrait de la nouveauté est bien souvent un piège.

Mieux vaut, autant que possible, choisir un logiciel ayant atteint une certaine maturité : dans un logiciel activement développé et utilisé depuis au moins quelques années, il y a des chances que les plus gros problèmes aient déjà été découverts et corrigés… y compris les failles de sécurité.

Pour s’en rendre compte, il faut consulter l’historique de chacun des logiciels, sur leur site web ou dans le fichier nommé Changelog (ou approchant), généralement livré avec le logiciel.

Processus de production et « communauté »

L’étiquette logiciel libre est un critère essentiellement juridique, qui ne doit jamais suffire à nous inspirer confiance.

Certes, le fait qu’un logiciel soit placé sous une licence libre ouvre la possibilité de modes de développement inspirant confiance.

Mais les personnes développant ce logiciel peuvent fort bien, intentionnellement ou non, décourager toute coopération et travailler en vase clos. Que nous importe alors que le programme soit juridiquement libre, si, de fait, personne d’autre ne lira jamais son code source ?

Il convient donc d’étudier rapidement le processus de production des logiciels en lice, en s’aidant des questions suivantes, qui nous permettront de surcroît de jauger le dynamisme du processus :

  • Qui développe ? Une personne, des personnes, toute une équipe ?
  • Le nombre de personnes qui contribuent au code source va-t-il en augmentant ou en diminuant ?
  • Le développement est-il actif ? Il ne s’agit pas ici de vitesse pure, mais de réactivité, de suivi à long terme, de résistance. Le développement logiciel est une course d’endurance et non un sprint.

Et à propos des outils de communication collective sur lesquels s’appuie le développement (listes et salons de discussion, par exemple) :

  • A-t-on facilement accès aux discussions guidant le développement du logiciel ?
  • Ces discussions rassemblent-elles de nombreuses personnes ?
  • Ces personnes participent-elle à son développement, ou ne font-elles que l’utiliser ?
  • Quelle atmosphère y règne ? Calme plat, silence de mort, joyeuse cacophonie, sérieux glaçant, bras ouverts, hostilité implicite, tendre complicité, etc. ?
  • Le volume de discussion, sur les derniers mois/années, va-t-il en diminuant ou en augmentant ? Plus que le volume brut, c’est surtout la proportion de messages obtenant des réponses qui importe : un logiciel mûr, stable et bien documenté ne sera pas forcément source de discussions, mais si plus personne n’est là pour répondre aux questions des néophytes, ça peut être mauvais signe.
  • Peut-on trouver des retours d’utilisation, des suggestions d’améliorations ? Si oui, sont-elles prises en compte ?
  • Les réponses sont-elles toujours données par un nombre réduit de personnes, ou existe-t-il des pratiques d’entraide plus large ?

Popularité

La popularité est un critère délicat en matière de logiciels. Le fait que la grande majorité des ordinateurs de bureau fonctionnent actuellement sous Windows n’indique en rien que Windows soit le meilleur système d’exploitation disponible.

Pour autant, si ce logiciel n’est pas utilisé par beaucoup de monde, on peut douter de sa viabilité à long terme : si l’équipe de développement venait à cesser de travailler sur ce logiciel, que deviendrait-il ? Qui reprendrait le flambeau ?

On peut donc retenir, comme règle générale, qu’il faut choisir un logiciel utilisé par un nombre suffisamment important de personnes, mais pas forcément le logiciel le plus utilisé.

Afin de mesurer la popularité d’un logiciel, il est possible, d’une part, d’utiliser les mêmes critères que ceux décrits ci-dessus au sujet du dynamisme de la « communauté » formée autour de lui. D’autre part, Debian publie les résultats de son concours de popularité1, qui permet de comparer non seulement le nombre de personnes ayant installé tel ou tel logiciel, mais aussi, voire surtout, l’évolution dans le temps de leur popularité.

Passé de sécurité

Voici de nouveau un critère à double tranchant.

On peut commencer par jeter un œil sur le suivi de sécurité2 proposé par Debian. En y cherchant un logiciel par son nom, on peut avoir la liste des problèmes de sécurité qui y ont été découverts et parfois résolus.

Si ce logiciel a un historique de sécurité parfaitement vierge, ça peut impliquer soit que tout le monde s’en fout, soit que le logiciel est écrit de façon extrêmement rigoureuse.

Si des failles de sécurité ont été découvertes dans le logiciel étudié, il y a plusieurs implications, parfois contradictoires.

  1. Ces failles ont été découvertes et corrigées :
    • donc elles n’existent plus, a priori ;
    • donc quelqu’un s’est préoccupé de les trouver, et quelqu’un d’autre de les corriger : on peut supposer qu’une attention est donnée à cette question.
  2. Ces failles ont existé :
    • le logiciel est peut-être écrit sans que la sécurité soit un souci particulier ;
    • d’autres failles peuvent subsister, non encore découvertes ou pire, non encore publiées.

Afin d’affiner notre intuition par rapport à ce logiciel, il peut être bon de se pencher sur le critère « temps » : par exemple, il n’est pas dramatique que quelques failles aient été découvertes au début du développement d’un logiciel, si aucune n’a été découverte depuis quelques années ; on peut alors mettre ça sur le compte des erreurs de jeunesse. Au contraire, si de nouvelles failles sont découvertes régulièrement, depuis des années, et jusqu’à très récemment, il est fort possible que le logiciel ait encore de nombreux problèmes de sécurité totalement inconnus… ou non publiés. Tout comme une nombre relativement élevé de failles, même récentes peut indiquer une communauté de développement active et être meilleur signe qu'aucune faille de sécurité pour un logiciel dont très peu de personnes ne s'occupent au final.

Équipe de développement

Qui a écrit, qui écrit ce logiciel ? Si l’on a réussi à répondre à cette question, divers indices peuvent nous aider à déterminer la confiance qui peut être accordée à l’équipe de développement. Par exemple :

  • Les mêmes personnes ont aussi écrit un autre logiciel, que nous utilisons déjà intensivement ; nos impressions sur cet autre logiciel sont tout à fait pertinentes dans le cadre de cette étude.
  • Des membres de l’équipe de développement ont des adresses qui finissent par @debian.org, et ont donc le droit de modifier les logiciels fournis par Debian GNU/Linux ; si nous utilisons cette distribution, nous accordons déjà, de fait, une certaine confiance à ces personnes.
  • Des membres de l’équipe de développement ont des adresses qui finissent par @google.com, ce qui montre que Google les paie ; s’il n’y a aucun doute à avoir sur leurs compétences techniques, on peut se demander à quel point leur travail est téléguidé par leur employeur qui, lui, n’est digne d’aucune confiance quant à ses intentions concernant vos données personnelles.

  1. Debian.org, 2014, Debian Popularity Contest (en anglais).

  2. L’équipe de sécurité de Debian maintient des informations pour chacun des paquets, visibles sur le security tracker.