Benoît Sibaud a écrit 8961 commentaires

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)

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.

1. 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 ?

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

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

Corrigé, merci.

Et de 3

mamot.fr    4   0%
framapiaf.org   4   0%
piaille.fr  4   0% 

Et de deux:

framapiaf.org   4   0%
piaille.fr  4   0% 

Corrigé, merci.

Ce bug là est annoncé corrigé dans la version suivante 1.2.2 de yoga-image-optimizer. Cf https://github.com/flozz/yoga-image-optimizer/issues/41

mais elle a un autre souci chez moi…

$ yoga-image-optimizer images/sections/*.png 
Traceback (most recent call last):
  File "/home/oumph/.local/bin/yoga-image-optimizer", line 5, in <module>
    from yoga_image_optimizer.__main__ import main
  File "/home/oumph/.local/lib/python3.9/site-packages/yoga_image_optimizer/__main__.py", line 4, in <module>
    from .application import YogaImageOptimizerApplication
  File "/home/oumph/.local/lib/python3.9/site-packages/yoga_image_optimizer/application.py", line 20, in <module>
    from .image_store import ImageStore
  File "/home/oumph/.local/lib/python3.9/site-packages/yoga_image_optimizer/image_store.py", line 17, in <module>
    Pango.VERSION_MAJOR >= 1 and Pango.VERSION_MINOR >= 49
  File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 32, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in __getattr__
    raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Pango' object has no attribute 'VERSION_MAJOR'

Je dirais que ma version est insuffisante (1.46 installée, pour une 1.49 nécessaire) :

ii  libpango-1.0-0:amd64       1.46.2-3     amd64        Layout and rendering of internationalized text

$ grep -n Pango  ~/.local/lib/python3.9/site-packages/yoga_image_optimizer/image_store.py
7:from gi.repository import Pango
17:    Pango.VERSION_MAJOR >= 1 and Pango.VERSION_MINOR >= 49

Une typo chttps:// au lieu de https://, corrigée, merci.

Temporairement, le remplacement des 75%% par small a fait l'affaire pour permettre l'optimisation des images.

$ grep -n small ~/.local/lib/python3.9/site-packages/yoga_image_optimizer/image_store.py
272:                        '<span font_size="small" font_weight="400">↓ %i×%i px</span>'
358:                    '%s\n<span font_size="small" font_weight="400">%s%s %%</span>'

cf https://github.com/linuxfrorg/linuxfr.org/commit/c1b56b0548b0475a98b6f6be4c93eb71c03ed57a

vu les évolutions des tailles, ça vaudrait le coup de passer une petite optimisation de taille des images. Mais pour le moment mon yoga-image-optimizer boude un peu donc ça va attendre…

(yoga-image-optimizer:17258): Gtk-WARNING **: 21:06:58.905: Failed to set text from markup due to error parsing markup: Value of 'size' attribute on <span> tag on line 2 could not be parsed; should be an integer no more than 2147483647, or a string such as 'small', not '75%'