Anti-trampas de videojuego
El juego que un visitante juega durante unos segundos es la parte que ves. Debajo está el sistema de anti-trampas que hace que el juego cuente como prueba de un humano. Caputchin toma prestado el manual que los juegos multijugador competitivos usan contra los tramposos: el servidor es autoritativo sobre cada ronda, el juego corre en un sandbox cerrado, y el desenlace se vuelve a derivar repitiendo las entradas del jugador. El juego se puede jugar, no falsear.
Este es el tercer gate de verificación, apilado con el proof of work y la instrumentación. Se configura por clave en la página de Seguridad.
El ciclo de vida
Una ronda atraviesa tres fases: montada en el servidor antes de jugar, corrida en sandbox en el navegador durante el juego, y vuelta a verificar en el servidor después de jugar.
Antes de la ronda: montaje autoritativo del servidor
Todo lo que decide qué es la ronda ocurre en el servidor, nunca en el navegador. Este es el principio de "nunca te fíes del cliente" del anti-trampas multijugador: el cliente envía intención, el servidor decide la realidad.
- Un ticket firmado de un solo uso acuña la ronda. Es de vida corta y solo se puede gastar una vez. Un ticket capturado no se puede repetir en una segunda aprobación.
- El juego y su semilla aleatoria se eligen en el servidor y se llevan en el ticket. El navegador no puede elegir un juego más fácil ni una semilla más amable, porque nunca hace esa elección.
- Un juego distinto del pool elegible cada vez. Un solver nunca sabe a qué juego se enfrentará, así que no puede pre-entrenarse en un único objetivo estático. Los operadores pueden estrechar la rotación, pero el servidor siempre elige del conjunto permitido. El propio pool solo contiene juegos que pasaron una comprobación de conformidad en tiempo de indexación. Mira construye un juego del marketplace.
Durante la ronda: un juego en sandbox
El juego corre en el navegador del visitante, pero dentro de un límite que protege tanto el sitio del visitante como la integridad de la ronda.
<caputchin-game> monta cada juego en un iframe aislado sin acceso de mismo origen, así que el juego tiene un origen opaco y no puede alcanzar las cookies, el almacenamiento, el DOM, ni la red de mismo origen de la página anfitriona. Su content-security-policy inline fija el script a exactamente el bundle del juego y bloquea las llamadas de red salientes, y el bundle se comprueba contra un hash conocido antes de correr (un desajuste falla cerrado). La propia política de seguridad de la página anfitriona queda intacta. La forma precisa del sandbox y la política está documentada en cómo Caputchin pone los juegos en sandbox.
La conclusión: el juego es no-confiable-por-defecto y está contenido. No puede exfiltrar nada, y no puede manipular la página en la que está incrustado.
Después de la ronda: repetición determinista
Cuando el visitante termina, el navegador envía la traza de entradas registrada. El servidor no se fía de la palabra del navegador sobre el resultado. Vuelve a correr la traza.
- La ronda se vuelve a simular en el servidor con la misma semilla derivada del servidor, en un isolate sellado sin acceso a red y con un presupuesto de tiempo duro. Esta es la misma propiedad de la que depende el lockstep determinista en los juegos de estrategia: semilla idéntica más entradas idénticas reproducen un juego idéntico. Una traza que de verdad no superó el juego no reproduce un desenlace aprobado.
- El aprobado o el fallo se toma de esa repetición, nunca de un número que el navegador reportó. Un cliente no puede reclamar una puntuación que no ganó.
- Un token firmado se emite solo si la repetición confirma el juego. Ese token es a su vez de un solo uso cuando tu backend lo confirma más tarde en el momento de la verificación.
Lo que Caputchin no hace
La mayoría de los CAPTCHA de juego e interactivos se apoyan en señales de comportamiento: entropía de la trayectoria del ratón, temporización de toques, telemetría de dispositivo alimentada a un clasificador que adivina bot-frente-a-humano. Caputchin deliberadamente no lo hace. No recoge ningún perfil de comportamiento del jugador. En vez de adivinar cómo se produjeron las entradas, vuelve a derivar si de verdad superan el juego desde primeros principios. Esto es a la vez una postura de privacidad y una de seguridad: no hay modelo de comportamiento que engañar, solo física que reproducir.
Un límite honesto
El gate es tan fuerte como el juego. La maquinaria de anti-trampas prueba que una ronda se jugó genuinamente y no se falseó, pero no puede hacer difícil un juego fácil. Un juego trivial (un tablero estático, la jugada ganadora legible en el DOM, "haz clic en el punto rojo para pasar") es barato de resolver para un script, y la repetición determinista confirmará fielmente que esas entradas con scripts ganan, porque lo hacen. La resistencia a los bots viene de que el propio juego sea difícil de resolver de forma programática: reacciones rápidas, sensoriales, en fracciones de segundo, sin solución sentada en el DOM. La capa de anti-trampas garantiza que el juego fue real; el diseño del juego decide si el juego real fue difícil de automatizar. Elige y construye juegos con eso en mente, mira construye un juego del marketplace.
El aprobado o el fallo lo decide la propia lógica de cada juego; el servidor vuelve a correr fielmente esa lógica pero no cuestiona qué considera una victoria un juego dado. El anti-trampas de videojuego es más fuerte compuesto con el proof of work, la instrumentación, y el resto de los ajustes de seguridad de una clave.