Journal Une norme pour les logiciels respectueux de la vie privée ?

Posté par  . Licence CC By‑SA.
Étiquettes :
18
5
avr.
2021

Bon journal,

je lis souvent dans tes pages, mais aussi dans la vraie vie, l'étonnement de gens qui découvrent que tel ou tel logiciel, pourtant bien libre, fuite allègrement des données plus ou moins personnelles. Beaucoup espèrent bien plus que ce que le logiciel libre garantit : en matière de vie privée il ne garantit rien d'autre que d'avoir le droit d'analyser les sources. Ce qui, à part pour des logiciels très simples ou des développeurs expérimentés, n'aide en rien.

Il me semble manquer un moyen d'identifier le niveau de respect de vie privée, de catégoriser et d'encourager les logiciels les plus respectueux.

En cherchant un peu sur le sujet je n'ai rien trouvé. Alors j'ai pensé que mettre en place une norme pourrait répondre à ce manque.

Sans plus paraphraser la description de la norme, je voulais te soumettre cette idée; voici une ébauche encore très grossière https://forge.chapril.org/anubis/MDLPD

Merci pour tes suggestions !

  • # Belle initiative !

    Posté par  . Évalué à 5. Dernière modification le 05 avril 2021 à 16:43.

    Quelques questions / remarques / idées :

    • de quelles données parle-t-on ? Par exemple, est-ce que la recherche d’une mise à jour sur le site de l’éditeur devrait être considérée comme une fuite ? → il vaudrait certainement le coup de définir formellement « donnée de l’utilisateur »
    • Quel processus pour catégoriser un logiciel ? Je ne veux pas avoir à faire confiance à l’éditeur du logiciel pour la catégorie, alors :
    • qui fait l’audit ? Si le processus est collectif, comment la procédure est organisée ? Consensus ? J’imagine que l’évaluation d’un logiciel pourrait être faite par différentes personnes / différents organismes qui pourraient arriver à des conclusions différentes.
    • y a-t-il une procédure systématique proposée pour catégoriser le logiciel ? (étude du code – comment ?, analyse des accès réseaux avec un outil tel que Wireshark, etc)
    • Si plusieurs manières de catégoriser peuvent être employées, la ou les méthodes qui ont été utilisées devraient-elles clairement apparaître, de façon normée ?
    • est-ce que le caractère libre ou source-available est un pré-requis ?
    • est-ce que la production de binaire doit être reproductible ? (sinon difficile de garantir qu’un binaire correspond aux sources, et donc de garantir son bon comportement vis-à-vis de la norme)
    • est-ce qu’il est prévu de documenter un niveau d’utilité des fonctionnalités est prévu (core, essential, optional…)
    • est-ce que la direction de la fuite est considérée ? Par exemple on peut vouloir faire confiance à l’éditeur d’un logiciel mais pas à des « partenaires commerciaux » ou autre tiers.
    • Dans le cas d’un logiciel composé d’un client et d’un serveur, l’évaluation n’est-elle pas différente si le serveur est installé chez soi ou chez un prestataire ? (zéro fuite chez soi, mais « tout » fuite chez le presta).
    • Y a-t-il une notion de « tiers de confiance » à introduire pour rendre la norme plus informative pour ce genre de cas ?

    Au passage, cela fait me fait un peu penser au système d’anti fonctionnalités dans F-Droid, même si c’est très différent : https://f-droid.org/en/docs/Anti-Features/

    • [^] # Re: Belle initiative !

      Posté par  . Évalué à 2.

      Salut,

      Se pose aussi le problème de quand. A chaque release majeure ? mineure ? commit ?

      Matricule 23415

      • [^] # Re: Belle initiative !

        Posté par  . Évalué à 1.

        J'ai bien identifié dans la norme que l'évaluation doit être associée à une version précise :

        logiciel : il est sous-entendu, dans une version donnée, dans un packaging pour une distribution donné.

        Et prévu le cas si certains éditeurs voudraient filouter/confusioner l'utilisateur avec plusieurs versions :

        Si certaines les versions / variantes d'un logiciel ne respectent pas le même niveau de la norme, seul le niveau moins-disant de toutes les versions proposées sur le site peu apparaitre ou alors, les niveaux doivent apparaitre en face de la désignation explicite des versions / variantes concernées.

        Ensuite, si l'évaluation est extérieure au projet, elle aura lieu quand quelqu'un voudra bien la faire !

        Il sera possible de tracer les évolutions du support de la norme au cours du temps/des versions, un peu à la manière de WineHQ : https://appdb.winehq.org/objectManager.php?bIsQueue=false&bIsRejected=false&sClass=version&sTitle=&sReturnTo=&iId=2633

        aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

    • [^] # Re: Belle initiative !

      Posté par  . Évalué à 2.

      de quelles données parle-t-on ? Par exemple, est-ce que la recherche d’une mise à jour sur le site de l’éditeur devrait être considérée comme une fuite ? → il vaudrait certainement le coup de définir formellement « donnée de l’utilisateur »

      Je l'ai défini via « Absence de fuite » : « le logiciel n'effectue pas de connexions autres que celles explicitement requises par l'utilisateur final »; ça reste interprétable et subjectif mais je pense que cette définition ne peut être améliorée que par des exemples (sinon j'accepte vos propositions !).
      Pour répondre à la question, la recherche de mise à jour ne fait pas partie des fonctions pour lesquelles l'utilisateur télécharge/installe le logiciel, donc cela constituerait bien une fuite.

      Quel processus pour catégoriser un logiciel ? Je ne veux pas avoir à faire confiance à l’éditeur du logiciel pour la catégorie, alors :
      qui fait l’audit ? Si le processus est collectif, comment la procédure est organisée ? Consensus ? J’imagine que l’évaluation d’un logiciel pourrait être faite par différentes personnes / différents organismes qui pourraient arriver à des conclusions différentes.

      Je pense qu'on devrait autoriser l'éditeur à s'auto-évaluer pour 2 raisons :
      - c'est lui qui connaît le mieux ce qu'il a implémenté (cf plus loin, l'évaluation agnostique peut demander beaucoup de temps)
      - s'il ment, un audit indépendant pourra toujours découvrir la tricherie (dans le cas où les sources sont disponibles) et faire une très mauvaise presse sur l'éditeur

      A voir si le concept convainc suffisamment d'éditeurs pour avoir rapidement des auto-évaluations (je l'espère ! Si des dev de projets populaires me lisent, leurs intentions m'intéressent particulièrement !), mais je pense que dans tous les cas une base centralisée collaborative sera nécessaire, pour faciliter la catégorisation d'un grand nombre de logiciel, surveiller l'évolution au cours du temps, …

      Je verrai bien une interface à la WineHQ : https://appdb.winehq.org/objectManager.php?sClass=version&iId=2633

      y a-t-il une procédure systématique proposée pour catégoriser le logiciel ? (étude du code – comment ?, analyse des accès réseaux avec un outil tel que Wireshark, etc)

      Clairement, pas pour le moment; c'est compliqué d'avoir des outils systémiques garantissant la couverture de n'importe quel code en n'importe quel langage, pour n'importe quel OS ! Je pense que ça pourrait venir dans un deuxième temps. Pour le moment on ne peut que rassembler quelques conseils/recommandations pour dégrossir.
      Globalement, dans cette première phase on pourra au moins commencer à identifier les logiciels qui ont des fuites avérées avec les outils dispo (Wireshark, PiHole, …). Garantir qu'un gros logiciel n'a pas de fuite sans outil d'analyse me parait chronophage.

      Si plusieurs manières de catégoriser peuvent être employées, la ou les méthodes qui ont été utilisées devraient-elles clairement apparaître, de façon normée ?

      Oui la méthode utilisée devrait bien être renseignée (pour la traçabilité/reproductibilité).

      est-ce que le caractère libre ou source-available est un pré-requis ?

      Non, car :
      - l'analyse par « l'extérieur » (Wireshark, proxy…) suffit pour identifer des fuites (donc suffit pour classer un logiciel en autre chose que 0L)
      - l'éditeur peut toujours s'auto-évaluer; bien sûr dans ce cas l'impossibilité de vérification extérieure devrait apparaître.

      est-ce que la production de binaire doit être reproductible ? (sinon difficile de garantir qu’un binaire correspond aux sources, et donc de garantir son bon comportement vis-à-vis de la norme)

      Effectivement c'est un point important à mentionner.

      est-ce qu’il est prévu de documenter un niveau d’utilité des fonctionnalités est prévu (core, essential, optional…)

      Il me semble que c'est ce que j'ai proposé de définir en Possible (pour les fonctions secondaires) et Systématique (pour les fonctions incontournables) ?

      est-ce que la direction de la fuite est considérée ? Par exemple on peut vouloir faire confiance à l’éditeur d’un logiciel mais pas à des « partenaires commerciaux » ou autre tiers.

      Non, car je pense que la norme doit rester simple; quelque soit le destinataire de la fuite, il faut que l'éditeur l'affiche à l'utilisateur. Ensuite c'est à l'utilisateur de juger s'il est OK ou pas de prendre ce risque, pour cette application (suivant son usage).

      Dans le cas d’un logiciel composé d’un client et d’un serveur, l’évaluation n’est-elle pas différente si le serveur est installé chez soi ou chez un prestataire ? (zéro fuite chez soi, mais « tout » fuite chez le presta).

      Comme indiqué dans la FAQ, je ne m'intéresse (au moins dans un premier temps) qu'aux logiciels en interface avec l'utilisateur final : dans tous les cas le client doit informer qu'il y a une fuite vers un serveur; si le serveur est configurable alors l'utilisateur le sait via la norme ('''IC'''); sur le fait de choisir plutot XXX que YYY comme serveur ce ne peut pas être du périmètre de la norme !

      Y a-t-il une notion de « tiers de confiance » à introduire pour rendre la norme plus informative pour ce genre de cas ?

      Pas sur de bien saisir cette question, mais la norme n'a pas vocation à donner des préférences de serveurs ! Il y a quelques sites comparatifs spécialisés suivant les protocoles/applications.

      Au passage, cela fait me fait un peu penser au système d’anti fonctionnalités dans F-Droid, même si c’est très différent : https://f-droid.org/en/docs/Anti-Features/

      C'est clairement ce qui m'a inspiré !

      Merci ce retour riche; ne pas hésiter à passer sur le salon xmpp:sécurité-vie-privée@chat.jabberfr.org?join pour compléter/discuter un peu plus dans le détail les propositions.

      aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.