En février 2023, nous annoncions la mise en place d’une durée de conservation des données à caractère personnel (DCP) sur LinuxFr.org, avec à partir du 28 juin 2023 :

• fermeture des comptes inactifs pendant trois ans et suppression de leurs données conservées inutiles au service ;
• suppression des données associées inutiles au service pour les comptes fermés depuis plus d’un an.

L’aide du site explique :

• Quelles sont les données à caractère personnel (DCP) traitées par le site ?
• Quelles sont les données sans caractère personnel relatives au compte traitées par le site ?
• Quelles sont les données inutiles au service qui sont supprimées des comptes fermés ?

Depuis le 31 mai 2023, une information de date de dernière activité est associée à chaque compte. Ajoutons que depuis septembre 2023 l’accès à cette information est aussi réduite au besoin du service (on peut connaître l’info de son propre compte ; les admins ont seulement besoin de savoir si la dernière activité date de moins d’un mois, d’un an, trois ans ou plus, en raison des règles précitées).

Nous voici donc un an après, et cette partie de la règle s’applique donc pour la première fois. Nous détaillerons les effets dans la seconde partie de la dépêche.

Sommaire

• Script de minimisation des données et semaine normale
• Effet « 1 an »
• Ça change quoi ?
• Et après ?

Script de minimisation des données et semaine normale

La suppression des données inutiles au service repose actuellement sur un script de minimisation externe, lancé manuellement. Une des raisons de l’aspect manuel est notamment le fait que l’on n’avait pas encore passé la première année, qui marque un seuil comme nous le verrons plus tard.

La précédente exécution du script ayant eu lieu le 19 mai 2024 à 11h (Paris), voyons ce que ça donne sur 12 jours et quelques heures :

Started at vendredi 31 mai 2024, 22:19:15 (UTC+0200)
Dry run mode
13 inactive accounts never used to purge
0 users to minimize
0 accounts to minimize because inactive and not seen since 1 year
0 active accounts not seen since 3 years to inactivate and minimize
12 users without comments/contents to purge
12 accounts to purge
6 logs to purge
12 friendly_id_slugs to purge
0 taggings to purge
0 oauth_access_grants for an oauth_application to purge
0 oauth_access_tokens for an oauth_application to purge
0 oauth_applications to purge
0 oauth_access_grants to purge
0 oauth_access_tokens to purge
0 deleted comments to minimize
0 comments from non-public contents to purge
0 taggings from non-public contents to purge
0 wiki_versions from non-public wiki_pages to purge
0 slugs from non-public wiki_pages to purge
0 non-public wiki_pages to purge
0 slugs from non-public trackers to purge
0 non-public trackers to purge
0 slugs from non-public posts to purge
0 non-public posts to purge
0 poll_answers to from non-public polls to purge
0 slugs from non-public polls to purge
0 non-public polls to purge
0 slugs from non-public bookmarks to purge
0 non-public bookmarks to purge
0 slugs from non-public diaries to purge
0 diaries converted into non-public news to purge
0 non-public diaries to purge
1 news_versions from non-public news to purge
10 paragraphs from non-public news to purge
0 links from non-public news to purge
1 slugs from non-public news to purge
1 non-public news to purge
1 non-public contents to purge

En fonctionnement pré-« 1 an », on a seulement quelques comptes créés mais jamais utilisés à nettoyer (ainsi que tout ce qui y est associé, donc les comptes « accounts », les individus « users », les logs associés « logs » s’il y en a, les raccourcis pour les adresses du site « slugs ») et les contenus, commentaires et étiquetages associés non publics donc non visibles qui ne sont plus nécessaires. On parle donc d’une poignée de comptes et autres par semaine.

Effet « 1 an »

Quelques heures plus tard, le résultat n’est plus du tout le même :

Started at Sat Jun 1 10:55:34 CEST 2024
Dry run mode
15 inactive accounts never used to purge
250 users to minimize
2616 accounts to minimize because inactive and not seen since 1 year
0 active accounts not seen since 3 years to inactivate and minimize
1412 users without comments/contents to purge
1412 accounts to purge
2285 logs to purge
1412 friendly_id_slugs to purge
6 taggings to purge
0 oauth_access_grants for an oauth_application to purge
0 oauth_access_tokens for an oauth_application to purge
0 oauth_applications to purge
15 oauth_access_grants to purge
47 oauth_access_tokens to purge
147 deleted comments to minimize
98 comments from non-public contents to purge
288 taggings from non-public contents to purge
0 wiki_versions from non-public wiki_pages to purge
0 slugs from non-public wiki_pages to purge
0 non-public wiki_pages to purge
0 slugs from non-public trackers to purge
0 non-public trackers to purge
166 slugs from non-public posts to purge
165 non-public posts to purge
10 poll_answers to from non-public polls to purge
2 slugs from non-public polls to purge
2 non-public polls to purge
46 slugs from non-public bookmarks to purge
46 non-public bookmarks to purge
27 slugs from non-public diaries to purge
0 diaries converted into non-public news to purge
27 non-public diaries to purge
139 news_versions from non-public news to purge
1278 paragraphs from non-public news to purge
33 links from non-public news to purge
66 slugs from non-public news to purge
61 non-public news to purge
301 non-public contents to purge

On a certes gagné 2 comptes jamais utilisés de plus à nettoyer, mais surtout on va minimiser plusieurs milliers de comptes et supprimer ou minimiser des centaines de contenus, commentaires et étiquetages. C’est le moment où la main ne doit pas trembler et où l’on doit avoir confiance dans le script de nettoyage et dans nos sauvegardes de la base de données, parce qu’il va falloir l’exécuter pour de vrai, et pas juste en mode « dry run » ou répétition, test à vide.

En pratique, quelques soucis très mineurs rencontrés sur la grosse transaction faite en base de données : un problème d’ordre de suppression et l’impossibilité de mettre une chaîne vide pour l’adresse de courriel, car il y a un index dessus qui demande l’unicité (une adresse .invalid propre à chaque compte sera donc utilisée).

Après l’exécution, si on relance le script, on se retrouve juste avec le nombre de comptes encore ouverts mais sans activité depuis un an :

Started at Sat Jun 1 13:30:16 CEST 2024
Dry run mode
0    inactive accounts never used to purge
0    users to minimize
905  accounts to minimize because inactive and not seen since 1 year
(…)

Ça change quoi ?

Regardons les statistiques des comptes avant et après le nettoyage « 1 an » (les évolutions ont été mises en visibilité avec un point rouge) :

Interprétation : il s’agit des états des comptes par ordre d’identifiant en base de données (temporellement dans l’ordre de création), regroupés par paquets de 10 000 consécutifs. Quasiment pas de modification sur les comptes très anciens (il y en a beaucoup moins), et les changements se concentrent sur les comptes des dernières années. On a moins de comptes fermés après (on a pu en purger) et donc plus de comptes purgés (c’est-à-dire d’identifiants qui ne sont plus utilisés en base). Et le reste des changements correspond aux visites nominales du site.

On peut comparer les statistiques juste avant :

53667 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
33216 comptes
2205 comptes utilisés sur le site au cours des trois derniers mois avec 20.2 jours de moyenne sans visite et 25.3 jours d’écart‑type
10 comptes en attente
2809 comptes fermés

Et les actuelles (au moment de la rédaction de cet article) :

51943 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
31492 comptes
2208 comptes utilisés sur le site au cours des trois derniers mois avec 20.0 jours de moyenne sans visite et 25.3 jours d’écart‑type
1 compte en attente
1089 comptes fermés

Nous avons aussi réoptimisé les tables de la base de données (enfin on a dit à la base d’optimiser ce qu’elle pouvait avec un OPTIMIZE TABLE quoi). Ça devrait avoir entre une absence d’effet et un effet imperceptible sur les performances, a priori.

Et côté sauvegarde, on est passé d’un dump compressé gzip de 2 088 253 834 octets avant à 2 086 608 391 octets après, soit un gain faramineux de 0,08 %, bref rien.

Et après ?

Une fois « 1 an » passé, on aura chaque semaine les quelques comptes créés mais jamais utilisés à nettoyer, ainsi que les quelques contenus, commentaires et étiquetages associés non publics non nécessaires. Mais aussi les comptes qui auront atteint l’année d’inactivité dans la semaine courante (probablement une ou deux dizaines). Et ce jusqu’aux « 3 ans ».

À partir des « 3 ans », on va commencer à fermer des comptes et il y aura encore plus de données concernées chaque semaine.

Et ensuite on aura atteint le rythme nominal de fermeture de comptes et de minimisation de données associées.

Rendez-vous pour les « 3 ans » en juin 2026 donc.

L’Association Francophone Python (AFPy) organise la PyConFR 2024 du jeudi 31 octobre au dimanche 3 novembre. Pour cette 15^e édition, nous sommes accueillis par l’UFR Mathématique et d’Informatique de Strasbourg (https://mathinfo.unistra.fr/) !

Si vous ne connaissez pas la PyConFR, c’est un évènement gratuit sur 4 jours autour du langage de programmation Python. Tout d’abord, il y a deux jours de développements participatifs (sprints), puis deux jours de conférences et ateliers.

Vous pouvez proposer un sujet de sprint, de conférence ou d’atelier jusqu’au 21 juillet. Peu importe votre niveau en Python, n’hésitez pas à proposer un sujet ! Venez parler de développement logiciel, de diversité, de communauté, faire un retour d’expérience sur un outil, présenter votre projet, un domaine d’activité…

Dans un secteur aussi masculin que le développement informatique, nous proposons aux personnes habituellement peu représentées en conférence de l’aide pour trouver un sujet, rédiger la proposition de conférence, rédiger le support de conférence et pour répéter. Vous pouvez nous contacter à l’adresse diversite@afpy.org si vous pensez en avoir besoin.

Enfin, la PyConFR est entièrement financée par les sponsors. Si vous connaissez des sponsors potentiels, n’hésitez pas à leur parler de l’évènement !

Sur LinuxFr, on préfère les IN (intelligences naturelles) aux IA (intelligences artificielles). Las, nous ne sommes pas les seuls à constater un début d’envahissement du site par les IA. Voici ce qui vous (nous) attend dès que ça sera mis en production pour essayer d’y pallier.

Les faits

Le constat est le suivant : non seulement les IA spammeuses commencent à polluer le site, mais, en prime, au niveau rédactionnel, elles se montrent plus futées que les vulgaires spammeurs en mode SEO auxquels on était habitués jusqu’à présent. De facto, leur prose est parfois difficile à différencier de celle des autres intelligences, naturelles, elles, qui interagissent sur le site.

Rédigé ou pas par des IN, le spam reste du spam.

La solution retenue actuellement

Heureusement, d’autres que nous se sont penchés sur la question et il existe des critères permettant de faire la différence entre une IA et une IN. À part le test de Turing, s’entend. Après quelques hésitations, nous sommes arrivés à une solution qui devrait, en outre, répondre aux prochains textes législatifs et réglementaires dont l’objectif est de réguler cette zone de non-droit qu’est Internet.

Dès que ça sera mis en production, les personnes qui accèdent au site sans être connectées auront donc droit à cette fenêtre modale qui nous permettra de séparer le bon grain (les IN) de l’ivraie (les IA). On est franchement désolés d’en arriver là, mais on n’avait pas vraiment le choix. Merci à l’avance de votre compréhension.

La problématique et d’autres solutions envisageables

Le spam sur un site web peut avoir de nombreuses conséquences négatives, notamment la dégradation de l’expérience utilisateur, la perte de crédibilité et de confiance des utilisateurs, et la diminution du trafic sur le site. En outre, le spam peut également entraîner des problèmes de sécurité, tels que des attaques par déni de service ou l’infection des visiteurs par des logiciels malveillants.

Pour protéger le site web LinuxFr.org contre le spam, il est nécessaire de mettre en place des mesures techniques restrictives et contraignantes. Ces mesures comprennent l’utilisation de captcha, la validation des adresses IP, la limitation du nombre de publications par utilisateur, la modération automatique des commentaires, et la mise en place de filtres anti-spam.

Ces mesures permettent de limiter la capacité des spammeurs à envoyer du contenu indésirable sur le site, tout en préservant la facilité d’utilisation pour les utilisateurs légitimes. Bien que ces mesures puissent être contraignantes pour les utilisateurs, il est essentiel de les mettre en place pour garantir la sécurité et la fiabilité du site. En mettant en place ces mesures, LinuxFr.org peut protéger sa réputation et maintenir la qualité de son contenu, tout en offrant une expérience utilisateur optimale à ses visiteurs.

Dans un second temps, des ajustements seront faits pour :

1. Renforcer les protocoles de sécurité pour limiter les accès non autorisés et renforcer la protection des données des utilisateurs.
2. Mettre en place un système de validation stricte pour l’inscription des nouveaux membres afin d’éviter les trolls et les spams.
3. Limiter la publication de contenus sensibles ou offensants en mettant en place un système de modération plus strict.
4. Renforcer les mesures anti-piratage pour protéger les contenus et les informations confidentielles du site.
5. Mettre en place un système de surveillance des activités des membres pour détecter et prévenir les comportements inappropriés ou dangereux.
6. Renforcer les règles de confidentialité et de protection des données personnelles des utilisateurs en conformité avec les réglementations en vigueur.
7. Mettre en place des audits de sécurité réguliers pour garantir la fiabilité et l’intégrité du site et de ses serveurs.
8. Mettre en place un système de sauvegarde automatique des données pour éviter toute perte d’informations en cas de problème technique.
9. Renforcer la sécurité des transactions en ligne pour protéger les données financières des utilisateurs.
10. Mettre en place des formations régulières pour sensibiliser les membres aux bonnes pratiques en matière de sécurité informatique.

Il est essentiel de trouver un équilibre entre la sécurisation absolue des données et la préservation totale de la vie privée et de la liberté d’expression sans limite des utilisateurs.

Dans un troisième temps, les retouches finales seront apportées :

• Créer un champ de force magnétique autour du datacenter pour éloigner les astéroïdes et les débris spatiaux.
• Utiliser des hologrammes pour créer des illusions d’optique afin de détourner l’attention des ennemis potentiels.
• Utiliser des lasers géants pour dévier les ouragans avant qu’ils n’atteignent les serveurs.
• Mettre au point une machine à voyager IPoT dans le temps pour aller régler les problèmes du passé avant qu’ils ne deviennent des catastrophes.
• Créer des capsules de sommeil ultra-efficaces pour permettre aux administrateurs de se reposer en seulement quelques minutes.
• Utiliser des mini-robots volants pour surveiller et protéger le réseau physique d’accès au site.
• Développer une technologie de téléportation pour se déplacer instantanément d’un endroit à un autre pour les interventions.