Les hackers ont mis aux enchères les données de la plus grande boîte d’enchères
Un groupe de hackers a mis aux enchères le 3 juin dernier les données personnelles des clients de Christie's, un géant de la vente d'art.
Un groupe de hackers a mis aux enchères le 3 juin dernier les données personnelles des clients de Christie's, un géant de la vente d'art.
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 :
L’aide du site explique :
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.
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.
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
(…)
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.
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.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Un groupe de pirates informatiques se faisant appeler ShinyHunters dit avoir récupéré des données personnelles issues de Ticketmaster, une plateforme spécialisée dans la vente de tickets pour du sport, des concerts et des spectacles. 560 millions d'internautes seraient touchés.
Un groupe de pirates a publié les données de l’aéroport de Pau-Pyrénées, l’école de commerce de Pau et du campus numérique de la ville. Les informations contiennent des documents administratifs ainsi que des informations sur les employés.
Cet article a été réalisé en collaboration avec Bitdefender
Est-ce un message d'un véritable livreur ou une énième arnaque ? Une véritable amende ou un scam ? Si vous avez un doute, demandez donc au nouveau chatbot gratuit Scamio de Bitdefender ce qu’il en pense.
Cet article a été réalisé en collaboration avec Bitdefender
Il s’agit d’un contenu créé par des rédacteurs indépendants au sein de l’entité Humanoid xp. L’équipe éditoriale de Numerama n’a pas participé à sa création. Nous nous engageons auprès de nos lecteurs pour que ces contenus soient intéressants, qualitatifs et correspondent à leurs intérêts.
Cet article a été réalisé en collaboration avec Bitdefender
Vous avez un doute sur la fiabilité d’un message ? Demandez donc au nouveau chatbot gratuit Scamio de Bitdefender ce qu’il en pense.
Cet article a été réalisé en collaboration avec Bitdefender
Il s’agit d’un contenu créé par des rédacteurs indépendants au sein de l’entité Humanoid xp. L’équipe éditoriale de Numerama n’a pas participé à sa création. Nous nous engageons auprès de nos lecteurs pour que ces contenus soient intéressants, qualitatifs et correspondent à leurs intérêts.
Des hackers ont infiltré le site de formation de l'influence masculiniste Andrew Tate. Les données de près d'un million d'utilisateurs sont en ligne.
Dell informe ses clients d'une fuite de données, tandis qu'un pirate affirme détenir les informations de 49 millions de clients de l'entreprise.
Aleksanteri Julius Kivimäki a été condamné par la justice finlandaise à six ans de prison. Ce cybercriminel recherché par Europol avait été arrêté par hasard par la police française.
Présentation rapide de RootDB, une application auto-hébergeable open-source (AGPLv3), permettant de générer des rapports à base de requêtes SQL.
Pour les besoins d'un client, il fallait que je génère rapidement des statistiques d'usage diverses et variées (à bases de tableaux et graphiques), à partir de plusieurs base de données relationnelles classiques et que j'intègre ces rapports dans un backoffice.
Le premier réflexe fut de me tourner vers une solution que j'ai utilisée pendant une dizaine d'années auparavant et qui se nomme MyDBR. Cela répondait parfaitement à son besoin tout en étant abordable. MyDBR, bien maitrisé, permet de faire énormément de choses, mais l'interface est vraiment datée et l'accès aux fonctionnalités des bibliothèques graphiques se fait par l’intermédiaire de wrappers en SQL.
J'ai cherché des alternatives, auto-hébergeables, simples à mettre en place, maintenues et avec la même logique pour la création de rapport mais je n'ai pas trouvé mon bonheur. Il y a, évidemment, pleins de solutions qui existent mais il y avait toujours quelque chose qui n'allait pas après essai, que ce soit dans la manière de générer des rapports ou bien les pré-requis, parfois compliqués, pour l'hébergement.
D'ou l'idée de créer, avec un collègue, notre propre solution de reporting - parce que pourquoi pas, finalement.
Ce projet n'était pas open-source à la base et nous pensions simplement vendre des licences d'utilisation.
Sauf qu’aujourd’hui beaucoup de monde utilise le cloud, et ce dernier vient avec ses solutions intégrées de reporting, limitant de fait l'intérêt de ce genre de projet. Pour faire bref, je reste convaincu que tout le monde n'est pas sur le cloud et que ce genre de solution peut encore intéresser quelques personnes.
À cause des doutes sur la pertinence même du projet, je n'ai jamais sérieusement cherché du financement, ce qui ne m'a jamais permis d'être à temps plein dessus. Nous avons donc mis du temps avant de produire quelque chose d'exploitable dans un environnement de production : un an et demi environ.
À cela s'ajoute le fait que ce projet n'existerait pas sans toutes les briques open-source sur lesquelles il se base. Et comme c'est l'open-source qui me fait vivre depuis un certain nombre d'années, il me semblait finalement bien plus naturel de rendre ce projet open-source (licence AGPLv3) que d'essayer de le vendre en chiffrant le code source.
Étant familier du SQL et du JavaScript, nous voulions avoir une solution qui ne mette pas de bâtons dans les roues du développeur, à savoir :
Ce choix de préférer un environnement de développement de rapport orienté développeur est assumé, d'où le nom du projet.
Je ne vais pas vous présenter toutes les fonctionnalités car le site web principal et l'instance de démonstration les présentent déjà correctement. Je vais donc plutôt mettre en avant les spécificités du projet.
Les requêtes SQL peuvent prendre du temps à tourner, surtout si les tables ne sont pas correctement optimisées. Par conséquent l'interface repose lourdement sur les websockets afin d'éviter les problèmes de timeout. Quand un rapport est exécuté, l'exécution des différentes requêtes est dispatchée de manière asynchrone et les vues affichent des résultats uniquement quand les données arrivent sur le websocket du rapport.
D'une manière générale toute l'interface est rafraichie par websocket.
Nous donnons accès à Chart.js ou D3.js, sans limitation, sans wrapper. Il est donc possible de se référer directement à la documentation officielle de ces deux bibliothèques.
Nous aimons bien les menus. :)
C'est simple, élégant et permet d'accéder à beaucoup d'options de manière claire.
L'interface repose sur une barre de menu principale dynamique et une barre d'onglets dans lesquels s'affiche les différentes parties de l'application. Il est donc possible d'ouvrir plusieurs rapports (ou le même) dans le même onglet du navigateur web.
Il existe deux niveaux de cache :
Il est très facile de générer ses propres paramètres afin de filtrer les rapports, que ce soit sur une plage de date, une liste d'options sortie d'une base de données, des cases à cocher etc.
Que ce soit avec Chart.js ou bien un tableau, vous pouvez créer des liens entre vos rapports ou bien sur le même rapport pour faire des rapports de type drill-down.
Côté API, RootDB est une application Laravel qui fonctionne sur du PHP en version 8.2.x (voir 8.3.x, mais pas encore bien testé) et utilise Memcached pour la gestion du cache.
Le serveur de websocket est propulsé par Laravel Reverb.
Côté Frontend, il s'agit d'une application React classique, en TypeScript, qui utilise PrimeReact pour la suite de composants prêt-à-l'emploi.
Concernant les fonctionnalités que nous aimerions mettre en place petit à petit :
Nous pouvons aider à l'utilisation, par l’intermédiaire :
Voilà, c'était une brève présentation de RootDB.
C'est un projet qui n'a pas encore été testé par beaucoup de monde, d’où cette présentation pour le faire connaitre un peu plus.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Dropbox a subi une intrusion dans ses systèmes, entraînant l'exposition de données sensibles telles que les mots de passe des utilisateurs de son option « Dropbox Sign ».
Selon une étude, la France est l'un des pays les concernés au monde par les fuites d'informations personnelles. Le nombre de mots de passe en ligne appelle à la vigilance.
Les médias allemands révèlent que la Chine a espionné le groupe automobile Volkswagen pendant cinq ans, dérobant des dizaines de milliers de documents confidentiels, dont des informations sur les véhicules électriques.