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, ...
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.
[^] # Re: Belle initiative !
Posté par anubis . En réponse au journal Une norme pour les logiciels respectueux de la vie privée ?. Évalué à 2.
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.
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
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.
Oui la méthode utilisée devrait bien être renseignée (pour la traçabilité/reproductibilité).
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.
Effectivement c'est un point important à mentionner.
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) ?
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).
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 !
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.
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