La remarque de ce post me parait assez pertinente.
Puisque à la clef est attachée un prénom, un nom et une adresse mail (voir plusieurs adresses mails), par exemple la personne qui a révoquée sa clef et qui ne voudrait plus apparaitre doit pouvoir être en capacité de demander à disparaitre de la liste.
C'est dommage de réduire ces sujets à un simple lien je trouve. Il y aurait plus à dire sur RGPD et infrastructures informatiques (ICANN & DNS, GPG, blockchain, etc.).
Tentative de résumé des échanges sur la liste gnupg-devel :
les serveurs de clé peuvent partager des noms/prénoms/courriels (voire des photos) associés aux clés
cela se fait sans permettre la suppression et rentrerait en conflit avec le droit à l'oubli
cela fait partie du fonctionnement (la collecte n'est pas abusive)
demander des confirmations/informer l'utilisateur à chaque envoi serait contre-productif en termes d'interface utilisateur et de diffusion de la crypto
un tiers peut collecter les données partagées de toute façon, sans accord utilisateur ou sans respect de la loi (spammeur par exemple)
techniquement, il n'est pas actuellement possible de marquer « privée »/non diffusable une clé publique (ou de la supprimer). Il faudrait au moins permettre la suppression de la clé (ou au moins de la partie UID nom/prénom/courriel/photo) par le propriétaire de la clé.
les serveurs SKS ne seraient pas compatibles RGPD, mais d'autres serveurs de clé (celui de Mailvelope est cité) le seraient.
Il faudrait au moins permettre la suppression de la clé (ou au moins de la partie UID nom/prénom/courriel/photo) par le propriétaire de la clé.
RGPD ou pas, c’est une demande qui revient souvent. Le fait que les serveurs de clefs sont en écriture seule est sans doute un des aspects les plus mal connus de ces serveurs, et il n’est pas rare en découvrant cet aspect que la première réaction d’un utilisateur soit quelque chose du genre « mais pourquoi vous n’autorisez pas au moins le propriétaire de la clef à la supprimer, il suffirait de… »
Pour ceux qui seraient intéressés, cette question a fait l’objet d’une longue discussion sur gnupg-users en janvier dernier. Le point de départ de la discussion. Et une conclusion à méditer de Robert J. Hansen : But please, understand why SKS works the way it does before telling people to change it.
Cette conclusion est des plus classiques/banales. La plupart des gens s'exprime sur des sujets sans en maîtriser les tenants et les aboutissants (forcément on n'est pas experts spécialisés en tout) : la plupart des personnes qui s'exprime sur le karma, la modération ou les fonctionnalités de LinuxFr.org (pour prendre un exemple que je connais bien) ne connaisse pas les détails techniques, l'historique ou les raisons des choix, mais ont des avis tranchés en général. On ne doit pas leur dire de ne pas s'exprimer, c'est même souhaitable qu'elles s'expriment pour dire ce qui leur plaît, ne leur plaît pas, leurs suggestions, etc. Tout au plus peut-on espérer un peu de pondération/modération dans les propos pour convertir un « Votre xxxx c'est de la merde » ou « Bordel pourquoi vous n'avez pas encore fait ça ? » en « Votre xxx est améliorable pour telle ou telle raison et par tel ou tel moyen » ou « Pourquoi votre xxx fait-il cela ? ». C'est moins présomptueux, plus empathique, moins inflammatoire, plus respectueux, plus intéressant pour les deux parties (le demandeur réfléchit un peu plus aux raisons, et de fait le répondant aussi, tâchant de se rappeler pourquoi c'est comme ça et si ça ne devrait pas être documenté quelque part), et ça rend le poil soyeux et guérit la faim de la guerre des cancers du monde.
Je peux comprendre que ça devienne irritant quand on reçoit tout le temps les mêmes critiques, qu'on sait que ça serait bien de changer, mais qu'on ne peut rien faire parce qu'il y a trop d'impacts.
Mais bon, la solution est peut-être d'ajouter une entrée dans la FAQ, dans ce cas. Au moins on a pas besoin de re-rédiger la réponse à chaque fois et on peut pointer les gens sur la réponse existante.
Pour moi il est hors de question que le serveur sks puisse supprimer une clef gpg.
Car une sois-disant autorité pour être vite mise en place pour forcer l'effacement des clés sois-disant "indesirables"
C'est à l'openpggp (gnupgp et les autres acteurs) de permettre au propriétaire de la clef d'effacer manuellement ou de prévoir une date de révocation-effacement des données, mais pas de la clef, ainsi le serveur pourrait garder la clé même vide et respecter ce pour quoi il est conçu. Garantir que la clé reste disponible quoi qu'il arrive .
Tout le monde a un cerveau. Mais peu de gens le savent.
# En effet !!!
Posté par TuxMips . Évalué à 2.
La remarque de ce post me parait assez pertinente.
Puisque à la clef est attachée un prénom, un nom et une adresse mail (voir plusieurs adresses mails), par exemple la personne qui a révoquée sa clef et qui ne voudrait plus apparaitre doit pouvoir être en capacité de demander à disparaitre de la liste.
Sauf erreur, ce n'est pas le cas actuellement.
# Journal ou dépêche
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
C'est dommage de réduire ces sujets à un simple lien je trouve. Il y aurait plus à dire sur RGPD et infrastructures informatiques (ICANN & DNS, GPG, blockchain, etc.).
Tentative de résumé des échanges sur la liste gnupg-devel :
[^] # Re: Journal ou dépêche
Posté par gouttegd . Évalué à 4.
RGPD ou pas, c’est une demande qui revient souvent. Le fait que les serveurs de clefs sont en écriture seule est sans doute un des aspects les plus mal connus de ces serveurs, et il n’est pas rare en découvrant cet aspect que la première réaction d’un utilisateur soit quelque chose du genre « mais pourquoi vous n’autorisez pas au moins le propriétaire de la clef à la supprimer, il suffirait de… »
Pour ceux qui seraient intéressés, cette question a fait l’objet d’une longue discussion sur gnupg-users en janvier dernier. Le point de départ de la discussion. Et une conclusion à méditer de Robert J. Hansen : But please, understand why SKS works the way it does before telling people to change it.
[^] # Re: Journal ou dépêche
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Cette conclusion est des plus classiques/banales. La plupart des gens s'exprime sur des sujets sans en maîtriser les tenants et les aboutissants (forcément on n'est pas experts spécialisés en tout) : la plupart des personnes qui s'exprime sur le karma, la modération ou les fonctionnalités de LinuxFr.org (pour prendre un exemple que je connais bien) ne connaisse pas les détails techniques, l'historique ou les raisons des choix, mais ont des avis tranchés en général. On ne doit pas leur dire de ne pas s'exprimer, c'est même souhaitable qu'elles s'expriment pour dire ce qui leur plaît, ne leur plaît pas, leurs suggestions, etc. Tout au plus peut-on espérer un peu de pondération/modération dans les propos pour convertir un « Votre xxxx c'est de la merde » ou « Bordel pourquoi vous n'avez pas encore fait ça ? » en « Votre xxx est améliorable pour telle ou telle raison et par tel ou tel moyen » ou « Pourquoi votre xxx fait-il cela ? ». C'est moins présomptueux, plus empathique, moins inflammatoire, plus respectueux, plus intéressant pour les deux parties (le demandeur réfléchit un peu plus aux raisons, et de fait le répondant aussi, tâchant de se rappeler pourquoi c'est comme ça et si ça ne devrait pas être documenté quelque part), et ça rend le poil soyeux et guérit la faim de la guerre des cancers du monde.
[^] # Re: Journal ou dépêche
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Je peux comprendre que ça devienne irritant quand on reçoit tout le temps les mêmes critiques, qu'on sait que ça serait bien de changer, mais qu'on ne peut rien faire parce qu'il y a trop d'impacts.
Mais bon, la solution est peut-être d'ajouter une entrée dans la FAQ, dans ce cas. Au moins on a pas besoin de re-rédiger la réponse à chaque fois et on peut pointer les gens sur la réponse existante.
# serveur sks
Posté par Ms-Mac . Évalué à 3.
je gère un serveur sks et la question c'est posé.
Pour moi il est hors de question que le serveur sks puisse supprimer une clef gpg.
Car une sois-disant autorité pour être vite mise en place pour forcer l'effacement des clés sois-disant "indesirables"
C'est à l'openpggp (gnupgp et les autres acteurs) de permettre au propriétaire de la clef d'effacer manuellement ou de prévoir une date de révocation-effacement des données, mais pas de la clef, ainsi le serveur pourrait garder la clé même vide et respecter ce pour quoi il est conçu. Garantir que la clé reste disponible quoi qu'il arrive .
Tout le monde a un cerveau. Mais peu de gens le savent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.