Expiration des comptes et des données
C'est un sujet que nous avons évoqué les dernières années en le conservant en dernier recours. Il est revenu récemment sous l'angle de Matrix (synapse#115 (closed)), et il continuera de revenir tant que nous sommes de plus en plus gros, même tout doucement : faut-il conserver les comptes inactifs et les données associées ? Le débat est simplement entre la durabilité des données comme un de nos engagements d'hébergeur d'une part ; les performances, le coût des services et le respect le droit à l'oubli d'autre part.
Dans l'échange récent autour de Matrix, le retour général était plutôt pour la suppression, sous des conditions à discuter et à voter. J'ouvre donc ce ticket pour instruire le sujet. Objectif : converger d'ici mi-juillet pour voter les règles de suppression ensuite.
La première proposition est de fonder des règles génériques par familles de données, puis de préciser éventuellement des règles alternatives pour certaines services. Je propose les catégories suivantes, je vous laisse la main pour les premiers échanges sur des durées entendables.
- Les comptes, c'est-à-dire le moyen d'authentification sur TeDomum, principalement via Hiboo. Non utilisé depuis un temps, il est à peu près sûr que l'utilisateurice ne reviendra pas, sans lien spécialement avec les données publiées.
- Les données privées, c'est-à-dire capitalisées sur nos services mais accessibles à personne d'autre que l'utilisateurice ou les personnes avec qui iel aura partagé explicitement, par ex. les données Nextcloud, Vaultwarden, les MP Mastodon, salons privés Matrix, etc.
- Les données publiques « historiques », c'est-à-dire datées et inscrites dans un historique daté, par exemple une timeline Mastodon ou bien un historique de messages sur Matrix sans nécessairement englober le profil intégral ou le salon lui-même.
- Les données publiques structurelles, c'est-à-dire qui fondent un cadre, qui ne périment pas nécessairement car pas datées, par exemple des images uploadées sans savoir à quoi elles servent, un profil sans savoir s'il est consulté, un salon lui-même indépendamment de ses messages.
Chaque catégorie peut concerner des données dont nous sommes le point de référence, d'autres dont nous n'hébergeont qu'un cache, pour les performances ou en cas de défaillance du point de référence. La durée indiquée varie en fonction.
Evidemment, la règle par défaut peut être interprétée en fonction de ce que propose la solution technique. J'essaie d'illustrer par quelques cas de figure. Imaginons que nous indiquions conserver les données historiques jusqu'à X jours après leur publication, et les données structurelles jusqu'à Y jours après leur dernière activité mesurée. Sur Mastodon cela pourrait militer pour supprimer les toots par défaut après X jours, et les profils sans nouveau toot après Y jours. Nous pourrions constater que Mastodon est mauvais pour configurer une suppression par défaut des toots à X jours, et nous nous contenterions de la règle de suppresion des profils par limitation technique.
Appliquée à Matrix, cette même règle indiquerait la suppression par défaut des messages après X jours et des salons inactifs après Y jours. Pour la suppression des messages, nous pourrions configurer une règle de suppression automatique s'appliquant aux nouveaux salons. Nous pourrions aussi considérer que l'approche est inadaptée aux salons Matrix privés qui relèvent des données privées à conservation plus longue, mais ne pas réussir à distinguer les salons privés des autres avec une règle simple.
La discussion est lancée, vous pouvez également venir en parler sur #home:tedomum.net sur Matrix, et je synthétiserai ici.