Instrumentación
El proof of work prueba que se gastó esfuerzo. No prueba qué lo gastó. Un atacante decidido con una granja de navegadores reales puede triturar puzzles barato. La instrumentación es la segunda capa que cierra esa brecha: prueba que el trabajo ocurrió dentro de un navegador genuino.
Cómo funciona
En cada petición, Caputchin genera un programa de JavaScript fresco y de un solo uso y lo corre en el navegador del visitante. El programa ejercita maquinaria que solo un navegador real tiene, y reporta de vuelta lo que observó:
- Sondas de API de navegador que comprueban que la funcionalidad genuina del navegador está presente y se comporta correctamente.
- Cadenas de cómputo de operaciones de enteros bit a bit.
- Aritmética del DOM que construye árboles de elementos, lee los valores que el motor de layout computa para ellos, y los desmonta de nuevo.
El truco es una asimetría: un motor de renderizado real produce las respuestas correctas casi gratis, mientras que un runtime headless o con scripts deja estas operaciones como stubs, las implementa incorrectamente, o las salta por velocidad. El desajuste delata al visitante.
Content-Security-Policy
Como el programa corre eval en el navegador del visitante, la página que incrusta tu widget debe permitir 'unsafe-eval' en su Content-Security-Policy de script-src. No hay fallback para esto: si 'unsafe-eval' está bloqueado, el programa no puede correr y la verificación falla. Si tu política no puede permitirlo, apaga la instrumentación para la clave en su página de Seguridad, lo que quita el requisito a costa de la detección de navegadores automatizados (el proof of work y cualquier juego exigido siguen corriendo). Mira sandboxing de juego para la política completa de la página anfitriona.
Por qué se empareja con el proof of work
Las dos capas cubren los puntos ciegos de la otra. El proof of work por sí solo puede minarse barato con navegadores reales; la instrumentación por sí sola podría falsearse con un script que nunca hace el trabajo. Juntas elevan el coste en dos ejes independientes: el proof of work prueba esfuerzo, la instrumentación prueba entorno.
Ofuscación
Como el programa se envía al visitante, un atacante motivado podría estudiarlo e intentar precomputar las respuestas. Para hacer eso más difícil, el programa está ofuscado. La página de Seguridad de una clave expone un Obfuscation level: subirlo hace el programa más difícil de ingeniería inversa, a costa de más CPU del servidor. Las mismas señales respaldan la opción Block automated browsers, que rechaza de plano los clientes headless y WebDriver detectados.
Un límite honesto
La instrumentación no es infalible. Los navegadores sigilosos parchean los indicios que busca, y las propias comprobaciones señalan que pueden vencerse. Es una capa entre varias, más fuerte cuando se apila con el proof of work y el resto de los ajustes de seguridad de una clave.