En fait, pour la pub ciblé, tu n'as pas besoin qu'elle soit parfaitement ciblé, juste que les clients (eg les gens qui payent pour afficher la pub) le croit.
Donc faire plus de ramdam sur la capacité de Google a suivre les gens, ça renforce leur position commercial.
Ce genre de commentaire, c'est presque faire le VRP pour Google.
Mais tellement ça. Ça me rappelle la news récente sur la "backdoor esp32" (au lieu de dire "commande de debug non documenté"), ou l'affaire Jessica Burgess aux USA (ou l'accent a été mis sur Facebook/meta quand la réalité est que les forces de l'ordre sont arrivés avec un mandat disant "on a trouvé des restes de bébé humain brulés"), ou l’éternelle légende de Target et de la teenager enceinte et du coupon de reduc (avec N=1, mais tout le monde se fout de la méthode scientifique)
J'attends de voir une version un peu plus transparente sur ce qui est demandé et comment les infos sont traitées. Parce que là ça sent les biais dans la façon dont les appels sont faits. Je ne prétends pas que l'API est "bien" ou que Google respecte la vie privée et ne fait pas des suppositions à partir de maigres indices (on sait qu'ils n'ont aucune morale), mais ce qui pourrait être un bon outil de sensibilisation n'est en fait qu'un coup marketting créatif.
Je suppose que le fonctionnement, c'est de prendre une image, filer ça a Google Vision AI qui te renvoie un tableau en json avec des annotations:
Chaque annotation va avoir un score de confidence, et j'imagine que le site balance ça à la poubelle et passe le résultat à une IA générative pour faire le texte.
Ça explique pourquoi le site voit des choses que Google ne voit pas (genre le salaire du personnage dans un commentaire plus haut), vu qu'elle va inventer des bouts. Et j'imagine que suivant le prompt mis, l'IA générative peut avoir comme instruction de générer des trucs pour jouer sur les émotions, comme tu le pointes, comme "indique le salaire de la personne et sa religion etc, etc".
Oui, si on ne sait pas coder dans ce language, c'est compliqué. Et oui, Python est un language plus permissif que Java. On fait moins de bêtises en étant pied et poing liés.
Tu as loupé la partie ou il dit "I started writing in the 2010s when Python 2 was going to be deprecated and Python 3 was too early to support" ?
C'est un grand écart que de déduire qu'il sait pas écrire du code python alors qu'il est sorti de la fac il y a quand même 15 ans.
Et en quoi c'est représentatif d'une application en production où bien souvent les temps d'attente viennent de la bdd ou du stockage ?
Et pour la consommation mémoire, c'est aussi le stockage et la bdd qui jouent, ou c'est simplement à ignorer dans la reprise de "chacun des arguments" ?
On peut aussi parler du temps de démarrage, une des raisons qui font que Mercurial a été refait en rust. Mercurial qui n'est pas juste un bench hello world, et qui n'a pas été écrit par des gens qui ne savent pas coder.
Python n'est pas le plus rapide, ni le plus léger des langages et il n'excelle que dans un domaine.
S'interconnecter avec d'autres langages et d'autres outils.
Et il est bon partout.
Bah comme dit plus haut, c'est pas bon pour les hyperscalers, ou pour les gens prêts de leur sous. Je suis content de voir qu'Element a finalement corrigé la conso mémoire/cpu de synapse (une histoire de conversion de chaîne inutile, je retrouve pas l'annonce), mais comme je l'ai posté en 2021, c'était pas fameux du tout par rapport à du Rust ou du Go (et ça fait la différence de quelques euros par mois en terme de VM pour moi, et sans doute de quelques dizaines à centaines de milliers d'euros pour Element, vu qu'ils ont aussi du refaire des bouts de Synapse en rust.
Et comme le montre le cas de Mercurial (ou dnf/yum vs apt), c'est pas non plus terrible pour les CLIs (git est en C, et la vitesse de git m'a souvent été mise en avant comme avantage).
Ce qui fait que ça marche, c'est que n'importe qui peut l'apprendre (comme j'ai pu le voir à mon grand regret plus d'une fois en passant en second), donc ça a fini par remplacer perl en terme écosystème.
Venir attaquer Python sur un bench Hello World, c'est comme se plaindre du C++ qui nécessite une compilation pour s'exécuter …
Ce qui serait valable si il faut mesurer la simplicité d'apprentissage.
Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Mais tu pars du principe que ta distribution propose les paquets que tu veux. Et c'est quand même pas toujours le cas.
Par exemple, j'ai une application web super simple qui file un fichier ics indiquant quand il y a du merdier à cause du changement d'heure (genre, les 3 prochaines semaines, les joies de bosser dans une multinationale).
J'utilise exactement 3 paquets python pour ça. J'ai l'impression que le module ics n'est ni dans Debian (mais j'ai pas trop regardé, trop de match via apt), ni dans Fedora (ou n'était pas à l'époque).
Résultat, je me suis résolu à faire un pip install à l'époque, et le faire dans un conteneur me va parfaitement (parce que le pip install va pas consommer sensiblement plus de ressources que apt/dnf install).
Et ça fait quelques mois que je me dit "je devrais refaire l'application en rust", et la, ça serait encore pire niveau paquets de distributions.
Donc le jour ou je trouve une lib rust qui remplace mon usage de pytz (ou que je décide de parser les fichiers à la main), je passerais directement par cargo, d'autant plus qu'avec une CI et un bot, je peux automatiser la mise à jour des dépendances comme ici. Et donc avec le pipeline de déploiement qui vient avec un infra de conteneur, je pourrait avoir le serveur déployé à jour sans avoir à intervenir.
Maintenant, c'est sur que si tu as pas l'infra de gestion des conteneurs, c'est pas aussi bien. Moi, j'ai celle du boulot dont je suis responsable, et ça marche bien (genre le cluster s'auto update, j'ai du config as code pour pas mal de chose, etc, etc).
Mais lancer un conteneur sur un serveur seul, c'est bof, surtout si le conteneur est mal foutu.
Mais quand tu regardes les régressions du droit à l'IVG aux USA, c'est principalement dans les endroits ou ça a été imposé d'en haut et ou il n'y a pas vraiment de support de l'électorat.
Prenons par exemple le Texas. L'arrêt Roe v. Wade de 1973 a pour origine les lois de l'état, et donc je suppose que ça a été perçu comme un arrêt venu d'en haut (imagine les gens qui râlent sur les technocrates de l'Europe ou les bureaucrates de Paris). Après Roe v. Wade, il y a eu des tas de lois passés par la législature pour tenter de limiter ça, jusqu'à l'interdiction de nos jours. Vu le soutien assez constant pour le parti républicain depuis 1994 et la taille de la population évangélique sur place, on peut difficilement dire qu'il n'y a pas de légitimité populaire pour le moment (même si on peut dire que c'est des cons).
À l'inverse, il y a l'état de New York où depuis Janvier le droit à l'avortement est dans la constitution de l'état après un vote.
Donc je pense que c'est surtout la façon de faire passer des avancées sociales via les bricolages de la Cour suprême qui me semble être un souci. Si il y avait eu un support suffisant de la population sur le sujet, il y aurait eu un changement, soit au niveau des états, soit au niveau du Congrès.
Le Colorado est un bon exemple de ça. En 1992, il y a eu un vote sur l'interdiction de passer des lois de non discrimination pour les personnes LGBT, vote qui a obtenu 53% de oui (donc 53% pour interdire aux villes d'interdire la discrimination). ~30 ans plus tard en 2024, c'est 64% de vote pour la légalisation du mariage homosexuel, c'est quand même un sacré retournement d'opinion en une génération.
De ce que je sais, je ne pense pas que "tout" soit applicable à ce niveau la, sauf à croire que la seule chose soit "des objectifs à l'embauche".
Il y a toujours des ERG (Employee Ressources Groups), il y a toujours des politiques internes de non discrimination (car ça reste des multinationales qui peuvent avoir des procès partout dans le monde), sans doute toujours autant de training annuelles. Je suis sur que les GAFAM continuent de se préoccuper de l'ADA (Americans with Disabilities Act), je suis sur qu'il y a toujours des indicateurs sur la paie (vu qu'il faut publier en France parmi tant d'autres).
Mouarf excellent. Y a vraiment qu'ici qu'on peut apprendre des trucs comme ça.
Franchement, d'habitude, c'est plutôt l'inverse (à savoir que des gens se posent la question d'une journée de l'homme, vu que il y a toujours quelqu'un pour en parler lors du 8 mars, et c'est la que je rappelle que la journée des toilettes tombe le même jour)
Mais l'évolution de leur politique dans le domaine ne donne pas de signe particuliérement encourageant : https://time.com/7213195/google-diversity-hiring-targets-trump-dei/
Si on est sensible a cette cause, c'est regrettable, mais c'est pas étonnant dans le sens de ce que je disais, plus, ça reste une entreprise et les entreprises vont essentiellement dans le sens du vent et de leur intérêts. (L'éthique et le capitalisme ….)
Pour commencer, le lien marche pas chez moi. Il existe, j'en doute pas (il est dans l'index de DDG, pour commencer, et l'info est ailleurs), mais ça marche pas.
Ensuite, un point que je ne vois pas souvent mis en avant sur le sujet, c'est qu'il y aussi eu un changement dans la loi. En 2023, la Cour Suprême des USA a publié l'arrêt Students for Fair Admissions v. Harvard, avec comme effet de fragiliser encore plus les pratiques d'Affirmative action. L'arrivé de Trump à la présidence et le basculement du Congrès vers une majorité républicaine fait que la pratique d'avoir des objectifs d'embauches n'était sans doute plus tenable d'un point de vue juridique. Trump et le reste de la fachosphère US sont assez transparent dans leurs obsessions, vu qu'ils passent leur temps en boucle sur les sujets.
Et de toute façon, je suis personnellement assez mitigé sur l'idée, donc je suis pas vraiment sur que ça soit un probléme de ne plus avoir ça.
Tout d'abord, je suis pas sur que ça marche des masses. On peut regarder la loi en France, qui demande à avoir 6% de travailleurs handicapés dans les entreprises de plus de 20 personnes depuis 1987. Si j'en crois les chiffres de l'AGEFIPH (Association pour la gestion des fonds pour l’insertion professionnelle des personnes handicapées) de 2023, il n'y a que 29% des entreprises qui arrivent à ce chiffre, avec 69% qui emploient au moins une personne qui se déclare.
Donc il y a 1 entreprise sur 3 qui payent une amende/cotisation pour ça, et il y a des chances que les 30% qui sont en dessous de 6% le soient par hasard plus que par une politique consciente pour remplir le dit quota. Par exemple, si quelqu'un est déjà dans la boite et obtient une RQTH (Reconnaissance de la Qualité de Travailleur Handicapé) suite à un accident, une maladie ou autre, ça serait le genre de hasard en question.
Ça fait 2 ans que je vais au salon Inclusiv Day en mai, et chaque fois, le sujet qui revient majoritairement, c'est les questions de handicap.
Pour résumer, l'état mets des incitations financières, les salariés ont des incitations à se déclarer (car il faut une RQTH pour avoir des aménagements), il y a toute une industrie pour aider et ça fait 40 ans que ça existe. Et malgré ça, on arrive pas, c'est bien que c'est pas la panacée d'avoir des objectifs de ce genre, et qu'il faut faire plus comme le souligne la Défenseuse des droits en février 2025.
Ensuite, avoir des objectifs, je pense que c'est assez peu applicable en dehors des questions de genre et de handicap car ça requiert de faire des stats.
Par exemple, si tu veux faire ça sur les questions d'équité raciale, ça n'a plus trop de sens en dehors d'un pays spécifique, et pour une multinationale, c'est un souci (en sachant que les multinationales sont celles qui ont les moyens de mettre en place ce genre de programme).
Est ce qu'avoir principalement des personnes noires dans ton bureau de Nairobi doit faire grimper les chiffres mondiaux ? Est ce qu'il faut prendre en compte la religion comme en Inde ? Quid des castes, qui sont sources aussi de discriminations même en dehors du pays ?
D'un point de vue pratique, ça se heurte assez vite au RGPD en Europe vu que pas mal de choses tombent sous l'égide de l'article 9, et je rappelle qu'en entreprise, l'exception 9.2.a ne peut pas trop s'appliquer à cause du différentiel de pouvoir entre l'employeur et l'employé, §21 des guidelines de l'EDPB (European Data Protection Board)). Et le RGPD, il se réplique un peu partout. Le Brésil a le LGPD, le Japon a sa loi, le Canada aussi, avec tous le même genre d'articles que le RGPD.
Et même pour le genre, ça reste à mon sens fragile. J'ai largement donné mon avis dans les commentaires d'un journal sur le sujet des marqueurs de genre, et je pense que sanctuariser les marqueurs de genre pour abolir les inégalités de genre, ça n'est pas le meilleur plan sur le long terme. C'est selon moi assez dans l'esprit de la citation d'Audrey Lorde:
For the master’s tools will never dismantle the master’s house.
Et au delà de la question du long terme, il reste les questions qui fâchent sur le décompte des personnes non binaires, sur l'impact des transitions de genre, et comment tu fais des stats sur ça, surtout dans des pays qui ne permettent pas d'avoir des marqueurs autre que H/F, comme la France, ou des pays qui ne permettent pas de transitionner comme la Hongrie.
Et pour rester dans la pensée afro féministe, il y a aussi les questions autour de l'intersectionnalité, surtout quand on regarde l'histoire à l'origine du concept. Dans son article de 1989 ou elle présente l'idée, Kimberle Crenshaw analyse l'affaire DeGraffenreid c. General Motors. En très gros, General Motors a eu un procès pour discrimination par 5 femmes noires qui ont été licenciés. Et GM s'en ai tiré en disant que comme l'action de licenciement n'a pas ciblé toutes les femmes (cad pas les femmes blanches), ça ne pouvait pas être une discrimination sexiste, et comme elle n'a pas ciblé toutes les personnes noires (cad pas les hommes noirs), ça ne pouvait pas être une discrimination raciste.
Et une fois que tu commences à vouloir prendre en compte les discriminations croisées dans des objectifs d'embauche, c'est le bordel assuré. Mais si tu ne gardes ça que pour un seul axe, c'est aussi un souci car ça va masquer justement des discriminations croisées.
Ça part d'un bon sentiment, je suis sur que ça a fait bouger un peu les choses (même si je suis pas sur qu'on puisse attribuer les chiffres de Google à cette action, en tout cas pas avec les infos qu'on a en tant qu'externe), mais ça reste un outil quand même extrêmement limité dans le grand ordre des choses.
note par la même occasion que le fait qu'ils ne célèbrent pas la journée internationale des toilettes peut laisser dubitatif quand a l’intérêt qu'ils portent à la qualité de ces installations pourtant cruciales
Comme dit plus bas, Apple n'a semble t'il jamais proposé ça dans le calendrier. On peut donc voir que la priorité business de l'Huma, c'est pas exactement l'exactitude, ou du moins, pas quand ça va contre le fait de créer de l'outrage (et donc des clicks et de la pub). Ça fait toujours aussi tache pour un journal.
Quand à Google, il s'agit d'une transition d'ordre purement technique avec un effet de bord sur ça, qui a du commencer avant les élections présidentielles US.
De plus, le 8 mars est massivement médiatisé, donc l'avoir ou pas dans un calendrier optionnel (car oui, personne ne le dit, mais il faut s'inscrire sur les différents calendriers pour les voir, et donc il y a des chances que la majorité des gens ne le fassent pas) est assez mineur.
Et ce genre d'outrage, c'est quand même digne de la droite, voir de l’extrême droite américaine qui râle tout les ans sur "the war on christmas". Rentrer dans le jeu de la culture de l'outrage, c'est finalement valider les méthodes populistes de ce genre de formation, et faciliter par la suite la création d'un outrage à des fins anti-démocratiques, selon moi.
Enfin, les milieux militants râlent tout les ans sur les mesures purement cosmétiques des entreprises (genre offrir des roses aux salariées le 8 mars, changer son avatar en rajoutant un drapeau arc en ciel en juin, etc), et il est assez paradoxale finalement d'en faire une montagne quand une mesure purement cosmétique sans grand impact pratique n'est plus la.
De plus, il faut aussi balayer devant notre porte. Nextcloud (dans sa version de Framagenda, mais c'est pareil sur un Nextcloud selfhosté ou sans doute Owncloud) ne propose non seulement rien sur les jours internationaux (donc pas le 8 mars ni rien), mais en plus ne propose même pas tout les pays du monde pour les congés. J'ai compté 86 calendriers qui couvrent 77 pays (sur grosso modo 190 à 200 suivant comment on compte), avec une répartition qui favorise pas mal les pays riches. Par exemple, il n'y a 5 pays d'Afrique sur les 54 (si je me plante pas).
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.
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.
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).
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).
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).
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:
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).
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).
Sans surprise, il y a plus d’énergie dans la communauté pour râler sur les réseaux sociaux que pour proposer des patchs (même si je suppose que la question de la migration doit rendre ça plus complexe que ça a en a l'air)
La fondation GNOME a des données personnelles, celle des membres de la fondation et des donateurs et celle des devs (vu que un depot git, ça contient des données personnelles par définition, vu qu'on identifie quelqu'un). Mais en pratique, on s'en fout de tout ça.
La question est plus de savoir exactement ce qu'on veut mettre dans "It’s time for policymakers to take their responsibilities and not let America control the digital public space.".
Et je suis pas sur que s'appuyer sur une fondation de droit américain soit sur le chemin direct vers le non contrôle de l'espace publique numérique par les USA, surtout que le dit contrôle n'est pas vraiment explicité (et donc tout le monde y mets ce qu'il veut), donc on ne peux pas dire en pratique si garder la fondation en droit US importe ou pas.
Et au passage, je trouve aussi curieux de ne pas mentionner la moindre distribution à la fin, je cite: "It is tempting to think that since Microsoft, Google and Apple are already shipping several operating systems each, that we don’t need one more."
La vraie raison est surtout qu'on (la communauté du libre) a déjà plusieurs projets qui tentent de faire ça, et si finalement, personne parmi les distros ne suit la vision de Gnome, faut se poser la question de pourquoi. Est ce qu'il y a des soucis d'incitation, des soucis techniques, des soucis personnels ?
Et dans la mesure ou Thibault a déjà été membre du board de la fondation pendant 2 ans, je pense qu'il faut aussi se poser la question sur pourquoi le board n'a pas fait plus pendant ses 2 ans (vu que ce discours, je pense qu'il l'avait avant d'être au board, et il serait sans doute intéressant de savoir ce qui a bloqué, vu que ça va sans doute encore bloquer ).
Il manque un 3eme point, KDE e.v. est une association de droit allemande, donc dans l'UE, ce qui n'est pas le cas de la fondation, GNOME basée en Californie.
Si le but est d'éviter les USA et de se faire financer par l'Europe, ça me semble quand même à souligner, même si ça reste selon moi symbolique.
Ensuite, les 2 ont des salons de discussion qui dépendent d'une entreprise hors UE (vu que Element est basée au Royaume Uni, la fondation Matrix aussi), je suppose que ça rentrerais aussi dans les questions de souverainetés européennes mais qu'on va pas en parler trop fort :p ?
L'article dit que Cozy Cloud est en liquidation depuis février, et qu'une annonce va être fait.
Ça parle aussi d'une plainte devant la CNIL par un ex employé "recruté en 2016 comme ingénieur développeur et administrateur système". Il n'y a pas trop besoin de chercher de qui il s'agit vu qu'il y a eu un article de blog sur ça, et qu'il y a eu masse messages sur les réseaux sociaux sur la plainte, la CNIL, etc.
Je suppose que "Autant vous dire que, lorsque nous avons réalisé que c'était sa candidature qu'il nous envoyait, et pas une liste de bugs de sécu de Cozy, nous étions positivement ravis !" ne doit plus trop être vrai en 2025 (mais bon, ça, j'aurais pu le dire déjà en 2016).
[^] # Re: contexte
Posté par Misc (site web personnel) . En réponse au lien Comment Google interprète vos photos. Évalué à 5 (+2/-0).
En fait, pour la pub ciblé, tu n'as pas besoin qu'elle soit parfaitement ciblé, juste que les clients (eg les gens qui payent pour afficher la pub) le croit.
Donc faire plus de ramdam sur la capacité de Google a suivre les gens, ça renforce leur position commercial.
Ce genre de commentaire, c'est presque faire le VRP pour Google.
[^] # Re: C'est surtout de la pub non ?
Posté par Misc (site web personnel) . En réponse au lien Comment Google interprète vos photos. Évalué à 7 (+4/-0).
Mais tellement ça. Ça me rappelle la news récente sur la "backdoor esp32" (au lieu de dire "commande de debug non documenté"), ou l'affaire Jessica Burgess aux USA (ou l'accent a été mis sur Facebook/meta quand la réalité est que les forces de l'ordre sont arrivés avec un mandat disant "on a trouvé des restes de bébé humain brulés"), ou l’éternelle légende de Target et de la teenager enceinte et du coupon de reduc (avec N=1, mais tout le monde se fout de la méthode scientifique)
Je suppose que le fonctionnement, c'est de prendre une image, filer ça a Google Vision AI qui te renvoie un tableau en json avec des annotations:
https://cloud.google.com/vision/docs/reference/rest/v1/AnnotateImageResponse
Chaque annotation va avoir un score de confidence, et j'imagine que le site balance ça à la poubelle et passe le résultat à une IA générative pour faire le texte.
Ça explique pourquoi le site voit des choses que Google ne voit pas (genre le salaire du personnage dans un commentaire plus haut), vu qu'elle va inventer des bouts. Et j'imagine que suivant le prompt mis, l'IA générative peut avoir comme instruction de générer des trucs pour jouer sur les émotions, comme tu le pointes, comme "indique le salaire de la personne et sa religion etc, etc".
C'est 100% un coup marketing.
[^] # Re: un avis contraire
Posté par Misc (site web personnel) . En réponse au journal Une backdoor dans les ESP32 ?. Évalué à 2 (+0/-1).
Pourquoi tu veux faire retirer des fonctionnalités du matos que j'ai payé et qui m'appartient ?
[^] # Re: Développeur Python en production ici 😉
Posté par Misc (site web personnel) . En réponse au lien Difficile de recommander Python en production . Évalué à 7 (+5/-1).
Tu as loupé la partie ou il dit "I started writing in the 2010s when Python 2 was going to be deprecated and Python 3 was too early to support" ?
C'est un grand écart que de déduire qu'il sait pas écrire du code python alors qu'il est sorti de la fac il y a quand même 15 ans.
Et pour la consommation mémoire, c'est aussi le stockage et la bdd qui jouent, ou c'est simplement à ignorer dans la reprise de "chacun des arguments" ?
On peut aussi parler du temps de démarrage, une des raisons qui font que Mercurial a été refait en rust. Mercurial qui n'est pas juste un bench hello world, et qui n'a pas été écrit par des gens qui ne savent pas coder.
Bah comme dit plus haut, c'est pas bon pour les hyperscalers, ou pour les gens prêts de leur sous. Je suis content de voir qu'Element a finalement corrigé la conso mémoire/cpu de synapse (une histoire de conversion de chaîne inutile, je retrouve pas l'annonce), mais comme je l'ai posté en 2021, c'était pas fameux du tout par rapport à du Rust ou du Go (et ça fait la différence de quelques euros par mois en terme de VM pour moi, et sans doute de quelques dizaines à centaines de milliers d'euros pour Element, vu qu'ils ont aussi du refaire des bouts de Synapse en rust.
Et comme le montre le cas de Mercurial (ou dnf/yum vs apt), c'est pas non plus terrible pour les CLIs (git est en C, et la vitesse de git m'a souvent été mise en avant comme avantage).
Ce qui fait que ça marche, c'est que n'importe qui peut l'apprendre (comme j'ai pu le voir à mon grand regret plus d'une fois en passant en second), donc ça a fini par remplacer perl en terme écosystème.
Ce qui serait valable si il faut mesurer la simplicité d'apprentissage.
[^] # Re: Huhu
Posté par Misc (site web personnel) . En réponse au lien Difficile de recommander Python en production . Évalué à 6 (+3/-0).
Mais tu pars du principe que ta distribution propose les paquets que tu veux. Et c'est quand même pas toujours le cas.
Par exemple, j'ai une application web super simple qui file un fichier ics indiquant quand il y a du merdier à cause du changement d'heure (genre, les 3 prochaines semaines, les joies de bosser dans une multinationale).
J'utilise exactement 3 paquets python pour ça. J'ai l'impression que le module ics n'est ni dans Debian (mais j'ai pas trop regardé, trop de match via apt), ni dans Fedora (ou n'était pas à l'époque).
Résultat, je me suis résolu à faire un pip install à l'époque, et le faire dans un conteneur me va parfaitement (parce que le pip install va pas consommer sensiblement plus de ressources que apt/dnf install).
Et ça fait quelques mois que je me dit "je devrais refaire l'application en rust", et la, ça serait encore pire niveau paquets de distributions.
Donc le jour ou je trouve une lib rust qui remplace mon usage de pytz (ou que je décide de parser les fichiers à la main), je passerais directement par cargo, d'autant plus qu'avec une CI et un bot, je peux automatiser la mise à jour des dépendances comme ici. Et donc avec le pipeline de déploiement qui vient avec un infra de conteneur, je pourrait avoir le serveur déployé à jour sans avoir à intervenir.
Maintenant, c'est sur que si tu as pas l'infra de gestion des conteneurs, c'est pas aussi bien. Moi, j'ai celle du boulot dont je suis responsable, et ça marche bien (genre le cluster s'auto update, j'ai du config as code pour pas mal de chose, etc, etc).
Mais lancer un conteneur sur un serveur seul, c'est bof, surtout si le conteneur est mal foutu.
[^] # Re: Plutôt une bonne chose, non ?
Posté par Misc (site web personnel) . En réponse au lien Apple et Google suppriment la journée internationale des droits des femmes de leur calendrier . Évalué à 4 (+1/-0).
Mais quand tu regardes les régressions du droit à l'IVG aux USA, c'est principalement dans les endroits ou ça a été imposé d'en haut et ou il n'y a pas vraiment de support de l'électorat.
Prenons par exemple le Texas. L'arrêt Roe v. Wade de 1973 a pour origine les lois de l'état, et donc je suppose que ça a été perçu comme un arrêt venu d'en haut (imagine les gens qui râlent sur les technocrates de l'Europe ou les bureaucrates de Paris). Après Roe v. Wade, il y a eu des tas de lois passés par la législature pour tenter de limiter ça, jusqu'à l'interdiction de nos jours. Vu le soutien assez constant pour le parti républicain depuis 1994 et la taille de la population évangélique sur place, on peut difficilement dire qu'il n'y a pas de légitimité populaire pour le moment (même si on peut dire que c'est des cons).
À l'inverse, il y a l'état de New York où depuis Janvier le droit à l'avortement est dans la constitution de l'état après un vote.
Donc je pense que c'est surtout la façon de faire passer des avancées sociales via les bricolages de la Cour suprême qui me semble être un souci. Si il y avait eu un support suffisant de la population sur le sujet, il y aurait eu un changement, soit au niveau des états, soit au niveau du Congrès.
Le Colorado est un bon exemple de ça. En 1992, il y a eu un vote sur l'interdiction de passer des lois de non discrimination pour les personnes LGBT, vote qui a obtenu 53% de oui (donc 53% pour interdire aux villes d'interdire la discrimination). ~30 ans plus tard en 2024, c'est 64% de vote pour la légalisation du mariage homosexuel, c'est quand même un sacré retournement d'opinion en une génération.
[^] # Re: Proposition de remplacements
Posté par Misc (site web personnel) . En réponse au lien Apple et Google suppriment la journée internationale des droits des femmes de leur calendrier . Évalué à 3 (+0/-0).
De ce que je sais, je ne pense pas que "tout" soit applicable à ce niveau la, sauf à croire que la seule chose soit "des objectifs à l'embauche".
Il y a toujours des ERG (Employee Ressources Groups), il y a toujours des politiques internes de non discrimination (car ça reste des multinationales qui peuvent avoir des procès partout dans le monde), sans doute toujours autant de training annuelles. Je suis sur que les GAFAM continuent de se préoccuper de l'ADA (Americans with Disabilities Act), je suis sur qu'il y a toujours des indicateurs sur la paie (vu qu'il faut publier en France parmi tant d'autres).
[^] # Re: Proposition de remplacements
Posté par Misc (site web personnel) . En réponse au lien Apple et Google suppriment la journée internationale des droits des femmes de leur calendrier . Évalué à 5 (+2/-0).
Franchement, d'habitude, c'est plutôt l'inverse (à savoir que des gens se posent la question d'une journée de l'homme, vu que il y a toujours quelqu'un pour en parler lors du 8 mars, et c'est la que je rappelle que la journée des toilettes tombe le même jour)
Pour commencer, le lien marche pas chez moi. Il existe, j'en doute pas (il est dans l'index de DDG, pour commencer, et l'info est ailleurs), mais ça marche pas.
Ensuite, un point que je ne vois pas souvent mis en avant sur le sujet, c'est qu'il y aussi eu un changement dans la loi. En 2023, la Cour Suprême des USA a publié l'arrêt Students for Fair Admissions v. Harvard, avec comme effet de fragiliser encore plus les pratiques d'Affirmative action. L'arrivé de Trump à la présidence et le basculement du Congrès vers une majorité républicaine fait que la pratique d'avoir des objectifs d'embauches n'était sans doute plus tenable d'un point de vue juridique. Trump et le reste de la fachosphère US sont assez transparent dans leurs obsessions, vu qu'ils passent leur temps en boucle sur les sujets.
Et de toute façon, je suis personnellement assez mitigé sur l'idée, donc je suis pas vraiment sur que ça soit un probléme de ne plus avoir ça.
Tout d'abord, je suis pas sur que ça marche des masses. On peut regarder la loi en France, qui demande à avoir 6% de travailleurs handicapés dans les entreprises de plus de 20 personnes depuis 1987. Si j'en crois les chiffres de l'AGEFIPH (Association pour la gestion des fonds pour l’insertion professionnelle des personnes handicapées) de 2023, il n'y a que 29% des entreprises qui arrivent à ce chiffre, avec 69% qui emploient au moins une personne qui se déclare.
Donc il y a 1 entreprise sur 3 qui payent une amende/cotisation pour ça, et il y a des chances que les 30% qui sont en dessous de 6% le soient par hasard plus que par une politique consciente pour remplir le dit quota. Par exemple, si quelqu'un est déjà dans la boite et obtient une RQTH (Reconnaissance de la Qualité de Travailleur Handicapé) suite à un accident, une maladie ou autre, ça serait le genre de hasard en question.
Ça fait 2 ans que je vais au salon Inclusiv Day en mai, et chaque fois, le sujet qui revient majoritairement, c'est les questions de handicap.
Pour résumer, l'état mets des incitations financières, les salariés ont des incitations à se déclarer (car il faut une RQTH pour avoir des aménagements), il y a toute une industrie pour aider et ça fait 40 ans que ça existe. Et malgré ça, on arrive pas, c'est bien que c'est pas la panacée d'avoir des objectifs de ce genre, et qu'il faut faire plus comme le souligne la Défenseuse des droits en février 2025.
Ensuite, avoir des objectifs, je pense que c'est assez peu applicable en dehors des questions de genre et de handicap car ça requiert de faire des stats.
Par exemple, si tu veux faire ça sur les questions d'équité raciale, ça n'a plus trop de sens en dehors d'un pays spécifique, et pour une multinationale, c'est un souci (en sachant que les multinationales sont celles qui ont les moyens de mettre en place ce genre de programme).
Est ce qu'avoir principalement des personnes noires dans ton bureau de Nairobi doit faire grimper les chiffres mondiaux ? Est ce qu'il faut prendre en compte la religion comme en Inde ? Quid des castes, qui sont sources aussi de discriminations même en dehors du pays ?
D'un point de vue pratique, ça se heurte assez vite au RGPD en Europe vu que pas mal de choses tombent sous l'égide de l'article 9, et je rappelle qu'en entreprise, l'exception 9.2.a ne peut pas trop s'appliquer à cause du différentiel de pouvoir entre l'employeur et l'employé, §21 des guidelines de l'EDPB (European Data Protection Board)). Et le RGPD, il se réplique un peu partout. Le Brésil a le LGPD, le Japon a sa loi, le Canada aussi, avec tous le même genre d'articles que le RGPD.
Et même pour le genre, ça reste à mon sens fragile. J'ai largement donné mon avis dans les commentaires d'un journal sur le sujet des marqueurs de genre, et je pense que sanctuariser les marqueurs de genre pour abolir les inégalités de genre, ça n'est pas le meilleur plan sur le long terme. C'est selon moi assez dans l'esprit de la citation d'Audrey Lorde:
For the master’s tools will never dismantle the master’s house.
Et au delà de la question du long terme, il reste les questions qui fâchent sur le décompte des personnes non binaires, sur l'impact des transitions de genre, et comment tu fais des stats sur ça, surtout dans des pays qui ne permettent pas d'avoir des marqueurs autre que H/F, comme la France, ou des pays qui ne permettent pas de transitionner comme la Hongrie.
Et pour rester dans la pensée afro féministe, il y a aussi les questions autour de l'intersectionnalité, surtout quand on regarde l'histoire à l'origine du concept. Dans son article de 1989 ou elle présente l'idée, Kimberle Crenshaw analyse l'affaire DeGraffenreid c. General Motors. En très gros, General Motors a eu un procès pour discrimination par 5 femmes noires qui ont été licenciés. Et GM s'en ai tiré en disant que comme l'action de licenciement n'a pas ciblé toutes les femmes (cad pas les femmes blanches), ça ne pouvait pas être une discrimination sexiste, et comme elle n'a pas ciblé toutes les personnes noires (cad pas les hommes noirs), ça ne pouvait pas être une discrimination raciste.
Et une fois que tu commences à vouloir prendre en compte les discriminations croisées dans des objectifs d'embauche, c'est le bordel assuré. Mais si tu ne gardes ça que pour un seul axe, c'est aussi un souci car ça va masquer justement des discriminations croisées.
Ça part d'un bon sentiment, je suis sur que ça a fait bouger un peu les choses (même si je suis pas sur qu'on puisse attribuer les chiffres de Google à cette action, en tout cas pas avec les infos qu'on a en tant qu'externe), mais ça reste un outil quand même extrêmement limité dans le grand ordre des choses.
[^] # Re: Proposition de remplacements
Posté par Misc (site web personnel) . En réponse au lien Apple et Google suppriment la journée internationale des droits des femmes de leur calendrier . Évalué à 2 (+0/-1).
C'est triste ton avis sur le 19 novembre, journée internationale de l'homme :p
[^] # Re: Huhu
Posté par Misc (site web personnel) . En réponse au lien Difficile de recommander Python en production . Évalué à 5 (+3/-0).
Il y a eu 12 000 personnes pour Kubecon EU à Paris en 2024. PyCon US, à titre de comparaison, c'est 2700 tickets la même année.
On peut donc en effet difficilement dire que l'usage de conteneurs est minoritaire (ou en tout cas, par rapport à celui de Python).
[^] # Re: Condamnée à quoi ?
Posté par Misc (site web personnel) . En réponse au lien La France condamnée par la Cour européenne des droits de l'homme pour violation du droit à la vie. Évalué à 3 (+0/-0).
Et la réponse: non violation de l'article 2.
[^] # Re: Proposition de remplacements
Posté par Misc (site web personnel) . En réponse au lien Apple et Google suppriment la journée internationale des droits des femmes de leur calendrier . Évalué à 5 (+2/-0).
Comme dit plus bas, Apple n'a semble t'il jamais proposé ça dans le calendrier. On peut donc voir que la priorité business de l'Huma, c'est pas exactement l'exactitude, ou du moins, pas quand ça va contre le fait de créer de l'outrage (et donc des clicks et de la pub). Ça fait toujours aussi tache pour un journal.
Quand à Google, il s'agit d'une transition d'ordre purement technique avec un effet de bord sur ça, qui a du commencer avant les élections présidentielles US.
De plus, le 8 mars est massivement médiatisé, donc l'avoir ou pas dans un calendrier optionnel (car oui, personne ne le dit, mais il faut s'inscrire sur les différents calendriers pour les voir, et donc il y a des chances que la majorité des gens ne le fassent pas) est assez mineur.
Et ce genre d'outrage, c'est quand même digne de la droite, voir de l’extrême droite américaine qui râle tout les ans sur "the war on christmas". Rentrer dans le jeu de la culture de l'outrage, c'est finalement valider les méthodes populistes de ce genre de formation, et faciliter par la suite la création d'un outrage à des fins anti-démocratiques, selon moi.
Enfin, les milieux militants râlent tout les ans sur les mesures purement cosmétiques des entreprises (genre offrir des roses aux salariées le 8 mars, changer son avatar en rajoutant un drapeau arc en ciel en juin, etc), et il est assez paradoxale finalement d'en faire une montagne quand une mesure purement cosmétique sans grand impact pratique n'est plus la.
De plus, il faut aussi balayer devant notre porte. Nextcloud (dans sa version de Framagenda, mais c'est pareil sur un Nextcloud selfhosté ou sans doute Owncloud) ne propose non seulement rien sur les jours internationaux (donc pas le 8 mars ni rien), mais en plus ne propose même pas tout les pays du monde pour les congés. J'ai compté 86 calendriers qui couvrent 77 pays (sur grosso modo 190 à 200 suivant comment on compte), avec une répartition qui favorise pas mal les pays riches. Par exemple, il n'y a 5 pays d'Afrique sur les 54 (si je me plante pas).
[^] # Re: Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. Évalué à 4 (+1/-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 Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. É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 Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. É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 Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. É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 Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. Évalué à 7 (+4/-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 Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. É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 Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. É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).
# Pour moi, ça sera avec de la sauce caramel
Posté par Misc (site web personnel) . En réponse au lien EU-OS, une démonstration de principe d'un OS pour le secteur public européen. Évalué à 6 (+5/-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).
# lz4 et firefox
Posté par Misc (site web personnel) . En réponse au journal Recupérer la liste des onglets ouverts sur Firefox. Évalué à 8 (+5/-0).
En fait, c'est simplement que l'usage de lz4 par Firefox est antérieur à la création d'un format de fichier:
https://bugzilla.mozilla.org/show_bug.cgi?id=1209390#c10
Sans surprise, il y a plus d’énergie dans la communauté pour râler sur les réseaux sociaux que pour proposer des patchs (même si je suppose que la question de la migration doit rendre ça plus complexe que ça a en a l'air)
[^] # Re: Petit résumé sans IA
Posté par Misc (site web personnel) . En réponse au lien "Des prothèses qui ne trahissent pas", une proposition de réforme de la gouvernance de GNOME. Évalué à 4 (+1/-0).
La fondation GNOME a des données personnelles, celle des membres de la fondation et des donateurs et celle des devs (vu que un depot git, ça contient des données personnelles par définition, vu qu'on identifie quelqu'un). Mais en pratique, on s'en fout de tout ça.
La question est plus de savoir exactement ce qu'on veut mettre dans "It’s time for policymakers to take their responsibilities and not let America control the digital public space.".
Et je suis pas sur que s'appuyer sur une fondation de droit américain soit sur le chemin direct vers le non contrôle de l'espace publique numérique par les USA, surtout que le dit contrôle n'est pas vraiment explicité (et donc tout le monde y mets ce qu'il veut), donc on ne peux pas dire en pratique si garder la fondation en droit US importe ou pas.
Et au passage, je trouve aussi curieux de ne pas mentionner la moindre distribution à la fin, je cite: "It is tempting to think that since Microsoft, Google and Apple are already shipping several operating systems each, that we don’t need one more."
La vraie raison est surtout qu'on (la communauté du libre) a déjà plusieurs projets qui tentent de faire ça, et si finalement, personne parmi les distros ne suit la vision de Gnome, faut se poser la question de pourquoi. Est ce qu'il y a des soucis d'incitation, des soucis techniques, des soucis personnels ?
Et dans la mesure ou Thibault a déjà été membre du board de la fondation pendant 2 ans, je pense qu'il faut aussi se poser la question sur pourquoi le board n'a pas fait plus pendant ses 2 ans (vu que ce discours, je pense qu'il l'avait avant d'être au board, et il serait sans doute intéressant de savoir ce qui a bloqué, vu que ça va sans doute encore bloquer ).
[^] # Re: Un gpl killer? TAN !
Posté par Misc (site web personnel) . En réponse au lien FYI: An appeals court may kill a GNU GPL software license. Évalué à 8 (+5/-0).
L'opinion d'un collègue qui connaît bien le sujet (genre, corédacteur de la GPL v3) est qu'en effet, l'article semble hyperbolique.
[^] # Re: Petit résumé sans IA
Posté par Misc (site web personnel) . En réponse au lien "Des prothèses qui ne trahissent pas", une proposition de réforme de la gouvernance de GNOME. Évalué à 4 (+1/-0).
Il manque un 3eme point, KDE e.v. est une association de droit allemande, donc dans l'UE, ce qui n'est pas le cas de la fondation, GNOME basée en Californie.
Si le but est d'éviter les USA et de se faire financer par l'Europe, ça me semble quand même à souligner, même si ça reste selon moi symbolique.
Ensuite, les 2 ont des salons de discussion qui dépendent d'une entreprise hors UE (vu que Element est basée au Royaume Uni, la fondation Matrix aussi), je suppose que ça rentrerais aussi dans les questions de souverainetés européennes mais qu'on va pas en parler trop fort :p ?
[^] # Re: paywall
Posté par Misc (site web personnel) . En réponse au lien Linagora rachète Cozy Cloud. Évalué à 6 (+3/-0).
L'article dit que Cozy Cloud est en liquidation depuis février, et qu'une annonce va être fait.
Ça parle aussi d'une plainte devant la CNIL par un ex employé "recruté en 2016 comme ingénieur développeur et administrateur système". Il n'y a pas trop besoin de chercher de qui il s'agit vu qu'il y a eu un article de blog sur ça, et qu'il y a eu masse messages sur les réseaux sociaux sur la plainte, la CNIL, etc.
Je suppose que "Autant vous dire que, lorsque nous avons réalisé que c'était sa candidature qu'il nous envoyait, et pas une liste de bugs de sécu de Cozy, nous étions positivement ravis !" ne doit plus trop être vrai en 2025 (mais bon, ça, j'aurais pu le dire déjà en 2016).