Contexte et objectifs

Le groupe Electronic Disturbance Theater (EDT) se situe à l’intersection de l’activisme radical, de l’art performatif et du développement logiciel. Son ambition est de transposer les tactiques de désobéissance civile – blocage physique, sit‑in – sur l’infrastructure d’Internet. En 1998, l’EDT cible les sites du gouvernement mexicain et du gouvernement américain afin de soutenir le mouvement zapatiste et de démontrer la capacité d’une action collective décentralisée à perturber des services en ligne.

Architecture de Flood Net

Flood Net est présenté comme une applet Java capable d’automatiser le rafraîchissement d’une page web. La version tactique 1.0, dévoilée le 10 avril, envoie une requête de rechargement toutes les sept secondes vers la page du président mexicain Zedillo. Le mécanisme repose sur le principe suivant : chaque participant exécute l’applet, qui ouvre une connexion HTTP vers l’URL cible et déclenche la fonction reload() du navigateur à intervalle fixe. L’effet cumulé d’un grand nombre de clients simultanés crée un trafic de requêtes répétées qui surcharge le serveur web, limitant ainsi la disponibilité du service pour les utilisateurs légitimes.

Déploiements et résultats observés

Lors de l’action du 10 avril, plus de 8 000 participants ont utilisé Flood Net contre le site de Zedillo. Les rapports indiquent que le site a été « intermittently blocked », ce qui montre que le seuil de saturation a été atteint malgré un intervalle de sept secondes. Le 10 mai, la même technique a été appliquée au site de la Maison Blanche, avec un intervalle réduit à trois secondes et la diffusion via cinq miroirs. L’absence de compteur sur la plupart des miroirs empêche une mesure précise du nombre de participants, et aucune preuve de blocage effectif n’a été rapportée, probablement en raison de la capacité supérieure du serveur de la Maison Blanche à absorber le trafic supplémentaire.

Contre‑mesures gouvernementales

Le 10 juin, l’EDT a visé le site de la Secretaría de Gobernación mexicaine. Le gouvernement a réagi en injectant un script Java dans la page cible. Ce script détecte l’activité de Flood Net et ouvre successivement de multiples fenêtres pop‑up dans le navigateur de l’attaquant. L’objectif est de saturer les ressources locales du client (mémoire, processus du navigateur) et d’inciter l’utilisateur à interrompre l’applet, neutralisant ainsi le flux de requêtes vers le serveur. Cette réponse montre que la défense contre un « virtual sit‑in » peut être implémentée côté client, contournant la nécessité de renforcer l’infrastructure serveur.

Analyse technique et limites

Flood Net dépend de la disponibilité d’un environnement Java activé dans le navigateur, ce qui restreint son audience aux utilisateurs disposant de la technologie requise. Le choix d’intervalles fixes (7 s, puis 3 s) reflète un compromis entre la charge générée et la probabilité de détection : des intervalles trop courts augmentent le risque de blocage par les filtres de trafic, tandis que des intervalles trop longs réduisent l’impact. De plus, la stratégie repose sur la coopération volontaire d’un grand nombre d’acteurs, ce qui rend la reproductibilité difficile sans une organisation préalable. Les contre‑mesures côté serveur (détection d’IP, limitation de débit) ou côté client (scripts anti‑pop‑up) peuvent neutraliser l’attaque sans nécessiter de modifications d’infrastructure majeures.