build with gitlab.com CI an atomic operating system and demonstrate how layers can be used to build variants on top of it
Sur le sujet de l'atomique, je vous prépare une dépêche qui en parle sous un autre angle, mais qui évoquera le cas de Bazzite, un OS également basé sur Fedora Kinoite et qui rencontre un petit succès auprès des gamers depuis peu.
Je suis sur que ç'est encore du flan, vu que c'est basé sur Linux, donc Unix, et Unix rends relativement difficilement le renommage de compte (vu que la majorité des logiciels stockent le login et pas un uuid comme Windows), donc relativement difficile la conformité à ce niveau la (c'est pas impossible, c'est juste beaucoup plus manuel que ça devrait si c'était fait correctement)
Et oui, c'est une question de compliance avec le RGPD via l'article 16, celui que les libristes ont tendance à oublier (je prépare un talk sur le sujet pour les JDLLs, talk qui bien sur ne se résume pas à "c'est conforme" et "c'est pas conforme", mais je vais pas tout mettre dans un commentaire).
La personne concernée a le droit d'obtenir du responsable du traitement, dans les meilleurs délais, la rectification des données à caractère personnel la concernant qui sont inexactes. Compte tenu des finalités du traitement, la personne concernée a le droit d'obtenir que les données à caractère personnel incomplètes soient complétées, y compris en fournissant une déclaration complémentaire.
Bon, c'est difficile, mais c'est techniquement possible. À noter que dans le cadre d'un ordinateur personnel, la personne responsable du traitement est la «personne concernée». Dans le cadre d'un ordinateur de bureau, effectivement, c'est plus compliqué.
En ce qui concerne Windows, si l'UUID est une donnée qui est unique pour chaque utilisateur, donc permettant de l'identifier, c'est donc une donnée personnelle. Est-ce possible de modifier l'UUID ? est-ce que les programmes fonctionnent ensuite ?
Bon, c'est difficile, mais c'est techniquement possible
Tout comme c'est techniquement possible de le faire sur git, mais que personne ne le fait.
Dans le cadre d'un ordinateur de bureau, effectivement, c'est plus compliqué.
La spec dit: "integration with directory service for identity and policy management as well as Single-Sign-On with either".
Que je sache, on peut renommer un compte sur FreeIPA (voir l'explication sur le bug tracker de Noggin pour la question sur l'infra de Fedora). Mais en pratique, on sait que ça casse beaucoup de choses chez Fedora.
En ce qui concerne Windows, si l'UUID est une donnée qui est unique pour chaque utilisateur, donc permettant de l'identifier, c'est donc une donnée personnelle. Est-ce possible de modifier l'UUID ? est-ce que les programmes fonctionnent ensuite ?
L'article 17 n'est pas un droit à la modification arbitraire mais le droit à ce que les données correspondent et soient exactes. Si l'UUID n'a de sens que dans l'AD, comment est ce qu'il peut être inexact ?
Ce qui peut être inexact, c'est la correspondance entre l'UUID et le nom/login/email, mais dans ce cas, c'est le nom/login/email que tu changes, pas l'UUID.
Et bien sur, si tu va directement dans l'annuaire pour modifier à l'arrache la chaine de l'UUID, ça va casser des choses. Mais tu n'as pas besoin de changer l'UUID pour obtenir le résultat que demande l'article 17, à savoir que les données te concernant soient exactes dans l'AD et les applications qui l'utilisent (sauf si les applis sont pourris et n'utilisent pas l'UUID, bien sur).
Tout comme c'est techniquement possible de le faire sur git, mais que personne ne le fait.
Rééditer l'historique git ça peut engendrer pas de mal de boulot, encore plus si les commits et tags sont signés, que les artefacts produits sont liés à des commits, que la CI prenne bien ou pas le --force, etc. Sans parler du fait que GitLab/GitHub conservent indirectement des commits qui ne sont plus dans git, ce qui va gêner ici.
Je suis sur que ç'est encore du flan, vu que c'est basé sur Linux, donc Unix, et Unix rends relativement difficilement le renommage de compte (vu que la majorité des logiciels stockent le login et pas un uuid comme Windows), donc relativement difficile la conformité à ce niveau la (c'est pas impossible, c'est juste beaucoup plus manuel que ça devrait si c'était fait correctement)
Ou alors ils utilisent un module PAM qui le permet
Pour le moment, il n'y a pas de code, qu'un site web, donc ça n'utilise pas de module pam spécifique.
Si c'est juste des changements de gecos, ça passe. Si c'est des changements de login parce que le login, c'est le nom de famille, c'est clairement autre chose.
Par exemple, quid du repertoire home ?
Le chemin est codé en dur dans divers fichiers comme la config gtk:
Alors oui, on peut sans doute imaginer des tas de choses avec un fichier nss qui fasse de la magie (genre qui renvoie le même uid pour 2 comptes, mais quid de l'inverse ?), avec une config pam qui fait de l'automontage de /home/ancienlogin de base sur le nom de /home/nouveaulogin.
Sauf que pour le moment, ce code reste purement théorique, et ç'est pas par défaut dans aucune des distros majeurs que je sache. Les outils font sans doute des choses incorrects par défaut, comme par exemple usermod qui renomme le repertoire ce qui casse l'existant.
Et même les nouveaux trucs comme systemd-userdb ne supportent pas ça de base. Par exemple, j'ai trouvé 2 bugs ou des gens demandent à pouvoir renommer et/ou avoir des aliases:
Si c'est juste des changements de gecos, ça passe. Si c'est des changements de login parce que le login, c'est le nom de famille, c'est clairement autre chose.
Il me semble qu'avec ldap, tu peux distinguer le login (ce que tu met dans le champs login) de l'identifiant NSS. Vu que je l'ai déjà utilisé avec mon mail pour me connecter mais pas mon mail comme home.
Historiquement y a NIS / yellow pages pour avoir un même login/group partout en ayant le même UID/GID. Maintenant LDAP et Active Directory. Ça ne marche parfaitement que si tout est géré ainsi évidemment.
Après il y a aura des collisions uid/gid ou login/group de façon inévitable : exemple tar peut se baser sur l'un ou l'autre, mais du coup au de-tar faut être sûr des correspondances.
Mais mon point est que changer le login (via pam, vim ou n'importe quoi d'autres) ne suffit pas pour assurer une transition d'un login à un autre sans avoir aussi à faire des modifications manuelles ailleurs.
Pour l'exemple de ma machine, si je change de misc vers notmisc, je perds mes bookmarks dans les applis GTK et gnome boxes risque d'être cassé, y compris les bookmarks par défaut sauf si je fait un lien. De même, je ne pourrais plus lancer le VPN du boulot sans le réimporter dans NetworkManager (vu que les permissions sont sur le login par l'uid).
ben je suis curieux de voir quel modif de configuration va régler la question d'un login codé en dur dans un fichier de configuration, cf l'exemple de NetworkManager.
NSS ne supporte pas vraiment le concept d'alias utilisateur que je sache. On peut magouiller pour que id misc et id notmisc renvoie le même UID après renommage de misc vers notmisc (suffit juste d'avoir 2 , mais on ne peux pas faire en sorte que id 1000 renvoie l'un et l'autre.
Donc suivant la façon dont NetworkManager va vérifier les permissions sur le VPN, ça peut casser ou pas.
Si NM prends le login (notmisc), utilise nss pour avoir l'uid (1000) et compare avec l'uid du login dans sa config (misc, donc 1000), ça va passer avec assez de config nss.
Si NM prends l'UID de l'utilisateur (1000), le transforme en login (notmisc) et compare les chaînes, ça va coincer (car misc != notmisc).
Et des logiciels comme ça, je suis sur qu'il y en a des tas. Pas forcément beaucoup, mais la configuration ne peut pas éviter les rectifications manuels quand le logiciel ne suit pas des bonnes pratiques (bonnes pratiques totalement non écrites).
Ensuite, si on rajoute "en patchant assez de logiciels" à "avec assez de config", oui, on peut sans doute obtenir quelque chose.
Mais personne ne semble travailler dessus (et par travailler dessus, je veux dire plus que dire de façon indirect via un markdown qui dit "on va supporter le RGPD", car la question n'est pas de "supporter" le RGPD que de rendre les obligations faciles à appliquer).
Il n'y aucun bonne pratique sur ça. Par exemple, je ne croit pas qu'on dise aux logiciels upstream de n'utiliser que des groupes unix pour les accès et jamais de login (ou alors le message ne passe pas). Les docs sur le changement de login ne parlent souvent que de usermod, ignorant les emmerdes que j'ai pointé (et ne couvre pas les sujets qu'on suppose possible).
Encore une fois j’ai plus accès à la machine en question mais j’ai déjà eu mon mail en login et tout à fait autre chose comme nom d’utilisateur (que ce soit mon $HOME ou mon whoami. C’était adossé à un LDAP et je suis parfaitement sûr qu’il n’y avait pas de développement spécifique (mais peut être une configuration sophistiquée par contre). Ce n’est pas une question de modifier un tas de logiciels, mais simplement de faire en sorte que ton processus de log puisse faire la distinction.
On peut imaginer que les utilisateurs aient tous un identifiant, un login et un display name et une API pour récupérer les uns à partir des autres (pour la sécurité il parait pertinent que même le display name soit unique), mais ça va encore créer des guerres interminables.
Le département info a tenté d'avoir un login qui soit 4 lettres au pif avec des aliases mail et de login. Pour une raison que je ne connais pas, l'expérience n'a pas été suivi d'un déploiement pour le reste de la boite alors que ça semble être dans la lignée de ta proposition.
Alors, je suis véritablement et sincèrement curieux.
Par quelle analyse tu décides que le login (géré par la boite, à sa totale discrétion) est une donnée dont l'utilisateur peut décider qu'elle est ou pas "correcte", et donc qu'il peut faire jouer dessus son droit de rectification ?
Parce que, autant dans ma boite, j'ai fait mon possible pour que nos systèmes permettent de changer l'identifiant d'une personne à sa guise, autant on ne m'a jamais fait remonter ça comme une exigence réglementaire. Et je serai bien intéressé de voir une décision de justice ou d'une autorité de contrôle qui confirme cette interprétation.
Le nom, le prénom, le genre, la date de naissance, toutes les données pour lesquelles la personne peut prouver qu'elles sont fausses, pas de débat. Mais le login ? Je vois pas sur quelle base on pourrait avancer qu'il est inexact, puisqu'il est toujours arbitraire.
Genre, en cas d'homonyme, comment tu satisferais cette exigence pour les 2 personnes à la fois ? Tu peux coller un incrément derrière le login de la seconde personne, bien sûr, mais ça ne fait que prouver que ça ne colle qu'à une règle arbitraire de l'employeur, qui peut parfaitement décider qu'il est non-modifiable, et le RGPD n'aura rien à y redire. Comme l'UID, quoi.
Et dans l'hypothèse où tu aurais raison, Linux serait très loin d'être le seul concerné par cette application difficile de l'exigence que tu sembles attribuer à l'article 16. (G|Hot|Yahoo)Mail seraient bien en peine de modifier ton adresse après un changement de nom d'usage, par exemple.
Mais j'en apprends tous les jours et, comme je le disais, je suis curieux de connaître ton raisonnement. D'autant que j'imagine que si tu prépares une présentation sur le sujet, c'est que tu en sais sans doute plus que moi.
Par quelle analyse tu décides que le login (géré par la boite, à sa totale discrétion) est une donnée dont l'utilisateur peut décider qu'elle est ou pas "correcte", et donc qu'il peut faire jouer dessus son droit de rectification ?
Alors ça dépend bien sur du type de boite. Si ta boite te file un login totalement aléatoire (genre 8 chiffres au pif) pour je ne sais pas quel raison, oui, ça va être dur d'argumenter.
Si ta boite est une startup qui te laisse choisir ton login et que tu choisis "batman" et que tu t'appelles Jean Dupont, c'est difficilement applicable aussi.
Par contre, si ton login est jean.dupont et que c'est pareil dans toute la boite (cad qu'il y a prénom.nom quand applicable, ou des variations du même genre par défaut), c'est déjà plus dur de dire que ça n'a rien de personnel.
Et il y une jurisprudence sur le sujet, l'affaire 2023-8336 devant l'autorité de protection des données (DPA) de la Suède (l'IMY), ou une banque a reçu une amende pour avoir refusé de changer le login d'un client suite à une demande sous l'article 16. Certes, le login était aussi l'email, mais ça ne change pas grand chose. Et comme le but du RGPD est d'unifier les lois au niveau européen, les DPA sont censées être d'accord les unes avec les autres (article 63 du RGPD).
Et je pense que le point qui me semble important, c'est de savoir si on peut déduire une info spécifique (en l’occurrence le nom et/ou le prénom) à partir du login, et ce qui arriverait si on décide que ça n'est pas couvert par l'article 16.
Pour illustrer le raisonnement, je vais me référer à un arrêt de la CJUE (Cour de Justice de l'Union Européenne) qui a tenu exactement ce raisonnement dans le cas C-184/20 sur la publication du nom du ou de la partenaire des haut fonctionnaires en Lituanie (pour des questions de transparence, etc, etc).
En 2022, la cour a estimé que comme on peut déduire l'orientation sexuelle de quelqu'un avec cette info (vu qu'on peut déduire le genre avec le prénom, en général), c'est une info dite sensible pour le RGPD au sens de l'article 9. Et donc, pour avoir une protection efficace des données notamment sensibles (§126 de l'arrêt), alors il faut considérer que ça couvre les données directs comme "Jean Dupont est gay", mais aussi des données qui permettent de déduire la même information comme "Le mari de Jean Dupont est Robert Dupont".
Et il n'y a pas besoin de rentrer dans les détails de savoir si Jean et/ou Robert sont homosexuels, bisexuels ou hétéros qui veulent des réductions d’impôts, car au nom du principe d'égalité ça marcherais aussi si Jean était marié à Roberta. Même si il y a une présomption d'hétérosexualité dans la société, ça reste une orientation sexuelle, et la loi ne fait pas la distinction à ce niveau.
Si on regarde bien le §126 qui détaille l'avis des juges, la cour explique que si elle avait décidé le contraire (e.g. le nom d'un/une partenaire n'est pas une info couverte par l'article 9), alors ça aurait ouvert un trou dans la protection du RGPD, et donc, ça n'était pas la bonne option.
Donc pour l'article 16, le raisonnement serait le même. Si le RGPD te donne le droit de rectifier ton nom/prénom, mais qu'on estime que ce droit ne s'applique plus quand on combine les 2 (jean.dupont), qu'on rajoute un chiffre ou n'importe quoi de réversible pour faire un login (j.dupont), alors ça permettrait au contrôleur d'éviter trivialement les demandes, donc ça réduirait la portée des droits du RGPD.
Si rajouter 1234 dans le fichier (par exemple, une base de donnée) permet d'éviter les obligations de l'article 16, on pourrait dire que ça permet aussi d'éviter l'article 17 (droit à l'effacement) et donc sans doute tout le RGPD.
Donc il y a de fortes chances que la CJUE ou les DPAs décident que ça n'est pas le bon raisonnement, et donc que les nom/prénom combinés pour faire un login doivent être couvert par le droit accordé au titre de l'article 16.
Il y aurait sans doute d'autres arguments, comme un angle de minimisation des données (l'arrêt Mousse c. SNCF Connect et CNIL vis à vis du fait que garder le login et corriger le nom d'affichage va révéler soit une situation maritale, soit une transition de genre, mais ça me semble plus faible comme argument.
Par contre, dans le cas des transitions de genre, je pense que l'employeur a également un certain nombre d’obligation de protection contre les discriminations (en droit français depuis 2012), et qu'on pourrait sans doute argumenter que ça recouvre une obligation de ne pas afficher leur transition ad vitam eternam contre le gré des gens, surtout quand la demande émane de la personne elle même.
autant on ne m'a jamais fait remonter ça comme une exigence réglementaire
Je suis pas spécialement étonné, personne n'en parle, et je pense que les boites le font déjà sans avoir besoin de sortir le bazooka.
Ma collègue juriste en charge de la vie privée pour l'Europe m'a dit que toute la profession a été prise par surprise par l'arrêt C-184/20 (en Lituanie sur l'orientation sexuelle), alors que personnellement, ça m'a semblé assez évident depuis le début. De même, l'issue de C-394/23 (Mousse c. SNCF) m'a paru prévisible vis à vis de la libre circulation des personnes dans l'Union. À partir du moment ou tu peux vivre en France avec une carte d'identité allemande qui peut avoir plus que M/F, les boites doivent s'adapter même si l'ordre juridique français ne reconnaît que 2 options (une position validé par la CEDH (cour européenne des droits de l'homme) dans l'affaire Y c. France en 2023).
Genre, en cas d'homonyme, comment tu satisferais cette exigence pour les 2 personnes à la fois ?
De la même façon que tu le fait sans l'article 16. Je sais pas dans quel boite tu bosses, mais parmi mes 20000 collègues, il y a 3 qui s'appellent Matthew Miller, depuis 10 ans. Pour les logins, on prends la première lettre du prénom + le nom, et on limite à 8 lettre, donc il y en a un avec première lettre du prénom + nom, l'autre avec les 2 premières lettres, etc. Parfois, ils recoivent des courriers pour les autres, donc je dit pas que ça n'apporte pas son lot d'emmerde, mais aucun n'a changé de nom, et aucun n'habite en Europe. Donc le RGPD n'a rien changé.
Et pire encore le système de création de compte est tombé en panne il y a 12 ans car il n'était plus capable de produire des variations de nom/prénom après avoir embauché trop de gens avec les mêmes nom/prénom. J'ai plus les détails exactes, mais c'était des noms et prénoms chinois assez court, genre Lee Sun. Ça a du faire lsun, lesun, leesun et pour le 4eme, le système a tourné en boucle toute la journée.
Donc il n'y a rien de spécial à ce genre de conflit de nom et prénom, c'est déjà un souci qui existe à l'embauche et partir d'une certaine taille de boite.
Et tu peux pas dire "on embauche pas tel personne car on a déjà un Jean Dupont dans la boite", car ça serait refuser d'embaucher quelqu'un sur la base de son patronyme, ergo une discrimination interdite (Article 225-1 du code pénal) et sans doute non justifiable (c'est difficile de dire que c'est techniquement impossible quand le reste du monde y arrive).
Et dans l'hypothèse où tu aurais raison, Linux serait très loin d'être le seul concerné par cette application difficile de l'exigence que tu sembles attribuer à l'article 16. (G|Hot|Yahoo)Mail seraient bien en peine de modifier ton adresse après un changement de nom d'usage, par exemple.
Je n'ai pas de compte mail perso chez un des providers cités, mais que je sache, ça ne pose pas de souci particulier sur Google Workspace au taf.
Sur l'intranet de mon employeur, on a un document gigantesque sur comment changer ton login à différent endroits avec tout les soucis qu'on trouve, les tickets pour que ça soit corriger, les contournements, etc. Il n'y a aucune instruction sur le changement de login pour Google Workspace, ce qui signifie que ça marche directement (comprendre une fois qu'on a changé l'annuaire, ça se fait tout seul).
Certes, le login était aussi l'email, mais ça ne change pas grand chose.
Ben, si, ça change beaucoup de choses, en fait. Dans le cas que tu cites, la personne voulait faire rectifier son email, qui n'était pas le bon et qui aurait empêché la personne concernée de récupérer son compte en cas de difficulté, par exemple. La décision de l'autorité de contrôle portait en l'occurrence sur le fait que l'email devait pouvoir être modifié. Le fait que dans ce cas email=identifiant était le problème du responsable de traitement, et qu'il se débrouille pour corriger le tir. Mais rien ne dit que la décision aurait été la même pour un système découplant email et identifiant.
Ton exemple sur la déduction de donnée est très valable, et la décision ne me surprend absolument pas non plus compte-tenu des risques encourus par les personnes concernées, mais je ne vois en revanche pas le lien avec un login sur un système interne, qui permet certes au rares personnes qui y ont accès de déduire que la personne concernée a porté un autre nom, mais ne met pas vraiment ses droits et libertés en péril (puisque c'est l'enjeu principal du RGPD dans la protection des personnes).
Bref, je pense que tu extrapoles un peu trop vite à partir de choses qui ont beaucoup de sens sur un cas où ça en a beaucoup moins. Pour te donner un exemple qui illustre que l'application du RGPD n'est pas "tout noir ou tout blanc" et rejoindre l'exemple des obligations de transparence et du risque sur les données sensibles, on a en France eu une décision du conseil d'état (N°431875) qui a déterminé que la publication du statut de travailleur handicapé, sans précision sur la nature du handicap, ne valait pas publication d'une donnée de santé (en l'occurrence, il en a en revanche imposé la limitation dans le temps à ce qui était nécessaire). Cela prouve simplement qu'il y a des limites à l'exercice des droits, ces limites étant liées aux risques pour les personnes. Et dans le cas d'un login sur un système interne, je réitère, j'ai de forts gros doutes quant à la validité de tes conclusions.
Ben, si, ça change beaucoup de choses, en fait. Dans le cas que tu cites, la personne voulait faire rectifier son email, qui n'était pas le bon et qui aurait empêché la personne concernée de récupérer son compte en cas de difficulté, par exemple
L'article 16 (et d'autres) ne demande pas de démontrer une conséquence négative pour avoir le droit de faire rectifier des données. Donc la distinction entre l'email ou tu vois des raisons et le login ou tu en vois moins n'a pas d'impact.
Ce que l'affaire que j'ai cité pointe, c'est que la DPA considére que la réponse de Klarna est une violation de l'article 12, celui qui dit que le contrôleur doit faciliter l'application de l'article 16 (entre autres). Dire que c'est pas possible pour des raisons techniques n'est pas suffisant vis à vis des obligations, et donc n'est pas une réponse valable.
Et en pratique ça n'était sans doute pas motivé par des questions de récupération du compte. Comme son nom l'indique, Klarna Bank est une banque, donc elle a des obligations de vérification qui font qu'il faut sans doute plus qu'un simple email pour ouvrir un compte (lutte contre le financement du terrorisme, contre le blanchiment, KYC, etc), donc même si l'email est incorrect, la banque a le moyen de retrouver son client. Ça n'est pas non plus une question d'affichage, le texte en suédois dit à un moment que le service client a réussi à éditer les factures existantes.
on a en France eu une décision du conseil d'état (N°431875) qui a déterminé que la publication du statut de travailleur handicapé, sans précision sur la nature du handicap, ne valait pas publication d'une donnée de santé
Sauf que ça ne compte pas vraiment pour le RGPD.
Pour commencer, le §10 auquel tu fais référence n'est pas la décision en tant que tel, la décision est après le §13, et aucun des 5 articles ne parle de ça. Donc le caractère normatif est assez réduit.
Le §10, c'est juste le raisonnement, et il est quand même un peu pourri, parce que le conseil d'état speedrun sa réponse (cf §11) en s'appuyant sur l'équivalent de l'article 4 du RGPD pour contredire le tribunal d'en dessous. Le §8, c'est comme Indiana Jones dans l'arche perdu, le film se termine de la même façon sans lui. En l'occurrence, ça ne sert à rien de discuter le fait que ça tombe sous l'équivalent de article 9 ou pas si au final, la réponse serait la même qu'on dise oui ou qu'on dise non (car même si le CE avait estimé que ça tombe sous l'article 9, le ministère aurait quand même du retirer l'info vu que le raisonnement se base sur le fait qu'il n'y a plus besoin de l'afficher).
Ensuite, c'est une décision du Conseil d'État, une juridiction avec un périmètre restreint, l'administration de l'état français. Ses décisions n'ont qu'un impact juridiquement limité au contraire de la CJUE ou d'une DPA.
Enfin, c'est une décision de 2021, antérieur à mon exemple de la CJUE qui date de 2022.
C'est aussi en contradiction avec le raisonnement de la CJUE dans l'affaire C‑21/23 en 2024 qui touche directement à la question des données de santé et de l'article 9. La Cour, dans son paragraphe §81, applique le même raisonnement que dans l'affaire C‑184/20 (celle de 2022) et rappelle qu'il faut avoir une interprétation large de ce qui correspond à des données de santé.
Mais c'est aussi une décision qui juge une affaire qui est plus vielle que la mise en pratique du RGPD (vu que le premier courrier date de 2015, le RGPD en tant que tel est applicable à partir de mai 2018).
Donc pour tout ça, il y a des chances que la CNIL soit plus lié par des raisonnements plus récents, plus nombreux par un tribunal plus spécialisé dans le domaine qui concerne la CNIL, que par un raisonnement plus vieux, moins détaillé, d'un tribunal non spécialisé et plus limité (et avec sans doute moins de juges, moins de contradictoire et une visée normative moindre).
Ensuite, je parle en tant que personne qui bosse dans le privé, donc peut être que les injonctions du CE t'impacte plus que moi, je sais pas ou tu bosses ou ce que tu gères.
mais je ne vois en revanche pas le lien avec un login sur un système interne, qui permet certes au rares personnes qui y ont accès de déduire que la personne concernée a porté un autre nom, mais ne met pas vraiment ses droits et libertés en péril (puisque c'est l'enjeu principal du RGPD dans la protection des personnes).
Comme dit plus haut, l'appréciation du contrôleur sur les droits et libertés et leur périls n'as pas vraiment d'importance sur le droit ou pas d'utiliser l'article 16. Ça n'est pas conditionnel aux nombre de personnes qui ont l'info, ça n'est pas conditionnel aux risques dans la situation précise de quelqu'un qui veut jouir de ses droits.
Les seuls conditions sont énoncés à l'article 12 et 11, et c'est quand même assez limités.
Par quelle analyse tu décides que le login (géré par la boite, à sa totale discrétion) est une donnée dont l'utilisateur peut décider qu'elle est ou pas "correcte", et donc qu'il peut faire jouer dessus son droit de rectification ?
Login ou adresse de courriel basées sur le nom/prénom : changement de nom suite à mariage par exemple, combinaison problématique (genre Megan Finger si le login est nom + 2 premières lettres du prénom), changement de prénom sur une transition, éventuellement le cas de la collision (gestion du 69e Kevin Durand de l'entreprise), "impossibilité" technique (désolé Émilie ou Jördis mais notre système prend les deux premières lettres du prénom mais en ASCII 7 bits, pour un groupe international ou conséquent, l'Unicode doit arriver assez vite…), modification du nom de famille sur une nationalisation, … j'oublie probablement des cas possibles.
Je suis sûr qu'ils pourraient faire mieux que EU-OS comme nom pour leur truc.
Franchement ça n'envoie pas du rêve et ça va encore être une catastrophe en référencement sur les moteurs de recherche.
# Et c'est de l'atomique
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
En tout cas, c'est bien parti pour être basé sur Fedora Kinoite :
Sur le sujet de l'atomique, je vous prépare une dépêche qui en parle sous un autre angle, mais qui évoquera le cas de Bazzite, un OS également basé sur Fedora Kinoite et qui rencontre un petit succès auprès des gamers depuis peu.
[^] # Re: Et c'est de l'atomique
Posté par Mimoza . Évalué à 3 (+1/-0).
Pourquoi partir sur un base contrôlé pas une boite américain si l’objectif est justement de s’émanciper de leur diktat ?
[^] # Re: Et c'est de l'atomique
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Pour autant que je sache, Fedora n'est pas contrôlé par Red Hat ?
# Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 5 (+4/-2).
Alors dans les specs, il y a marqué compatibilité avec le RGPD:
https://gitlab.com/eu-os/eu-os.gitlab.io/-/blob/main/spec.md?ref_type=heads#non-functional-requirements
Je suis sur que ç'est encore du flan, vu que c'est basé sur Linux, donc Unix, et Unix rends relativement difficilement le renommage de compte (vu que la majorité des logiciels stockent le login et pas un uuid comme Windows), donc relativement difficile la conformité à ce niveau la (c'est pas impossible, c'est juste beaucoup plus manuel que ça devrait si c'était fait correctement)
Et oui, c'est une question de compliance avec le RGPD via l'article 16, celui que les libristes ont tendance à oublier (je prépare un talk sur le sujet pour les JDLLs, talk qui bien sur ne se résume pas à "c'est conforme" et "c'est pas conforme", mais je vais pas tout mettre dans un commentaire).
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par lejocelyn (site web personnel) . Évalué à 5 (+3/-0).
Bon, c'est difficile, mais c'est techniquement possible. À noter que dans le cadre d'un ordinateur personnel, la personne responsable du traitement est la «personne concernée». Dans le cadre d'un ordinateur de bureau, effectivement, c'est plus compliqué.
En ce qui concerne Windows, si l'UUID est une donnée qui est unique pour chaque utilisateur, donc permettant de l'identifier, c'est donc une donnée personnelle. Est-ce possible de modifier l'UUID ? est-ce que les programmes fonctionnent ensuite ?
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Tout comme c'est techniquement possible de le faire sur git, mais que personne ne le fait.
La spec dit: "integration with directory service for identity and policy management as well as Single-Sign-On with either".
Que je sache, on peut renommer un compte sur FreeIPA (voir l'explication sur le bug tracker de Noggin pour la question sur l'infra de Fedora). Mais en pratique, on sait que ça casse beaucoup de choses chez Fedora.
L'article 17 n'est pas un droit à la modification arbitraire mais le droit à ce que les données correspondent et soient exactes. Si l'UUID n'a de sens que dans l'AD, comment est ce qu'il peut être inexact ?
Ce qui peut être inexact, c'est la correspondance entre l'UUID et le nom/login/email, mais dans ce cas, c'est le nom/login/email que tu changes, pas l'UUID.
Et bien sur, si tu va directement dans l'annuaire pour modifier à l'arrache la chaine de l'UUID, ça va casser des choses. Mais tu n'as pas besoin de changer l'UUID pour obtenir le résultat que demande l'article 17, à savoir que les données te concernant soient exactes dans l'AD et les applications qui l'utilisent (sauf si les applis sont pourris et n'utilisent pas l'UUID, bien sur).
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Rééditer l'historique git ça peut engendrer pas de mal de boulot, encore plus si les commits et tags sont signés, que les artefacts produits sont liés à des commits, que la CI prenne bien ou pas le --force, etc. Sans parler du fait que GitLab/GitHub conservent indirectement des commits qui ne sont plus dans git, ce qui va gêner ici.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Ou alors ils utilisent un module PAM qui le permet
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 2 (+0/-1).
Pour le moment, il n'y a pas de code, qu'un site web, donc ça n'utilise pas de module pam spécifique.
Si c'est juste des changements de gecos, ça passe. Si c'est des changements de login parce que le login, c'est le nom de famille, c'est clairement autre chose.
Par exemple, quid du repertoire home ?
Le chemin est codé en dur dans divers fichiers comme la config gtk:
Ou la config de gnome boxes:
Quand c'est pas le home directory, c'est directement le login qui est dans une configuration comme pour NetworkManager:
Et c'est ce que je trouve juste en 30 secondes.
Alors oui, on peut sans doute imaginer des tas de choses avec un fichier nss qui fasse de la magie (genre qui renvoie le même uid pour 2 comptes, mais quid de l'inverse ?), avec une config pam qui fait de l'automontage de /home/ancienlogin de base sur le nom de /home/nouveaulogin.
Sauf que pour le moment, ce code reste purement théorique, et ç'est pas par défaut dans aucune des distros majeurs que je sache. Les outils font sans doute des choses incorrects par défaut, comme par exemple usermod qui renomme le repertoire ce qui casse l'existant.
Et même les nouveaux trucs comme systemd-userdb ne supportent pas ça de base. Par exemple, j'ai trouvé 2 bugs ou des gens demandent à pouvoir renommer et/ou avoir des aliases:
https://github.com/systemd/systemd/issues/24032
https://github.com/systemd/systemd/issues/30136
Et y a 0 tractions depuis 2 ou 3 ans.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Il me semble qu'avec ldap, tu peux distinguer le login (ce que tu met dans le champs login) de l'identifiant NSS. Vu que je l'ai déjà utilisé avec mon mail pour me connecter mais pas mon mail comme home.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Historiquement y a NIS / yellow pages pour avoir un même login/group partout en ayant le même UID/GID. Maintenant LDAP et Active Directory. Ça ne marche parfaitement que si tout est géré ainsi évidemment.
Après il y a aura des collisions uid/gid ou login/group de façon inévitable : exemple tar peut se baser sur l'un ou l'autre, mais du coup au de-tar faut être sûr des correspondances.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
Mais mon point est que changer le login (via pam, vim ou n'importe quoi d'autres) ne suffit pas pour assurer une transition d'un login à un autre sans avoir aussi à faire des modifications manuelles ailleurs.
Pour l'exemple de ma machine, si je change de misc vers notmisc, je perds mes bookmarks dans les applis GTK et gnome boxes risque d'être cassé, y compris les bookmarks par défaut sauf si je fait un lien. De même, je ne pourrais plus lancer le VPN du boulot sans le réimporter dans NetworkManager (vu que les permissions sont sur le login par l'uid).
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Et je crois que ce qu’on te dit c’est qu’il est possible de le faire via une installation prévue pour (exactement l’objectif du projet).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
ben je suis curieux de voir quel modif de configuration va régler la question d'un login codé en dur dans un fichier de configuration, cf l'exemple de NetworkManager.
NSS ne supporte pas vraiment le concept d'alias utilisateur que je sache. On peut magouiller pour que
id miscetid notmiscrenvoie le même UID après renommage de misc vers notmisc (suffit juste d'avoir 2 , mais on ne peux pas faire en sorte queid 1000renvoie l'un et l'autre.Donc suivant la façon dont NetworkManager va vérifier les permissions sur le VPN, ça peut casser ou pas.
Si NM prends le login (notmisc), utilise nss pour avoir l'uid (1000) et compare avec l'uid du login dans sa config (misc, donc 1000), ça va passer avec assez de config nss.
Si NM prends l'UID de l'utilisateur (1000), le transforme en login (notmisc) et compare les chaînes, ça va coincer (car misc != notmisc).
Et des logiciels comme ça, je suis sur qu'il y en a des tas. Pas forcément beaucoup, mais la configuration ne peut pas éviter les rectifications manuels quand le logiciel ne suit pas des bonnes pratiques (bonnes pratiques totalement non écrites).
Ensuite, si on rajoute "en patchant assez de logiciels" à "avec assez de config", oui, on peut sans doute obtenir quelque chose.
Mais personne ne semble travailler dessus (et par travailler dessus, je veux dire plus que dire de façon indirect via un markdown qui dit "on va supporter le RGPD", car la question n'est pas de "supporter" le RGPD que de rendre les obligations faciles à appliquer).
Il n'y aucun bonne pratique sur ça. Par exemple, je ne croit pas qu'on dise aux logiciels upstream de n'utiliser que des groupes unix pour les accès et jamais de login (ou alors le message ne passe pas). Les docs sur le changement de login ne parlent souvent que de usermod, ignorant les emmerdes que j'ai pointé (et ne couvre pas les sujets qu'on suppose possible).
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Encore une fois j’ai plus accès à la machine en question mais j’ai déjà eu mon mail en login et tout à fait autre chose comme nom d’utilisateur (que ce soit mon $HOME ou mon whoami. C’était adossé à un LDAP et je suis parfaitement sûr qu’il n’y avait pas de développement spécifique (mais peut être une configuration sophistiquée par contre). Ce n’est pas une question de modifier un tas de logiciels, mais simplement de faire en sorte que ton processus de log puisse faire la distinction.
On peut imaginer que les utilisateurs aient tous un identifiant, un login et un display name et une API pour récupérer les uns à partir des autres (pour la sécurité il parait pertinent que même le display name soit unique), mais ça va encore créer des guerres interminables.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
Le département info a tenté d'avoir un login qui soit 4 lettres au pif avec des aliases mail et de login. Pour une raison que je ne connais pas, l'expérience n'a pas été suivi d'un déploiement pour le reste de la boite alors que ça semble être dans la lignée de ta proposition.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par lesensei . Évalué à 4 (+3/-0).
Alors, je suis véritablement et sincèrement curieux.
Par quelle analyse tu décides que le login (géré par la boite, à sa totale discrétion) est une donnée dont l'utilisateur peut décider qu'elle est ou pas "correcte", et donc qu'il peut faire jouer dessus son droit de rectification ?
Parce que, autant dans ma boite, j'ai fait mon possible pour que nos systèmes permettent de changer l'identifiant d'une personne à sa guise, autant on ne m'a jamais fait remonter ça comme une exigence réglementaire. Et je serai bien intéressé de voir une décision de justice ou d'une autorité de contrôle qui confirme cette interprétation.
Le nom, le prénom, le genre, la date de naissance, toutes les données pour lesquelles la personne peut prouver qu'elles sont fausses, pas de débat. Mais le login ? Je vois pas sur quelle base on pourrait avancer qu'il est inexact, puisqu'il est toujours arbitraire.
Genre, en cas d'homonyme, comment tu satisferais cette exigence pour les 2 personnes à la fois ? Tu peux coller un incrément derrière le login de la seconde personne, bien sûr, mais ça ne fait que prouver que ça ne colle qu'à une règle arbitraire de l'employeur, qui peut parfaitement décider qu'il est non-modifiable, et le RGPD n'aura rien à y redire. Comme l'UID, quoi.
Et dans l'hypothèse où tu aurais raison, Linux serait très loin d'être le seul concerné par cette application difficile de l'exigence que tu sembles attribuer à l'article 16. (G|Hot|Yahoo)Mail seraient bien en peine de modifier ton adresse après un changement de nom d'usage, par exemple.
Mais j'en apprends tous les jours et, comme je le disais, je suis curieux de connaître ton raisonnement. D'autant que j'imagine que si tu prépares une présentation sur le sujet, c'est que tu en sais sans doute plus que moi.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 6 (+3/-0).
Alors ça dépend bien sur du type de boite. Si ta boite te file un login totalement aléatoire (genre 8 chiffres au pif) pour je ne sais pas quel raison, oui, ça va être dur d'argumenter.
Si ta boite est une startup qui te laisse choisir ton login et que tu choisis "batman" et que tu t'appelles Jean Dupont, c'est difficilement applicable aussi.
Par contre, si ton login est jean.dupont et que c'est pareil dans toute la boite (cad qu'il y a prénom.nom quand applicable, ou des variations du même genre par défaut), c'est déjà plus dur de dire que ça n'a rien de personnel.
Et il y une jurisprudence sur le sujet, l'affaire 2023-8336 devant l'autorité de protection des données (DPA) de la Suède (l'IMY), ou une banque a reçu une amende pour avoir refusé de changer le login d'un client suite à une demande sous l'article 16. Certes, le login était aussi l'email, mais ça ne change pas grand chose. Et comme le but du RGPD est d'unifier les lois au niveau européen, les DPA sont censées être d'accord les unes avec les autres (article 63 du RGPD).
Et je pense que le point qui me semble important, c'est de savoir si on peut déduire une info spécifique (en l’occurrence le nom et/ou le prénom) à partir du login, et ce qui arriverait si on décide que ça n'est pas couvert par l'article 16.
Pour illustrer le raisonnement, je vais me référer à un arrêt de la CJUE (Cour de Justice de l'Union Européenne) qui a tenu exactement ce raisonnement dans le cas C-184/20 sur la publication du nom du ou de la partenaire des haut fonctionnaires en Lituanie (pour des questions de transparence, etc, etc).
En 2022, la cour a estimé que comme on peut déduire l'orientation sexuelle de quelqu'un avec cette info (vu qu'on peut déduire le genre avec le prénom, en général), c'est une info dite sensible pour le RGPD au sens de l'article 9. Et donc, pour avoir une protection efficace des données notamment sensibles (§126 de l'arrêt), alors il faut considérer que ça couvre les données directs comme "Jean Dupont est gay", mais aussi des données qui permettent de déduire la même information comme "Le mari de Jean Dupont est Robert Dupont".
Et il n'y a pas besoin de rentrer dans les détails de savoir si Jean et/ou Robert sont homosexuels, bisexuels ou hétéros qui veulent des réductions d’impôts, car au nom du principe d'égalité ça marcherais aussi si Jean était marié à Roberta. Même si il y a une présomption d'hétérosexualité dans la société, ça reste une orientation sexuelle, et la loi ne fait pas la distinction à ce niveau.
Si on regarde bien le §126 qui détaille l'avis des juges, la cour explique que si elle avait décidé le contraire (e.g. le nom d'un/une partenaire n'est pas une info couverte par l'article 9), alors ça aurait ouvert un trou dans la protection du RGPD, et donc, ça n'était pas la bonne option.
Donc pour l'article 16, le raisonnement serait le même. Si le RGPD te donne le droit de rectifier ton nom/prénom, mais qu'on estime que ce droit ne s'applique plus quand on combine les 2 (jean.dupont), qu'on rajoute un chiffre ou n'importe quoi de réversible pour faire un login (j.dupont), alors ça permettrait au contrôleur d'éviter trivialement les demandes, donc ça réduirait la portée des droits du RGPD.
Si rajouter 1234 dans le fichier (par exemple, une base de donnée) permet d'éviter les obligations de l'article 16, on pourrait dire que ça permet aussi d'éviter l'article 17 (droit à l'effacement) et donc sans doute tout le RGPD.
Donc il y a de fortes chances que la CJUE ou les DPAs décident que ça n'est pas le bon raisonnement, et donc que les nom/prénom combinés pour faire un login doivent être couvert par le droit accordé au titre de l'article 16.
Il y aurait sans doute d'autres arguments, comme un angle de minimisation des données (l'arrêt Mousse c. SNCF Connect et CNIL vis à vis du fait que garder le login et corriger le nom d'affichage va révéler soit une situation maritale, soit une transition de genre, mais ça me semble plus faible comme argument.
Par contre, dans le cas des transitions de genre, je pense que l'employeur a également un certain nombre d’obligation de protection contre les discriminations (en droit français depuis 2012), et qu'on pourrait sans doute argumenter que ça recouvre une obligation de ne pas afficher leur transition ad vitam eternam contre le gré des gens, surtout quand la demande émane de la personne elle même.
Je suis pas spécialement étonné, personne n'en parle, et je pense que les boites le font déjà sans avoir besoin de sortir le bazooka.
Ma collègue juriste en charge de la vie privée pour l'Europe m'a dit que toute la profession a été prise par surprise par l'arrêt C-184/20 (en Lituanie sur l'orientation sexuelle), alors que personnellement, ça m'a semblé assez évident depuis le début. De même, l'issue de C-394/23 (Mousse c. SNCF) m'a paru prévisible vis à vis de la libre circulation des personnes dans l'Union. À partir du moment ou tu peux vivre en France avec une carte d'identité allemande qui peut avoir plus que M/F, les boites doivent s'adapter même si l'ordre juridique français ne reconnaît que 2 options (une position validé par la CEDH (cour européenne des droits de l'homme) dans l'affaire Y c. France en 2023).
De la même façon que tu le fait sans l'article 16. Je sais pas dans quel boite tu bosses, mais parmi mes 20000 collègues, il y a 3 qui s'appellent Matthew Miller, depuis 10 ans. Pour les logins, on prends la première lettre du prénom + le nom, et on limite à 8 lettre, donc il y en a un avec première lettre du prénom + nom, l'autre avec les 2 premières lettres, etc. Parfois, ils recoivent des courriers pour les autres, donc je dit pas que ça n'apporte pas son lot d'emmerde, mais aucun n'a changé de nom, et aucun n'habite en Europe. Donc le RGPD n'a rien changé.
Et pire encore le système de création de compte est tombé en panne il y a 12 ans car il n'était plus capable de produire des variations de nom/prénom après avoir embauché trop de gens avec les mêmes nom/prénom. J'ai plus les détails exactes, mais c'était des noms et prénoms chinois assez court, genre Lee Sun. Ça a du faire lsun, lesun, leesun et pour le 4eme, le système a tourné en boucle toute la journée.
Donc il n'y a rien de spécial à ce genre de conflit de nom et prénom, c'est déjà un souci qui existe à l'embauche et partir d'une certaine taille de boite.
Et tu peux pas dire "on embauche pas tel personne car on a déjà un Jean Dupont dans la boite", car ça serait refuser d'embaucher quelqu'un sur la base de son patronyme, ergo une discrimination interdite (Article 225-1 du code pénal) et sans doute non justifiable (c'est difficile de dire que c'est techniquement impossible quand le reste du monde y arrive).
Je n'ai pas de compte mail perso chez un des providers cités, mais que je sache, ça ne pose pas de souci particulier sur Google Workspace au taf.
Sur l'intranet de mon employeur, on a un document gigantesque sur comment changer ton login à différent endroits avec tout les soucis qu'on trouve, les tickets pour que ça soit corriger, les contournements, etc. Il n'y a aucune instruction sur le changement de login pour Google Workspace, ce qui signifie que ça marche directement (comprendre une fois qu'on a changé l'annuaire, ça se fait tout seul).
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par lesensei . Évalué à 2 (+1/-0).
Ben, si, ça change beaucoup de choses, en fait. Dans le cas que tu cites, la personne voulait faire rectifier son email, qui n'était pas le bon et qui aurait empêché la personne concernée de récupérer son compte en cas de difficulté, par exemple. La décision de l'autorité de contrôle portait en l'occurrence sur le fait que l'email devait pouvoir être modifié. Le fait que dans ce cas email=identifiant était le problème du responsable de traitement, et qu'il se débrouille pour corriger le tir. Mais rien ne dit que la décision aurait été la même pour un système découplant email et identifiant.
Ton exemple sur la déduction de donnée est très valable, et la décision ne me surprend absolument pas non plus compte-tenu des risques encourus par les personnes concernées, mais je ne vois en revanche pas le lien avec un login sur un système interne, qui permet certes au rares personnes qui y ont accès de déduire que la personne concernée a porté un autre nom, mais ne met pas vraiment ses droits et libertés en péril (puisque c'est l'enjeu principal du RGPD dans la protection des personnes).
Bref, je pense que tu extrapoles un peu trop vite à partir de choses qui ont beaucoup de sens sur un cas où ça en a beaucoup moins. Pour te donner un exemple qui illustre que l'application du RGPD n'est pas "tout noir ou tout blanc" et rejoindre l'exemple des obligations de transparence et du risque sur les données sensibles, on a en France eu une décision du conseil d'état (N°431875) qui a déterminé que la publication du statut de travailleur handicapé, sans précision sur la nature du handicap, ne valait pas publication d'une donnée de santé (en l'occurrence, il en a en revanche imposé la limitation dans le temps à ce qui était nécessaire). Cela prouve simplement qu'il y a des limites à l'exercice des droits, ces limites étant liées aux risques pour les personnes. Et dans le cas d'un login sur un système interne, je réitère, j'ai de forts gros doutes quant à la validité de tes conclusions.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
L'article 16 (et d'autres) ne demande pas de démontrer une conséquence négative pour avoir le droit de faire rectifier des données. Donc la distinction entre l'email ou tu vois des raisons et le login ou tu en vois moins n'a pas d'impact.
Ce que l'affaire que j'ai cité pointe, c'est que la DPA considére que la réponse de Klarna est une violation de l'article 12, celui qui dit que le contrôleur doit faciliter l'application de l'article 16 (entre autres). Dire que c'est pas possible pour des raisons techniques n'est pas suffisant vis à vis des obligations, et donc n'est pas une réponse valable.
Et en pratique ça n'était sans doute pas motivé par des questions de récupération du compte. Comme son nom l'indique, Klarna Bank est une banque, donc elle a des obligations de vérification qui font qu'il faut sans doute plus qu'un simple email pour ouvrir un compte (lutte contre le financement du terrorisme, contre le blanchiment, KYC, etc), donc même si l'email est incorrect, la banque a le moyen de retrouver son client. Ça n'est pas non plus une question d'affichage, le texte en suédois dit à un moment que le service client a réussi à éditer les factures existantes.
Sauf que ça ne compte pas vraiment pour le RGPD.
Pour commencer, le §10 auquel tu fais référence n'est pas la décision en tant que tel, la décision est après le §13, et aucun des 5 articles ne parle de ça. Donc le caractère normatif est assez réduit.
Le §10, c'est juste le raisonnement, et il est quand même un peu pourri, parce que le conseil d'état speedrun sa réponse (cf §11) en s'appuyant sur l'équivalent de l'article 4 du RGPD pour contredire le tribunal d'en dessous. Le §8, c'est comme Indiana Jones dans l'arche perdu, le film se termine de la même façon sans lui. En l'occurrence, ça ne sert à rien de discuter le fait que ça tombe sous l'équivalent de article 9 ou pas si au final, la réponse serait la même qu'on dise oui ou qu'on dise non (car même si le CE avait estimé que ça tombe sous l'article 9, le ministère aurait quand même du retirer l'info vu que le raisonnement se base sur le fait qu'il n'y a plus besoin de l'afficher).
Ensuite, c'est une décision du Conseil d'État, une juridiction avec un périmètre restreint, l'administration de l'état français. Ses décisions n'ont qu'un impact juridiquement limité au contraire de la CJUE ou d'une DPA.
Enfin, c'est une décision de 2021, antérieur à mon exemple de la CJUE qui date de 2022.
C'est aussi en contradiction avec le raisonnement de la CJUE dans l'affaire C‑21/23 en 2024 qui touche directement à la question des données de santé et de l'article 9. La Cour, dans son paragraphe §81, applique le même raisonnement que dans l'affaire C‑184/20 (celle de 2022) et rappelle qu'il faut avoir une interprétation large de ce qui correspond à des données de santé.
Mais c'est aussi une décision qui juge une affaire qui est plus vielle que la mise en pratique du RGPD (vu que le premier courrier date de 2015, le RGPD en tant que tel est applicable à partir de mai 2018).
Donc pour tout ça, il y a des chances que la CNIL soit plus lié par des raisonnements plus récents, plus nombreux par un tribunal plus spécialisé dans le domaine qui concerne la CNIL, que par un raisonnement plus vieux, moins détaillé, d'un tribunal non spécialisé et plus limité (et avec sans doute moins de juges, moins de contradictoire et une visée normative moindre).
Ensuite, je parle en tant que personne qui bosse dans le privé, donc peut être que les injonctions du CE t'impacte plus que moi, je sais pas ou tu bosses ou ce que tu gères.
Comme dit plus haut, l'appréciation du contrôleur sur les droits et libertés et leur périls n'as pas vraiment d'importance sur le droit ou pas d'utiliser l'article 16. Ça n'est pas conditionnel aux nombre de personnes qui ont l'info, ça n'est pas conditionnel aux risques dans la situation précise de quelqu'un qui veut jouir de ses droits.
Les seuls conditions sont énoncés à l'article 12 et 11, et c'est quand même assez limités.
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Login ou adresse de courriel basées sur le nom/prénom : changement de nom suite à mariage par exemple, combinaison problématique (genre Megan Finger si le login est nom + 2 premières lettres du prénom), changement de prénom sur une transition, éventuellement le cas de la collision (gestion du 69e Kevin Durand de l'entreprise), "impossibilité" technique (désolé Émilie ou Jördis mais notre système prend les deux premières lettres du prénom mais en ASCII 7 bits, pour un groupe international ou conséquent, l'Unicode doit arriver assez vite…), modification du nom de famille sur une nationalisation, … j'oublie probablement des cas possibles.
# Détail mais…
Posté par Maclag . Évalué à 7 (+4/-0).
Je suis sûr qu'ils pourraient faire mieux que EU-OS comme nom pour leur truc.
Franchement ça n'envoie pas du rêve et ça va encore être une catastrophe en référencement sur les moteurs de recherche.
[^] # Re: Détail mais…
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
S'ils avaient mon rapport, ils seraient parti sur Debian pour faire DEUbian.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.