Contexte et objectifs
Le service Anubis a été conçu comme une couche de protection contre le scraping automatisé. Face à la multiplication des collectes massives de données, les opérateurs ont choisi d’appliquer un Proof‑of‑Work (PoW) similaire à celui proposé par Hashcash pour le filtrage du spam électronique. L’idée centrale est que chaque visiteur légitime supporte une charge de calcul négligeable, alors que les agents automatisés, en grand nombre, voient leurs coûts augmenter de façon exponentielle.
Architecture du Proof‑of‑Work
Anubis génère un défi cryptographique basé sur le calcul d’un hachage dont le préfixe doit contenir un nombre défini de zéros. Le client doit itérer jusqu’à obtenir un nonce satisfaisant la contrainte, puis renvoyer le résultat. Cette opération repose sur les API JavaScript modernes (notamment crypto.subtle et les fonctions asynchrones) qui ne sont pas disponibles lorsque des extensions de protection comme JShelter désactivent ces fonctionnalités. Le texte indique explicitement que la présence de telles extensions empêche le fonctionnement du défi, imposant aux utilisateurs de les désactiver.
Intégration de WebAssembly
Le titre de l’article révèle que le support de WebAssembly (Wasm) a nécessité une année de travail avant d’être déployé dans Anubis. Bien que le corps du texte ne fournisse pas de métriques précises (versions de moteur Wasm, temps de compilation, taille du binaire), on peut en déduire que l’équipe a dû adapter le moteur JavaScript afin d’exécuter du code Wasm dans le contexte du PoW. Cette adaptation permet de déléguer le calcul intensif du hachage à un module Wasm, qui offre généralement de meilleures performances que le JavaScript natif grâce à une compilation proche du métal. Le gain de vitesse potentiel justifie l’investissement d’une année, surtout pour un défi qui doit être résolu en quelques centaines de millisecondes sur des appareils grand public.
Limitations et perspectives
Le mécanisme PoW d’Anubis présente deux contraintes majeures. Premièrement, il dépend de la disponibilité de fonctionnalités JavaScript avancées ; les navigateurs ou extensions qui les bloquent sont automatiquement bloqués, ce qui peut affecter des utilisateurs légitimes soucieux de leur vie privée. Deuxièmement, le texte ne fournit aucun indicateur de charge moyenne (par exemple, le nombre de zéros requis ou le temps moyen de résolution), ce qui rend difficile l’évaluation de l’impact réel sur les scrapers versus les humains. Enfin, l’ajout de WebAssembly, bien que performant, augmente la surface d’attaque potentielle : chaque module Wasm doit être audité pour éviter les vulnérabilités de type mémoire ou exécution non contrôlée. En l’absence de données publiques sur les audits de sécurité, le risque reste à quantifier.
