Techno-Fil et faits divers

Après mon article précédent “Le blues de l’administrateur”, j’explore ici le rôle des modérateurs dans le contexte des réseaux sociaux du fédiverse, un rôle qui n’est pas exempt d’exigences et de frustrations… mais qui est néanmoins essentiel et souvent mal compris.

Une anecdote pour commencer

Il y a très longtemps, j’ai commencé à jouer à un jeu vidéo de manière assidue à l’occasion d’un achat dans lequel il était fourni gratuitement en cadeau : “The Lord Of The Rings Online” ou LOTRO. Ce jeu est de la famille des MMORPG (jeu de rôle en ligne massivement multijoueur, pour le traduire librement en français), et j’en parle au présent car il existe toujours bien que je n’y joue plus. Pour faire court, il se déroule dans l’univers du Seigneur des Anneaux (je suis un fan inconditionnel de Tolkien et de son œuvre) et consiste en un monde ouvert persistant, dans lequel on peut interagir avec tous les autres joueurs en temps réel et réaliser des quêtes sélectionnées, allant des plus guerrières aux plus triviales et pacifiques.

Pourquoi je vous parle de cela ? Car on peut créer ou adhérer à des communautés ou confréries pour reprendre le vocabulaire du jeu , c’est-à-dire des groupements de joueurs unis dans un esprit ou un objectif commun. C’est donc ce que je fis et en sélectionnai une qui me sembla adaptée à ce que je recherchais, mû par la personnalité et la vocation de sa créatrice bienveillante.

Au début tout se passa bien. Malheureusement, y adhéra un personnage qui se révéla rapidement agressif, invasif, prenant toute la place au service d’un idéal guerrier très différent de la promesse initiale. La créatrice n’était pas conflictuelle et souffrait par ailleurs de problèmes personnels, ses lieutenants n’ont pas pris la mesure ou n’ont pas jugé la menace suffisante, de sorte que cette personne prit en quelque sorte le contrôle de cette confrérie et y imposa sa manière et son esprit néfaste. Après quelques prises de bec, je décidai que ce n’était pas ce que je recherchais et je quittai cette confrérie sans jamais en chercher une autre.

Cet épisode m’a profondément marqué car c’est un reflet miniature de la vie réelle : une personne toxique qui prend toute la place suffit à semer la zizanie et à créer un état d’esprit totalement différent de celui qui pouvait prévaloir au sein d’un groupe initialement formé. J’en garde une trace encore aujourd’hui, et une répulsion profonde envers ces personnes qui agissent toujours aux limites des règles, tout en sachant très bien ce qu’elles font pour pervertir une équipe au service de leur propre idéal maléfique.

Voilà, je trouve, une parfaite métaphore d’un réseau social, et ce que le modérateur ne doit jamais laisser s’installer : cette dérive de l’esprit d’un groupe. Je conserve contre ces excès une vigilance et une aversion, que je considère comme du devoir du modérateur d’en protéger la communauté.

L’équipe de modération

L’équipe de modération évolue au cours du temps. Chaque candidature se fait sur la base du volontariat, elle est acceptée collégialement entre les modérateurs existants et l’administrateur, par un processus de cooptation intuite personae.

L’objectif de la modération est de faire de GayFR un réseau social où chacun de ses membres se sente bien, y soit respecté et y prenne du plaisir.

Le modérateur a une responsabilité importante : par ses actions, il aide chaque utilisateur à bien utiliser le réseau social, dans le respect de ses valeurs et de ses règles ; il évite les débordements et les abus éventuels ; il influence la ligne éditoriale du site ; il en renvoie ainsi à tous une certaine image. Au-delà du cercle du réseau social, il contribue à son rayonnement et en est un ambassadeur.

Le modérateur, comme l’administrateur, contribue dans le cadre d’une action volontaire, bénévole et non rémunérée. Bien que cela puisse prendre du temps, il ne faut pas en attendre une compensation financière, mais bien plutôt la satisfaction de contribuer à la communauté et de rendre le réseau social meilleur. Il n’a pas non plus vocation à promouvoir ses intérêts personnels dans ce cadre, mais il est le bienvenu à faire connaître sa position de modérateur à l’extérieur et à promouvoir le site.

Le modérateur doit faire respecter la charte de modération, toujours avec bienveillance. Ceci nécessite tact, politesse mais aussi à certains moments, fermeté. Les règles s’appliquent à tous, administrateur et modérateurs compris.

Chaque modérateur pourra prendre seul ses décisions en accord avec son meilleur jugement, en la documentant si nécessaire dans l’interface. S’il a un doute ou besoin de se concerter avec d’autres modérateurs, il pourra le faire à son initiative. Chaque modérateur est au même niveau que les autres, le premier à se saisir d’un sujet est légitime à le faire, il n’y a pas de pré carré a priori. La communication entre modérateurs est encouragée, sans remettre en cause le principe de l’anonymat souhaité par chacun.

Aucun engagement de temps de réponse ni de volume de travail n’est demandé, et il est tout-à-fait clair pour chacun que la vie réelle amène ses exigences qui doivent toujours rester prioritaires, et peuvent entraîner une indisponibilité plus ou moins longue sans préavis ni justification à donner. Le modérateur pourra quitter ses fonctions à tout moment, sans avoir de raison à fournir.

L’esprit…

J’ai développé ce qui suit dans une publication sur Mastodon, que je reprends avec quelques ajustements.

Les gens partent, viennent, c’est la vie d’une instance et c’est très bien. Bienvenue d’ailleurs aux nouveaux, j’espère que vous vivrez une expérience agréable ici.

Car c’est bien le but : faire de ce lieu un endroit où il est plaisant d’échanger, de discuter, sans prise de tête et en toute liberté.

En toute liberté ? Oui, mais dans un cadre défini toutefois. Il y a des règles, et oui. Cela vous paraît paradoxal ? Et pourtant, ne dit-on pas que la liberté des uns s’arrête là où commence celle des autres ? Comme sur tous les autres serveurs du fédiverse, nous avons des règles que vous avez toutes acceptées en vous inscrivant. Elles sont résumées dans les douze points en bas de cette page, n’hésitez pas à vous rafraîchir la mémoire si vous le sentez utile et vous comprendrez alors à nouveau pourquoi elles sont importantes et à dire vrai, évidentes.

Malheureusement et comme dans toute société aussi petite soit-elle, il y a toujours un risque de dérive, et c’est la lourde tâche des modérateurs (dont fait partie l’administrateur que je suis) que de veiller à leur application. Nous ne contrôlons pas tout ! Seulement ce qui nous est signalé et ce qui apparaît dans le fil public, et à l’occasion, ce qui peut croiser nos regards d’utilisateurs ordinaires.

Et pour tout dire, la nécessaire conformité aux lois françaises n’est pas un gage suffisant de respect des autres, et certaines formes d’interpellations notamment vis-à-vis de personnes inconnues peuvent paraître déplacées. Vous arrêteriez un passant ou une passante dans la rue pour lui faire une blague salace ou de l’humour noir ? Non, hein ? Sur internet, c’est pareil.

Certaines personnes sont fragiles, peuvent se sentir stigmatisées, et ce type d’humour peut être perçu comme un harcèlement. Utiliser des termes homophobes « pour en désactiver la charge agressive » (je cite) peut très bien passer avec certaines personnes, pas avec d’autres. Et demander à ce que celles-ci bloquent l’auteur n’est pas conforme à l’esprit « opt-in » du fédiverse : c’est déjà trop tard, on a été exposé, certes on n’en verra pas plus mais pour certains le mal est fait.

Quand on connaît la personne, c’est différent, pour peu que celle-ci ne vous ait pas demandé d’arrêter ou n’ait pas manifesté de signe évident d’agacement devant les réponses systématiques décalées à chacune de ses publications, par exemple. Quand c’est sur le fil public et non pas dirigé contre un utilisateur, c’est aussi différent, et les avertissements de contenus (« CW ») utilisés selon votre bon jugement sont appropriés.

On a droit à l’erreur, on peut se laisser emporter. Mais quand un modérateur vous en fait gentiment la remarque, il suffit de rectifier et de reconnaître que oui, les autres ne reçoivent pas forcément les messages de la même manière que vous aviez l’intention de les communiquer. On peut argumenter des opinions ; les sentiments, eux, ne se discutent pas, c’est la perception de celui qui les reçoit, et on y prête attention.

Faire respecter cela, c’est une tâche ingrate qui incombe aux modérateurs et à l’administrateur mais qui est pourtant nécessaire pour un réseau social sûr et bienveillant. Cela n’est en rien du contrôle dictatorial, cela n’a rien à voir avec « Chat Control » (renseignez-vous si vous en doutez !) et non, désolé, on ne peut pas tout dire, même soi-disant « pour plaisanter ». Combien de déclarations toxiques ont été faites sous ce couvert !

Nous offrons beaucoup de liberté ici, mais si vous pensez que ce n’est pas suffisant, n’hésitez pas à nous contacter, nous sommes toujours disponibles et à l’écoute. Et sinon, il existe d’autres serveurs peut-être moins bien modérés mais qui vous permettront toute expression ou qui conviendront mieux au fond et à la forme que vous souhaiteriez y donner.

Et si de votre côté vous vous sentez abusés ou vous tombez sur des contenus inacceptables, vous savez que vous pouvez bloquer la personne, voire la signaler afin que notre équipe de modération prenne les actions adéquates.

Notre serveur est modéré, oui. Pour le bien et pour le confort de tous. Nous ne voulons pas qu’il devienne comme certains de ces réseaux que vous avez justement fuis pour cette bonne et simple raison. Nous ne sommes pas, et ne deviendrons jamais, une cave à trolls.

… et la lettre

À quoi sert le modérateur, concrètement ?

Pour les utilisateurs

Avant tout, le modérateur est là pour aider les utilisateurs, et assurer que le réseau social est sain, plaisant, respectueux et bienveillant.

Pour l’image

De plus, les publications et le comportement de nos membres influent sur la perception que les autres serveurs ont de nous. Si on laissait faire, ces derniers pourraient (à juste titre) nous bloquer en retour en nous jugeant toxiques, avec le risque d’un effet domino. Et une fois que l’on est sur une telle liste, il devient quasiment impossible de s’en faire retirer. Être bloqué, c’est la sanction ultime, le risque d’isolement et à terme la mort du serveur, c’est pourquoi nous sommes particulièrement vigilants sur ce point.

Pour la licéité

On en parle peu, mais il faut se rappeler que le mécanisme de la fédération fait que les contenus visibles sont répliqués sur tous les serveurs. Ainsi, on peut se retrouver à stocker des images illégales si certaines publications étaient visibles depuis chez nous.

Que fait le mod ?

Si vous ne l’avez pas fait récemment, prenez le temps de relire nos douze règles en bas de cette page, ainsi que notre charte de modération. Car le modérateur ne se contente pas de les appliquer, il doit les promouvoir et les faire respecter (en toute sympathie).

Fil public

Le fil public est un peu l’image que renvoie notre serveur à l’extérieur. Aussi, on le consulte régulièrement pour s’assurer qu’il respecte nos règles. C’est le seul cas où on lit les publications a priori. Accessoirement, on peut aussi agir si on tombe par hasard ou en réponse sur des posts problématiques.

Signalements

C’est la voie normale pour traiter les publications suspectes qui sont remontées par d’autres utilisateurs, soit sur notre serveur, soit depuis un autre (utilisateur et/ou publication). J’ai écrit « suspectes » car parfois le signalement n’est pas justifié, notamment on reçoit des signalements pour du contenu NSFW mais si celui-ci respecte nos règles, on laisse passer.

Tendances

C’est l’essentiel de l’activité du modérateur. C’est ce que voient nos utilisateurs dans la rubrique « tendances » ou « explorer » avec trois sous-chapitres : « messages », « hashtags » et « actualités ». Ces contenus sont filtrés par modération, pour éviter de nous faire noyer sous les contenus indésirables, sans intérêt pour nous ou de type politique US invasifs. Ce qui donne donc du travail aux modérateurs. Quand ? En continu !

Comptes

Les actions sur les comptes (limitation, suspension) font l’objet d’un échange avant action, sauf pour les cas évidents (violation patente de nos règles par homophobie, racisme, pédo…)

Les défis du modérateur

Ne pas vouloir tout contrôler

Le modérateur n’est pas là pour tout contrôler, pour lire toutes les publications ni pour garantir que tout va bien à 100%. C’est clairement écrit dans notre charte, nous faisons de notre mieux, dans les limites de la proportionnalité des efforts possibles et souhaitables.

Rester neutre

Autre défi : rester neutre, le modérateur n’abuse pas de sa position. Et si en tant qu’utilisateur, vous sentez une injustice, vous pouvez faire appel d’une décision à votre encontre.

Ferme mais bienveillant

Tout est dans le titre, et cela ne pose aucun problème car tous les modérateurs ici ont cet état d’esprit ! La présomption de bonne foi prévaut.

Ambassadeur

Tout comme l’administrateur, le modérateur incarne également en partie le serveur qu’il représente. Par transparence, les modérateurs sont identifiés par un badge discret sur leur profil.

Ne tirez pas sur le pianiste !

Remercions tous les modérateurs pour leur contribution à rendre le réseau social meilleur ! Leur rôle peut paraître ingrat et on n’aime pas forcément être interpellé par un modérateur, mais c’est dans un esprit positif et au service du bien de tous.

Et si malgré cette description ce rôle vous tente et vous avez envie de contribuer plus activement et de l’intérieur à un monde meilleur sur le fédiverse, n’hésitez pas à me contacter !

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Administrateur du fédiverse… Un rôle que je tiens depuis plus de trois ans, je me confie ici sur comment c’est arrivé, ce que j’en pense, les joies, les difficultés et les frustrations associées.

Genèse

Vous le savez peut-être car je m’en suis déjà confié ailleurs, mais tout a commencé par un bannissement du réseau social Twitter (maintenant X) en septembre 2022, pour une nouvelle bannière de profil jugée trop explicite. Après plusieurs tentatives infructueuses d’appel pour rétablir mon accès, j’ai commencé à regarder des alternatives, et j’ai découvert l’existence du réseau Mastodon et plus généralement du protocole ActivityPub.

Je confesse n’en avoir jamais entendu parler auparavant, j’étais comme beaucoup simple consommateur (et de fait, produit) de ces réseaux sociaux centralisés et commerciaux, mais la promesse d’un monde différent rendant le contrôle aux utilisateurs, couplé avec une soudaine popularité de Mastodon poussée par la reprise du réseau X par Elon Musk, m’a incité à approfondir, puis finalement à tenter l’expérience.

En première étape, je me suis inscrit sur un réseau existant : rubber.social. Ce n’était pas exactement mon cœur de cible, mais en octobre 2022, avec l’afflux soudain d’inscriptions, beaucoup de serveurs Mastodon avaient limité voire suspendu les adhésions, surpris par la montée en charge non anticipée. Ceci m’a permis de monter à bord, comprendre les concepts, me familiariser avec l’interface et enfin décider d’aller plus loin.

Je cherchais un réseau gay plutôt francophone, permettant d’exposer de la nudité sans être soumis aux caprices d’une autorité centrale, et ne trouvant pas vraiment mon bonheur, j’ai commencé ce qui était à l’origine un projet personnel : monter mon propre serveur. J’ai été encouragé à l’époque par un autre utilisateur, Xtian, qui deviendrait ensuite mon premier membre puis modérateur ; il est depuis reparti pour des raisons personnelles, mais je lui garde une place spéciale dans mon cœur.

Je pratiquais Linux depuis longtemps avec une distribution assez hardcore : Gentoo, qui m’avait permis de bien comprendre le système d’exploitation en profondeur, avec une installation très manuelle et une compilation systématique de toutes les bibliothèques et applications. J’ai donc loué les composants nécessaires : nom de domaine, serveur VPS, stockage S3 et mail dédié, et suivi scrupuleusement le tutoriel officiel d’installation de Mastodon. Bien qu’expérimentale, je ne voulais pas d’une installation bricolée sur un PC à la maison, sachant que celle-ci ne supporterait pas la mise à l’échelle et souhaitant également apprendre à utiliser à titre privé ces services nuagiques qui étaient déjà monnaie courante au boulot.

Avant Noël 2022, Mastodon GayFR était né !

Contenant et compte nu

Premiers pas

C’était assez grisant de voir son serveur se connecter aux autres, et le fil s’enrichir au fur et à mesure. J’avoue que je ne savais pas à quoi m’attendre au niveau des adhésions, et une dizaine sont arrivées assez rapidement, avant un flux plus lent. Finalement, début 2023 la migration massive depuis X était déjà derrière nous, et je n’avais pas bénéficié de cet appel d’air.

Je me suis mis à m’interroger sur la vocation de ce serveur. Fallait-il qu’il fût focalisé sur le contenu explicite et la nudité, ou bien être plus divers ? En fin de compte j’optai pour la seconde solution, car cela correspondait mieux à ce que semblaient rechercher certains de nos premiers membres alors que l’offre en contenus sexuels était par ailleurs déjà pléthorique.

Je décidai ainsi de changer de compte principal, conservant l’autre pour les contenus sus-cités, mais affichant une image plus généraliste en tant qu’administrateur, ce qui me sembla alors une nécessité car malheureusement, l’habit (ou son manque) fait le moine et on a plus de mal à faire confiance à un profil libertin pour gérer un service.

Industrialisation

Les premiers mois, je me reposais sur les outils de base fournis. Mais baignant dans un univers professionnel informatique et sécurité, je résolus de mettre en place des sauvegardes quotidiennes complètes (pour assurer un Plan de Reprise d’Activités) et une observabilité granulaire à partir d’un nouveau serveur dédié : des indicateurs partout, avec génération d’alertes en cas de soucis. Jusqu’ici tout s’était bien passé, mais je me sentais un peu aveugle, et ces tableaux de bord m’ont permis d’améliorer et d’augmenter la capacité des serveurs au fur et à mesure de la croissance des services.

Je me suis dit que par souci de transparence, j’afficherai les indicateurs les plus intéressants : ils sont ici, là ou encore là.

Expansion

Un peu déçu par la croissance continue mais lente de Mastodon, je me suis dit qu’en offrant une nouvelle application, je multiplierai l’intérêt et gagnerai de nouveaux membres. Ainsi naquit Pixelfed GayFR sur un nouveau serveur et un nouveau domaine, après avoir dans un premier temps enrichi l’expérience de blog avec Plume à l’époque (désormais remplacé par WriteFreely GayFR sur lequel vous lisez cet article).

Je fus alors pris d’une sorte de frénésie pour offrir progressivement tous les types de services dont le fédiverse disposait : non pas toutes les applications car il y en a trop, mais plutôt la plus connue dans chaque catégorie. Et pour essayer de mettre un peu d’ordre dans un univers par nature dispersé, je créai un portail pour guider les futurs utilisateurs. J’arrivai ainsi à dix applications dans le fédiverse, plus un lecteur de flux RSS et une messagerie instantanée XMPP. Enfin, je développai un pont pour lier cette dernière avec le fédiverse.

Je considère que nous avons désormais atteint une bonne offre de services, même si je reste à l’écoute sur les évolutions et extensions encore possibles.

Tout cela tourne sur trois serveurs chez un hébergeur européen, ainsi qu’un service de stockage S3 pour les médias et les sauvegardes chez un autre hébergeur, européen également. Comme je m’en suis expliqué dans un autre article), j’ai souhaité que ces services demeurent gratuits.

L’incarnation du mâle

La malédiction de l’administrateur

Depuis le début, je savais que le plus grand danger de l’administration est que la gestion du contenant prenne le pas sur le plaisir du contenu. Je lutte contre cela, mais c’est malheureusement quasiment inévitable, car le maintien du service en production reste prioritaire puisque tous les utilisateurs en dépendent.

Ce que j’avais moins bien mesuré, c’est à quel point l’administrateur est à son corps défendant l’incarnation de son serveur. Dans un système contraint par la surveillance mutuelle justifiée par la peur de toute dérive de Mastodon vers les abus des plateformes centralisées, toute action ou opinion exprimée est scrutée, et le moindre écart peut être sanctionné par la très redoutée “suspension” ou “défédération”, c’est-à-dire la mise à l’index par le reste du fédiverse.

Il se trouve que l’on ne peut rien me reprocher sur ce plan, néanmoins cela oblige à une discipline dans l’expression qui peut parfois être pesante. Un mot d’humeur, couplé à la distance et la difficulté de l’écrit dans un monde multilingue qui plus est, peut être mal interprété et exposer tous nos utilisateurs à des conséquences. Je m’en garde donc.

La frustration du modérateur

Le rôle du modérateur est par essence conflictuel : détecter les abus, répondre aux signalements, expliquer avec diplomatie mais fermeté à des utilisateurs ce qu’ils ne devraient pas faire et pourquoi, pour en retour recevoir des reproches ou des insultes, heureusement peu courantes !

Ce rôle est nécessaire, sans un minimum de règles, de respect mutuel et de bienveillance ce réseau social perdrait son âme : respectez également les messagers que sont les modérateurs. Quand ceux-ci doivent intervenir, c’est rarement de gaité de cœur. Nous sommes tolérants : si vous suivez les douze règles et valeurs que vous avez acceptées lors de votre inscription, vous êtes bien !

Si malgré cette description ce rôle vous tente et vous avez envie de contribuer plus activement et de l’intérieur à un monde meilleur sur le fédiverse, n’hésitez pas à me contacter !

Les instances toxiques

Certains serveurs ont été créés pour partager ou propager des contenus toxiques : racisme, homophobie, pédopornographie, antisémitisme… la liste est trop longue et il m’est pénible de l’énumérer.

Pour nous protéger contre ces contenus, il s’agit donc de bloquer ces serveurs afin que leurs publications ne nous atteignent pas ; incidemment, d’éviter par la même occasion de stocker du contenu illégal, car la mécanique de la fédération recopie sur tous les serveurs du réseau chaque contenu qui en est connu.

C’est un exercice très désagréable, car je ne bloque pas à l’aveugle, mais j’utilise des listes publiées par ailleurs ou des blocages de serveurs référents pour nourrir nos propres suspensions en agrégeant et en vérifiant. C’est long, c’est sale, mais le monde actuel nous impose cette discipline.

Les mises à jour

Quand on gère trois serveurs et une quinzaine d’applications de fait, il y a toujours des mises à jour à faire. Je les réalise hebdomadairement, sauf en cas d’urgence de sécurité où je peux le faire plus rapidement. Autant les mises à jour du système sont bien gérées par l’éditeur, autant les applications du fédiverse sont très hétéroclites dans leurs dépendances techniques, leur documentation et leur approche.

Selon les semaines, cela peut donc nécessiter une à plusieurs heures. Et dire que c’est passionnant serait exagéré. Mais c’est essentiel, en particulier pour la sécurité. Et ces derniers mois, tout s’est accéléré avec l’intelligence artificielle et la détection et publication de nouvelles vulnérabilités, vitesse qui risque de croître encore…

Ne s’use que si l’on s’en sert

Comptes

Certains utilisateurs créent un compte, puis ne se connectent… jamais. Ont-ils changé d’avis ? Trouvé ailleurs ? Va savoir.

D’autres se connectent mais ne remplissent ni biographie, ni profil. Parmi eux, une partie ne se connecte plus après un temps : on peut penser qu’ils n’ont pas apprécié leur expérience ; et d’autres s’abonnent sans jamais interagir : ils sont probablement là pour mater, rien de plus.

Puis certains essayent : profil, biographie, une ou deux interactions puis s’en va (ou pas, mais se ne connecte plus) : là aussi, une expérience qu’ils n’ont pas aimée, ou bien peut-être pas assez d’interactions à leur goût. Car comme vous le savez, le fédiverse nécessite un effort continu pour se faire connaître dans la durée et avoir des interactions.

Et enfin, les réguliers : le noyau dur qui est là quotidiennement (merci à vous !), ceux qui vont et viennent de temps à autre mais qui restent dans la durée (plutôt des irréguliers, donc). Cette catégorie doit représenter moins de 10% de tous les comptes.

C’est la première fois que je gère un réseau social, et je ne m’attendais pas à ces chiffres. Mais finalement, j’ai l’impression que c’est assez représentatif. Cher lecteur, si vous avez d’autres éléments, je suis preneur !

Visibilité

Si l’on veut attirer de nouveaux utilisateurs, il faut être visible. Et on s’aperçoit de la difficulté à le devenir dans la jungle de l’internet, dominée par les algorithmes des corporations centralisées. Les techniques classiques de SEO peuvent être appliquées, avec la limitation que vous ne contrôlez pas le code des applications.

Il existe en général pour chaque application un annuaire, auquel on peut soit s’inscrire directement, soit plus souvent demander à y figurer, ce qui peut être plus ou moins compliqué (ce le fut pour nous inscrire sur l’annuaire officiel de Mastodon). En théorie, cela devrait amener de nouveaux inscrits.

En théorie seulement, car la plupart ont un serveur “officiel” (ou flagship en anglais) qui est leur vitrine et qu’ils promeuvent. Celui-ci se retrouve ainsi le plus gros, car il est le premier et que son caractère “officiel” lui confère autorité, et on recrée ainsi des serveurs importants et dominants dans un univers qui se veut décentralisé. Pour Mastodon, c’est accentué par le fait que c’est le serveur par défaut qui est proposé dans l’application cliente. Oui on peut changer, mais encore faut-il le savoir et le vouloir.

Je pense que cette situation n’est pas satisfaisante, et que la tentation de la centralisation tord le modèle fédéré, au détriment de la diversité et des bonnes volontés des “petits” serveurs. Cela rend notre visibilité encore plus difficile.

Croître ?

Mais faut-il croître ? Au risque de dénaturer ou de diluer la petite communauté hébergée sur son serveur ?

Je pense que oui, pourvu que cette croissance soit modérée. Sans ça, et avec l’attrition naturelle, on court le risque de diminuer en deçà d’un seuil acceptable. Et les nouveaux apportent du… neuf, des changements salutaires qui évitent que l’on se sclérose, des opportunités d’échanges avec des personnes différentes. Certes, on n’est pas limité à son serveur ; mais celui-ci représente une part de sa communauté et bien souvent le siège de partages privilégiés.

Et puis pour ma part, j’ai besoin de savoir que mes services sont utiles, donc utilisés. Sinon, à quoi bon ?

Maître du donjon, et joueur ?

En guise de conclusion, la question est posée : peut-on être à la fois administrateur et membre actif d’un serveur, tout en y prenant du plaisir ?

Après avoir lu cet article, vous en sortirez peut-être avec un avis mitigé. Je ne sais pas si je vous ai donné envie de vous lancer ! Ce n’était pas l’objectif, l’inverse non plus d’ailleurs, mais bien de vous conter sans fard comment je le vis et de vous plonger dans la vie quotidienne des administrateurs, qui sont parfois critiqués voire qualifiés de dictateurs (oui, je l’ai lu !), mais sans qui les réseaux décentralisés n’existeraient pas.

Heureusement, j’ai fait de belles rencontres ici et les relations, parfois depuis le début, parfois récentes, sont plus intimes et se perpétuent. Ce sont des choses que je n’avais jamais vécues sur Twitter !

Rassurez-vous ! Je n’ai aucune envie de m’arrêter et j’ai la ferme intention de continuer encore pendant de nombreuses années. Et c’est aussi ma manière de lutter pour la défense de la vie privée et des libertés individuelles.

Vous voulez m’aider ? Faites de la publicité pour recruter des membres de qualité qui enrichiront notre communauté. Parlez de votre expérience, faites que vos amis et relations quittent les GAFAM, et si vous êtes bien ici, dites-le partout !

Merci pour tout…

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

This article in French is also available in English here.

Introduction

Dans un précédent article, j’expliquais mes motivations et choix pour protéger Mastodon (et les autres applications du fédiverse) contre les bots IA. Ce nouvel article, à destination des administrateurs, détaille les étapes techniques afin d’arriver au résultat ; il est également disponible en anglais ici.

Pour mémoire, voici les objectifs visés :

• Protéger nos utilisateurs du moissonnage massif et systématique de leur contenu ;
• Protéger nos serveurs des attaques en masse de ces bots IA ;
• Laisser nos sites internet visibles publiquement, car c’est pour moi une des vocations des réseaux sociaux, le choix étant laissé à l’utilisateur de sélectionner la visibilité de ses publications ;
• Ne pas utiliser un service en ligne dédié de type CloudFlare, car une de mes valeurs est de protéger la vie privée de nos utilisateurs, et dépendre d’une solution externe qui a toute visibilité sur le trafic, les identifiants en clair et le contenu des consultations n’est pas acceptable ;
• Aller au-delà du filtrage “standard”, et ainsi adresser la problématique des bots IA quelles que soient leurs adresses IP et qui s’identifient comme des utilisateurs humains (font semblant d’utiliser un navigateur).

Ainsi, j’ai choisi d’installer Anubis, un programme en source ouverte (disponible ici sous licence MIT) que j’auto-héberge afin d’être autonome et de garantir la sécurité et la confidentialité de la navigation.

Les défis posés

Le site présentant Anubis est très bien fait, et détaille comment installer l’application et protéger un site internet standard. Néanmoins, pour Mastodon et plus généralement pour les applications du fédiverse, j’ai fait quelques choix et j’ai dû résoudre quelques problématiques particulières, concernant notamment :

• Une instance Anubis commune protégeant toutes les applications installées sur le même serveur ;
• Configuration en sous-requête d’authentification (subrequest authentication);
• Renvoi d’un code 200 et d’une fausse page aux robots bloqués (plutôt qu’un code 403) ;
• Prise en compte de l’API de streaming et du changement légitime possible des adresses IP ;
• Prise en compte de l’authentification applicative avec OAuth ;
• Prise en compte des médias intégrés (embedded) ;
• Fonctionnement en mode failsafe (si Anubis tombe, le service reste fonctionnel) ;
• Des métriques montrant les taux de blocage des clients.

J’aborderai l’ensemble de ces points, en utilisant un serveur linux Ubuntu 24.04LTS avec Nginx et une installation native (sans Docker). Je vous laisse le soin d’adapter ces instructions à votre propre configuration.

Installation d’Anubis

Vous pouvez vous référer à la documentation du site officiel pour cette installation, sachant que nous utiliserons la configuration subrequest authentication.

Dans ce mode, Nginx reste en frontal internet et va interroger Anubis pour autoriser la requête : ce dernier renverra 200 si le client est autorisé ou a déjà son cookie d’autorisation, 403 s’il est interdit et 401 s’il a besoin d’être vérifié ; dans ce dernier cas, la requête est redirigée (307) sur la page Anubis et doit passer le défi pour récupérer un cookie d’autorisation et enfin atteindre la page visée en cas de succès.

Comme le décrit le site officiel, vous devez modifier la politique Anubis afin que DENY renvoie un code 403 au lieu de 200 par défaut, pour que Nginx l’interprète correctement :

status_codes:
  CHALLENGE: 200
  DENY: 403

Nous allons toutefois améliorer cette situation, car certains bots IA retentent leur chance sur un code 403.

Configuration d’Anubis

Concernant la configuration d’Anubis, le premier point concerne les variables d’environnement et le second les politiques.

Variables d’environnement

Voici un extrait des variables d’environnement que j’utilise, je décris ci-dessous les points importants pour notre problématique :

BIND=/run/anubis/anubis.sock
BIND_NETWORK=unix
SOCKET_MODE=0660
COOKIE_EXPIRATION_TIME=168h
JWT_RESTRICTION_HEADER="User-Agent"
METRICS_BIND=:8240
METRICS_BIND_NETWORK=tcp
POLICY_FNAME=/usr/local/etc/botPolicies.yaml
REDIRECT_DOMAINS="example.net,*.example.net"
SERVE_ROBOTS_TXT=false
TARGET=" "

Les trois premières lignes concernent le point d’écoute du serveur Anubis. J’ai choisi d’utiliser un socket unix, vous pouvez rester sur un port tcp, auquel cas vous devrez adapter les configurations de Nginx qui suivent. Assurez-vous que l’utilisateur www-data a bien les droits d’accès pour lire sur le socket (appartient au groupe qui exécute Anubis).

L’expiration du cookie est fixé à une semaine. Vous pouvez réduire cette durée, sachant que chaque expiration casse le flux Mastodon sur le navigateur et nécessite que l’utilisateur rafraîchisse sa page. Il faut donc choisir le bon équilibre entre protection et expérience utilisateur.

Pour la même raison, JWT_RESTRICTION_HEADER est lié au User-Agent de l’utilisateur plutôt qu’à son adresse IP (défaut). Le problème de l’adresse IP est que celle-ci peut changer dynamiquement en navigation mobile ou bien avec certains VPN, et dans ce cas le flux Mastodon est cassé à chaque fois, parfois après quelques minutes, ce qui rend le service quasiment inutilisable. Nous sommes donc obligé d’adapter le niveau de protection en ne tenant pas compte de l’adresse IP.

Les quatre valeurs qui suivent sont classiques et permettent l’observabilité à travers Prometheus (nous en reparlerons plus loin), le fichier des politiques et les domaines de redirection autorisés qu’il est conseillé de configurer (ceux de vos applications à protéger, donc).

Le paramètre SERVE_ROBOTS_TXT ne fait pas sens dans le mode Anubis utilisé, néanmoins nous servirons notre propre fichier robots.txt directement avec Nginx.

Enfin, la valeur de TARGET=" " est essentielle pour que le mode subrequest authentication fonctionne.

Politiques

J’utilise une seule instance Anubis pour protéger toutes mes applications, ainsi les politiques utilisées doivent être adaptées à toutes, ce qui en pratique ne pose aucun problème.

Le point essentiel est celui cité plus haut concernant status_codes. Sinon, les politiques par défaut, éventuellement adaptées à votre sauce, peuvent parfaitement convenir. Notez bien que si aucune politique ne s’applique à la requête, celle-ci sera acceptée par défaut : il n’y a donc aucun problème posé pour par exemple la fédération entre serveurs.

Néanmoins, vous pouvez souhaiter accepter explicitement certains flux comme par exemple la fédération ou les flux RSS :

- name: federation
  action: ALLOW
  user_agent_regex: >-
    ^(Mastodon|Pleroma|Akkoma|Misskey|Calckey|Firefish|gotosocial|Friendica|Hubzilla|Lemmy|Kbin|PeerTube|Pixelfed|BookWyrm|WriteFreely|Mobilizon|Funkwhale|Sharkey|Loops|AodeRelay)
  expression:
    all:
      - '"Accept" in headers'
      - 'headers["Accept"].matches("^application/(activity\\+json|jrd\\+json|ld\\+json)(\\s*;.*)?$")'

- name: rss-feeds
  action: ALLOW
  expression:
    all:
      - '"Accept" in headers'
      - 'headers["Accept"].matches("^application/(rss|atom|rdf)\\+xml(\\s*;.*)?$")'

Rappelons enfin que l’objectif d’Anubis n’est pas de bloquer tous les bots mais bien ceux qui se présentent pour collecter en masse vos pages internet. Pour les bots malveillants, je complète avec des outils tels que iptables et ipset pour bloquer les IP toxiques et fail2ban pour les attaques par force brute (mais c’est une autre histoire).

Configuration de Nginx

Maintenant que votre service Anubis est prêt, passons à Nginx qui reste en frontal de l’internet public. Dans le fichier concernant Mastodon (ou toute autre application à protéger), par exemple /etc/nginx/sites-available/mastodon, nous allons rajouter les directives suivantes.

Configuration générale

Adaptant légèrement la documentation officielle, voici les lignes à rajouter :

location ^~ /.within.website/ {
    proxy_pass http://unix:/run/anubis/anubis.sock:;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Original-URI $request_uri;
    proxy_set_header Accept $http_accept;
    proxy_set_header User-Agent $http_user_agent;
    add_header Cache-Control "no-store";
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    auth_request off;
    proxy_cache off;
    proxy_connect_timeout 1s;
    proxy_read_timeout 1s;
    proxy_send_timeout 1s;
}

location @redirectToAnubis {
    return 307 /.within.website/?redir=$scheme://$host$request_uri;
    auth_request off;
    proxy_cache off;
}

Notons en particulier que nous nous assurons de ne pas utiliser le cache en passant la requête à Anubis (ce qui empêcherait le bon fonctionnement de la vérification) et que nous réduisons la durée d’attente (timeout) afin que la configuration failsafe puisse être acceptable du point de vue de l’utilisateur.

Optionnel : servir de fausses pages aux bots IA

Afin de retrouver le même fonctionnement d’Anubis qu’en mode proxy, et donc d’éviter de renvoyer un code 403 aux bots interdits (ceux-ci pouvant alors réitérer sans cesse leurs requêtes), nous avons trois options possibles.

Option basique : page statique

Vous pouvez servir un texte statique tout en renvoyant un code 200 ainsi, en rajoutant les lignes suivantes au même fichier :

location @fake200 {
    default_type text/html;
    return 200 "<h2>Service not available</h2>\n";
    auth_request off;
}

Option élaborée : page dynamique

Il est également possible de servir des pages dynamiquement générées à la volée avec un script lua. Pourquoi faire ? Car cela permet un contenu variable que l’on peut faire passer pour de véritables pages html (contenus multiples mais stables par bot, délai variable par requête, contenu réaliste). L’objectif étant que le bot IA trouve un contenu et en conclut : “rien d’intéressant ici”.

Pour ce faire, nous allons plutôt rajouter les lignes suivantes au même fichier (à la place de l’option basique précédente) :

location @fake200 {
    access_by_lua_file /var/www/html/fake_200.lua;
    auth_request off;
}

Pour que ceci fonctionne, il faut deux conditions : que le module lua soit installé avec Nginx (ce n’est pas le cas par défaut sur Ubuntu 24.04LTS), et qu’un fichier fake_200.lua soit présent sous /var/www/html/ (ou tout autre répertoire de votre choix). Pour installer le module sous Ubuntu :

$ sudo apt install libnginx-mod-http-lua

Si vous êtes intéressé par le fichier fake_200.lua complet que j’utilise, contactez-moi.

local ngx = ngx
--
-- Logic : cache, fingerprinting, generate random content, noise, padding, jitter
--
ngx.say(body)
return ngx.exit(ngx.HTTP_OK)

Option nucléaire : bombe zip

Il est possible d’aller encore plus loin, et au lieu de servir au bot un contenu trompeur, lui servir un contenu carrément nocif. Pour cela, il existe des techniques simples comme les “bombes zip” qui vont coûter très cher en ressources au robot, voire le faire planter.

Vous pourrez facilement trouver sur internet des exemples et adapter les configurations précédentes en ce sens. Pour ma part, je reste réticent à utiliser cette technique, mais à vous de voir…

Voici toutefois un exemple de mise en œuvre (inspiré par Ibrahim Diallo sur son blog), qui va servir un fichier de 10 Mo qui se décompressera en 10 Go, assez pour faire planter les bots qui n’y prennent garde. Génération du fichier :

$ dd if=/dev/zero bs=1G count=10 | gzip -c > /var/www/html/10GB.gz

Et ensuite, rajouter les lignes suivantes au même fichier de configuration Nginx (à la place des options précédentes) :

location @fake200 {
    add_header Content-Encoding gzip;
    return 200 /10GB.gz
    auth_request off;
}

location = /10GB.gz {
    root /var/www/html;
    auth_request off;
}

Optionnel : mode failsafe

Avec Anubis devant l’ensemble de mes applications, un dysfonctionnement les rendrait toutes indisponibles à la fois. Même si cela ne s’est jamais produit, je préfère qu’en cas de souci, l’utilisateur puisse continuer à accéder aux applications, le temps de résoudre la panne d’Anubis. Il suffit de rajouter les lignes suivantes au même fichier :

location @allowOnFailure {
    try_files $uri @mastodon;
    auth_request off;
}

Les lignes hors auth_request off; étant à adapter à ce qui est servi par défaut aux répertoires protégés (la racine / pour Mastodon).

Notez que j’omets add_header Strict-Transport-Security "max-age=63072000; includeSubDomains"; dans chaque directive location contrairement à ce qui est indiqué dans la documentation officielle Mastodon, car je mets cet en-tête au niveau du serveur avec always :

server {
...
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
...
}

Flux OAuth

Le flux d’autorisation OAuth est cassé pour les applications qui n’utilisent pas un navigateur et ne suivent pas une redirection 307 (cas de Tusky par exemple). Pour permettre ce type de flux, il est nécessaire de contourner explicitement Anubis, ainsi il faut rajouter dans le fichier de configuration Nginx pour Mastodon (à adapter pour les autres applications du fédiverse) :

location ^~ /oauth/ {
    try_files $uri @mastodon;
    auth_request off;
}

location ^~ /api/v1/apps {
    try_files $uri @mastodon;
    auth_request off;
}

location ^~ /auth/sign_in {
    try_files $uri @mastodon;
    auth_request off;
}

Il peut semble contre-intuitif de contourner Anubis pour le chemin /auth/sign_in mais encore une fois, Anubis n’est pas une protection contre les attaques par force brute, utilisez fail2ban ou un équivalent pour cela.

Médias intégrés

Les médias intégrés (embedded) posent également souci car les navigateurs récents ne permettent pas aux pages intégrées de type iframe de stocker leurs cookies. Ainsi, si vous souhaitez pouvoir intégrer des publications (par exemple, Mastodon) ou des médias (par exemple, PeerTube), il est nécessaire là aussi de contourner Anubis. Voici les lignes à rajouter dans Nginx pour Mastodon :

location ~ ^/@[^/]+/\d+/embed$ {
    try_files $uri @mastodon;
    auth_request off;
}

location ~ ^/api/v1/statuses/\d+$ {
    try_files $uri @mastodon;
    auth_request off;
}

location = /embed.js {
    try_files $uri @mastodon;
    auth_request off;
}

Cette fonction étant moins utilisée sur Mastodon, vous pouvez choisir de faire sans, mais elle reste indispensable pour PeerTube. Sans cela, l’intégration affichera la fenêtre “non autorisé” d’Anubis.

Partie principale

Sur chaque chemin à protéger, on peut maintenant rajouter les lignes suivantes dans Nginx. Pour Mastodon, cela se limite à la racine / :

location / {
    auth_request /.within.website/x/cmd/anubis/api/check;
    auth_request_set $anubis_status $upstream_status;
    error_page 401 = @redirectToAnubis;
    error_page 403 = @fake200;
    error_page 500 502 503 504 = @allowOnFailure;
    try_files $uri @mastodon;
}

Notez la ligne auth_request_set qui nous sert pour l’observabilité et pour associer dans les logs Nginx le statut renvoyé par Anubis, on y reviendra plus loin. Si cela ne vous intéresse pas, vous pouvez omettre cette ligne.

Dans toutes les autres directives location, on rajoute auth_request off; pour contourner la vérification. Cela concernera en général les fichiers statiques et les autres pages qui ne nécessitent pas ou qui ne devraient pas être protégées (proxy interne, streaming…).

Le fichier robots.txt

Enfin, pour rester cohérent et même si beaucoup de bots IA l’ignorent, on peut choisir de servir son propre fichier robots.txt en lieu et place de celui servi par Mastodon (ou une autre application du fédiverse) qui est minimaliste. Voici un exemple de lignes à rajouter dans Nginx :

location = /robots.txt {
    auth_request off;
    root /var/www/html;
    default_type text/plain;
    access_log off;
    log_not_found off;
}

Mon fichier robots.txt a été mis en cohérence avec les politiques Anubis. Je peux vous le fournir sur demande.

Et en avant !

Tout est maintenant prêt. Bien entendu, si vous utilisez un stockage objet S3 avec un proxy inversé Nginx, vous ne toucherez pas à cette dernière configuration, il n’est pas souhaitable d’y utiliser Anubis.

Si vous ne l’avez déjà fait, après avoir modifié les configurations :

$ sudo systemctl restart anubis
$ sudo systemctl reload nginx

Désormais, vous aurez la fenêtre de vérification Anubis la première fois que vous visiterez votre site, et ensuite vous serez tranquille pour la durée que vous avez configurée (une semaine si vous avez suivi ce guide à la lettre).

Après expiration du cookie, le flux Mastodon sur un navigateur sera rompu : si vous l’aviez laissé ouvert, vous aurez alors un message d’erreur de Mastodon, vous invitant à tenter de rafraîchir la page, ce qui résout la situation. C’est une gêne mineure que je n’ai pas réussi à éliminer, mais elle me semble acceptable. Bien entendu, elle ne se produit pas sur les applications clientes.

Cette configuration fonctionne parfaitement chez moi après plusieurs mois, sans impact visible sur les performances, Anubis protégeant cinq applications du fédiverse sur chacun de mes deux serveurs principaux. La charge poussée par les bots IA a nettement diminué, et les défis non résolus varient entre 70% et 95% selon les périodes, donnant une idée du taux important de bots IA qui tentent de se faire passer pour des navigateurs légitimes !

Bonus : observabilité

Si vous souhaitez rajouter quelques métriques pour mesurer l’efficacité, vous pouvez utiliser deux sources complémentaires.

Prometheus

Si vous avez configuré Anubis comme indiqué, vous retrouverez sur le port 8240 des métriques Prometheus que vous pourrez utiliser :

curl http://127.0.0.1:8240/metrics

Pour ma part je les exporte avec Alloy vers un serveur Prometheus / Grafana. Contactez-moi si vous voulez en savoir plus.

Nginx

En utilisant la variable $anubis_status configurée ci-dessus, vous pouvez associer le “vrai'“ statut renvoyé par Anubis à chaque requête Nginx dans les journaux (200, 401, 403…) et enrichir ainsi les statistiques (par exemple, par pays).

Pour ma part je remonte les logs filtrés avec Alloy vers le même serveur avec Loki / Grafana. Contactez-moi également pour plus de détails.

Résultat

Pour un exemple de résultat de ce que cela peut donner, vous pouvez alors voir la page de statut de notre serveur Mastodon ici. Les statistiques correspondantes se trouvent sur la dernière section.

Pour les autres applications du fédiverse

La même logique s’applique aux autres applications, mais les configurations et chemins dans Nginx diffèrent et nécessitent de légères adaptations. N’hésitez pas à me contacter si vous souhaitez tous les détails.

Avec Anubis, je protège ainsi avec succès Mastodon, Pixelfed, PeerTube, Lemmy, Friendica, WriteFreely, Loops, Mobilizon, BookWyrm, Funkwhale, ainsi que FreshRSS et les blogs Movim.

J’accueille volontiers vos retours et suggestions. Et sus aux bots IA !

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Cet article en anglais est également disponible en français ici.

Introduction

In a previous article in French, I explained my motivations and choices to protect Mastodon (and other Fediverse applications) against AI bots. This new article, targeting administrators, details the technical steps to achieve that; it is also available in French here.

For reference, my objectives are to:

• Protect our users against content systematic bulk-scraping;
• Protect our servers against massive AI bot attacks;
• Maintain public visibility of our servers, as it is to me a core purpose of social networks, each user retaining control over the visibility of published content;
• Not use a dedicated online service such as CloudFlare, as one of my values is to protect our users’ privacy, and I consider that depending on an external solution which has full traffic visibility, including credentials in clear text and browsing content, is not acceptable;
• Go beyond the “standard” filtering, thus targeting the AI bots situation whatever their IP address and however they identify as human users (meaning they pretend to use a browser).

I therefore chose to install Anubis, an open-source application (available here under the MIT license) which I self-host so as to be autonomous and to guarantee security and confidentiality of browsing.

Challenges ahead

The official Anubis website is well designed, and details how to install the application and protect a standard website. However, for Mastodon and more generally for Fediverse applications, I made some choices and had to solve some specific pitfalls, namely:

• One common Anubis instance to protect all applications hosted on the same server;
• Configured using subrequest authentication;
• Return a 200 code and a fake page to rejected bots (rather than a 403 code);
• Deal with streaming API and potentially legitimate IP address changes;
• Deal with application authentication using OAuth;
• Deal with embedded media;
• Operate in failsafe mode (if Anubis is down, services remain operational);
• Metrics showing rejection rates of clients.

I will describe all these aspects, using a linux Ubuntu 24.04LTS server with Nginx and a native installation (no Docker). I let you adapt these instructions to your own configuration.

Installing Anubis

Please refer to the official site’s documentation for installing Anubis on your server. We will be using the subrequest authentication configuration.

In that specific mode, Nginx remains internet-facing and will query Anubis to authorize the request: the latter will return 200 if the client is authorized or already has an authorization cookie, 403 if it is rejected and 401 if it requires verification; in that last case, the request is redirected (307) to the Anubis page and must fulfill the challenge to obtain an authorization cookie, and finally reach the target page in case of success.

As described in the official site, you must modify the Anubis policy so DENY returns a 403 code instead of a 200 by default, so Nginx understands the result correctly:

status_codes:
  CHALLENGE: 200
  DENY: 403

We shall however improve this part, as some AI bots may keep trying when receiving a 403 code.

Configuring Anubis

Regarding Anubis configuration, the first part is about environment variables and the second about policies.

Environment variables

Here is an extract of the environment variables I use, let me describe just after the important aspects relating to our subject:

BIND=/run/anubis/anubis.sock
BIND_NETWORK=unix
SOCKET_MODE=0660
COOKIE_EXPIRATION_TIME=168h
JWT_RESTRICTION_HEADER="User-Agent"
METRICS_BIND=:8240
METRICS_BIND_NETWORK=tcp
POLICY_FNAME=/usr/local/etc/botPolicies.yaml
REDIRECT_DOMAINS="example.net,*.example.net"
SERVE_ROBOTS_TXT=false
TARGET=" "

The first three lines are about the Anubis server listening endpoint. I elected to use a unix socket, you could also use a tcp port, in which case you will need to adapt the following Nginx configurations. Make sure the www-data user has proper read access rights to the socket (belongs to the group executing Anubis).

Cookie expiration is set to one week. You could reduce this duration, knowing that every time it expires the Mastodon timeline flow will break on the browser and require a refresh from the user. So you need to choose the right balance between protection and user experience.

For the same reason, JWT_RESTRICTION_HEADER is tied to the User-Agent rather than the user IP address (default). The issue with the IP address is that it may dynamically change when browsing on a mobile device or when using some VPN networks, in which case the Mastodon timeline breaks, sometimes only after a few minutes, which makes the service unusable. Thus we need to adapt the protection level by ignoring the IP address.

The four following variables relate to observability using Prometheus (we will touch on this further down), policies file and authorized redirect domains which you should configure (those of your applications to protect).

The SERVE_ROBOTS_TXT variable does not make sense in the Anubis mode we use, however we will serve our own robots.txt file directly from Nginx.

Finally, the value of TARGET=" " is essential so subrequest authentication mode works.

Policies

I use only one Anubis instance to protect all my applications, so policies must be adapted to all of those, which in practice is no issue.

The critical point is the one mentioned previously about status_codes. Otherwise, default policies make perfect sense, possibly adapted to your liking. Remember that when no policy matches the request, it will be accepted by default: so federation between servers, for example, will not be an issue.

You might however want to explicitly accept some flows, such as federation or RSS feeds:

- name: federation
  action: ALLOW
  user_agent_regex: >-
    ^(Mastodon|Pleroma|Akkoma|Misskey|Calckey|Firefish|gotosocial|Friendica|Hubzilla|Lemmy|Kbin|PeerTube|Pixelfed|BookWyrm|WriteFreely|Mobilizon|Funkwhale|Sharkey|Loops|AodeRelay)
  expression:
    all:
      - '"Accept" in headers'
      - 'headers["Accept"].matches("^application/(activity\\+json|jrd\\+json|ld\\+json)(\\s*;.*)?$")'

- name: rss-feeds
  action: ALLOW
  expression:
    all:
      - '"Accept" in headers'
      - 'headers["Accept"].matches("^application/(rss|atom|rdf)\\+xml(\\s*;.*)?$")'

Let’s just remember that Anubis’ objective is not to block all bots but specifically those which want to mass-scrape your internet pages. For malicious bots, I also use other tools such as iptables and ipset to block toxic IP addresses and fail2ban for brute-force attacks (but that’s a different story).

Configuring Nginx

Now that our Anubis service is ready, let’s move to Nginx which remains the public internet facing server. In the file relating to Mastodon (or any other application to protect), for example /etc/nginx/sites-available/mastodon, we shall add the following directives.

General configuration

Here are the lines to add, slightly adapting the official documentation:

location ^~ /.within.website/ {
    proxy_pass http://unix:/run/anubis/anubis.sock:;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Original-URI $request_uri;
    proxy_set_header Accept $http_accept;
    proxy_set_header User-Agent $http_user_agent;
    add_header Cache-Control "no-store";
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    auth_request off;
    proxy_cache off;
    proxy_connect_timeout 1s;
    proxy_read_timeout 1s;
    proxy_send_timeout 1s;
}

location @redirectToAnubis {
    return 307 /.within.website/?redir=$scheme://$host$request_uri;
    auth_request off;
    proxy_cache off;
}

Note that we explicitly instruct not to use a cache when directing the request to Anubis (which would impair verification) and that we reduce the timeout so failsafe configuration can work acceptably from a user’s standpoint.

Optional : serve fake pages to AI bots

You can have the same behavior of Anubis as in proxy mode and not return a 403 code to rejected bots (as those may retry again and again), for this we have three possible options.

Basic option: static page

You can serve a static text whilst returning a 200 code by adding the following lines to the same file:

location @fake200 {
    default_type text/html;
    return 200 "<h2>Service not available</h2>\n";
    auth_request off;
}

Advanced option: dynamic page

You can also serve dynamic pages generated on-the-fly with lua scripting. Why do that? Because this allows for variable content that may look like real html pages (different content but stable per bot, varying jitter, realistic content). The objective here is that the AI bot finds content and concludes: “nothing interesting here”.

To achieve that, we shall rather add the following lines to the same file (replacing previous option):

location @fake200 {
    access_by_lua_file /var/www/html/fake_200.lua;
    auth_request off;
}

For this to work, you need two conditions: the lua module must be installed with Nginx (it is not by default on Ubuntu 24.04LTS), and a file named fake_200.lua must be present under /var/www/html/ (or any other directory of your choice). To install the module with Ubuntu :

$ sudo apt install libnginx-mod-http-lua

If you are interested by my own complete fake_200.lua file, please contact me.

local ngx = ngx
--
-- Logic : cache, fingerprinting, generate random content, noise, padding, jitter
--
ngx.say(body)
return ngx.exit(ngx.HTTP_OK)

Nuclear option: zip bomb

It is possible to go even further, and rather than serve deceptive content to the bot, serve it really toxic content. To achieve this, there are some simple techniques such as “zip bombs” which will be very costly resource-wise for the robot, or even trigger a failure.

You can easily find examples on the internet and adapt the previous configurations. As for myself, I am reluctant to use these techniques, but it’s up to you…

Nonetheless, here is an example of implementation (inspired by Ibrahim Diallo on his blog), which will serve a 10 MB file which will unzip to 10 GB, usually enough to trigger a failure for unaware bots. Generate the file:

$ dd if=/dev/zero bs=1G count=10 | gzip -c > /var/www/html/10GB.gz

And now, add the following lines to the same Nginx configuration file (replacing previous options):

location @fake200 {
    add_header Content-Encoding gzip;
    return 200 /10GB.gz
    auth_request off;
}

location = /10GB.gz {
    root /var/www/html;
    auth_request off;
}

Optional: failsafe mode

With Anubis virtually sitting in front of all my applications, a failure would make them all unavailable at once. Even if that has never happened yet, I prefer that users can continue to use my applications should an issue occur with Anubis, waiting for resolution. You simply need to add the following lines to the same file:

location @allowOnFailure {
    try_files $uri @mastodon;
    auth_request off;
}

The lines above auth_request off; must be adapted to what is served by default on the protected paths (only root / for Mastodon).

Note that I don’t use add_header Strict-Transport-Security "max-age=63072000; includeSubDomains"; in each location directive, as opposed to what is listed in the Mastodon official documentation, as I set this header at the server-level using always :

server {
...
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
...
}

OAuth flow

The OAuth authorization flow is broken for apps that don’t use a browser and don’t follow a 307 redirect (case of Tusky as an example). To allow this flow type, you must explicitly bypass Anubis, so you need to add in the Nginx configuration file for Mastodon (to adapt for other Fediverse applications):

location ^~ /oauth/ {
    try_files $uri @mastodon;
    auth_request off;
}

location ^~ /api/v1/apps {
    try_files $uri @mastodon;
    auth_request off;
}

location ^~ /auth/sign_in {
    try_files $uri @mastodon;
    auth_request off;
}

It may seem counter-intuitive to bypass Anubis for the path /auth/sign_in but once again, Anubis is not a protection against brute-force attacks, use fail2ban or an equivalent for that.

Embedded media

Embedded media are also an issue as recent browsers do not allow iframe-type embedded pages to store their cookies. Thus if you want to embed posts (e.g. Mastodon) or media (e.g. PeerTube), you must also bypass Anubis. Here are the lines you should add in Nginx for Mastodon:

location ~ ^/@[^/]+/\d+/embed$ {
    try_files $uri @mastodon;
    auth_request off;
}

location ~ ^/api/v1/statuses/\d+$ {
    try_files $uri @mastodon;
    auth_request off;
}

location = /embed.js {
    try_files $uri @mastodon;
    auth_request off;
}

This functionality is less used on Mastodon so you could choose to do without, but it remains necessary for PeerTube. Without those lines, the embedded window will display the Anubis “unauthorized” page.

Main part

On each path to protect, we can now add the following lines in the appropriate Nginx location. For Mastodon, this only needs to be done on the root directory / :

location / {
    auth_request /.within.website/x/cmd/anubis/api/check;
    auth_request_set $anubis_status $upstream_status;
    error_page 401 = @redirectToAnubis;
    error_page 403 = @fake200;
    error_page 500 502 503 504 = @allowOnFailure;
    try_files $uri @mastodon;
}

Note the line auth_request_set which is used for observability and to associate to Nginx logs the Anubis status, we will come back to this just after. If you are not interested, you can omit this line.

For all other location directives, we add auth_request off; to avoid verification. This usually covers static assets and other pages which need not or should not be protected (internal proxying, streaming…).

The robots.txt file

Finally, to remain consistent and even though many AI bots disregard it, you can serve your ownrobots.txt file to replace the one served by Mastodon (or any other Fediverse application) which is minalistic. Here an example of lines to add in Nginx:

location = /robots.txt {
    auth_request off;
    root /var/www/html;
    default_type text/plain;
    access_log off;
    log_not_found off;
}

I put my own robots.txt file to be consistent with Anubis policies. I can provide it on request.

Let’s go!

Everything is now ready. Of course, if you are using S3 object storage with a Nginx reverse-proxy, you don’t modify anything in its configuration file, Anubis should not be used there.

If not done already, after setting everything up:

$ sudo systemctl restart anubis
$ sudo systemctl reload nginx

You now should have the Anubis verification page on your first site visit, and then you will be fine for the duration you configured (one week if you followed exactly this guide).

After the cookie expiry, the Mastodon timeline flow on a browser will break: if the browser were still open, you will then get a Mastodon error message, inviting the user to refresh the page, which resolves the situation. It’s a minor hindrance that I could not get rid of, but it seems acceptable. Of course, this won’t happen on client apps.

This configuration works fine for me after several months, with no visible impact on performances, Anubis protecting five Fediverse applications on each of my two main servers. The toll taken by AI bots has significantly decreased, and unresolved challenges vary from 70% to 95% depending on the period, giving a hint on the important proportion of AI bots trying to mimic they are legitimate users!

Bonus: observability

If you want to add some metrics to evaluate efficiency, you can use two complementary sources.

Prometheus

If you configured Anubis as described, you will find on port 8240 Prometheus metrics you may use:

curl http://127.0.0.1:8240/metrics

As for myself, I export those using Alloy to a Prometheus / Grafana server. Contact me if you want more details.

Nginx

By using the $anubis_status variable configured above, you can associate the “real” status returned by Anubis on each Nginx request in the logs (200, 401, 403…) and enrich statistics (e.g. by country).

As for myself, I upload filtered logs using Alloy to the same server with Loki / Grafana. Contact me also for more details.

Result

For an example of what you can expect, you can browse our Mastodon server status page here. Corresponding statistics are on the last section.

For the other Fediverse applications

The same logic applies to other applications, but configurations and paths in Nginx differ and require minor adaptations. Don’t hesitate to contact me if you want all details.

I successfully use Anubis to protect Mastodon, Pixelfed, PeerTube, Lemmy, Friendica, WriteFreely, Loops, Mobilizon, BookWyrm, Funkwhale, as well as FreshRSS and Movim blogs.

I welcome any feedback and suggestions. And down with the AI bots!

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Introduction

Cette publication en français est à destination des utilisateurs francophones curieux.

Elle est suivie d’un article plus technique (en français et en anglais) afin de détailler comment protéger les applications du fédiverse contre les bots IA. En effet, j’ai dû résoudre un certain nombre de problèmes avant d’arriver à une solution satisfaisante que je partagerai donc ici.

Grâce à ça, tous nos services du fédiverse (présentés sur notre portail) sont désormais protégés.

Contexte

Dans les derniers mois et avec une accélération grandissante, j’ai constaté une augmentation significative du trafic vers l’ensemble de nos sites. Bonne nouvelle ? Regardons de plus près…

Beaucoup de ce trafic venait de Chine ou Singapour notamment, avec des ordres de grandeur dépassant largement les pays européens (fois dix, voire plus). Étonnant pour des sites francophones… Un peu de travail pour bloquer avec le pare-feu les adresses IP malveillantes à partir de bases de données libres m’ont permis de ramener initialement ce trafic à un profil plus normal, où traditionnellement les pays dominants sont la France, la Belgique, la Suisse puis l’ensemble des pays européens suivis de la plaque continentale américaine.

Mais ce répit a été de courte durée, et ce blocage (pourtant mis à jour en continu) ne suffit désormais plus. Un trafic toujours en croissance, émanant des pays les plus divers (mais notamment USA, Singapour, Chine et Hong-Kong…) et qui semble attaquer par vagues successives, avec des adresses IP sources multiples et différentes qui n’apparaissent pas sur les listes de blocage.

Problème

La cause à tout cela est claire : les « crawlers IA » ou « bots IA ». Il s’agit de comptes robots (c’est-à-dire automatisés, sans personne derrière) dont l’objectif est de parcourir l’ensemble des pages internet pour les analyser et apprendre des contenus de toutes les pages disponibles. Il y a toujours eu des comptes robots, par exemple ceux liés aux moteurs de recherche (type Google, Bing, DuckDuckGo…) et qui permettent d’indexer les pages afin que celles-ci se retrouvent dans les résultats des recherches que l’on utilise quotidiennement, mais ces derniers sont « raisonnables » dans leur sollicitation des ressources et leur intention.

Les études récentes montrent que plus de la moitié du trafic internet est désormais le fait de bots, et que la croissance des bots IA est exponentielle.

Ici, ces bots IA posent des problématiques particulières :

• Éthiques d’une part, car ils pillent littéralement les contenus pour les réutiliser et pour nourrir leurs modèles, au mépris des droits d’auteur, des licences et de la volonté de leurs créateurs ;
• Impactant les sites internet d’autre part, car ces bots sont très nombreux et consultent inlassablement et continûment les mêmes pages, provoquant des requêtes internet en masse sur les serveurs pouvant aller jusqu’à ralentir leur performance ou carrément les faire tomber (ce qu’on appelle un « déni de service »).

A ce double titre, ils peuvent être considérés comme des maliciels (« malwares » en anglais). Et pour ces deux raisons, j’ai souhaité les bloquer, à la fois pour protéger nos serveurs et par respect pour nos utilisateurs et leurs contenus.

Caractéristiques

Normalement, l’internet est fait pour accommoder les comptes robots, et il y a plusieurs façons de les reconnaître.

Adresses IP

Ces adresses identifient quelle est la machine source qui envoie les requêtes vers un serveur. Certaines de ces adresses IP sont bien connues et identifiées comme étant malveillantes, et des listes publiques sont maintenues et utilisées pour les bloquer (y compris par moi).

Les bots IA contournent pour beaucoup ce mode d’identification, en utilisant des adresses IP résidentielles, multiples et évolutives, rendant impossible leur blocage compte tenu du nombre et du caractère dynamique de telles listes.

Le fichier robots.txt

Historiquement, ce petit fichier texte présent à la racine des sites internet permet d’indiquer de manière normalisée ce que l’administrateur du site souhaite accepter comme type de comptes robots. Il est indicatif et n’effectue aucun blocage, c’est comme un autocollant « pas de pub svp » sur votre boîte aux lettres. Respecté par les bots « honnêtes » comme celui d’indexation du moteur de recherche Google ou Bing, il ne l’est malheureusement pas par la plupart des bots IA qui l’ignorent allègrement.

Le User-Agent

Quand une machine va consulter un serveur, elle envoie entre autres choses un en-tête (invisible à l’utilisateur) qui s’appelle le User-Agent et qui identifie quelle est l’application source qui fait la requête. On peut donc normalement l’utiliser pour savoir si on a affaire à un navigateur (et donc à un utilisateur humain) ou bien à une autre application, y compris un robot. Ces derniers devraient donc s’identifier comme tels, et par exemple la fédération (le processus automatisé qui permet à tous les serveurs du fédiverse de communiquer entre eux) respecte également cette pratique, le User-Agent de Mastodon identifiant bien cette application pour ne prendre qu’un exemple.

Caractéristique de leur comportement voyou, beaucoup de bots IA se font passer pour un navigateur standard (et donc un utilisateur) en envoyant un User-Agent volontairement faux et trompeur. Il est donc difficile d’utiliser ce seul critère pour débusquer ces bots.

Solutions possibles

Vous l’aurez compris, beaucoup de bots IA sont difficiles à déceler car ils sont précisément conçus pour imiter la consultation d’un site internet par un humain. Alors, que faire ? Plusieurs solutions.

Rendre son site internet privé

Solution radicale, il est possible d’exiger la création d’un compte pour s’identifier et accéder au contenu de son site internet. Les bots IA ne disposant pas de ces identifiants, ne peuvent accéder qu’au contenu public et si celui-ci est vide, problème résolu. Seulement, cela impacte aussi les utilisateurs ainsi que la visibilité du site en question (le fameux « SEO ») et n’est pas forcément souhaitable si l’on désire afficher des pages publiques. D’autre part, il faut sécuriser la création de compte (avec par exemple un CAPTCHA) car certains bots savent le faire automatiquement, confirmation par e-mail comprise.

Utiliser un service en ligne spécialisé

Certains services en ligne (je pense notamment à Cloudflare) proposent un filtrage configurable et savent résoudre notamment le problème du déni de service. Pour ma part, je n’aime pas cette solution, car elle revient à introduire entre l’utilisateur et le site internet un intermédiaire (américain pour Cloudflare) qui voit passer tout le trafic en clair. Oui, vous avez bien lu, et donc toutes vos consultations, contenus, vos identifiants et mots de passe sont également disponibles à cet intermédiaire. Cette solution n’est pas acceptable par rapport aux objectifs d’éthique et de protection de la vie privée que je recherche, mais elle pourrait l’être pour d’autres.

Se contenter des filtrages standards

Si l’on reprend les éléments cités plus haut (adresses IP, fichier robots.txt, User-Agent), il est possible de bâtir un ensemble de filtrages qui amélioreront la situation par rapport au fait de ne rien faire du tout. Certains vont même jusqu’à bannir des pays entiers par leur adresse IP (Chine, par exemple) mais cela me semble trop radical et exclut de facto les utilisateurs légitimes de ces pays (et il y en a). Dans tous les cas, cette solution ne permettra pas de filtrer les bots IA qui utilisent des adresses IP résidentielles, qui ignorent robots.txt et utilisent un User-Agent de navigateur standard : une grande partie de ces bots, en fait.

Solution choisie

Voici ce que j’ai cherché à atteindre :

• Protéger nos utilisateurs du moissonnage massif et systématique de leur contenu ;
• Protéger nos serveurs des attaques en masse de ces bots IA ;
• Laisser nos sites internet visibles publiquement, car c’est pour moi une des vocations des réseaux sociaux, le choix étant laissé à l’utilisateur de sélectionner la visibilité de ses publications ;
• Ne pas utiliser un service en ligne dédié, car une de mes valeurs est de protéger la vie privée de nos utilisateurs, et dépendre d’une solution externe qui a toute visibilité sur le trafic et le contenu des consultations n’est pas acceptable ;
• Aller au-delà du filtrage « standard », et ainsi adresser la problématique des bots IA quels que soient leurs adresses IP et qui s’identifient comme des utilisateurs humains (font semblant d’utiliser un navigateur).

Ainsi, j’ai choisi d’installer Anubis, un programme en source ouverte (disponible ici sous licence MIT) que j’auto-héberge afin d’être autonome et de garantir la sécurité et la confidentialité de la navigation.

Impacts

En tant qu’utilisateur, voici les impacts pour vous :

• Si vous utilisez une application (comme sur un smartphone) : aucun ;
• Si vous utilisez un navigateur : vous verrez apparaître une fenêtre de « vérification que vous n’êtes pas un robot » pendant une à deux secondes, puis vous serez redirigé automatiquement vers le site. À partir de ce moment, vous n’aurez plus cette fenêtre pendant une semaine (sauf si vous changez d’appareil ou de navigateur), et le cycle recommencera.

Notez bien qu’Anubis requiert que le navigateur autorise Javascript et le dépôt de cookies, mais sans cela Mastodon ne fonctionnerait pas de toutes façons.

Côté performances, cela a un impact négligeable sur le temps de réponse.

Ce dispositif réalise le meilleur compromis entre gêne utilisateur (faible et sans action de votre part) et blocage du trafic IA. Car il s’agit bien d’un compromis ! Aucune solution de ce type ne peut être parfaite, il faut trouver le bon équilibre pour ne pas bloquer les utilisateurs légitimes. De plus, certains robots évolués seraient capables de contourner cette protection en reprenant l’ensemble des caractéristiques de l’utilisateur humain, mais cela leur demanderait plus de ressources de par le fonctionnement inhérent d’Anubis : ainsi, il ne s’agit pas tant de bloquer entièrement tous les bots IA, que de rendre leur utilisation en masse trop gourmande pour eux en essayant de consulter nos sites.

Pour aller plus loin

Ainsi, Anubis protège nos sites contre une grande majorité de bots IA, tout en laissant nos contenus publics visibles sans nécessiter de connexion.

Toutefois, si vous recherchez une protection absolue, vous devez avoir en tête les éléments suivants :

• Comme on l’a dit, certains robots évolués (ou conçus spécialement) pourraient passer malgré tout ;
• Le mécanisme de la fédération fait que vos publications sont recopiées sur les autres serveurs des personnes qui vous suivent (si posts publics) ou s’il y a interaction (like, boost, commentaire) ; si ces serveurs ne sont pas protégés contre les bots IA, ces derniers pourraient accéder indirectement au contenu ;
• Si un compte vous suit et qu’il n’est autre qu’un bot IA masqué, il accédera également à votre contenu. Prenez garde à qui sont vos abonnés !

Si vous souhaitez vraiment augmenter encore votre protection par rapport aux deux derniers points, considérez alors jouer sur la visibilité de vos publications (qui impactera également comment les utilisateurs humains verront vos posts) :

• Tout ce que vous publiez en visibilité « publique » est visible… publiquement, et peut donc être moissonné à partir d’un autre serveur fédéré non protégé ;
• Si vous publiez en visibilité « public discret », on ne la verra pas dans les fils mais elle restera accessible publiquement à partir de son lien (qu’il faut donc connaître). Le moissonnage par un bot IA est plus difficile, mais peut se faire par exemple si ce bot suit un utilisateur qui interagit avec votre post ;
• Si vous publiez en mode « abonnés seuls », il n’y a que ces derniers qui peuvent voir vos publications (ce qui nécessite donc d’avoir un compte et de vous suivre). Il faudra alors veiller à ce qu’aucun compte abonné ne soit en réalité un bot IA masqué ;
• La seule protection absolue : la visibilité « mention privée ». Mais alors, on n’est plus sur un réseau social…

Si vous suspectez un compte « bot IA masqué » sur une instance, n’hésitez pas à la signaler.

Si vous rencontrez un souci d’accès, contactez votre administrateur.

Pour conclure

En conclusion, tous nos services sont protégés contre les bots IA ce qui vous offre un haut niveau de protection contre le vol en masse direct et systématique de vos données – mais ce n’est pas une protection absolue.

Nous resterons évolutifs dans nos solutions de protection, car c’est un jeu du chat et de la souris.

L’internet reste une jungle et tout ce qui est publié publiquement restera accessible à un acteur déterminé, pour l’éternité.

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Vue d’ensemble de quelques fonctionnalités plus avancées

Dans cette troisième partie consacrée à Mastodon, je balaye quelques fonctionnalités plus avancées. Si vous ne l’avez pas encore fait, je vous conseille la lecture de la partie 1 (concepts et philosophie de Mastodon) et de la partie 2 (bien commencer avec Mastodon).

Usage

On supposera donc ici que vous maîtrisez les bases de Mastodon et que vous savez publier ainsi que vous abonner à d’autres comptes. Nous aborderons des aspects parfois moins connus mais néanmoins utiles, sans prétendre à l’exhaustivité. Je décris simplement la fonctionnalité sans vous abreuver de captures d’écran, d’autant plus que les icônes et leur localisation peuvent varier selon que vous utilisez un navigateur ou bien une application, ainsi vous saurez qu’elle existe et vous la trouverez sans difficulté.

Marque-pages

Vous pouvez classer des publications avec l’icône marque-page, pour y revenir plus tard. Toutes apparaîtront dans un fil spécial identifié avec la même icône ; par ailleurs, cela pourra être utile pour définir des exceptions si vous mettez en place une suppression automatique de messages (voir plus loin).

Listes

Vous voulez regrouper certains membres auxquels vous êtes abonné pour voir leurs publications dans un fil particulier ? Ou définir un groupe restreint de personnes qui vous intéressent plus particulièrement ou sur un thème précis ? Créez une ou plusieurs listes pour y rattacher les comptes correspondants, vous pourrez ensuite consulter leurs publications dans la liste correspondante.

Brouillon

La fonctionnalité n’est pas disponible nativement mais il est possible de créer un brouillon pour le publier plus tard de la manière suivante : écrivez votre message en visibilité « mention privée », mais sans mentionner personne ; en le publiant, vous seul pourrez continuer à le voir (si vous avez peur de ne pas le retrouver, vous pouvez aussi utiliser le marque-page). Quand vous êtes prêt, ouvrez-le à nouveau et choisissez « supprimer et ré-écrire » (car sinon vous ne pourrez pas modifier sa visibilité) ; ajustez éventuellement le message existant qui est repris dans l’interface et surtout modifiez sa visibilité selon le niveau souhaité, puis publiez.

Suivi de hashtags

Vous savez que vous pouvez suivre des comptes, mais savez-vous que vous pouvez aussi suivre des hashtags ? Choisissez des thèmes qui vous intéressent pour ainsi enrichir votre fil, vous y verrez toutes les publications mentionnant les hashtags suivis (en plus des comptes auxquels vous êtes abonnés).

Flux RSS

Si vous utilisez un lecteur de flux RSS, vous pouvez aussi suivre toutes les publications d’un compte Mastodon avec l’URL du compte souhaité suffixé par .rss ; donc par exemple, pour mon compte cela donnera https://gayfr.social/@barbapulpe.rss

Invitations

Si votre administrateur l’a autorisé, il est possible de générer des liens d’invitations (avec des limites que vous définissez). Transmettez-les aux personnes que vous souhaitez et celles-ci pourront rejoindre la même instance Mastodon de manière facilitée en cliquant sur le lien.

Visibilité

Voici probablement l’aspect le plus délicat à maîtriser, qui caractérise l’univers fédéré par rapport à celui centralisé auquel les grandes plateformes commerciales nous ont habitué. Sans aller dans les détails techniques, il est important de bien comprendre comment votre visibilité est affectée car votre expérience ici en dépend.

Qui voit qui et quand ?

Quand vous créez un compte sur un serveur Mastodon, tous les autres comptes sur ce serveur verront votre profil et vos publications, mais personne d’autre. Pour que les comptes d’autres serveurs vous voient, votre compte doit y être connu, et pour cela il faut que quelqu’un de ce serveur vous suive, ou interagisse avec une de vos publications (like, boost, commentaire).

Il y a donc un effet « œuf et poule » ! Et si vous voulez gagner des abonnés notamment au début, il vous faudra suivre d’autres comptes (qui pourront alors vous suivre en retour) ou interagir avec d’autres publications (pour susciter des réponses ou des interactions). Cela produit un effet « boule de neige » car plus vous interagissez, plus vous vous ferez connaître et plus vous deviendrez visible. Il suffit d’une personne sur chaque autre serveur qui vous suive pour que vous soyez connu partout et par tous ! Si en revanche vous n’avez aucun abonné et que personne n’a interagi avec vos publications, seuls les membres de votre serveur vous verront.

Enfin, vos publications ne seront automatiquement visibles d’un autre serveur qu’à partir de l’instant où une personne de ce serveur a commencé à vous suivre ; avant, il faudra lui donner le lien complet de la publication. Voilà pourquoi quand vous vous abonnez à un nouveau compte, vous ne verrez peut-être pas ses plus anciens posts, voire même un profil vide de publications si vous êtes le premier de votre serveur à vous y abonner.

Citations

Il est désormais possible de citer des publications d’autres membres, pour peu que celui-ci l’ait autorisé. Vous gardez le contrôle de qui peut vous citer (tout le monde, abonnés ou personne) : à la fois par défaut dans les réglages de votre profil, et pour chaque publication au moment de poster. Et vous pouvez modifier ce réglage a posteriori.

Vie privée

N’oubliez jamais que tout ce qui est publié en mode public est visible… publiquement. Comme toujours sur internet, vous ne pourrez pas garantir que le contenu n’a pas été copié par un robot et son effacement ultérieur est donc incertain. Réfléchissez bien avant de publier publiquement…

Certains réglages de votre profil permettent de définir le comportement vis-à-vis de l’indexation de moteurs de recherche, etc. mais là encore, cela ne vous rend pas invisible sur internet.

Vous pouvez changer la visibilité par défaut de vos publications pour par exemple la définir sur « abonnés seulement », les rendant non visibles publiquement, mais si c’est votre intention alors je vous recommande de verrouiller l’abonnement à votre compte afin d’accepter les nouveaux prétendants, sinon n’importe qui pourra voir vos publications simplement en s’abonnant à vous.

Enfin, comme le rappelle la bannière de Mastodon, les « messages privés » ne sont pas chiffrés de bout-en-bout. Concrètement, cela veut dire qu’ils peuvent potentiellement être lus par l’administrateur du serveur source et destination (mais aussi par des intermédiaires techniques,…) Si cela vous pose un souci, n’utilisez par ce moyen pour communiquer mais préférez une messagerie sécurisée offrant un chiffrement fiable (nous offrons XMPP, par exemple).

Masquage

Vous n’aimez pas ce que certains comptes publient et vous ne voulez plus les voir dans votre fil ? Utilisez le masquage dans les options sur leur profil et vous ne verrez plus leurs publications.

Blocage

Si certains comptes vous dérangent carrément et que vous voulez cesser toute interaction avec eux, utilisez alors le blocage : plus fort que le masquage, cela coupera toute visibilité réciproque et toute interaction comme par exemple les commentaires. Ce sera comme si le compte n’existait plus pour vous (et vice-versa pour l’autre). Si le compte publie du contenu contraire aux règles du serveur, vous pouvez en plus créer un signalement.

Filtrage

Pour être plus fin sur ce que vous voyez ou ce que vous souhaitez cacher derrière un avertissement de contenu, vous pouvez également dans vos options de profil définir un ou plusieurs filtres basés sur des mots-clefs qui vous permettront de contrôler davantage les articles apparaissant dans votre fil.

Suppression automatique

Par défaut, vos publications restent permanentes, mais vous pouvez définir une durée après laquelle elles seront automatiquement effacées. Notez également que des exceptions sont possibles, par exemple pour celles épinglées ou celles ayant un marque-page, pour un nettoyage moins destructif selon votre choix.

Vérification

Dans un système fédéré sans autorité centrale, la notion de vérification de compte (pour authentifier qu’un compte appartient bien à son auteur) n’est pas possible directement. Le stratagème défini par Mastodon pour s’en rapprocher est de certifier qu’un site internet (réputé être sous le contrôle de l’auteur ou de son organisation) renvoie bien au compte Mastodon de l’auteur.

Cela se matérialise de la manière suivante : j’ai confiance dans le site gayfr.online et je sais que son auteur s’appelle Barbapulpe ; sur le profil Mastodon de Barbapulpe, j’ai un lien vers ce site et celui-ci apparaît comme validé par un marquage vert ou avec une coche. Cela fonctionne car pour obtenir ce résultat, il faut créer un lien spécial sur le site gayfr.online que seul son administrateur contrôle.

La manipulation nécessaire est décrite dans l’option correspondante de votre profil.

Changement de serveur

Vous souhaitez changer de serveur ? C’est possible ! Vous pouvez le faire à de multiples reprises, mais dans la limite d’une fois par mois maximum (pour éviter les abus). Sachez toutefois que si vous garderez globalement vos abonnements et vos abonnés, vous perdrez vos publications existantes qui ne seront pas reprises sur le nouveau serveur.

Voici les étapes à réaliser :

• Sauvegarder votre profil depuis l’ancien serveur : avant de migrer, il est conseillé de sauvegarder votre profil et vos données. Bien que vous ne puissiez pas transférer vos publications, vous pouvez conserver une copie de votre profil.
• Créer un nouveau compte : inscrivez-vous sur le nouveau serveur Mastodon que vous souhaitez rejoindre.
• Importez ensuite sur ce nouveau compte toutes les données sauvegardées précédemment que vous souhaitez récupérer (abonnements, listes, marque-pages, blocages…)
• Toujours à partir de ce nouveau serveur, dans les préférences de votre compte, créez un alias avec l’ancien compte dans l’option « déplacement depuis un compte différent ».
• Connectez-vous ensuite à votre ancien compte sur l’instance d’origine, et dans les préférences de votre compte, sélectionnez l’option « déménager vers un compte différent » et entrez le nom d’utilisateur de votre nouveau compte. Cette opération est irréversible !
• Vérifier la redirection : une fois la migration effectuée, votre ancien compte affichera un message indiquant que le profil a été déplacé, et vos abonnés seront redirigés progressivement vers votre nouveau compte.
• Finaliser la migration : après « un certain temps », vous pouvez choisir de supprimer votre ancien compte si tout fonctionne correctement sur le nouveau serveur.

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Version française (English version below)

Voici un article court et une fois n’est pas coutume, il est rédigé en français et en anglais, sous la forme d’une FAQ (foire aux questions).

Les services de GayFR sont-ils tous gratuits ?

Oui. Nous vous offrons dix applications du fédiverse toutes interconnectées, une messagerie instantanée ainsi qu’un lecteur de flux RSS, le tout pour la modique somme de zéro (insérer votre devise ici).

Quelle est la contrepartie ?

Il n’y en a pas. Vos données personnelles restent protégées et privées et ne seront jamais exploitées ni revendues, nos services sont assurés de manière éthique, sans aucun objectif commercial ni de rentabilité.

Alors, pourquoi fournir ces services ?

C’est une manière de rendre à la société ce qu’elle m’a donné, et un moyen de vous permettre de vous exprimer en un lieu sûr, à l’abri de l’homophobie et de toute forme de discrimination.

C’est aussi ma façon de lutter contre le mépris des libertés individuelles et de la vie privée en fournissant une plateforme éthique qui ne poursuit aucun but capitalistique ni de promotion d’idéologies politiques toxiques.

Est-ce que ça a un coût ?

Bien sûr ! Cela se présente sous deux formes.

Coût financier

Les coûts comprennent l’achat des quatre noms de domaine et e-mails correspondants, la location des trois serveurs virtuels ainsi que celle de l’espace de stockage objet S3. Et je remercie ici tous les développeurs des applications gratuites en source ouverte !

Peu importe les montants puisque je ne demande aucun contribution ! Si cela vous intéresse, contactez-moi directement.

Effort humain

C’est probablement le plus exigeant. Une fois passée la phase d’installation des services, qui s’est réalisée très progressivement et qui s’est étalée sur presque trois ans, depuis l’instance Mastodon initiale jusqu’à l’ajout des derniers services, nous sommes désormais en régime de croisière.

Je réalise des mises à jour hebdomadaires car c’est crucial pour la sécurité ! Et accessoirement, cela apporte de nouvelles fonctionnalités. Disons que cela peut prendre une heure quand il y a peu de mises à jour, à quelques heures chaque semaine quand il y en a beaucoup.

Et tous les deux ans, compte tenu du modèle commercial du fournisseur des serveurs virtuels, je migre intégralement chaque serveur, ce qui est sain par ailleurs car cela me permet de les reconstruire sur une base saine.

Enfin, c’est peu fréquent mais il peut y avoir des interventions en urgence quand une partie du système tombe en panne.

Pourquoi ne rien faire payer ?

Parce que cela changerait notre relation ! Et parce que j’ai la chance de ne pas en avoir besoin, je préfère dès lors donner plutôt que de tarifer ces services.

Certains permettent de faire des dons et c’est très bien. Quant à moi je ne veux pas d'argent, c’est mon choix.

Si vous voulez contribuer et m’aider, continuez à lire…

Peut-on avoir confiance ?

Oui. Bien sûr, je ne vais pas répondre autre chose… Alors pour être plus convaincant, je vous dirai que j’offre ces services depuis plus de trois ans et tous nos membres peuvent témoigner que cela se passe bien et n’ont jamais eu de problème à déplorer ici.

Maintenant, en tant qu’administrateur j’ai toute visibilité sur les applications et les données que vous y mettez (sauf la messagerie instantanée chiffrée). Tout personne avec les droits root qui vous dirait le contraire est soit un menteur, soit un incompétent ! Donc, si vous n’êtes pas convaincu, ne venez pas, je ne peux pas vous dire mieux…

Comment contribuer ?

Je souhaite que ces services soient utiles, donc utilisés ; ainsi, si vous voulez aider, parlez-en autour de vous, faites-en de la publicité, inscrivez-nous dans des annuaires ou des articles sur tous les médias appropriés… Plus nous aurons de membres de qualité, plus cela aura du sens et bénéficiera à l’ensemble de la communauté.

Merci de votre fidélité !

Ah au fait, si vous cherchez nos services, allez voir en cliquant ici.

---

Here it’s free… but you are not the product

English version

Here is a short article, and for once, it is written in English and French, in the form of an FAQ (frequently asked questions).

Are all GayFR services free?

Yes. We offer ten interconnected Fediverse applications, instant messaging, and an RSS feed reader, all for the modest sum of zero (insert your currency here).

What's the catch?

There isn't one. Your personal data remains protected and private and will never be exploited or resold. Our services are provided ethically, without any commercial or profit-making objectives.

So why provide these services?

It's a way of giving back to society what it has given me, and a way of allowing you to express yourself in a safe place, free from homophobia and all forms of discrimination.

It is also my way of fighting against the disregard for individual freedoms and privacy by providing an ethical platform that does not pursue any capitalist goals or promote toxic political ideologies.

Does it come at a cost?

Of course! There are two types of costs.

Financial cost

The costs include the purchase of the four domain names and corresponding email addresses, the rental of the three virtual servers, and the rental of S3 object storage space. And let me thank here all the free open-source application developers!

The amounts are irrelevant, as I am not asking for any contribution! If you are interested, please contact me directly.

Human effort

This is probably the most demanding aspect. Once the service installation phase was complete, which took place very gradually over almost three years, from the initial Mastodon instance to the addition of the latest services, we are now in a steady state.

I perform weekly updates because it's crucial for security! And incidentally, it brings new features. Let's say it can take an hour when there are few updates, to a few hours each week when there are many.

And every two years, given the business model of the virtual server provider, I migrate each server in its entirety, which is healthy because it allows me to rebuild them on a sound basis.

Finally, it's rare, but there can be emergency interventions when part of the system goes down.

Why not charge anything?

Because it would change our relationship! And because I am fortunate enough not to need to, I prefer to give rather than charge for these services.

Some offer the possibility of donating and that’s great. As for me I don’t want any money, it’s my choice.

If you want to contribute and help me, keep reading…

Can we trust you?

Yes. Of course, I'm not going to say anything else… So to be more convincing, I'll tell you that I've been offering these services for over three years and all our members can testify that everything is going well and they've never had any problems here.

Now, as an administrator, I have full visibility of the applications and data you put on them (except for encrypted instant messaging). Anyone with root privileges who tells you otherwise is either a liar or incompetent! So, if you're not convinced, don't come, I can't say any more than that…

How to contribute?

I want these services to be useful, and therefore used, so if you want to help, spread the word, advertise us, list us in directories or articles in all appropriate media… The more quality members we have, the more meaningful it will be and the more it will benefit the entire community.

Thank you for your loyalty!

Oh, and if you're looking for our services, click here.

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Bien commencer pour les utilisateurs débutants

Voici mon second article consacré à Mastodon, destiné à expliquer aux utilisateurs débutants comment bien commencer.

Si vous ne l'avez pas encore fait, je vous conseille la lecture de la partie 1 (concepts et philosophie de Mastodon). J’aborderai ensuite dans un prochain article quelques fonctionnalités avancées.

Si vous êtes ici c'est que je présume que vous savez lire et cliquer, donc je ne vais pas vous encombrer avec un carrousel de photos d'écrans pas-à-pas. Je m'attacherai seulement aux points spécifiques à Mastodon et qui me paraissent importants pour bien débuter.

On choisit son serveur

Voilà ce qui vous prendra le plus de temps (peut-être) : choisir son serveur (ou instance, c'est pareil ici). On l'a dit, ce choix n'est pas irréversible, donc on pourra le changer plus tard, moyennant quelques opérations et limitations que nous détaillerons dans une prochaine partie.

La voie rapide

Vous êtes pressé, cela ne vous dérange pas d'être sur un serveur hébergeant des centaines de milliers de comptes aux intérêts très divers, avec une majorité anglophone ? Vous pourriez choisir le serveur opéré par l'organisation Mastodon : mastodon.social

Mais cela me fait mal d'écrire ça, car ce serveur est déjà tellement gros qu'il travaille à l'encontre de la philosophie de décentralisation (et ce d'autant plus que c'est le choix par défaut sur l'application Mastodon officielle). Il est fiable, probablement là pour durer, une valeur sûre, je dois l'admettre.

Ceci étant, je vous le déconseille, pour les raisons précédentes, et aussi parce que vous pourriez trouver une expérience plus enrichissante et plus sympathique sur un serveur francophone proche de vos intérêts, et c’est là toute la valeur d’un réseau décentralisé.

Un peu plus sélectif

Si vous voulez évoluer sur un serveur plus petit, regroupant une communauté d'intérêts de ses membres, peut-être plutôt francophone, recherchez alors dans des annuaires en filtrant, par exemple ici ou là.

Lisez la présentation détaillée, regardez le nombre d'utilisateurs, l'ancienneté du serveur... Et lisez ce qui se publie sur la page d'accueil du serveur ainsi que ses règles de fonctionnement (en bas de la présentation détaillée), pour voir si ça correspond à l'esprit que vous recherchez. Et si vous connaissez l'administrateur (et que vous lui faites confiance !), ne cherchez pas plus loin : c'est là qu'il faut aller !

Et petit coup de pub : n’hésitez pas à venir chez nous !

Une recherche fine (niveau avancé)

Si vous êtes du genre perfectionniste, c'est que comme moi vous recherchez un serveur fiable, avec un administrateur de confiance. C'est important car c'est la garantie de la sécurité de vos données et de la pérennité du service.

Ce n'est pas facile à détecter à distance, néanmoins quelques indices peuvent vous mettre sur la voie, sans que cela ne soit une absolue nécessité ni une assurance tous risques : le serveur est-il à jour à la dernière version ? Dispose-t-il sur sa page d'accueil d'un lien “Status” ou “État” montrant son état de santé ? Sa politique de confidentialité et ses conditions d’utilisation sont-elles personnalisées et rédigées en français, ou bien s'agit-il du modèle générique en anglais ? Le texte de présentation et les illustrations sont-elles soignées ? Le serveur offre-t-il des fonctionnalités en plus qui pourraient vous intéresser (limite étendue du nombre de caractères,...) ? L'administrateur est-il seul, se fait-il aider pour la modération ?

Tout cela montre le temps et l'investissement passé par l'administrateur à mettre en place et maintenir le service, et mon ancien métier d'auditeur m'a appris qu'en général, c'est un tout : quand la maison est bien tenue, c'est propre dans chaque pièce.

On choisit son application

Ça y est, le plus dur est fait. Côté application, je ne vais pas y aller par quatre chemins, d'abord car ce n'est pas mon domaine de prédilection, et ensuite car je trouve que Mastodon est très bien conçu pour fonctionner avec un navigateur, que ce soit sur PC ou sur smartphone. Choisissez le vôtre, je reste quant à moi fidèle à Firefox (quoique, avec l’arrivée de l’IA… mais c’est un autre sujet).

Sinon vous avez plein d'applications sur Android ou iOS dont certaines apportent des fonctionnalités en plus (de confort en général), je vous laisse chercher par vous-même, mais je reste convaincu qu'on ne devrait pas avoir à payer pour une app. qui se connecte sur un serveur opéré bénévolement. Votre choix.

De toutes façons vous pourrez changer sans douleur ultérieurement et autant de fois que vous voudrez, il faudra seulement se reconnecter.

Et on crée son compte

Sur le serveur sélectionné, on clique sur le bouton “Créer son compte”, et on nous présente alors un écran de synthèse des principales règles du serveur. Lisez-les. Toutes. Vous les aviez déjà lues ? Relisez-les. Elles ne vous conviennent pas ? Choisissez un autre serveur. Elles vous conviennent ? Acceptez.

Vous créerez ensuite votre nom d'utilisateur : choisissez bien, vous ne pourrez pas le modifier après ! Vous devrez également cocher la petite case attestant que vous adhérez à la politique de confidentialité et les conditions d’utilisation, vous savez, ces documents que personne ne lit jamais, mais qui sont pourtant la base juridique du contrat qui vous lie au fournisseur du service. Faites comme vous voulez, moi je lis au moins les paragraphes qui me paraissent essentiels...

Ensuite vous devrez confirmer votre adresse mail (classique), et voilà : vous avez désormais un compte sur le serveur sélectionné. Ce compte sera identifié de la manière suivante (sans espace) : @votrecompte @serveur.sélectionné. Oui, car vous avez un serveur de rattachement, et pour que d'autres personnes puissent interagir avec vous, il faut qu'elles le connaissent. Autre subtilité : votre nom de compte pourrait ne pas être unique si quelqu'un d'autre a utilisé le même nom sur un autre serveur, par exemple @votrecompte @autre.serveur, dans ce cas il s’agit bien de deux comptes totalement distincts. Essayez d'être original pour éviter les possibles confusions...

La minute sécurité : vous avez la possibilité de créer un second facteur d'authentification (avec une application d'authentification classique de type Google Auth.), faites-le ! Au passage, faites-le aussi pour tous vos autres comptes...

Et maintenant, quoi ?

Vous êtes sur un réseau social, vous vous souvenez ? Vous allez donc vouloir interagir avec d'autres personnes (sinon, vous vous êtes trompé d'endroit et de blog...). Donc, rechercher d'autres comptes avec qui vous pourriez avoir des affinités, et vous faire connaître. Autrement dit, des abonnements et des abonnés.

Premier réflexe, valable pour tout réseau social : complétez votre profil. Une biographie qui colle à votre style, une image d'avatar et une bannière (ici, des images “correctes” et non “explicites”, on y reviendra). Donnez envie. Personne ne souhaite réellement s'abonner à un profil vide qui n'a jamais rien publié.

Puis attendez, une foule en délire va rapidement venir s'abonner à vous... Non je déconne, au contraire si vous vous arrêtez là il ne se passera pas grand chose. Car le fonctionnement sur Mastodon est très différent de X (l'ancien Twitter, quoi) en ce qui concerne la visibilité :

• Sur X, tout le monde peut potentiellement voir tout le monde dès le commencement, même si on vous pousse des suggestions de comptes selon un algorithme mystérieux dont le but est de monétiser le service.
• Sur Mastodon, quand vous commencez vous êtes connu sur votre serveur d'inscription uniquement, et pour être connu d'un autre serveur, il faut être suivi par au moins un compte sur cet autre serveur (avoir au moins un abonné), ou bien qu’une personne de ce serveur ait interagi avec une de vos publications.

Donc, deux attitudes : soit vous voulez vous limiter à interagir avec les personnes de votre serveur ou à qui vous vous abonnez (qui souvent s'abonneront alors à vous en retour), soit vous voulez que d'autres comptes vous “découvrent” et vous avez alors intérêt à susciter des abonnés sur plusieurs serveurs. C'est pour ça que quand certains disent “le nombre d'abonnés, ce n'est pas important”, je répond “ça dépend” (la réponse typique des experts).

Les usages de Mastodon

Sur Mastodon, il y a des usages hérités d'une communauté initialement resserrée et qui se perpétuent. Certaines personnes y sont particulièrement sensibles, aussi il est important de les respecter.

L'introduction

Créez une première publication (voir ci-dessous) pour vous présenter, dans laquelle vous mettrez le hashtag #introduction. Hashtag, kézako ? Ce sont des mots précédés d'un dièse, qui peuvent être recherchés sur tous les serveurs. Très pratique pour typer des thèmes, des sujets et les partager.

Le fameux “CW”

Quand vous publiez, vous avez une option “avertissement de contenu” dite aussi “CW” (voir ci-dessous). Toute publication qui pourrait choquer d'une manière ou d'une autre (et la palette peut être large) doit en comporter une, cela a pour effet de masquer le texte derrière un titre (qui explicite ce que l'on peut s'attendre à voir ou à lire) qu'il faut cliquer pour y accéder.

Vous devrez de plus marquer le média comme “sensible” si vous mettez une pièce jointe potentiellement choquante (sexuellement explicite, par exemple). Veillez à bien respecter ces deux principes, et à respecter les éventuelles règles plus contraignantes de votre serveur : c'est important pour éviter que des personnes “innocentes” ne tombent par erreur sur un contenu qui puisse les choquer, et incidemment cela peut vous valoir un avertissement ou un blocage si vous le faites de manière répétée.

Le “ALT-text”

Quand vous associez une image à votre publication, veillez à mettre un texte décrivant son contenu dans le champ prévu à cet effet, ceci afin que les personnes malvoyantes nécessitant une assistance puissent en comprendre le contenu.

Boost et favoris

Certains disent que les partages (boost) et favoris (like) ne sont pas importants dans Mastodon car contrairement à X, ils ne nourrissent aucun algorithme.

Je ne suis pas d'accord : pour son auteur, c'est un encouragement et un motif de satisfaction de savoir si sa publication a été jugée intéressante ou a plu, c'est comme dire “merci” à quelqu'un qui vient de parler. Donc, n'hésitez pas !

Bienveillance

Le plus important pour la fin : la discrimination, les discours toxiques, les trolls et autres indésirables sont la raison pour laquelle une grande partie des membres de Mastodon a fui X, ils seront donc impitoyablement traqués et exterminés. Ici on est là pour intergair de manière bienveillante, respectueuse et constructive, vous êtes les bienvenus dans cet esprit.

En avant

Vous savez à peu près tout, vous êtes prêt à publier. Je vous laisse le soin de parcourir les multiples options pour enrichir votre profil, vos options d'affichage, etc. C'est plutôt bien décrit dans l'application.

Un tout dernier mot sur la visibilité de ce que vous publiez, vous avez différentes options : aux personnes mentionnées seules, à tous vos abonnés, public et non listé. La différence entre les deux dernières est la suivante : “public” apparaîtra dans les flux de tous les serveurs qui vous connaissent (voir plus haut), “non listé” n'y apparaîtra pas.

De votre côté, vous verrez toujours dans le “fil public local” toutes les publications publiques des autres membres de votre serveur, et dans le “fil public global” toutes les publications publiques de tous les autres membres connus de votre serveur – ce qui peut faire du monde et un fil bien encombré ! Finalement vous préférerez peut-être la partie “accueil” où vous verrez les publications de ceux que vous avez choisi de suivre...

Enfin, n’oubliez jamais ce qui peut paraître comme un truisme : ce qui est en visibilité publique est visible… publiquement. Vous aurez beau l’effacer par la suite, vous n’aurez pas la garantie que quelqu’un ne l’a pas copié entretemps. Soyez donc responsable et sélectionnez bien ce que vous souhaitez montrer au monde entier.

À bientôt sur Mastodon !

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling

Quelques concepts de base pour les utilisateurs débutants

Pour mon premier article de blog, quoi de plus logique que de vous parler de Mastodon, puisque je suis l'administrateur d'un tel serveur ?

Je détaille ici ma vision sur les concepts et la philosophie de Mastodon. J'aborderai dans un prochain article comment débuter avec les fonctions de base de Mastodon, et plus tard encore quelques fonctionnalités avancées.

Mastodon, c'est quoi ?

Mastodon, c'est un réseau social décentralisé de micro-blogging du fédiverse.

Oulà, stop ! Pas de termes techniques, ici le but de cet article est de s'adresser sans complexes aux utilisateurs non informaticiens. Car ces derniers (j'en fais partie) parlent toujours avec des mots compliqués, anglicisés, techniques, inaccessibles au commun des mortels. En fait ce n'est pas leur apanage, tous les experts utilisent un jargon, vous connaissez peut-être des juristes, des comptables, des architectes, des marins,...? Quand on n'est pas de la partie, pas toujours facile à suivre. La différence c'est que tout le monde aujourd'hui utilise un ordinateur et peut se croire un peu informaticien, jusqu'à ce qu'un spécialiste se délecte de lui faire perdre ses illusions en étalant à sa face son verbiage (pas toujours à bon escient, d'ailleurs).

Mais je m'égare. Parlons simplement, et répondons à la question : Mastodon, c'est quoi ?

Réponse simple : c'est comme Twitter. Ou plutôt maintenant, il faut dire “X” (pas facile de rester simple...). Ou encore, c'est un site pour publier des messages courts, où vous avez un compte, vous suivez d'autres comptes et d'autres comptes vous suivent, et chaque compte suiveur voit les publications des comptes suivis. Vous me suivez ?

Oui, mais quelle différence avec X alors ?

Là aussi, c'est simple : X appartient et est géré (comment, c'est un autre débat) par une entreprise privée, quand Mastodon n'appartient à personne et est géré par une multitude de bénévoles.

Comment est-ce possible ? Le programme informatique de Mastodon est développé collectivement et bénévolement et publié (en source ouverte) par une organisation à but non-lucratif européenne, et il est installé sur un ensemble de machines informatiques (“serveurs”) par des personnes bénévoles (“administrateurs”). Ces serveurs communiquent entre eux et permettent à l'utilisateur de suivre des personnes, où que leur compte soit hébergé.

C'est fondamentalement différent du modèle de X, où il n'existe qu'un serveur centralisé (en fait, un ensemble mais ce n'est pas important ici), une seule équipe d'administrateurs, un programme informatique propriétaire qui utilise des algorithmes au service de la monétisation du produit pour l'entreprise. Car ne nous y trompons pas : quand une entreprise, dont le but est d'être rentable, met à disposition un service gratuit, c'est que le produit, c'est vous (vos données personnelles !).

Au-delà des aspects techniques, il existe une dimension idéologique dans ce schéma, qui oppose le système capitalistique des grandes entreprises du numérique (X, Meta, Google,...) à un système auto-géré à la main des citoyens. Ceci explique en partie que les utilisateurs de Mastodon, qui sont souvent issus des réseaux sociaux traditionnels qu'ils ont fui, soient généralement des personnes soucieuses de leur liberté, de leur vie privée et farouchement opposées à toute forme de discrimination ou de biais algorithmiques qui leur seraient imposés. C'est aussi une continuation de l'esprit open-source, des programmes informatiques développés collectivement et bénévolement et mis à la disposition de tous.

Mais pour moi utilisateur, ça change quoi ?

On entend souvent dire que “Mastodon, c'est plus compliqué que X”. Ce n'est pas vraiment vrai : si on commence avec les fonctions de base, c'est presque aussi simple. Évidemment, l'interface utilisateur est différente, mais c'est le cas pour chaque réseau social, il suffit de s'y habituer. Le problème vient souvent du fait que Mastodon est promu par ses développeurs ou ses administrateurs, une population par nature technique et passionnée, qui a souvent cœur à vouloir montrer les différences subtiles et les fonctionnalités avancées. Et on perd tout le monde, surtout qu'on n’en a pas vraiment besoin, au moins pour une utilisation courante.

Vous avez noté mes termes : pas vraiment, presque... Oui, car il existe une différence notable à laquelle le débutant est exposé dès son entrée : le choix de son serveur (ou instance, c'est pareil ici). Car comme on l'a dit, le réseau n'est pas centralisé, il faut donc choisir où l'on créera son compte.

Pour bien comprendre, la meilleure analogie est celle de la messagerie électronique : quand vous créez un compte mail, vous choisissez un fournisseur de service (gmail, hotmail, yahoo,...). Mais à partir de là, vous pouvez recevoir et envoyer des mails à n'importe qui. Ici, c'est pareil.

Est-ce à dire que le choix du serveur n'est pas important ? Oui et non.

Pas très important, car vous pourrez changer d'avis après en migrant votre compte sur un autre serveur (même s'il vaut mieux ne pas faire cela trop souvent, nous verrons dans le prochain article pourquoi). Et si vous choisissez un serveur bien interconnecté aux autres (on dit fédéré), vous pourrez interagir avec tout le monde, y compris sur les autres serveurs.

Un peu quand même, car chaque serveur a ses propres règles, notamment en matière de ce qui peut y être publié. Elles sont résumées lors de votre inscription, lisez-les bien pour voir si elles vous conviennent ! Et aussi car vous aurez une relation plus proche avec les autres membres du même serveur (même si vous n'y êtes pas obligé), donc si vous avez des centres d'intérêt particuliers et que vous trouvez un serveur spécifiquement centré dessus, vous aurez plus de chances de “rencontrer” d'autres personnes qui les partagent. Et la langue du serveur peut également être importante, les serveurs francophones étant encore peu nombreux.

Mais comment faire confiance à Mastodon ?

Bénévolat, beaucoup de serveurs et d'administrateurs... Finalement, tout cela est-il bien fiable ? Ne vaut-il pas mieux faire confiance à une grosse entreprise de professionnels ?

Je ne commenterai pas le dernier point, ceux qui ont suivi les soubresauts de Twitter / X et de Meta auront peut-être une opinion. Pour le premier, l'inquiétude est légitime et soyons honnêtes, tout n'est pas parfait !

Mastodon a été lancé en 2016. Il a beaucoup évolué depuis et avec les dernières mises à jour, il est à un niveau de maturité et de sécurité tout-à-fait correct. Si vous recherchez quelques failles de sécurité et de fuites de données notables, vous en trouverez d'ailleurs un nombre important qui concerne les grandes entreprises du numérique, y compris Meta, Microsoft et Google.

Non, le talon d'Achille n'est pas là : il est paradoxalement dans ce qui fait aussi la force de Mastodon, c'est son caractère décentralisé. Soyons clairs : tous les serveurs et tous les administrateurs ne sont pas au même niveau, que ce soit en ressources et en compétences ; sans parler de quelques éclats mémorables d'administrateurs excédés qui ont sauvagement fermé leur service. A contrario, un serveur qui ferme, ce sont des milliers d'autres disponibles pour y migrer (avec un risque de perdre ses publications et abonnés quand même, si c'est vraiment brutal). Quasiment impossible, donc, d'être banni définitivement parce que sa gueule ne revient pas au propriétaire.

Enfin, les administrateurs sont, en principe, bienveillants, font cela par passion et plaisir, et parce qu'ils partagent la même vocation de tolérance et de service pour fournir à chacun une plateforme leur permettant de s'exprimer. Une bonne base de départ sur un socle de valeurs sain, donc.

Le nombre d'utilisateurs varie au fil du temps, on peut trouver ici par exemple des chiffres mis à jour en temps réel (1 million d'utilisateurs actifs pour 9 000 serveurs à la date de publication de cet article).

Conclusion

Pour conclure ce premier article qui est déjà bien assez long, retenez :

• Si vous voulez bénéficier d'une large exposition potentielle à une base très importante d'utilisateurs, et si cela ne vous dérange pas de confier vos données personnelles à une entreprise aux objectifs douteux dont l'objectif est d'en tirer profit en se réservant le droit de leur usage et de modifier unilatéralement les règles au fil du temps : restez avec X.
• Si vous préférez une audience plus focalisée et moins nombreuse, et si vous faites confiance à un administrateur de la communauté Mastodon pour gérer un serveur avec bienveillance et sans objectif de rentabilité, tentez l'aventure !

À suivre…

---

Techno-Fil et faits divers

Le blog d’un informaticien, animateur de multiples réseaux sociaux du fédiverse, administrateur système versé dans la sécurité informatique et la défense de la vie privée.

Je publierai des articles relatifs à l’informatique, la sécurité, la protection des données personnelles, avec le souci de vulgariser au maximum, plutôt en français mais pas exclusivement.

#infosec #security #privacy #dataprivacy #opensource #sysadmin #linux #fediverse #hardware #watercooling