Luxleaks : petite mise en garde sémantique aux journalistes et analystes juridiques

Aujourd’hui s’est ouvert le procès des Luxleaks. C’est un procès hors norme, celui d’Antoine Deltour et Raphaël Halet, lanceurs d’alerte et Edouard Perrin, journaliste. Ils sont poursuivis pour «divulgation de secrets d’affaires ou de fabrication, violation du secret professionnel, vol et vol domestique». Je ne me lancerai pas dans une analyse juridique à la simple lecture des faits qui leurs sont reprochés même si j’ai l’intime conviction que ces trois personnes n’ont rien à faire dans le box des accusés.

Cependant, il y a quelque chose qui me fait bondir, c’est la confusion entretenue par les journalistes et les juristes entre un « bug » ou une faille informatique, et une faille humaine, qu’honteuse, une accusation fera adopter à l’opinion comme une « faille informatique ».

Rappel : Quand un administrateur système n’est pas fichu d’appliquer les bonnes permissions sur un dossier, sur des fichiers, il s’agit d’un bug HUMAIN.

La fonction d’un serveur de fichiers, par défaut, est … tenez vous bien… de servir des fichiers.

S’il y a une authentification à la racine, ça ne veut pas dire que tout ce qui se trouve sous la racine est forcément privé ! Les pages d’accueil de Facebook ou de Twitter disposent bien d’une authentification et pourtant, la majorité des contenus se trouvant sous la racine sont publics.

Une « faille » ou un « bug » informatique impliquerait que les accusés aient contourné une mesure d’authentification pour s’octroyer des permissions qu’ils n’avaient pas.

Or, ce que l’on peut lire ce matin, c’est ça :

di

Nous avons donc des docs scannés placés dans un dossier qui se nomme « confidentiel » mais dont les permissions récursives ne sont pas appliquées, ou pire, qui n’est pas lui même configuré avec les bonnes permissions. Tant et si bien qu’une recherche, sans autorisation particulière restituera ces documents scannés. Une simple recherche qui restitue des documents publics parce que de mauvaises permissions sont appliquées, outre le fait que ça me rappelle quelque chose, c’est, encore une fois, un comportement NORMAL, et non « bug » informatique, ou encore moins une « faille ».

Maintenant, que vous soyez journaliste ou juriste, merci d’éviter ceci :

Bref tout ça pour vous dire, qu’avant d’écrire n’importe quoi, au risque de porter inutilement préjudice à des accusés, apprenez à faire la distinction entre une vulnérabilité technique qui aurait été exploitée de manière malicieuse et une erreur humaine d’un administrateur distrait qui n’a pas coché la bonne case et qui permet à n’importe quel utilisateur d’accéder à des documents.

En parlant de « bug » ou de « faille », vous condamnez Antoine Deltour, Raphaël Halet et Edouard Perrin dans l’opinion publique, et c’est le genre de bourde sémantique qui pèse lourd le jour d’un délibéré.

Twitter Facebook Google Plus email

17 thoughts on “Luxleaks : petite mise en garde sémantique aux journalistes et analystes juridiques”

  1. Etre sur une capture d’écran de reflets.info … C’est fait :D

    Bon, Dan Israel a corrigé rapidement l’erreur qu’il avait commise après un petit rappel … Mais c’est toujours une mise en garde utile (et documenté) :)

  2. Tout à fait d’accord sur le fond, sauf sur certains exemples comme « faille dans le système de sécurité », ce dans la mesure où l’admin fait partie du système de sécurité.
    Comme la merde vient d’une de ses erreurs, l’erreur est bien dans le système de sécurité.

    Bref, comme d’habitude, le bug est bien entre la chaise et le clavier.

  3. Etablir une jurisprudence sur la base d’une URL, authentification à la « racine » ou pas à l’ère de l’URL Rewriting et des alias me semble bien compliqué.

    Est-ce le chemin vu dans l’URL ou le chemin réel sur le filesystem qui fait foi ?

  4. Tous les bugs que j’ai corrigé dans ma vie ont été introduits par des humains.
    Du coup vous mettez où la distinction entre les erreurs humaines qui sont des bugs et celles qui n’en sont pas ?

  5. c’est exactement le comportement que je remarque chez la plupart des personnes qui ont été amenées (plus ou moins contre leur gré, ou par la force des choses) à utiliser l’outil informatique :
    – ça marche pas, il y a un bug !
    – hum… non regardez : il y a un problème de configuration à tel endroit. maintenant je configure de la manière que vous souhaitez. voilà, c’est fait.
    – ah super, vous avez corrigé le bug !

    pour répondre à Florent au-dessus : il y a « bug » lorsque l’algorithme implémenté est incohérent vis-à-vis des résultats attendus.
    là où on parle de configuration – et non d’implémentation – on ne devrait pas parler de bug.
    la programmation déclarative elle-même reste de la programmation et non de la configuration.

      1. « L’erreur est humaine » n’explique pas tout.

        Qui est le « on » de vos propos ?
        Le développeur ou bien l’utilisateur ?
        Dans le premier cas il y a bug, dans le second cas il y a problème de configuration.

  6. En même temps, c’est le rôle de l’avocat de la défense d’éclairer les juges sur la chose. Il est payé pour. S’il ne le fait pas, alors il est mauvais et l’accusé a intérêt à en changer

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *