Temps de lecture 32 min
Au fait, les libristes ont aussi un corps.
Et ils apprennent parfois à leurs dépens que dans le monde médical, le code propriétaire et les formats fermés peuvent empêcher d’avoir de meilleures chances de se soigner. Souvenez-vous de Salvatore Iaconesi, dont nous avions traduit les déclarations, qui voulait avoir accès à ses données médicales dans un format ouvert.
C’est une histoire personnelle comparable que raconte Karen Sandler au cours d’une conférence que nous vous proposons ici. Karen Sandler est loin d’être une inconnue dans le monde du Libre notamment par son militantisme et ses responsabilités au sein de la Gnome Foundation.
Découvrir qu’un problème cardiaque menace d’un jour à l’autre votre vie même est une épreuve que vous pouvez surmonter en faisant appel à un appareillage de haute technologie (pacemaker, défibrillateur…). Mais découvrir que cette technologie repose sur un code auquel on n’a pas accès, c’est comme le fait Karen prendre conscience que sa vie est à la merci d’un bug dans un code inaccessible…
Non seulement Karen livre ici avec humour le récit de ses déboires, mais elle évoque également d’autres domaines de la vie quotidienne où l’accès au code est désormais crucial. La vidéo qui suit, dont la transcription, la traduction et le sous-titrage ont été assurés par : FredB, Pandark, peupleLa, ga3lig, KoS, Mnyo, Lamessen, goofy, est relativement longue (54 minutes). Ceux qui ne disposent pas d’un long temps de lecture pourront découvrir de larges extraits de la conférence dans le texte sous la vidéo.
Note : je vois d’ici venir dans les commentaires tous ceux qui ne pourront résister au plaisir de faire un jeu de mots recyclant une des deux cent cinquante expressions comprenant le mot cœur. Eh bien, ils auront un gage ! À chaque astuce publiée en commentaire ils devront faire un petit don à Framasoft qui ne vit que de etc. voir le mantra automnal de notre campagne en cours.
La liberté dans mon cœur et partout ailleurs
Cliquer sur l’image pour accéder à la vidéo de la conférence
Je suis vraiment, vraiment contente d’être ici. Ma conférence s’appelle La liberté dans mon cœur et partout ailleurs. Comme dit précédemment, je fais partie de la communauté Libre et Open Source depuis un moment. Je suis directrice exécutive de la fondation GNOME. Nous en reparlerons un peu plus tard, c’est vraiment cool. Et j’ai longtemps été avocate au Software Freedom Law Center, pour finir par en devenir la directrice juridique. Donc j’ai eu l’occasion de faire la connaissance de plein de gens dans la communauté du logiciel Libre et Open Source en les aidant avec tous les emmerdements dont ils ne voulaient pas s’occuper. Vraiment, vraiment amusant ! Je suis une passionnée du Libre et de l’Open Source, je dirais, depuis les années quatre-vingt-dix.
Et je suis aussi une patiente.
Un très gros risque de mourir subitement
J’ai un cœur vraiment, vraiment très grand. En fait, j’ai un cœur énorme.
Vous pensez sûrement à mon travail pour des associations, mais en fait, j’ai une hypertrophie du cœur. J’ai une maladie appelée cardiomyopathie hypertrophique. Je suis toujours un peu nerveuse quand je parle de ça parce que ça revient à dire que mon cœur est un petit peu cassé. Ce n’est pas vraiment ça. Mon cœur est très épais et ça veut dire qu’il a du mal à battre. Il est un peu raide. Mais au final, tout va bien. Pour l’instant, je n’ai aucun symptôme. J’ai seulement un très gros risque de mourir subitement. Le terme est littéralement mort subite. C’est ce que les docteurs vous expliquent quand vous avez cette maladie et que vous devez suivre un traitement à vie. Ils disent que vous avez un risque élevé de mort subite.
Ce qui, en tant que patiente, est vraiment terrifiant. Deux ou trois fois par an je risque de mourir subitement. Et ça se cumule, donc j’ai découvert ça à 31 ans, soit de 20 % à 30 % environ de risque de mort subite pour la décennie suivante. C’est vraiment, vraiment une chose terrible à entendre… mais il existe maintenant une solution ! C’est de se faire poser un défibrillateur.
Le principe d’un défibrillateur, c’est qu’il est installé dans votre cœur. D’ailleurs j’en ai un, il est juste ici. Il a l’air vraiment énorme là mais c’est environ gros comme ça et c’est juste ici. Il a des câbles qui se glissent dans mes vaisseaux sanguins et qui s’enfoncent dans mon cœur, et en gros, il me surveille constamment.
C’est comme avoir des gens qui vous suivent partout avec un défibrillateur électrique et si je tombe raide morte tout à coup, il m’enverra une décharge et je serai remise sur pieds — Et je ne mourrai pas ! C’est formidable.
Qu’est-ce qui tourne dessus ?
Donc, tout ça est merveilleux, parfait. L’électrophysiologiste que j’ai rencontré et qui m’a expliqué ça en avait quelques-uns dans le tiroir de son bureau afin de pouvoir les montrer à tous ses patients parce qu’en voyant à quel point cet appareil est petit, ça parait nettement moins inquiétant. Il l’a poussé vers moi sur le bureau, j’étais assise là, avec ma mère. Je l’ai pris…
Et il disait : « Prenez-le, voyez comme c’est léger… » Alors je l’ai pris et j’ai demandé : « Cool ! Qu’est-ce qui tourne dessus ? ». En réponse, j’ai eu droit à un regard médusé. Ma mère semblait elle aussi perplexe.
Le chirurgien m’a demandé « Mais de quoi parlez-vous ? » et j’ai répondu « Eh bien, de toute évidence cet appareil ne vaut que ce que vaut son logiciel, c’est-à-dire qu’il se base sur le logiciel pour savoir quand je risque une mort subite, que ce soit quand je traverse une rue alors que je n’aurais pas dû, ou que je décide de courir un marathon, ou pour n’importe quelle autre raison. Je suis dépendante de ce logiciel pour savoir quand il est approprié de m’envoyer une décharge et quand ça ne l’est pas. Quand mon cœur a besoin d’être stimulé ou pas. Et l’électrophysiologiste, bien sûr, n’avait pas de réponse à me donner. Il m’a dit « Personne ne m’a jamais demandé ça. Je n’avais jamais pensé au logiciel sur cet appareil. Ne bougez pas, il y a un représentant de Medtronic dans nos bureaux aujourd’hui. Je vais aller lui demander, c’est lui le fabricant, et ils auront sûrement déjà pensé à ça ».
Donc, le représentant arrive et j’essaie de lui expliquer « Je suis avocate au Software Freedom Law Center. Je m’intéresse au logiciel sur mon appareil. Je veux juste savoir comment ça marche, sous quoi ça tourne ? Est-ce que vous pouvez me le dire ? ». Il a répondu : « Personne ne m’a jamais demandé ça auparavant ». Donc, on a eu une conversation très intéressante, et il a conclu par :
« Je comprends, c’est une question très importante, voici mon numéro, appelez moi, et je vous mettrai en contact avec des gens qui pourront vous parler de ça ». Enhardie par cet échange, je l’ai appelé à Medtronic. Il m’a passé le service technique et j’ai commencé à laisser des messages… Mais au final, je me faisais continuellement refouler. Personne ne voulait me parler de ça.
Vous devez nous faire confiance…
J’ai appelé les deux autres principaux fabricants d’appareil médicaux, Boston Scientific et St Jude, et aucun n’a su me donner une vraie réponse non plus. À la fin, j’ai commencé à appeler en disant : « Écoutez, si quelqu’un me laissait voir le logiciel… Je signerai un accord de confidentialité », C’est contre mes principes en tant que militante d’un organisme à but non-lucratif dans un domaine technique. Je n’ai pas envie de signer un contrat qui m’empêcherait de partager ce que je découvre avec le reste du monde. Mais j’ai pensé :
« Au moins, moi, je pourrai voir le code source et j’aurai davantage confiance dans ce qu’on installe dans mon corps ». Mais, malheureusement, on m’a envoyé balader. On m’a dit non. J’ai parlé avec des gens très compréhensifs à Medtronic. J’ai rencontré d’excellents docteurs. Et ces gens me disaient « Oh, vous savez, nous sommes Medtronic, nous avons à cœur de nous assurer de l’absence de bogue dans les logiciels que nous installons sur ces appareils. Évidement, nous ne le vendrions pas si nous ne pensions pas qu’il est sûr. Pour toutes ces raisons, vous devez nous faire confiance ».
Le docteur a ajouté que la FDA, l’Agence fédérale américaine des produits alimentaires et médicamenteux, approuve ces appareils. Donc votre réaction est clairement disproportionnée ». Et quand j’en parlais avec mon électrophysiologiste au téléphone, je disais que j’étais vraiment gênée par tout ça, parce que je pensais à tous ces gens qui portent ces appareils. Certains sont relativement puissants, Dick Cheney en avait un à l’époque. Il en a un encore plus impressionnant aujourd’hui, qui fait continuellement circuler son sang alors techniquement, il n’a pas de pouls. C’est un appareil vraiment fascinant !
Est-ce que je vais vraiment avoir un logiciel propriétaire à l’intérieur de mon corps ?
Les populations qui bénéficient de ces appareils sont souvent dans des positions de pouvoir. Donc on peut facilement imaginer une situation où quelqu’un voudrait éteindre ces appareils. Et l’électrophysiologiste à qui je parlais au téléphone était tellement contrarié, tellement contrarié…qu’il m’a raccroché au nez. Il m’a dit « Je pense que vous préparez quelque chose… je ne comprends pas.. ; je ne sais pas pourquoi ça vous dérange tellement. Si vous voulez un appareil, je vous aiderai mais je ne… Je pense que vous êtes… vous… »
Et il a raccroché.
C’est vraiment terrifiant parce qu’il m’avait précisé au début de la conversation qu’il installait ces appareils tout le temps. Il en installe parfois plusieurs par jour. Alors l’idée qu’il ait pu ne même pas s’être posé de question à propos du logiciel installé sur ces appareils le terrifiait. J’ai donc remis à plus tard et je me suis dit, il faut que j’arrête de penser à ça. C’est trop terrifiant.
Est-ce que je vais vraiment avoir un logiciel propriétaire à l’intérieur de mon corps ? Je ne sais pas. Ajoutez à ça cette histoire de « mort subite » et le fait d’avoir un équipement cousu à l’intérieur de mon corps. Ça fait beaucoup à gérer. Alors j’ai continué à remettre ça à plus tard jusqu’à ce que je ne puisse plus différer parce que mes amis et ma famille continuaient à m’en parler et à me dire « Nous nous inquiétons tellement pour toi, nous savons que tu peux mourir à tout instant » Ma mère… vous savez, évidemment je n’ai pas de ligne fixe et mon mobile ne capte pas bien dans mon appartement Et ma mère, si je ne la rappelais pas dans l’heure commençait à appeler tous mes amis en demandant « Vous avez parlé à Karen aujourd’hui ? Vous savez si elle va bien ? » Je suis allée déjeuner avec une amie, et elle m’a demandé où en était cette histoire. Et j’ai répondu « Eh bien, les compagnies médicales ne me rappellent pas. Et tu sais, je suis sûre que je vais me débrouiller. Et elle a fondu en larmes et dit :
« Tu sais, tu pourrais mourir. Aujourd’hui. Et je ne peux pas le supporter. Si tu ne règles pas cette histoire, je ne sais pas si je peux encore être ton amie. C’est une chose très grave et tu l’ignores juste pour… » ce qu’elle considérait comme un problème ésotérique.
J’ai vraiment compris ça et j’ai compris que je n’avais pas le choix. Alors j’ai eu un appareil. Je me le suis fait implanter et ça a pris un peu de temps pour me remettre de l’opération et aussi pour réfléchir à propos de ma propre situation, prendre un peu de recul, faire quelques recherches. Mais je me suis juré que si j’acceptais cet appareil, j’allais faire des recherches, écrire un article et parler des problèmes que j’avais rencontrés et auxquels la profession médicale, ou du moins, les professionnels de la médecine que j’avais interrogés n’avaient pas de réponse.
Un bogue pour cent lignes de code
Donc, j’ai découvert des choses en écrivant cet article, certaines peuvent sembler normales, mais d’autres vous surprendront. Les logiciels ont des bogues. (…) Et les appareils médicaux, comme l’a dit Matthew Garret, auront des bogues, parce que l’institut d’ingénierie logicielle estime qu’il y a environ un bogue pour chaque centaine de lignes de code. Donc même si la majorité des bogues était interceptés par les tests, même si les trois quarts des bogues étaient interceptés lors des tests, ça fait toujours un sacré nombre de bogues.
J’ai lu une étude qui observait les rappels d’appareils publiés par la FDA. Fondamentalement, l’étude portait sur l’ensemble des rappels et a déterminé ceux qui venaient vraisemblablement de pannes logicielles puis ils les ont évalués. Parmi ceux qu’ils ont pu étudier suffisamment et dont ils ont pu déterminer précisément les failles logicielles : 98 % d’entre elles auraient pu être détectées de simples tests par paires.
Donc, pour les tests basiques que vous êtes en droit d’attendre sur n’importe équipement technologique — oui, la FDA les soumet à quelques tests. Mais si les entreprises ne font pas de tests basiques qu’est ce qu’on peut faire ?
Donc, les logiciels ont des bogues. Ici dans cette pièce, tout le monde le sait. Une autre chose que la plupart d’entre nous savons c’est que la sécurité par l’obscurité ça ne marche pas. Même si ça peut sembler contre-intuitif pour ceux qui ne sont pas dans cette pièce. Toutes les personnes à qui j’ai expliqué cette idée dans le corps médical m’ont répondu : « Mais je ne comprends pas… pourquoi voulez vous que les gens puissent voir le logiciel ? Si tout le monde peut voir le code source, il sera beaucoup plus facile de le pirater ! ».
Mais nous savons tous que ce n’est pas le cas. En fait, en publiant le code source, tout le monde peut le voir, et il est plus sûr. Mais c’est une question capitale en réalité. J’en parle dans mon article : Tués par le code qui cite un certain nombre d’études montrant que les professionnels de la sécurité approuvent cette idée.
Donc pour le moment, on a le pire des deux mondes : un code fermé qui ne profite pas d’une relecture et d’une correction par le plus grand nombre. Mais on manque également de sécurité sur ces appareils. Beaucoup d’entre eux émettent des informations en sans fil. C’est le standard aujourd’hui. Quand j’ai découvert cela, j’étais choquée. Vous êtes en train de me dire que mon appareil cardiaque va émettre en continu ? Considérant les conférences auxquelles j’assiste, les gens que je fréquente, je n’ai vraiment pas envie de voir mes informations diffusées.
algorithmes
Donc c’est une des choses que j’ai abordées avec les différents docteurs que j’ai pu rencontrer. Comme vous l’imaginez, j’ai abandonné cet électrophysiologiste qui m’avait raccroché au nez. Et je suis allée de cardiologue en cardiologue pour trouver quelqu’un qui puisse comprendre ces problèmes ou qui puisse au moins comprendre pourquoi cela m’inquiétait. Et j’ai fini par trouver un excellent cardiologue et excellent électrophysiologiste qui m’a dit « Je n’avais jamais pensé à cette question, mais je comprends que ça puisse poser problème. Vous avez besoin de cet appareil, vous ne pouvez plus attendre. Mais je vais travailler avec vous, et on va trouver un moyen de résoudre au moins certains des problèmes qui vous inquiètent ».
Donc, l’une des choses que mon électrophysiologiste a faites c’est qu’il a appelé les hôpitaux, l’un après l’autre jusqu’à ce qu’il trouve un ancien pacemaker.
Il m’a expliqué que, ma défaillance cardiaque étant simple, j’avais seulement besoin d’un appareil qui surveillait les rythmes dangereux et qui m’enverrait une décharge en cas d’alerte. C’est un algorithme bien plus simple que celui des nouveaux appareils. Beaucoup des nouveaux appareils ont un algorithme complexe de stimulation pour des patients ayant une grande variété de problèmes. On peut tout à fait comprendre les raisons des compagnies médicales. Ces appareils sont très difficiles à faire. Ils fabriquent des produits de haute précision. Et s’ils peuvent utiliser ces appareils dans des cas plus variés alors tout est pour le mieux.
De plus vous ne pouvez pas savoir quels genres de complications les patients vont éventuellement développer. Donc, pour le moment, je n’ai aucun symptôme mais je pourrais en développer et c’est génial d’avoir cette technologie de stimulation. Mais mon cardiologue électrophysiologiste m’a dit : « Bon maintenant on voit que vous avez besoin de quelque chose de simple. Alors pourquoi ne pas vous trouver un ancien modèle d’appareil ? »
Donc j’ai actuellement un ancien appareil qui communique par couplage magnétique et non par technologie sans fil. Mais mon père a ce type de pacemaker et quand il entre dans une pièce du bureau des techniciens ils changent son pouls. Donc, avant même qu’il ne soit assis ils savent énormément de choses sur lui et ils ont la capacité de vraiment l’affecter. C’est incroyable. Mais comme vous pouvez le voir sur le dernier point de cette diapo ces appareils ont été hackés. En fait, un groupe de réflexion de plusieurs universités travaillant ensemble a montré qu’en utilisant du matériel disponible dans le commerce vous pouvez hacker ces appareils et en prendre le contrôle. Non seulement, Ils sont parvenus à déclencher des décharges ce qui est déjà terrifiant en soi…
— Une fois, mon pacemaker s’est déclenché par erreur et je peux vous dire, que c’est comparable à un coup de pied dans la poitrine. Ça vous met au tapis au moins pour quelques minutes. J’ai été forcée de m’asseoir, c’était si épuisant, la surprise et l’inquiétude m’ont forcée à dormir quelques heures pour m’en remettre. C’est très éprouvant.
… donc non seulement ils sont parvenus à envoyer une décharge mais ils ont également pu arrêter le traitement. Si l’appareil stimulait le pouls, ils pouvaient l’arrêter et beaucoup de gens ont besoin de stimulation pour rester en vie. Beaucoup de gens ne peuvent monter les escaliers sans cette stimulation. Mon père en fait partie. Ils ont également pu récupérer des informations clefs à partir de ces appareils comme les numéros d’identifications médicaux, les noms des médecins, les numéros de série… Beaucoup d’informations personnelles sont diffusées et il n’y a aucun chiffrement sur ces appareils. C’est plutôt inquiétant. Ils sont également parvenus à mettre les appareils en mode test ce qui a pour effet de consommer la batterie. Euh, la batterie s’épuise à un rythme bien plus rapide que dans des circonstances normales et ces appareils n’ont d’intérêt que s’ils ont de la batterie. Donc si la batterie lâche sur mon pacemaker il me faudra un nouvel appareil, ce qui signifie une opération.
…au bout du compte, personne à la FDA n’a vu le code source.
Donc ces appareils ont été hackés. Ces conclusions sont arrivées bien après mon diagnostic. Les médecins s’appuient beaucoup sur le fait que ces appareils ont l’agrément de la FDA aux États-Unis, et d’institutions similaires dans d’autres pays. En bonne avocate, j’ai fait des recherches sur la FDA et leur processus d’approbation des logiciels. Ce que j’ai découvert, c’est que la FDA ne vérifie pas systématiquement le code source des appareils sauf en cas d’erreur particulièrement visible en lien avec le logiciel, ils ne demandent généralement pas à le vérifier.
Il n’y a même pas de cahier des charges clair pour le logiciel et il y a des raisons pour ces décisions de la FDA, mais nous croyons que celle-ci devrait faire beaucoup plus qu’elle ne fait en réalité. L’absence de cahier des charges clair est lié au fait, d’après eux, que ces sociétés conçoivent des appareils très spécialisés avec des particularités propres à chaque fabricant. Il y a donc probablement des tests spécifiques à ces appareils et les mieux placés pour les réaliser sont ceux qui connaissent le mieux ces machines, c’est à dire leurs fabricants. Et il y a des allers-retours pour savoir s’ils ont fait les bons tests ou non, mais en vérité, au bout du compte, personne à la FDA n’a vu le code source.
Puisqu’ils ne le demandent pas, ils n’en ont même pas de dépôt. Donc si une panne catastrophique se produit chez Medtronic, par exemple, je ne sais pas s’il y a un dépôt canonique pour le logiciel auquel je pourrais avoir accès… et sans possibilité de mise à jour du logiciel sur mon appareil, je devrais être opérée pour en avoir un nouveau.
Pas de liberté vis-à-vis de mon propre corps
J’ai parlé lors d’un débat, avec un type dans la cyber-sécurité à la FDA et j’étais vraiment, vraiment nerveuse parce que j’ai fait tout ce que je pouvais en tant qu’avocate, j’ai fait toutes les recherches que j’ai pu sur la FDA mais je n’étais pas sûre que c’était vraiment le cas en pratique, donc j’ai projeté mes diapos et dit :
« John, dis-moi si je me trompe, mais voilà ce que je pense. Je pense que ça se passe comme ça… » Et j’ai continué avec une diapo sur le logiciel Libre et Open Source et pourquoi c’est tellement mieux et plus sûr. Dès qu’il a eu la parole, il a dit :
« Tout le monde pense que la FDA devrait faire comme ci, comme ça, mais nous n’avons pas les ressources et la FDA n’est pas là pour ça ».
Puis il a fait une pause, m’a regardée et juste quand j’allais… vous savez. Et il a dit : « Mais vous parlez d’autre chose. Vous parlez de laisser tous les autres passer en revue le code source, c’est quelque chose de très intéressant. Donc, s’assurer que les logiciels de nos appareils seront publiés revient à dire que tout le monde pourrait les relire. Mon père, qui a un pacemaker, est également ingénieur et un heureux programmeur. Il l’aurait probablement examiné.
Beaucoup ici connaissent des gens avec des pacemakers nous aurions fouillé dans ce code, assurément ! Une autre chose que j’ai découverte qui est un peu étrange c’est qu’aux États-Unis, comme ces appareils ont l’agrément d’une agence fédérale, les patients ne peuvent pas recourir à la State True Law. Il y a donc tout un éventail de recours auxquels ont normalement accès les patients, dont les fabricants n’ont même pas à s’inquiéter. Bon maintenant je ne dirais pas que les entreprises de matériel médical se moquent de savoir si les malades meurent, évidemment que non. Mais il y a toute une série de recours légaux qui ne sont pas disponibles. Vraiment étonnante cette étude, et j’ai tout résumé dans l’article que j’ai écrit : il est disponible sur le site web du centre juridique pour le logiciel libre.
Au bout du compte je n’ai pas de liberté vis-à-vis de mon propre corps. Je n’ai pas l’autorisation d’analyser le logiciel qui est implanté en moi. Il est littéralement connecté et vissé à mon cœur et je ne peux pas l’examiner. Ça me semble incroyable. Je n’en reviens toujours pas du fait que ça me soit arrivé. C’est un peu bizarre que moi, avocate au Software Freedom Law Center j’aie cette maladie cardiaque étrange, je l’admets. Mais c’est toujours hallucinant que je n’aie pas eu le choix. Le seul choix était entre une grande probabilité de mourir, ou se faire implanter cet appareil à l’intérieur du corps. J’espère que personne ici n’aura à faire ce choix, mais c’était vraiment, vraiment effrayant.
Voitures
Puis j’ai commencé à y réfléchir, et vous voyez, ce n’est pas seulement une question d’appareils cardiaques. Ça concerne tout ce dont dépendent nos vies dans notre société. Alors que j’y réfléchissais, j’ai pris conscience que cela concernait beaucoup plus de domaines de nos vies que je ne le pensais. Par exemple, les voitures. Comme ce groupe de réflexion universitaire qui a travaillé sur les appareils médicaux, soit dit en passant, si vous avez du temps, vous devriez lire cette étude. C’est fascinant, ils ont implanté cet appareil dans un sac de bacon ou de viande quelconque pour le stimuler et ils ont montré tout l’équipement facilement trouvable qu’ils ont utilisé pour modifier l’appareil.
Et la même procédure à été appliquée aux voitures. Et un autre groupe a montré qu’ils sont parvenus à pirater deux marques différentes, deux fabricants différents de voitures. Donc l’IEEE affirme qu’une voiture haut de gamme compte près de 100 millions de lignes de code. Donc si on revient à ce que le Software Engineering Institute a dit : « environ un bogue toutes les 100 lignes de code » ça fait un paquet de bogues, juste dans votre voiture. Et ce ce groupe a réussi à faire, tout ce que vous pouvez imaginer. Ils sont capable de faire accélérer, freiner la voiture. Ils ont réussi à contrôler chaque roue individuellement. Et ma partie préférée, juste pour s’amuser, je ne sais pas si vous pouvez voir, mais ils peuvent mettre des messages sur le tableau de bord et ils ont écrit pwnd et mis une petite émoticône avec un X pour les yeux. L’idée qu’ils aient pu prendre contrôle de deux marques différentes de voitures haut de gamme est vraiment incroyable pour moi.
La sécurité par l’obscurité ne fonctionne pas
Les machines à voter sont un autre domaine très sensible et nous en avons déjà parlé.
Beaucoup d’experts en sécurité ont parlé des problèmes avec leurs machines à voter. Aux États-Unis, nous comptons sur Diebold et beaucoup de fabricants privés. Nous avons eu des problèmes avec l’étalonnage. Je ne sais pas si vous avez vu ce dessin animé hilarant dans lequel des gens essayent de voter pour le bon candidat et le nom du candidat pour qui ils veulent voter se dérobe sur l’écran tandis que vous essayez d’appuyer dessus et à la fin, quel que soit votre choix, ça dit : « Vous vouliez voter pour l’autre candidat, n’est-ce pas ? N’est-ce pas ? »
Il est très difficile de le savoir parce que parfois nous n’avons pas de reçu pour vérifier, on ne sait même pas si notre vote a bien été enregistré et si on a pu voter pour notre candidat au final.
Vraiment bizarre car c’est la base de notre société et le pilier de notre démocratie. J’adore ce qu’ils ont fait au Brésil. Je ne sais pas si vous en avez entendu parler, mais le Brésil a dit : « On sait que ces logiciels ont des failles et des bogues ; alors on invite les équipes de hackers à venir, on vous donnera le code source et on donnera un prix à quiconque trouvera un moyen de trouver une faille pour s’introduire dans le système ». Sur toutes ces équipes, deux ont trouvé des bogues. Aucun d’eux ne pouvait affecter une élection, mais ils ont pu les corriger. Et ces hackers ont reçu une récompense. La démocratie est plus sûre. La sécurité par l’obscurité ne fonctionne pas. Je ne sais pas quand nous allons enfin le comprendre mais le Brésil a su le faire. Donc c’est possible.
Nos institutions financières, ouais c’est passionnant, les institutions financières sont un autre domaine dont nous avons récemment pu observer les déboires quand elles déclinent. De nombreuses institutions utilisent des logiciels et les marchés boursiers et le fonctionnement de nos banques. Toutes ces choses sont critiques vis-à-vis de la manière dont nous vivons. C’est plus sociétal, mais nous avons déjà vu qu’il y a des vulnérabilités de ce côté. Tout cela pour dire, et j’insiste : mon appareillage médical peut être contrôlé !
Nous avons atteint le point où le logiciel doit être utilisable par tous.
Nos voitures peuvent être contrôlées et détraquées et nos institutions financières compromises. Nous sommes tous d’accord, les logiciels socialement et vitalement critiques doivent être sûrs. Mais nous sommes à une période très intéressante. Car comment savoir quel logiciel est d’un intérêt vital ou socialement critique ? La manière d’utiliser les ordinateurs a changé si rapidement et récemment… Je suis ébahie par la quantité de gens qui se sont mis à utiliser des ordinateurs comme ils ne l’avaient jamais fait.
Ce ne sont plus seulement des personnes à l’aise avec la technologie. C’est tout le monde, nos grands-parents, tout le monde. Et nous utilisons les logiciels pour tout, c’est devenu notre manière de tout faire. Comment nous communiquons. Comment nous parlons au téléphone. Comment nous écrivons, faisons de l’art. Comment nous gérons les institutions scolaires et comment nous gérons nos vies. Nous construisons cette infrastructure et nous n’y réfléchissons même pas.
Beaucoup de personnes utilisent leurs téléphones pour suivre des choses comme leur entraînement ou leur régime. C’est très pratique parce qu’on peut suivre ce qu’on a mangé au fur et à mesure, ce qu’on a fait. Certains téléphones ont des podomètres, et c’est assez basique mais il existe déjà un logiciel pour l’iPhone qui peut communiquer avec une pompe à insuline et évaluer l’exercice et le régime en fonction du niveau de sucres dans le sang.
Et nous voilà revenus à l’appareillage médical. Vous avez un iPhone sur lequel vous comptez pour votre vie. Nous créons tout cette infrastructure, et nous avons envie d’y réfléchir voilà pourquoi l’ordinateur personnel est si important. C’est en quelque sorte là où tout prend son sens dans mon histoire personnelle et les raisons pour lesquelles j’ai quitté le Software Freedom Law Center que j’aimais et me rendait très heureuse d’y être avocate pour pouvoir travailler et être à la Fondation Gnome que j’ai également quittée.
Et je parle d’ordinateur entre guillemets parce que ça va des manières d’interagir avec nos ordinateurs à la façon dont nous gérons nos vies à travers des logiciels. Nous avons atteint le point où le logiciel doit être utilisable par tous. Je pense que tout le monde ici doit connaître une personne plus âgée qui, il y a quelque années, n’avait probablement jamais rien fait avec son ordinateur.
Ma mère était l’une de ces personnes. Je me rappelle qu’étant enfant, je lui répétais :
« Mais maman, regarde ces super jeux ! — m’intéressent pas »
Et je me rappelle qu’au collège, je lui disais :
« Maman, si nous pouvions parler par courriel, ça serait tellement mieux ! — (Rien)…
Je me rappelle à l’école de droit, je disais :
« Maman, je peux effectuer toutes ces recherches sur mon ordinateur, sans avoir à rester toute la journée à la bibliothèque, c’est génial ! — (Rien)…
Plus tard, j’ai essayé de lui dire « Maman, j’organise mon voyage avec mon ordinateur ». Soudain, elle était un peu intéressée et maintenant, avec tout ce qui est arrivé elle ne peut plus rien faire sans son ordinateur. Maintenant, son ordinateur est devenu… Premièrement, elle envoie des courriels et des messages à ses amis, elle gère ses voyages et ses finances. C’est spectaculaire pour moi parce que je n’ai pas utilisé ici mon père qui est ingénieur, mais ma mère était vraiment un peu technophobe. Et maintenant, elle aime Apple. ELLE AIME APPLE. Elle peut utiliser son ordinateur pour… elle n’a pas à y penser.
C’est super, et c’est très frustrant pour moi. Mais je suis contente qu’elle puisse maintenant utiliser un ordinateur et c’est quelque chose qu’elle possède maintenant. Elle ne me pose pas de questions, enfin si, elle le fait… Mais elle ne voit pas de raison pour laquelle ces appareils ne lui seraient pas destinés et elle est très représentative de la majorité de notre société. Et ces gens n’auraient pas été aussi capables il y a quelques années, de faire autant avec leurs ordinateurs. Nous devons séduire des gens parce que ce sont ceux qui choisissent d’adopter l’iPhone pour mettre en relation leur exercice et leur régime avec leur pompe à insuline.
C’est le genre de chose dont nous devons nous préoccuper parce que si nous ne rendons pas nos logiciels simple pour tout le monde, personne ne voudra les utiliser. Et nous avons aujourd’hui une opportunité, une fenêtre qui se referme lentement parce que nous faisons maintenant des choix avec lesquels nous allons devoir vivre longtemps. Nous créons des habitudes, nous créons des attentes et nous établissons la mesure de notre société concernant ce qui est ou non acceptable pour un logiciel.
Vous êtes ici, à LinuxConfAu, vous connaissez les raisons pour lesquelles vous devriez utiliser des logiciels Libres et Open Source. Vous êtes ici pour toutes ces raisons y compris parce que c’est vraiment amusant. Nous avons passé un bon moment ici, et appris toutes sortes de choses vraiment cool mais derrière tout ça, la source d’où proviennent toutes ces raisons, c’est la Liberté.
Le logiciel Libre et Open Source n’est pas juste un marché profitable c’est aussi la bonne chose à faire. Donc lorsque nous parlons de nos appareils cardiaques, nous parlons de nos machines à voter et ensuite de la manière de vivre nos vies et de l’infrastructure par laquelle nous communiquons.
Nous voyons que le logiciel Libre et Open Source est exactement ce qu’il faut à notre société et pour l’apporter aux autres gens nous devons nous assurer que c’est facile et simple à utiliser pour eux.
(…)
Nous devons franchir la barrière, nous devons fournir des logiciels utilisables par des gens qui sinon ne pourraient pas s’en servir. Nous devons nous assurer que nos ordinateurs sont accessibles à tous parce que nous ne pourrons pas créer la bonne infrastructure pour toute la société si nous n’embarquons pas ces gens avec nous. (…)
Vous savez, nous avons la technologie, c’est bien agréable. Je n’ai plus vraiment besoin de bidouiller mon bureau. Je suis passée sur Gnome-Shell, et c’est brillant et très bien fait, j’ai à peine besoin de lignes de commande pour les choses en lien avec mon environnement de travail et uniquement quand je me sens bloquée. Ce n’est pas pour tout le monde, mais nous devons faire le choix du libre et des plateformes ouvertes, nous avons besoin de développer là-dessus parce que c’est le seul moyen que nous ayons de créer des sociétés meilleures et plus sûres. C’est le seul moyen de créer un monde où nous saurons que nos logiciels seront revus et qu’ils auront leur intégrité. Nous devons construire nos communautés dans l’espace non lucratif car nous devons établir ce très haut degré de confiance. Nous devons réinvestir notre idéologie dans le logiciel libre. Pour aller un peu plus loin je dirais : il ne s’agit pas de terminologie, mais d’idéologie. Nous devons vraiment penser à rendre le monde meilleur car nous le pouvons et nous le devons. Choisissons les logiciels libres et ouverts pour nous-mêmes et pour notre société.
Néandre
De tous les arguments en faveur du logiciel libre, celui-ci me parait un des plus frappants, si ce n’est un des plus convaincants.
aucuneimportance
@Néandre : Sans doute vous dîtes-vous cela parce que c’est précisément l’argument le moins convaincant.
En gros qu’un logiciel serait moins buggé parce qu’il serait libre (à comparer avec l’équivalent propriétaire)… Bah c’est une énorme foutaise. Bon, effectivement, c’st une « idée » qui fait du bien à lire mais ce n’est pas pour autant qu’elle en devient incontournable, voire vraie.
Primo, il n’y a aucune étude qui démontre ce fait et deuxio, toute cette belle théorie (« les millmiers d’yeux qui regardent » et blabla) s’est effondrée par exemple lors de la faille de *sécurité* (pas anodin) ssh/ssl chez Debian, qui a survécu deux ans, je repète deux ans (pas anodin) alors que des milliers d’yeux étaient censé ausculter ce code…
Donc, la réalité est la suivante : il ne sert à rien d’avoir du code libre et des milliers d’yeux disponibles, si ces yeux regardent … ailleurs !
La notion de libre ou pas n’a rien à voir avec la notion de qualité ou de fiabilité. La meilleure méthode pour atteindre une fiabilité de (très) haut niveau c’est de *payer* beaucoups d’yeux pour être a peu près sûr qu’ils regardent là où on leur demande de regarder. Que le code à lire soit libre ou pas, n’a aucune importance.
Pareil pour les machines à voter, que le code soit libre ou pas, ce n’est pas le problème!
Enfin bref, on retrouve ici les bons vieux clichés qui réconfortent la Belle communauté du Libre. C’est juste des illusions d’optique, mais ça réconforte…
Youpi.
AP
@aucuneimportance : Vous semblez bien désabusé et dédaigneux de tous ceux qui aspirent à un peu plus de transparence dans le fonctionnement des logiciels et mécanismes qui encadrent toujours plus nos vies.
« […] qu’un logiciel serait moins buggé parce qu’il serait libre […] » Les partisans du logiciel libre n’affirment pas cela. Tant que le code est d’origine humaine, peu importe la structure, la rémunération, les contrôles qu’on trouve derrière : il subsistera toujours des erreurs dans une version lambda d’un logiciel. La question est ensuite : « qui a le droit, la possibilité de corriger d’éventuelles erreurs ? ».
« il ne sert à rien d’avoir du code libre et des milliers d’yeux disponibles, si ces yeux regardent … ailleurs ! ». Entièrement d’accord… mais au moins ils *peuvent* regarder… et le pool d’yeux disponibles n’est pas cantonné à un périmètre donné. Dans le cas d’un code propriétaire, ils ne peuvent pas. Ils sont soumis à la bonne ou mauvaise volonté du fournisseur, sans doute hyper-compétent mais libre de n’en faire qu’à sa tête.
Quand le logiciel touche à l’intime immatériel ou très physique comme ici (lien direct avec un organe), il est important de pouvoir disposer de tous les moyens possibles pour 1. contrôler qu’il fait correctement ce qu’il est censé faire, ni plus, ni moins et 2. corriger *vite* tout comportement non attendu, avec ou sans le concours des auteurs initiaux du logiciel. Cela vaut pour un bête logiciel de vidéoconférence (mes conversations doivent demeurer privées, je veux être sûr que personne ne pourra les pirater) comme pour un stimulateur cardiaque ou une voiture à conduite automatisée (auxquels je confie littéralement ma vie). Les licences libres constituent un outil simple allant dans ce sens.
Si on souhaite éviter le recours à l’ouverture directe, on pourrait aussi imaginer –mais c’est bien plus lourd à mettre en place– des institutions indépendantes et dotées de l’autorité nécessaire pour faire pression sur des entreprises créatrices de logiciels ou mécanismes propriétaires ayant soulevé des doutes… Dans le cas présent, ce genre d’institutions seraient à même de faire conduire des audits poussés sur tel ou tel matériel, sur simple requête.
Pandark
Le fait que certains bugs mettent du temps à être détectés dans des logiciels Libres et pas seulement dans des logiciels propriétaires est-il une preuve de l’inefficacité des logiciels libres en matière de sécurité ? Je ne pense pas.
Des bugs sont restés bien plus longtemps sans être découverts dans des logiciels propriétaires, mais surtout, certains sont restés plus longtemps une fois découverts dans ces derniers sans être corrigés.
Une différence importante, c’est que lorsqu’une faille est détectée, les gens sont au courant. Il y a dont une pression du public pour corriger les bugs et écrire des tests.
L’autre différence, c’est que les gens peuvent participer à ces revues, écrire des teste, proposer des améliorations…
Les fabricants de matériel informatique de pointe n’ont en gros de comptes à rendre à personne, et les organisations censé évaluer et valider la qualité de leurs produits n’ont pas les moyens (techniques, humains…) de le faire.
Comme l’indique Karen Sandler, des études montrent que des tests basiques (all-pairs testing) ne sont pas faits.
Une personne dont la vie ou celle d’un de ses proches dépend du fonctionnement d’un de ces appareils a une motivation d’un tout autre ordre que l’argent pour faire des revues et des tests du code.
aucuneimportance
Il ne s’agit pas d’être « désabusé », il s’agit d’être réaliste.
Et cela est à la portée de tout libriste : suffit de regarder ce qui se passe sous le capot lors du simple fonctionnement de votre distrib préférée. Surveillez attentivement les logs, le .xsession-errors, placez vos applis en mode debug, etc Et, observez…
Après, faîtes la transposition sur le logiclel de *votre* pacemaker… Et ce sera déjà moins rose 🙂
Autre suggestion : prenez au hasard le fil de discussion associé à un bug déposé sur un bug-tracker… 9 fois sur 10, le traitement de ce bug est « pifométrique », en gros les « yeux » n’ont pas de compétence particulière pour « raisonner », et bien souvent, très peu regardent réellement le code mais bien plus ce qui est « observable » (ça marche, ça marche pas, je tente ceci, je tente cela)…
Par définition, le logiciel libre ne possède qu’une seule qualité intrinsèque non-contestable : il est libre. Pour tout le reste (fiabilité, maintenabilité, disponibilité…) il n’y a aucune règle scientifiquement établie et encore moins de comparatif libre/proprio.
NB : ah oui, des tas de bugs dans du libre restent trèèèèèès longtemps sans être corrigés… Tous les bugs « libres » ne sont pas corrigés dans les 15 jours qui suivent. Ceci est également une légende…
marto
@aucuneimportance:
Je suis un peu surpris de ta réaction.
À te lire on pourrait croire que tu trouves tout cela très bien comme c’est.
Et pourtant l’article te met sous le nez un pacquet de choses que libérer le code améliorerait.
Dans ton argumentation tu utilises le fait que du code est du code, quelle que soit l’application et quelle que soit son utilité. Sauf que ça c’est pas vrai. D’abord la vitesse à laquelle se corrigent les bugs dépend de pleins de choses, en particulier de la vitesse à laquelle on les détecte. Donc pour une solution donné, il est très difficile de faire une comparaison entre 2 programmes, ba oui ces 2 programmes sont très probablement dans des contextes différents.
Le fait d’avoir du code ouvert, c’est quand même chouette (quand ta vie en dépend, tout particulièrement). Tu peux y jeter un œil quand l’envie t’en dit. Alors c’est pas parfait, comme les dix mille précédent tu vas probablement regarder la même partie, peu buggé comme par hasard. Par contre, sur les dix mille, au bout d’un moment, tu as peut-être 2-3 personnes qui vont s’y mettre sérieusement. Et là ça peut tout changer non? Il y a des choses qui seront corrigés ou améliorées. Pourquoi tu veux empêcher celui de passage d’améliorer le truc pour tous ceux qui passent après? Ça te fait trop mal au cœur (bon ok, je fais un don sous peu…) de voir les gens s’entre-aider?
DesPreuves
Je rejoins l’avis d’aucuneimportance. Malheureusement, l’argument du libre pour améliorer la sécurité n’est pas très convaincant. D’ailleurs on peut parfaitement encadrer juridiquement la publication des sources d’un logiciel sans que celui-ci soit libre pour autant. Mais ça ne veut pas dire qu’il ne faut pas faire de libre, simplement ce n’est pas pour cette raison que c’est un bon choix.
Pour ce qui est de la sécurité d’un système dit « critique » comme un pace-maker (ou les commandes de vol d’un avion), c’est avant tout par l’imposition de méthodes draconiennes et scientifiques qu’on peut parvenir à une grande confiance. Par exemple : un processus de développement très strict et encadré par des autorités compétentes et pourvues de moyens conséquents, l’emploi de méthodes avancées de génie logiciel (là il faut faire aux théoriciens du test et à leurs outils de couverture, non-régression, calcul de bornes, etc. ; mais aussi le développement par composants et contrats), l’usage de la preuve mathématique de la correction des logiciels. C’est le genre de choses sur lesquelles l’aéronautique, le spatial, le ferroviaire, les cartes à puce et le nucléaire sont les plus avancés, en particulier en France. À ma connaissance, ni l’automobile ni le médical ne sont à ce niveau de qualité alors qu’ils ont un impact direct sur la vie des personnes.
Là où le libre peut être défendu à ce niveau, c’est sur sa capacité de fait à produire un pot commun de composants « certifiés » qui pourraient être réutilisés de projets en projets.
jbar
hum hum … pour ceux qui nous vantent les procédés « critiques, strictes, rigoureux » de certains catégories de logiciel propriétaires :
http://fr.wikipedia.org/wiki/Vol_50…
Sans compter tous les crash « bizarres » des avions de combat moderne (secret-défense) rafale y compris.
Et pour ceux qui reviennent sur la faille Debian dans l’aléa openssh (qui vaut pas GnuTLS+GnuPG au passage). A-t-on seulement pu faire un virus efficace pour exploiter cette faille sur tous les serveurs Debian de par le monde ??
On est encore loin de voir qqch exploiter 7 zero-days d’un coup … :-p
http://www.bbc.co.uk/news/technolog…
http://fr.wikipedia.org/wiki/Flame_…
Question faille aucun logiciel est infaillible. Mais en tant qu’ ingénieur, développeur et architecte expérimenté, je préfère toujours utiliser des logiciels sur lesquels je peux prendre la main facilement (ie. en le compilant moi même plutôt qu’à devoir faire du reverse, décompilation et autre bidouilles chronophages).
Néandre
Je reste sceptique vis à vis de certaines de vos réactions, en particulier celle qui font le parallèle avec la fiabilité d’applications actuelles sous licence libre.
Certes, une partie des arguments de Karen Sandler sont tournés vers l’amélioration de la sécurité des applications critiques lorsqu’elles se tournent vers un format plus ouvert, et même si j’en suis pour ma part entièrement persuadé, j’admets volontiers que ce n’est pas systématique.
En revanche, si j’ai trouvé ses propos formidables, c’est qu’elle pose le doigt sur une problématique réelle : comment contrôler les logiciels qui tournent dans des environnements qui peuvent être vitaux. Au même titre que notre système démocratique dispose d’assesseurs pour contrôler le dispositif électoral, j’estime qu’avoir un droit de regard et une certaine transparence sur de telles plateformes est plus qu’un vieux cliché réconfortant la belle communauté du libre mais bien une nécessité.
jacques-olivier
Bonjour,
Je trouve cette présentation très convaincante. Et je dois dire que je suis touché par les propos et le courage de cette femme.
La discussion dans les commentaires semble porter sur l’efficacité/sécurité en opposant logiciels privatifs et open-sources … Personnellement ce que je trouve révoltant c’est que si quelqu’un le souhaite, il n’a juste pas la possibilité de connaître le fonctionnement de cet appareil. Même en insistant et en remuant ciel et terre.
Et c’est ce qui me fait être promoteur des logiciels / matériels / arts libres, c’est que si je veux en savoir plus, je peux. Si je veux participer, aider à la modification ou à la création, j’en ai la possibilité.
Cette liberté là m’est précieuse, cet exemple le démontre une fois de plus.
Librement,
Jacques-Olivier
nicoals
Certes, un logiciel libre n’est pas forcément plus fiable qu’un logiciel privateur équivalent. Mais il n’est pas non plus forcément moins fiable que son équivalent privateur.
Or c’est cette malheureuse impression de mauvaise qualité qui naît trop souvent chez des gens découvrant la gratuité du logiciel libre.
Et les arguments de l’Open Source, insistant sur les gains (gains POTENTIELS, pas systématiques, nous sommes tous d’accord.) en fiabilité et en sécurité du modèle libre par rapport au modèle privateur, ont pour but de tordre le coup à cette idée reçue. Ce qui est une bonne chose…
… mais il est vrai aussi que le l’idée du Libre est beaucoup plus profonde que d’éventuelles améliorations de code, et qu’il ne faut donc pas s’attarder trop sur ces arguments quand on explique le Libre aux néophytes.
DesPreuves
Cher jbar, tu es peut-être un « ingénieur, développeur et architecte expérimenté » mais il est clair que tu es complètement ignorant du monde du logiciel critique et du spatial, et même de ce qu’est le libre. Si tu connaissais le sujet, tu saurais qu’Airbus, le CNES, etc. disposent des sources des logiciels critiques présents sur leurs systèmes et peuvent donc les « compiler » comme tu dis. Pas besoin de faire du « reverse ».
Secundo, le logiciel d’Ariane n’est pas propriétaire, ni libre. Il est développé de façon ad hoc pour un unique système qui ne fait pas l’objet d’une distribution. RMS l’a déjà dit dans plein d’écrits, ce genre de logiciel n’a pas particulièrement vocation à être libéré.
Tertio, c’est bien de répéter la propagande de la commission d’enquête Ariane 501 qui avait quelque chose à vendre (quelque chose de bien d’ailleurs, donc on leur pardonnera)… mais l’erreur fondamentale dans le crash est une erreur d’ingénierie système, pas du tout d’informatique. Car le fait que l’erreur n’ait pas été capturée était volontaire, pour des raisons de physique et de capacité de calcul issues d’Ariane 4. L’équipe système de 501 n’a pas pensé que les conditions avaient changé et n’a donc même pas contacté les équipes logiciel. Cellec-ci n’ont donc rien à se reprocher et il n’y a donc pas de bug mais une erreur de réutilisation et de mise à jour de spécs système.
DesPreuves
PS :
Notez que je n’ai à aucun moment posé une quelconque supériorité du propriétaire sur le libre. Je dis que ce n’est pas pour une prétendue sécurité accrue qu’il faut promouvoir le libre, c’est tout. Pour des raisons éthiques, politiques, oui bien sûr.
Kalenx
@aucuneimportance
« » »toute cette belle théorie (« les millmiers d’yeux qui regardent » et blabla) s’est effondrée par exemple lors de la faille de *sécurité* (pas anodin) ssh/ssl chez Debian, qui a survécu deux ans, je repète deux ans (pas anodin) alors que des milliers d’yeux étaient censé ausculter ce code… » » »
Bon, d’accord, moi aussi je vais jouer :
Proposition : l’utilisation d’outils de débogage, l’adjonction de tests fonctionnels, d’intégration et unitaires et la révision externe augmentent la fiabilité du code
Contre-exemples : la sonde Mariner 1, le bug du Therac-25, Windows Me (d’accord le dernier c’est du troll). Tous ces exemples sont des cas notoires où ces toutes ces techniques poussées à leur maximum n’ont pas pu éviter un bug catastrophique.
Conclusion : les débogueurs, les tests fonctionnels, les révision de code, tout ça c’est du rêve, ça ne sert à rien. Toute cette belle théorie selon laquelle ces actions augmenteraient la fiabilité du code s’effondre.
Programmons toujours d’une traite, sans trop réfléchir, de toute façon, même quand on réfléchit il y a des bugs. CQFD
Facile, n’est-ce pas, de prouver par l’anecdote?
« » »
NB : ah oui, des tas de bugs dans du libre restent trèèèèèès longtemps sans être corrigés… Tous les bugs « libres » ne sont pas corrigés dans les 15 jours qui suivent. Ceci est également une légende…
« » »
Oui, c’est vrai, l’équipe de Supertuxkart ne corrige pas tous les bugs du software dans les 15 jours.
Cette fois, le sophisme utilisé est une généralisation excessive.
Personne n’a dit que max(temps de correction d’un bug pour tous les logiciels libres jamais publiés) < min(temps de correction d’un bug pour tous les logiciels proprio jamais publiés).
Non, ce qui est dit, c’est que le libre _permet_ une correction plus rapide que la sécurité par l’obscurité.
Mais c’est plus simple de lire de travers…
« » »
Autre suggestion : prenez au hasard le fil de discussion associé à un bug déposé sur un bug-tracker… 9 fois sur 10, le traitement de ce bug est « pifométrique », en gros les « yeux » n’ont pas de compétence particulière pour « raisonner », et bien souvent, très peu regardent réellement le code mais bien plus ce qui est « observable » (ça marche, ça marche pas, je tente ceci, je tente cela)…
« » »
Ben oui. Et si mon pacemakeur manque de me tuer parce que il a détecté dans mon mouvement de bras un début de crise cardiaque, ça reste assez « pifométrique ». Et si le fabricant se fiche de mon problème (mais non mon bon monsieur, c’est impossible, tous les tests répondant aux normes internationales les plus strictes ont été validés avec succès, etc.), ou pire, qu’il n’existe plus, alors je suis bien ennuyé…
Avec un L.L., je peux toujours à la limite prendre sur moi et chercher le bug moi-même, ou confier le travail à un programmeur.
J’ai une mauvaise nouvelle pour vous : à part quelques cas très spécifiques (et souvent triviaux) où des analyses formelles peuvent être utilisées, toutes les techniques de découverte de bogues sont « pifométriques ». L’ordinateur teste simplement toutes les combinaisons d’entrées possibles, envoie du bruit dans le système pour vérifier qu’il n’entre pas dans un état invalide, remplace un capteur par un capteur virtuel envoyant de fausses données qui doit être ignoré par le programme, etc.
Rapporter la recherche de bug « à l’observation » uniquement au L.L. est un procédé fallacieux, qui n’apporte rien au débat où à la question de fond.
« » »
Par définition, le logiciel libre ne possède qu’une seule qualité intrinsèque non-contestable : il est libre.
« » »
Argumentation par évidence. Évidemment que c’est vrai. Peu-importe les autres qualités que l’on peut donner au L.L., je peux les réfuter en écrivant demain un logiciel libre qui ne le fait pas.
Je vous laisse le soin de deviner pourquoi ça n’apporte rien à votre contre-argumentation (indice : on parle de possibilités et de confiance ici)…
Au final, je ne peux que regretter amèrement le constat incroyable auquel certaines personnes arrivent au terme de leur argumentation : qu’il vaut _mieux_ ne pas connaitre ce qui nous maintient littéralement en vie.
jbar
@DesPreuves: Avant de me traiter d’ignorant, sais-tu au moins dans quel secteurs et avec quels organismes/entreprises j’ai pu travailler ?
Tu nous apprends que les sources d’Airbus, d’EADS ou du CNES peuvent être compilé par ceux qui sont autorisés à travailler dessus (et ont signé bien souvent à cette occasion un NDA) , ouah c’est incroyable !! :-p
Quand à ta définition de « non-bug » pour le vol 501, je suis au moins content que tu précises que ce n’est pas l’erreur d’un « jeune » développeur comme moi, mais d’un vieux (c..) qui gagne 2 fois plus comme toi.
Bref dans les différents secteurs et entreprises privées dans lesquels j’ai pu bosser, j’ai souvent eut à intégrer ou communiquer avec des modules/composants logiciels (librairies, fichiers objets, application externe, parfois distante) dont je n’avais pas accès au source, bref à première vue des boîtes noires. Des fois alors même que le dit composant était développé par la même boîte.
Le problème c’est que l’on devait faire ou vendre qqch qui marche avec, et souvent on remarquait des bugs ou des comportement améliorables. Quand il s’agissait d’intégrer le composant, je me devais un minimum d’étudier, vérifier, et faire un peu de reverse pour les boites noires, afin de m’assurer qu’il n’y avait au moins pas de failles que je puisse trouver/exploiter facilement. Parfois l’équipe de l’autre coté (qui avait les mains dans son code) était réactive, on s’entendait bien, et corrigeait/améliorait rapidement leur « module ». Parfois aussi on s’entendait tellement bien qu’ils nous donnait (officiellement ou « sous le manteau ») accès à une partie des sources et l’on pouvait directement discuter code et proposer des patchs. Parfois au contraire, il n’y avait plus personne de vraiment compétent de l’autre coté ou ils refusaient de nous écouter pour des raisons financières/commerciales/politiques (je me suis jamais intéressé aux cotés commerciaux, j’aime juste faire que ça marche, et que ça marche bien).
De même je ne m’intéresse pas vraiment aux cotés politiques, et je n’ai aucunement parlé de logiciel Libre ou d’Open Source. Moi j’ai juste du cambouis sur les mains, j’aime ça. Et j’aime pas que l’on me donne des modules (pièces/moteurs) que je ne peux pas démonter…
Sachant qu’en réalité, si on peut toujours, juste que c’est bien plus difficile, et que l’effort passé sur ces m… ne vaut pas à mon avis celui passé à améliorer les choses pour lesquels ce genre de question (propriété intellectuel, secret industriel, « supériorité » stratégique… ) ne se pose pas.
Penthotal
Laisser une porte d’entrée sans serrure n’est pas le meilleur moyen d’assurer un minimum de sécurité, c’est même une négligence caractérisé qui peut être comprise par tous au vu d’une simple explication.
http://www.bluewin.ch/fr/index.php/…
Un coup d’oeil sur le code ne permet peut-être pas de corriger tout les bugs d’un système certe mais le point avancé dans cet article montre de grave négligences de sécurité.
jbar
Penthotal, tu comprends au moins les articles que tu cites ? :
« Un simple cryptage des données suffirait
… »
Karen n’a nullement dit qu’il ne fallait pas de serrure. Elle pense comme tous les hackers qu’il vaut mieux justement une porte bien visible avec une bonne serrure, que des portes cachés sans serrure (ce qui est potentiellement et à priori le cas de son pacemaker actuellement 🙁 ).
Maintenant je clarifie mon précédent propos pour DesPreuves. Soit une association C qui construit des fusées, pour cela elle a besoin de 2 fonctionnalités logicielles qu’elle demande sous la forme de deux modules avec leur sources à 2 sociétés A et B. Certes C possède le code source de A et B, mais bien souvent C ne se l’approprient pas vraiment, ni travaille pas suffisamment : C se contente de le relire rapidement, de faire éventuellement quelques petites retouches mineurs, puis les fameux tests qui parfois servent à quelque chose. Les deux modules sont intégrés dans le même système, il doivent alors interagir. Mais la société A n’a jamais eut accès au source de B. Et comme les spécs même fait avec le plus grand soin (ce qui n’est de plus pas toujours le cas, même pour le CNES, EADS…), laissent toujours une part floue d’interprétation, il arrive régulièrement que B sorte des données auxquelles A ne s’attendait pas (ou vice-versa), et que C n’aurait bien souvent jamais même pu voir/concevoir …. tout comme les imbéciles qui n’ont même pas pensé à ce que des paramètres pouvaient être différents entre les 2 arianes.
Alors que moi en tant qu’ingénieur développeur sur A ou B, j’aurais eut une chance de voir le problème si seulement j’avais eut une vision plus globale du travail que l’on me demandait (i.e. si j’avais eut un accès égal à l’autre code source).
Gourmet
L’action est légitime tout comme elle est légitime dans le cadre d’un vote public : pourquoi n’a-t-on pas, en tant que citoyen, accès au code de la machine de vote électronique ?
Pourquoi, d’ailleurs, ce code n’est-il pas GPL et pondu par la communauté de manière que toutes les machines aient le même code certifié par l’état (avec des moyens annexes de prouver que le code implanté est bien celui qui est publié ?).
Hein ?
Pourquoi n’ai-je pas accès aux multiples sources de codes qui tournent dans un avion de ligne ?
Mince alors, cet avion me transporte et tout bogue peut mettre en jeu la vie de centaines de personnes ?
Bon, ok, il y a des redondances multiples et il y a les pilotes ce qui n’est pas le cas d’un pacemaker.
La réponse est simple : le fric ! Et ses copains la propriété intellectuelle, les brevets de logiciel, etc.
Pourtant, justement, un code couvert par la propriété intellectuelle devrait pouvoir être publié vu qu’il est protégé ! Ben non !
De nos jours on nous demande de plus en plus de délaisser nos compétences (savoir comment fonctionne l’accès Internet, une télé, une radio, un logiciel, un PC, etc) : laissez-ça aux spécialistes, vous n’avez pas de temps à perdre à ça !
Ben tiens ! Et le jour où ça merde il n’y a plus personne pour réparer : on nous fait payer un max pour remplacer.
Dans le cas des pacemakers la perte de compétence peut s’avérer … mortelle !!!
C’est donc une prise de conscience générale qu’i lfaut avoir, dans tous les secteurs et tous les jours !
db
Ginko
@Kalenx, merci, j’avais commencé à lui répondre et puis j’ai laissé tombé. Les trolls à force, c’est lassant.
@DesPreuves, les domaines hyper-critiques tels ceux que tu cites sont peut-être les seuls où effectivement une dynamique open-source ne serait pas appropriée.
Dans tous ces domaines où un bug peut tuer plusieurs dizaines de gens, bouziller plusieurs milliards d’euros de matos ou polluer gravement et durablement l’environnement d’un seul coup, je peux comprendre que les mecs préfèrent garder le contrôle total sur le système.
Par contre dans *TOUS* les autres domaines, c’est injustifié. Et notamment dans la recherche et le médical.
Pour travailler dans l’industrie en général, j’ai un bon aperçu du niveau des développement en général dans ce domaine et c’est pas du tout reluisant. Je ne confierais pas ma vie à l’un de ces systèmes (heureusement, ils ne sont pas fait pour ça).
Erwann
Il me semble que beaucoup d’idées et d’opinions sont mélangées de telles manières à ce que l’ensemble de la discussion devienne stérile.
1/ Je comprends les questions de Karen, qui sont d’ailleurs tout à fait légitimes. Pour ma part, j’ai posé des questions similaires à mon concessionnaire, lorsque j’ai eu ma première « soft car ».
2/ Je suis tout à fait d’accord sur le fait que le nombre de paires d’yeux n’est pas gage de la capacité à trouver les erreurs dans le code.
3/ Karen pointe un vrai problème de certification des dispositifs médicaux. Même avec une réglementation un peu plus stricte aux USA qu’en Europe, le manque de compétence technique des évaluateurs et des inspecteurs représente un véritable problème.
4/ Je reste quelque peu utopiste, mais la plupart des personnes impliquées dans le développement de systèmes embarqués pour des dispositifs médicaux sont des personnes consciencieuses qui ont parfaitement intégré le fait qu’un bug peut, le cas échéant, tuer.
5/ Les bugs « historiques » mentionnés par les uns et les autres sont d’abord le fait de vraies faiblesses d’ingénierie système avant d’être des problèmes logiciels. Les Bonnes Pratiques d’Ingénierie ne peuvent être mises en oeuvre avec succès sans une solide gestion du risque.
5a/ Therac 25: défaut d’ergonomie du logiciel, défaut de conception du logiciel du fait qu’une protection matérielle avait été supprimée. Absence d’une gestion du risque pertinente.
5b/ Ariane Vol 501: défaut de conception et absence de test (pas besoin de tester puisque cela marche déjà sur Ariane 4), gestion du risque inadéquate. Le domaine d’utilisation du code ayant changé, il était nécessaire de répéter des tests aux limites, selon les nouvelles limites induites par le nouveau domaine de vol.
5c/ Mariner: défaut d’intégrité logicielle. Une gestion du risque des procédures de chargement des programmes et de l’initialisation du système aurait très probablement permis d’éviter un tel défaut.
5d/ Mars Climate Obiter (non cité): défaut de conception, référentiel d’ingénierie incohérent (impérial vs. métrique), tests d’intégration logicielle insuffisant voire absent. Gestion du risque projet insuffisante.
Pour en revenir au problème soulevé par Karen:
a/ Oui, cela doit être angoissant de se faire poser un appareil vital dont on ne comprend pas le fonctionnement. Pourtant, je ne suis pas sûr que la solution se situe dans l’ouverture du code. De plus, le code représente la véritable valeur ajoutée du dispositif. Si le code n’est plus protégé, il est à craindre qu’il n’y ait plus de recherche et développement et par voie de conséquence plus d’innovation dans ce domaine.
b/ Comme pour tout système, en particulier pour les systèmes embarqués, il est nécessaire d’avoir des processus d’ingénierie établis, matures et maîtrisés. La conception de système embarqué ne s’improvise pas, une gestion pertinente du risque est indispensable, les différentes batteries de tests – revue de code, tests unitaires, tests d’intégration, tests de régression, tests de stress, etc – sont des outils cruciaux pour délivrer des dispositifs fiables (cf. GAMP 5 et le Good Practice Guide concernant les tests de systèmes GxP, version 2 en cours de publication).
c/ Karen mentionne aussi les problèmes de cyber-sécurité. Ces problèmes sont systématiquement sous-estimés par tous les intervenants. Le comportement des banques déployant la technologie NFC sans aucun scrupule en est le meilleur exemple. A ma connaissance, il y a un groupe de travail / de réflexion à la FDA sur cette thématique. En revanche, je n’ai aucune idée de ce que seront les résultats de ces réflexions. Je suis aussi tout à fait d’accord sur le principe que l’obscurantisme n’est en aucun cas une protection contre des accès indésirables.
En conclusion
– Quoique l’on vous dise, il est indispensable d’être « parano » lorsque l’on est en charge de l’intégrité des systèmes ou des données. Les plus grands problèmes découlent la plupart du temps d’un amateurisme naïf, voire minimaliste.
– Lorsque l’on demande d’écrire des spécifications, il ne faut pas rechigner, ni crier à l’injustice (pourquoi moi?), mais il faut réaliser ce travail d’élaboration et de revue des spécifications avec exactitude et de la manière la plus complète et la plus cohérente possible. Cela prend du temps, cela demande de l’acharnement, mais c’est à mon humble avis la seule garantie significative pour d’avoir un code fiable et maintenable.
—
PS: je suis tout à fait favorable au logiciel libre et à l’ouverture du code source. Néanmoins, je ne suis pas persuadé que l’ouverture du code soit la seule et unique approche possible pour améliorer la qualité et la fiabilité des dispositifs médicaux.
Il ne faut pas non plus oublier qu’il existe des processus obligatoires de matério-vigilance qui servent à assurer une amélioration continue des dispositifs.
N’hésitez pas à vous abonner aux messages de l’ANSM, c’est une information libre.
—
aucuneimportance
@Erwann : ça fait du bien de lire un commentaire où l’on sent enfin la prise de recul et le souci d’objectivité…
En préparant un cours qui traite en partie des logiciels critiques, on arrive effectivement à la conclusion qu’il y a en fait très peu d’exemple d’erreur logicielle (et surtout pas la tarte à la crème Ariane 501). Ce qui amène effectivement à la conclusion que le problème n’est pas vraiment dans le code (libre ou pas), ni dans le développeur (payé ou pas) mais essentiellement dans le processus.
Ce questionnement n’est pas récent :
http://www.amazon.fr/Logiciel-libre…