#dataprivacy

9 posts · Last used 3d

Back to Timeline
@barbapulpe@blogs.gayfr.social · 5d ago

Protéger le fédiverse contre les bots IA

<h3 id="introduction">Introduction [...]</h3> Sensitive
Introduction Cette publication en français est à destination des utilisateurs francophones curieux. Elle sera suivie d’un article plus technique 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
0
0
0
@smeg@assortedflotsam.com · Apr 20, 2026
107
0
212
In reply to
@fediway@fediway.com · Jan 14, 2026
5/X #Fediway is implemented as server-side service that shift the complexity of recommendation logic from the user to the platform itself. 👉 The goal: advanced content discovery that actually competes with large platforms, without sacrificing #dataprivacy. #OpenSource #Mastodon #FediDev
6
1
2
@provadivita@mstdn.business · Feb 22, 2026
👁️ Smart glasses with native facial recognition. Residential surveillance networks. License plate tracking. As biometric wearables and AI-powered surveillance tools proliferate, the conversation around consent, oversight, and civil liberties has never been more urgent. Where do we draw the line? 🔗 https://provadivita.com/biometric-injection-attacks/ #BiometricPrivacy #FacialRecognition #SurveillanceTech #DataPrivacy #AIEthics #DigitalRights #BiometricSecurity #EPIC
0
0
1
In reply to
@AnneTheWriter1@universeodon.com · Feb 02, 2026
@codinghorror@infosec.exchange It's sad that people think an #LLM could ever be an accurate #TaxPreparation service. But it's even sadder that people need to be told to not feed their private financial data to a #chatbot when doing their #taxes . #DataPrivacy #Privacy #TaxTime #AI #PayingTaxes #GenerativeAI #ChatGPT #Finances #Money #PersonalFinances https://money.com/money-ai-privacy-fraud-risk/
0
0
0
@i47i@hachyderm.io · Jan 29, 2026
Lawsuit Alleges That WhatsApp Has No End-to-End Encryption A lawsuit filed in San Francisco alleges that #WhatsApp's end-to-end encryption contains backdoors allowing #Meta employees to access user messages in real-time. According to the complaint, internal tools allow engineers to view chats by User ID without a separate decryption step, bypassing the Signal Protocol protections the app claims to use. The lawsuit cites £whistleblowers who claim that workers can request access to specific accounts via internal tasks, gaining unlimited temporal scope to a user's history, including deleted messages. Meta has labeled these claims false and absurd. Technical experts note that while the Signal Protocol itself is mathematically secure, the integrity of end-to-end encryption relies entirely on the security of the endpoints. Potential vulnerabilities in WhatsApp include unencrypted cloud backups, metadata collection, and the fact that the client software is closed-source. Without the ability to audit the code or verify public keys through an independent directory, users must trust that the application is not exfiltrating plaintext data before it is encrypted for transit. The legal action highlights the ongoing tension between corporate privacy marketing and the technical reality of centralized messaging platforms. If the allegations of an internal "widget" for message access are proven true, it would represent a fundamental breach of the encryption standards Meta has advertised since 2016. https://it.slashdot.org/story/26/01/27/0550249/lawsuit-alleges-that-whatsapp-has-no-end-to-end-encryption #WhatsApp #Meta #Privacy #CyberSecurity #Encryption #DataPrivacy #E2EE #TechNews #Lawsuit #Whistleblower #DigitalRights #Messaging #InformationSecurity #SignalProtocol
2
0
7
@hkamran@vmst.io · Jan 28, 2026
Today is #DataPrivacyDay. Have you heard of California's DROP? It's a new way for Californians a way to delete their personal information from hundreds of data brokers at once! https://hkamran.com/article/california-drop #DataPrivacy #DataPrivacyWeek
2
0
0
@usa@murica.website · Jan 28, 2026
After years of bipartisan attacks on TikTok and its parent company ByteDance, which for a time included an effort to potentially ban the social media app in the U.S., a new U.S. TikTok spinoff has been announced, set to be owned and overseen by a tight-knit consortium of tech and financial megabillionaires, many of whom have had direct business relationships with Trump and members of his… Source This post has been syndicated from Truthout, where it was published under this address.
0
0
1
@technadu@infosec.exchange · Jan 12, 2026
Instagram denies a breach after mass password reset emails, citing a fixed bug — but third-party researchers report conflicting data as 6.2M emails appear in HIBP. https://www.technadu.com/instagram-denies-data-breach-after-password-reset-emails-6-2m-accounts-added-to-hibp/618128/ #InfoSec #DataPrivacy #IncidentResponse
0
0
0

You've seen all posts