Thomas Touhey

Sur le web d’aujourd’hui, les contenus passent petit à petit d’une logique centralisée avec les silos tels que les GAFAM ou même beaucoup de petites plateformes qui se veulent être l’alternative, bien qu’elles suivent la même logique et tomberaient, si elles grossissaient trop, dans les mêmes écueils, à une logique décentralisée, où les contenus sont fédérés entre la plateforme sur laquelle a été créé le contenu aux autres où se trouvent les consommateurs potentiels. Mais avec cette évolution se posent de nouveaux problèmes, dont notamment la suppression de contenu.

En effet, pour beaucoup des technologies de décentralisation de contenus d’aujourd’hui, qu’il s’agisse d’ActivityPub ou même de technologies plus primitives de syndication de contenus tels que les flux RSS ou Atom, beaucoup d’efforts vont dans la diffusion de contenus de façon à économiser le réseau et peu dans la suppression de contenus. Une fois un contenu envoyé, il est possible de supprimer la copie locale du contenu mais impossible d’ordonner aux destinataires précédents de supprimer leur contenu ; on suppose néanmoins qu’ils soient de bonne foi, comment leur dire alors qu’un contenu est supprimé ?

La logique des flux RSS ne rend pas cela réellement possible : en effet, ces flux sont simplement des listes récupérées périodiquement, et ne sont pas nécessairement complets, ils peuvent par exemple ne contenir que les dix dernières entrées. La suppression d’un élément du flux n’étant pas considérée comme une suppression de l’article, la copie locale est conservée.

Pour ActivityPub en revanche, c’est une autre paire de manches. Pour commencer, on oublie les partages et on ne prend que le serveur source et les serveurs abonnés. Le serveur source envoie son contenu mais l’utilisateur choisit de supprimer son contenu, le serveur source envoie alors une pierre tombale (tombstone) pour signifier que le statut est supprimé. Dans le cas d’un serveur qui viendrait après suppression demander ce statut-là en particulier, il recevrait également cette pierre tombale en réponse. C’est la même idée qu’avec les clés GPG : pour en révoquer une, on diffuse une révocation le plus possible.

Mais à moins d’être abonné ou de demander ce statut, on ne sait pas forcément que ce statut a été supprimé. Et il est hors de question de vérifier tous les statuts régulièrement : à titre d’exemple, mastodon.social héberge à lui tout seul plus de 6,5 millions de statuts à l’heure où j’écris cet article.

Pour illustrer ce problème, j’ai pu voir une discussion intéressante récemment : lors d’un partage sur Mastodon, actuellement, le serveur qui cherche à partager va d’abord sur le serveur source pour voir si le statut existe encore et pour récupérer ses données. Cela peut représenter une certaine charge pour ce serveur source, et si un utilisateur auquel plus de 4000 serveurs sont abonnés partage le statut d’un utilisateur auto-hébergé, c’est plus de 4000 serveurs qui viendront faire la requête en même temps à un serveur qui le supportera difficilement. C’est pour cela que, dans une discussion entre le mainteneur de Mastodon et un autre développeur, le premier a dit vouloir partager directement les statuts en utilisant des signatures comme preuve comme quoi le serveur source a bien émis ce statut pour alléger cette charge. Seulement, cette signature reste valide même si le contenu est supprimé sur le serveur source, et les utilisateurs d’un serveur tiers, ne pouvant pas savoir que le contenu est supprimé, peut permettre à ses utilisateurs de partager ce statut fantôme.

Si supprimer est une tâche si ardue, on peut alors se demander pourquoi vouloir le faire malgré l’idiome « Internet n’oublie rien ». Après tout, des technologies comme IPFS (autrefois promu comme le « Web permanent ») ou la Wayback Machine ne permettent-elles pas d’oublier le moins possible ? On entre dans un raisonnement éthique voire légal sur le droit à l’oubli, où l’on peut sans doute citer la RGPD entre autres, mais c’est hors du cadre de cet article, je vous laisse donc là ;)