Bonjour et merci pour ce commentaire fort développé et détaillé !
Je dois bien l'admettre, la citation relevée est imprécise et "aucune manière de vérifier quoi que ce soit" est une exagération qui mérite la critique. Les contraintes d'une émission de radio (en particulier pour le grand public) ne laissent pas vraiment la place pour entrer dans ces détails et facilitent les raccourcis trop hasardeux.
L'idée que j'ai voulu transmettre, c'est plutôt que le logiciel propriétaire n'offre pas des garanties suffisantes dès lors que l'on ne considère plus le fabricant comme un tiers dans lequel on place toute sa confiance.
Je ne crois pas que la seule possibilité d'étudier le code par rétro-ingénierie soit très significative en termes de garanties de sécurité.
D'une part, parce-que cela demande un travail et un investissement très lourd qui me semble assez peu systématisable. Étudier chacun des logiciels utilisés par un appareil de cette façon demande simplement trop de ressources pour être mis en œuvre à large échelle. De plus, c'est un sujet légalement sensible et il peut être compliqué de publier de telles recherches "preuves à l'appui" puisque l'assembleur correspondant ne peut être publié.
Le second point, à mon avis le plus essentiel, c'est que même en ayant identifié des failles de sécurité, l'utilisateur n'a pas la capacité de les corriger et ne peut qu'en faire part au constructeur, qui décidera de les résoudre ou non.
Et puis au fond, ça reste une question personnelle qui dépend des garanties que chacun recherche et de la confiance portée en chaque acteur.
[^] # Re: Critique de la pédagogie Kocialkowskienne
Posté par PaulK . En réponse à la dépêche Émission « Libre à vous ! » du 6 novembre 2018 — Podcast et références. Évalué à 5. Dernière modification le 08 novembre 2018 à 21:39.
Bonjour et merci pour ce commentaire fort développé et détaillé !
Je dois bien l'admettre, la citation relevée est imprécise et "aucune manière de vérifier quoi que ce soit" est une exagération qui mérite la critique. Les contraintes d'une émission de radio (en particulier pour le grand public) ne laissent pas vraiment la place pour entrer dans ces détails et facilitent les raccourcis trop hasardeux.
L'idée que j'ai voulu transmettre, c'est plutôt que le logiciel propriétaire n'offre pas des garanties suffisantes dès lors que l'on ne considère plus le fabricant comme un tiers dans lequel on place toute sa confiance.
Je ne crois pas que la seule possibilité d'étudier le code par rétro-ingénierie soit très significative en termes de garanties de sécurité.
D'une part, parce-que cela demande un travail et un investissement très lourd qui me semble assez peu systématisable. Étudier chacun des logiciels utilisés par un appareil de cette façon demande simplement trop de ressources pour être mis en œuvre à large échelle. De plus, c'est un sujet légalement sensible et il peut être compliqué de publier de telles recherches "preuves à l'appui" puisque l'assembleur correspondant ne peut être publié.
Le second point, à mon avis le plus essentiel, c'est que même en ayant identifié des failles de sécurité, l'utilisateur n'a pas la capacité de les corriger et ne peut qu'en faire part au constructeur, qui décidera de les résoudre ou non.
Et puis au fond, ça reste une question personnelle qui dépend des garanties que chacun recherche et de la confiance portée en chaque acteur.