Instrumentation

Le proof of work prouve que de l'effort a été dépensé. Il ne prouve pas ce qui l'a dépensé. Un attaquant déterminé avec une ferme de vrais navigateurs peut broyer les casse-têtes à bas coût. L'instrumentation est la deuxième couche qui comble cet écart : elle prouve que le travail s'est produit dans un navigateur authentique.

Comment ça marche

À chaque requête, Caputchin génère un programme JavaScript frais et à usage unique et l'exécute dans le navigateur du visiteur. Le programme exerce des mécanismes que seul un vrai navigateur possède, et rapporte ce qu'il a observé :

• Des sondes d'API de navigateur qui vérifient qu'une fonctionnalité authentique de navigateur est présente et se comporte correctement.
• Des chaînes de calcul d'opérations bit à bit sur des entiers.
• De l'arithmétique DOM qui construit des arbres d'éléments, lit les valeurs que le moteur de mise en page calcule pour eux, et les démonte.

L'astuce est une asymétrie : un vrai moteur de rendu produit les bonnes réponses presque gratuitement, tandis qu'un runtime headless ou scripté stube ces opérations, les implémente incorrectement, ou les saute pour la vitesse. Le décalage trahit le visiteur.

Content-Security-Policy

Parce que le programme exécute eval dans le navigateur du visiteur, la page qui intègre ton widget doit autoriser 'unsafe-eval' dans sa Content-Security-Policy script-src. Il n'y a pas de repli pour ça : si 'unsafe-eval' est bloqué, le programme ne peut pas tourner et la vérification échoue. Si ta politique ne peut pas l'autoriser, désactive l'instrumentation pour la clé sur sa page Sécurité, ce qui retire l'exigence au prix de la détection des navigateurs automatisés (le proof of work et tout jeu requis tournent encore). Vois bac à sable des jeux pour la politique complète de la page hôte.

Pourquoi elle s'associe au proof of work

Les deux couches couvrent les angles morts l'une de l'autre. Le proof of work seul peut être miné à bas coût par de vrais navigateurs ; l'instrumentation seule pourrait être truquée par un script qui ne fait jamais le travail. Ensemble, elles élèvent le coût sur deux axes indépendants : le proof of work prouve l'effort, l'instrumentation prouve l'environnement.

Obfuscation

Parce que le programme est livré au visiteur, un attaquant motivé pourrait l'étudier et tenter de pré-calculer les réponses. Pour rendre ça plus dur, le programme est obfusqué. La page Sécurité d'une clé expose un Niveau d'obfuscation : le monter rend le programme plus dur à rétro-ingénier, au prix de plus de CPU côté serveur. Les mêmes signaux adossent l'option Bloquer les navigateurs automatisés, qui rejette purement et simplement les clients headless et WebDriver détectés.

Une limite honnête

L'instrumentation n'est pas infaillible. Les navigateurs furtifs corrigent les indices qu'elle cherche, et les vérifications elles-mêmes notent qu'elles peuvent être battues. C'est une couche parmi plusieurs, plus forte quand empilée avec le proof of work et le reste des réglages de sécurité d'une clé.