Benoît Sibaud a écrit 9300 commentaires

Spammeur viré par la modération

Il existe des « privacy challenges », c'est-à-dire des compétitions d'attaque/défense de données anonymisées : les équipes proposent des jeux de données anonymisées et essaient de désanonymiser/réidentifier les données des autres équipes.

podcast en français NoLimitSecu sur le sujet https://www.nolimitsecu.fr/privacy-challenge/

avec un 'e', car dû à George Boole

la table badges devrait être supprimée (elle est vide)

fait

si on connaît mal les comptes actifs, alors on a un souci sur les statistiques des utilisateurs

à défaut, maintenant on parle de « comptes valides et s’étant connectés au cours des trois derniers mois » plutôt que de « comptes valides et utilisés au cours des trois derniers mois » dans les statistiques

Corrigé, merci. Actuellement : 49 comptes avec un champ Adresse Mastodon non vides, soit 3% des comptes valides et utilisés au cours des trois derniers mois. Cf https://linuxfr.org/statistiques/users#stats_infosperso

Fait (d'autant que c'était mes étiquetages…)

« Celui qui ne me hue! pas a rendu le mors » disait son équidé de cheval.

Belle longévité pour le logiciel et on peut apprécier aussi la persévérance dans la communication sur les infos projet et les publications de version via LinuxFr.org. Bravo.
Cf https://linuxfr.org/tags/cremecrm/public

Un logiciel pour tous les blaireaux.

Faut rajouter « , sait-il ? » à la fin pour clarifier.

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.

Voilà publié… https://linuxfr.org/news/agenda-du-libre-pour-la-semaine-8-de-l-annee-2023

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.

En français, 'plus' veut dire 'encore' ou 'stop' suivant le contexte.

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."

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 ?

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
  

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).

Corrigé, merci.

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.

Corrigé, merci.

Brut'Omates de Super Sécurité pour garder l'acronyme ?

Corrigé, merci.

Les timestamps _at ne sont pas en eux-mêmes des DCP.

Et la mesure de l'inactivité sera bien via le champ updated_at techniquement parlant.

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)