width = 0 ou -10 ? progress = -1.0, NaN, -Infinity ? width doit être inférieur à la taille max de String aussi (et petit de préférence sinon ça devrait se sentir aussi). Et on devrait pouvoir choisir la forme donc avoir un nom de fonction en template, et la couleur devrait être un paramètre, et on devrait pouvoir choisir la forme et la couleur de l'abri à vélo vert.
Les infos temporelles en base SQL susceptibles d'être utiles pour mesure l'activité/l'inactivité d'un compte (mais tout est toujours compliqué, entre l'historique, les changements de logiciel, les opérations manuelles en base à une époque, …) :
nb
ne pas oublier d'exclure Anonyme et Collectif des traitements
la table badges devrait être supprimée (elle est vide)
si on connaît mal les comptes actifs, alors on a un souci sur les statistiques des utilisateurs
mentionner les oauth_applications associées à la fermeture d'un compte dans les règles de gestion
nettoyer les oauth_access_grants révoqués (1539 sur 1599) passés un certain délai, y compris pour les comptes actifs ?
contenus créés (bookmarks.created_at, bookmarks.created, diaries.created_at, news.created_at, polls.created_at, posts.created_at, trackers.created_at, wiki_pages.created) et les indirects news_versions.created_at et wiki_versions.created_at : la date n'est pas modifiée en suite. Verdict: Utile pour repousser la fermeture faute de mieux, par contre tout le monde ne créé pas de contenus.
nodes.created_at devrait donner la même info que la précédente, à quelques secondes près (verdict: inutile pour notre besoin):
pour les contenus non modérés a priori ([0,2s] pour les bookmarks, [0,61s] pour les diaries, [-1d, 41s] pour les posts, étrange mais pas important ici, [0,4041s] pour les trackers, [0, 1s] pour les wiki_pages)
mais ça peut varier beaucoup, plusieurs années, pour les contenus modérés a priori qui ont patienté longtemps en rédaction/modération comme news et polls)
commentaires créés (comments.created_at) : la date n'est pas modifiée en suite. Par contre tout le monde ne commente pas. Verdict: Utile pour repousser la fermeture faute de mieux.
étiquetages créés (taggings.created_at) : la date n'est pas modifiée en suite. Par contre tout le monde n'étiquette pas. A priori pas éligible au droit d'auteur, donc pas forcément utile de conserver l'association au user_id si on peut autrement supprimer le compte (on réaffecte à Anonyme). Verdict: Utile pour repousser la fermeture faute de mieux.
uniquement pour les administrateurs : categories.created_at, categories.updated_at, forums.created_at, forums.updated_at, pages.created_at, pages.updated_at, sections.created_at, sections.updated_at)
mises à jour de contenus (verdict: inutile ici):
limités à l'équipe du site (bookmarks.updated_at, diaries.updated_at, polls.updated_at) et ne renseignent pas sur l'activité du compte concerné
le compte ou l'équipe du site (̀posts.updated_at, trackers.updated_at, poll_answers.created_at, poll_answers.updated_at, news.submitted_at) donc pas utilisable non plus ici
plusieurs comptes (wiki_pages.updated_at, news.updated_at)
nodes.updated_at, nodes.last_commented_at : influencé par le score, le dernier commentaire, etc. Verdict: inutile pour notre besoin
links.created_at, links.updated_at : autant se baser sur la dépêche…
mises à jour de commentaires (verdict: inutile pour notre besoin) : reflète initialement les éventuelles modifications par le compte pendant la période initiale, mais aussi les corrections par l'équipe du site ou simplement le score
friendly_id_slugs.created_at nous dira juste si le compte ou l'équipe du site a eu besoin de renommer quelque chose (verdict: inutile pour notre besoin)
logs.created_at nous dira qui a fermé le compte et quand (verdict: utile, mais juste pour les comptes fermés)
autorisations données et tokens pour les applications, par le compte oauth_access_grants.created_at, oauth_access_grants.revoked_at, oauth_access_tokens.created_at, oauth_access_tokens.revoked_at (verdict: utile pour repousser la fermeture faute de mieux)
oauth_applications.updated_at : a priori ça ne va pas forcément nous aider
création de comptes : users.created_at et accounts.created_at
confirmation du compte : accounts.confirmed_at et accounts.confirmation_sent_at (verdict: si les deux sont NULL et le rôle inactive, alors on peut virer ; mais si le rôle est différent, on n'apprend rien)
mise à jour de accounts.updated_at, reset_password_sent_at: changement de rôle, changement de karma, changement de feuille de style, d'adresse de courriel, demande de renvoi de courriel, se loguer, modifier les préférences -> verdict: inutile
mise à jour de users.updated_at: modifier son nom, ses adresses de site perso/mastodon, son avatar, sa signature -> a priori rien qui ne soit modifiable par un autre compte, et rien qui bouge après la fermeture du compte. Verdict: utile pour repousser la fermeture faute de mieux
accounts.remember_created_at ne marche que pour la fonctionnalité "se souvenir de moi"
accounts.current_sign_in_at (forcément mieux que accounts.last_sign_in_at) ne marche que si les sessions sont oubliés côté navigateur
Il y a une solution simple et habituellement utilisée je dirais: tu fais des CGU, tu imposes l'acceptation, et si tu n'acceptes pas après un certain délai, alors c'est que le compte est inactif.
Si, l'adresse de courriel sera supprimée après un an si tu fermes ton compte ou si l'équipe fermes ton compte, et après 3 ans d'inactivité et 1 an sinon.
Le cas se présente de temps en temps, mais rarement : suivant les cas, une ancienne signature, le texte présent dans un contenu ou commentaire qui référence un lien vers un site perso ou un autre site, une ancienne version d'un contenu/commentaire dans un archiveur web, etc. On a déjà fait des réattributions.
La même question se pose potentiellement dans bien d'autres cas (tous aussi rares actuellement pour nous, mais pas inexistants) : comment convaincre/prouver que X est décédé et que son compte doit être fermé, que Y a changé de nom ou de sexe, que toto123@vieuxdomain.com de 1998 est bien la même personne que le toto123@vieuxdomain.com de 2023, etc. L'adresse de courriel n'est pas une solution miraculeuse non plus, mais ça reste bien pratique pour un « compte sur un simple site web ».
Boulette de ma part : c'est bien adresse IP de connexion courante et adresse IP de dernière connexion. Je corrige la dépêche ce sens. Merci.
Finalité : « avoir des données d’identification (…) pour gérer les litiges éventuels (par exemple, le manifestement illégal, le prétendument illégal) ou le cadre légal (par exemple, la modification des données de son propre compte, le droit d’auteur) ; » et « détecter des éventuels abus (comptes multiples, etc.). »
Les IP des logs web sont hors de la « base active », et ne sont pas forcément reliables à un compte (accès anonyme, IP commune à de multiples comptes, etc.). Les logs web sont conservés un an actuellement.
Non, ce n'est pas uniquement la dernière « connexion ». Ça peut être un ajout de commentaire, d'étiquette, de contenu, une édition des préférences du compte, etc. Une consultation ou modification du site faite avec le compte ?
Idéalement non, le monde du courriel est suffisamment détérioré pour que ça soit pénible d'envoyer des milliers de courriel sans être classé spammeur, en devant gérer les erreurs variées, etc. La première application va concerner des comptes particulièrement anciens (certains auront plus de 10 ans d'inactivité par exemple).
Oui c'est indiqué dans la dépêche d'ailleurs. « La principale différence concerne la conservation de l’adresse de courriel pour permettre une réouverture du compte et un envoi de nouveau mot de passe en cas de demande. »
C'est une suppression de la base active, ça laisserait la possibilité d'un archivage intermédiaire par exemple. Cf https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees
Ensuite ça reste un compromis / arbitrage entre la minimisation des données demandées par le RGPD et la durée du droit d'auteur en dizaines d'années ( et les coûts et la complexité pour une structure associative aussi). On parle d'une période intermédiaire de 1 an ou 3+1 ans, pendant laquelle la personne n'a pas réagi. Et au final, c'est à la personne qui a fermé son compte ou laissé son compte expiré de montrer qu'elle est bien cette personne… (de même que c'est à la personne qui a perdu son mot de passe et laissé une adresse de courriel invalide sur son compte de prouver qu'elle est bien cette personne). Cela ne compromet pas totalement mais clairement ça rendrait plus difficile.
La montée de questions écologiques peut jouer là-dessus : optimisation des chaînes CI/CD pour éviter de brûler une forêt à chaque commit, moins de ressources nécessaires à l'exécution (processeur, mémoire, batterie, disque, réseau, etc.). À condition que ça devienne un critère plus ou moins mesuré et pris en compte, évidemment.
Ouais y en a marre du porno dans les corbeilles a-t-il déclaré. Je vais aussi lancer un rm ******** pour supprimer les mots de passe qui traînent aurait-il ajouté. Avant de conclure oups, la boulette.
[^] # Re: tout lu mais
Posté par Benoît Sibaud (site web personnel) . En réponse au journal 50 mauvais conseils de codage pour développeur C++. Évalué à 6.
width = 0 ou -10 ? progress = -1.0, NaN, -Infinity ? width doit être inférieur à la taille max de String aussi (et petit de préférence sinon ça devrait se sentir aussi). Et on devrait pouvoir choisir la forme donc avoir un nom de fonction en template, et la couleur devrait être un paramètre, et on devrait pouvoir choisir la forme et la couleur de l'abri à vélo vert.
[^] # Re: Dépêche AdL
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Plus de dépêche avec les événements de l'agenda du libre?. Évalué à 3 (+0/-0).
Voilà publié… https://linuxfr.org/news/agenda-du-libre-pour-la-semaine-8-de-l-annee-2023
# Dépêche AdL
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Plus de dépêche avec les événements de l'agenda du libre?. Évalué à 4 (+0/-0).
Cf https://linuxfr.org/wiki/fonctionnalite-agenda-du-libre pour la page wiki mentionnée
La dépêche n'est pas entièrement produite pas un script, et personne ne l'a produite le week-end dernier.
[^] # Re: Délivre-nous des anglicismes
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Deux ou trois trucs à savoir sur Openclipart (avec des morceaux d’Inkscape dedans). Évalué à 7.
En français, 'plus' veut dire 'encore' ou 'stop' suivant le contexte.
[^] # Re: Délivre-nous des anglicismes
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Deux ou trois trucs à savoir sur Openclipart (avec des morceaux d’Inkscape dedans). Évalué à 3.
y compris les langues mortes
https://sup.sorbonne-universite.fr/catalogue/lingua-latina/la-polysemie-en-latin
ou
https://www.persee.fr/doc/bsnaf_0081-1181_2012_num_2006_1_11017
et aussi https://www.quora.com/What-are-the-most-and-least-polysemic-languages "I hope you can see that this is an impossible question to answer."
[^] # Re: Délivre-nous des anglicismes
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Deux ou trois trucs à savoir sur Openclipart (avec des morceaux d’Inkscape dedans). Évalué à 5. Dernière modification le 23 février 2023 à 09:57.
Ce n'est pas propre au français. Chaque langue a son degré de polysémie.
To fix stuff avec 12 fois 9 sens possibles ?
# Timestamps SQL
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Pouvoir déterminer si un compte a eu de l'activité récemment. Évalué à 3 (+0/-0).
Les infos temporelles en base SQL susceptibles d'être utiles pour mesure l'activité/l'inactivité d'un compte (mais tout est toujours compliqué, entre l'historique, les changements de logiciel, les opérations manuelles en base à une époque, …) :
badgesdevrait être supprimée (elle est vide)oauth_applicationsassociées à la fermeture d'un compte dans les règles de gestionoauth_access_grantsrévoqués (1539 sur 1599) passés un certain délai, y compris pour les comptes actifs ?bookmarks.created_at,bookmarks.created,diaries.created_at,news.created_at,polls.created_at,posts.created_at,trackers.created_at,wiki_pages.created) et les indirectsnews_versions.created_atetwiki_versions.created_at: la date n'est pas modifiée en suite. Verdict: Utile pour repousser la fermeture faute de mieux, par contre tout le monde ne créé pas de contenus.nodes.created_atdevrait donner la même info que la précédente, à quelques secondes près (verdict: inutile pour notre besoin):bookmarks, [0,61s] pour lesdiaries, [-1d, 41s] pour lesposts, étrange mais pas important ici, [0,4041s] pour lestrackers, [0, 1s] pour leswiki_pages)newsetpolls)comments.created_at) : la date n'est pas modifiée en suite. Par contre tout le monde ne commente pas. Verdict: Utile pour repousser la fermeture faute de mieux.taggings.created_at) : la date n'est pas modifiée en suite. Par contre tout le monde n'étiquette pas. A priori pas éligible au droit d'auteur, donc pas forcément utile de conserver l'association auuser_idsi on peut autrement supprimer le compte (on réaffecte à Anonyme). Verdict: Utile pour repousser la fermeture faute de mieux.categories.created_at,categories.updated_at,forums.created_at,forums.updated_at,pages.created_at,pages.updated_at,sections.created_at,sections.updated_at)bookmarks.updated_at,diaries.updated_at,polls.updated_at) et ne renseignent pas sur l'activité du compte concernéposts.updated_at,trackers.updated_at,poll_answers.created_at,poll_answers.updated_at,news.submitted_at) donc pas utilisable non plus iciwiki_pages.updated_at,news.updated_at)nodes.updated_at,nodes.last_commented_at: influencé par le score, le dernier commentaire, etc. Verdict: inutile pour notre besoinlinks.created_at,links.updated_at: autant se baser sur la dépêche…friendly_id_slugs.created_atnous dira juste si le compte ou l'équipe du site a eu besoin de renommer quelque chose (verdict: inutile pour notre besoin)logs.created_atnous dira qui a fermé le compte et quand (verdict: utile, mais juste pour les comptes fermés)oauth_access_grants.created_at,oauth_access_grants.revoked_at,oauth_access_tokens.created_at,oauth_access_tokens.revoked_at(verdict: utile pour repousser la fermeture faute de mieux)oauth_applications.updated_at: a priori ça ne va pas forcément nous aiderusers.created_atetaccounts.created_ataccounts.confirmed_atetaccounts.confirmation_sent_at(verdict: si les deux sont NULL et le rôleinactive, alors on peut virer ; mais si le rôle est différent, on n'apprend rien)accounts.updated_at,reset_password_sent_at: changement de rôle, changement de karma, changement de feuille de style, d'adresse de courriel, demande de renvoi de courriel, se loguer, modifier les préférences -> verdict: inutileusers.updated_at: modifier son nom, ses adresses de site perso/mastodon, son avatar, sa signature -> a priori rien qui ne soit modifiable par un autre compte, et rien qui bouge après la fermeture du compte. Verdict: utile pour repousser la fermeture faute de mieuxaccounts.remember_created_atne marche que pour la fonctionnalité "se souvenir de moi"accounts.current_sign_in_at(forcément mieux queaccounts.last_sign_in_at) ne marche que si les sessions sont oubliés côté navigateur# L'éléphant dans le couloir
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : première quinzaine de février 2023. Évalué à 6.
Et j'ai bien sûr oublié de mentionner le changement à venir des règles de pérennité des comptes et des données à caractère personnel alors que ça a occupé un peu de temps en écriture et discussion… (avec la préparation de l'AG).
[^] # Re: Attention à l'URL
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Antarctique - La superficie de la banquise du pôle Sud n’a jamais été aussi petite . Évalué à 3.
Corrigé, merci.
[^] # Re: Comptes inactifs
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 4.
Il y a une solution simple et habituellement utilisée je dirais: tu fais des CGU, tu imposes l'acceptation, et si tu n'acceptes pas après un certain délai, alors c'est que le compte est inactif.
[^] # Re: coquille sur un lien
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Entretien avec Stephane-D à propos du SGDK. Évalué à 3.
Corrigé, merci.
[^] # Re: le lien "traductions" est pas bon
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Freedroid-RPG v1 est sorti. Évalué à 9.
Brut'Omates de Super Sécurité pour garder l'acronyme ?
[^] # Re: le lien "traductions" est pas bon
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Freedroid-RPG v1 est sorti. Évalué à 4.
Corrigé, merci.
[^] # Re: Comptes inactifs
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 4.
Les timestamps _at ne sont pas en eux-mêmes des DCP.
Et la mesure de l'inactivité sera bien via le champ
updated_attechniquement parlant.[^] # Re: Adresses IP
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 5. Dernière modification le 14 février 2023 à 16:57.
Connexion courante et connexion précédente.
Les durées de conservation des logs de connexion est une longue bataille législative au niveau national et européen sinon, avec ces allers et retours…
https://www.cnil.fr/sites/default/files/atoms/files/recommandation_-_journalisation.pdf (6 mois à un an)
[^] # Re: Comptes inactifs
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 3.
Si, l'adresse de courriel sera supprimée après un an si tu fermes ton compte ou si l'équipe fermes ton compte, et après 3 ans d'inactivité et 1 an sinon.
[^] # Re: Comptes fermés et adresse e-mail
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 7. Dernière modification le 14 février 2023 à 16:46.
Le cas se présente de temps en temps, mais rarement : suivant les cas, une ancienne signature, le texte présent dans un contenu ou commentaire qui référence un lien vers un site perso ou un autre site, une ancienne version d'un contenu/commentaire dans un archiveur web, etc. On a déjà fait des réattributions.
La même question se pose potentiellement dans bien d'autres cas (tous aussi rares actuellement pour nous, mais pas inexistants) : comment convaincre/prouver que X est décédé et que son compte doit être fermé, que Y a changé de nom ou de sexe, que
toto123@vieuxdomain.comde 1998 est bien la même personne que letoto123@vieuxdomain.comde 2023, etc. L'adresse de courriel n'est pas une solution miraculeuse non plus, mais ça reste bien pratique pour un « compte sur un simple site web ».[^] # Re: Adresses IP
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 4.
Boulette de ma part : c'est bien adresse IP de connexion courante et adresse IP de dernière connexion. Je corrige la dépêche ce sens. Merci.
Finalité : « avoir des données d’identification (…) pour gérer les litiges éventuels (par exemple, le manifestement illégal, le prétendument illégal) ou le cadre légal (par exemple, la modification des données de son propre compte, le droit d’auteur) ; » et « détecter des éventuels abus (comptes multiples, etc.). »
Les IP des logs web sont hors de la « base active », et ne sont pas forcément reliables à un compte (accès anonyme, IP commune à de multiples comptes, etc.). Les logs web sont conservés un an actuellement.
[^] # Re: Comptes inactifs
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 5.
Non, ce n'est pas uniquement la dernière « connexion ». Ça peut être un ajout de commentaire, d'étiquette, de contenu, une édition des préférences du compte, etc. Une consultation ou modification du site faite avec le compte ?
Idéalement non, le monde du courriel est suffisamment détérioré pour que ça soit pénible d'envoyer des milliers de courriel sans être classé spammeur, en devant gérer les erreurs variées, etc. La première application va concerner des comptes particulièrement anciens (certains auront plus de 10 ans d'inactivité par exemple).
Oui c'est indiqué dans la dépêche d'ailleurs. « La principale différence concerne la conservation de l’adresse de courriel pour permettre une réouverture du compte et un envoi de nouveau mot de passe en cas de demande. »
[^] # Re: Comptes fermés et adresse e-mail
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Règles de pérennité des comptes LinuxFr.org et données à caractère personnel. Évalué à 6.
C'est une suppression de la base active, ça laisserait la possibilité d'un archivage intermédiaire par exemple. Cf https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees
Ensuite ça reste un compromis / arbitrage entre la minimisation des données demandées par le RGPD et la durée du droit d'auteur en dizaines d'années ( et les coûts et la complexité pour une structure associative aussi). On parle d'une période intermédiaire de 1 an ou 3+1 ans, pendant laquelle la personne n'a pas réagi. Et au final, c'est à la personne qui a fermé son compte ou laissé son compte expiré de montrer qu'elle est bien cette personne… (de même que c'est à la personne qui a perdu son mot de passe et laissé une adresse de courriel invalide sur son compte de prouver qu'elle est bien cette personne). Cela ne compromet pas totalement mais clairement ça rendrait plus difficile.
[^] # Re: Et le libre ?
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Is software getting worse?. Évalué à 4.
La montée de questions écologiques peut jouer là-dessus : optimisation des chaînes CI/CD pour éviter de brûler une forêt à chaque commit, moins de ressources nécessaires à l'exécution (processeur, mémoire, batterie, disque, réseau, etc.). À condition que ça devienne un critère plus ou moins mesuré et pris en compte, évidemment.
[^] # Re: Dans le même genre
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 4.
Ouais y en a marre du porno dans les corbeilles a-t-il déclaré. Je vais aussi lancer un
rm ********pour supprimer les mots de passe qui traînent aurait-il ajouté. Avant de conclure oups, la boulette.[^] # Re: clustering et Single System Image
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche DragonFlyBSD 6.2 et 6.4. Évalué à 3.
Corrigé, merci.
[^] # Re: Deux huitième épisodes ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de janvier 2023. Évalué à 3.
Et de 3
[^] # Re: Deux huitième épisodes ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de janvier 2023. Évalué à 3.
Et de deux: