Integridad de la evaluación en línea y anti-trampas: un modelo progresivo para una app de matemáticas de consumo

Tabla de modelo de amenazas

Ataque	Quién lo hace	Qué tan detectable es	Costo de defender
Buscar la respuesta (buscador, libro de texto)	Cualquier edad/nivel	Tiempo de respuesta muy por debajo del tiempo de resolución humana más rápido plausible; corrección casi instantánea tras inactividad visible/pérdida de foco de la pestaña	Bajo — piso de tiempo de respuesta por ítem en el servidor, eventos de visibilidad de pestaña
El padre/hermano lo resuelve por el niño	Sobre todo niños pequeños	Desajuste de estilo contra la línea de tendencia de habilidad de la propia cuenta	Bajo-medio — solo señal basada en tendencia, nunca punitivo a esta edad
App resolvedora / calculadora en un segundo dispositivo	Niños mayores, adolescentes, adultos	Piso de tiempo de respuesta; un resolvedor responde casi al instante sin importar la dificultad, mientras el tiempo de un humano escala con ella	Bajo-medio — mismo mecanismo de piso, calibrado por tipo de ítem
Un segundo dispositivo responde mientras el principal es el “cronómetro”	Adolescentes, nivel competitivo	Difícil sin atestación de dispositivo; mitigado estructuralmente manteniendo el cronometraje en el servidor, de modo que un segundo dispositivo no gana ventaja medible	Medio — arquitectónico, no una verificación añadida
Compartir respuestas entre amigos	Cualquier edad, contextos de clase	Estadísticas de similitud de respuestas/colusión (omega, GBT, K-index); significativas solo cuando el banco de ítems es grande	Medio-alto — necesita un banco real más maquinaria estadística
Scripts/bots automatizados (repetición de API, navegador headless)	Usuarios técnicos, cazadores de leaderboard	Señales de gestión de bots (huella de comportamiento, prueba de cómputo, TLS/JA3), limitación de tasa, tokens Turnstile/Privacy Pass	Bajo-medio — infraestructura de estantería
Compartir cuenta (un login, muchas personas)	Familias, nivel competitivo	Detección de sesiones concurrentes, desajuste de credenciales WebAuthn, discontinuidad de habilidad	Medio — necesita seguimiento de sesión/dispositivo
Fallar a propósito contenido fácil para cultivar rango (“sandbagging”)	Usuarios competitivos/de leaderboard	Anomalía de varianza contra el propio historial	Medio — necesita una línea base de habilidad/rating mantenida (ya exigida por el tema 18)

Hallazgos

1. Puntuación con autoridad en el servidor y por qué no se puede confiar en el tiempo del cliente

Un navegador es totalmente inspeccionable y modificable por su propio usuario: DevTools puede pausar la ejecución, reescribir variables, repetir solicitudes de red editadas y sobreescribir Date.now()/performance.now(). Es el mismo modelo de amenaza que volvió obsoletas las arquitecturas multijugador “client-authoritative” (el cliente reporta su propio score/tiempo y el servidor simplemente le cree). El servidor debe fechar independientemente el momento en que se sirve la pregunta y en que se recibe la respuesta, y verificar independientemente la corrección — el cliente solo renderiza y recolecta. Nada más escala a un leaderboard donde la velocidad otorga puntos, ya que una duración reportada por el cliente es exactamente lo que más recompensa la manipulación.

2. Estrategia del banco de ítems: tamaño, parametrización, aleatorización, control de exposición

La investigación en CAT ofrece un manual directamente aplicable. La exposición de ítems —la proporción de evaluados que ven un ítem dado— tiende a 1 para los ítems más informativos en un algoritmo adaptativo ingenuo, lo cual es en sí mismo un problema de seguridad: un ítem mostrado repetidamente se vuelve compartible [10]. Tres mitigaciones establecidas: el método Sympson-Hetter (sacar un número aleatorio y compararlo con un parámetro de exposición por ítem antes de administrar siquiera el ítem de mejor ajuste); la selección randomesque/estratificada (elegir al azar entre los 5-10 ítems más informativos, no siempre el mejor único); y el shadow testing (van der Linden — construir en cada paso un examen hipotético completo óptimo para elecciones globalmente, no solo localmente, óptimas) [10]. Debajo de las tres está un banco de ítems grande, cultivado barato mediante generación de ítems parametrizada/algorítmica (una plantilla como a + b = ? con operandos aleatorizados por banda de dificultad) en lugar de ítems autorados a mano — explícitamente la forma práctica de hacer crecer bancos económicamente según la literatura de CAT [10].

3. Detección estadística: valores atípicos de tiempo de respuesta

El modelo log-normal de tiempos de respuesta de van der Linden trata los tiempos de respuesta de una persona a los ítems como gobernados por un parámetro de “velocidad” a nivel de persona junto con parámetros de intensidad temporal y discriminación a nivel de ítem, estructuralmente paralelo a cómo la TRI logística de dos parámetros trata la corrección [11]. Ajustado, admite verificaciones clásicas y bayesianas posterior-predictivas de aberrancia —una respuesta marcadamente más rápida o más lenta de lo predicho— ya aplicadas para detectar comportamiento aberrante en exámenes adaptativos computarizados [11]. Para Math Challenge, la versión práctica al inicio no necesita nada del modelo completo: un piso empírico (“ningún humano verificado resuelve esta clase de ítem en menos de X ms”) es una primera línea de defensa legítima, escalando al modelo más completo solo en niveles donde las apuestas justifiquen la inversión.

4. Detección estadística: índices de similitud de respuestas y colusión

La detección de copia de respuestas/colusión es un subcampo psicométrico establecido, confirmado vía ERIC: el índice omega (Ω) de Wollack (refinado por Maeda & Zhang 2017; Sunbul & Yormaz 2018), la prueba binomial generalizada (GBT) comparada contra omega en potencia/error Tipo I (Zopluoglu & Davenport, 2012), el K-index (Holland) frente a la divergencia Kullback-Leibler (Belov & Armstrong, 2010; Ucar & Dogan, 2021), una medida KL basada en tiempo de respuesta (Man et al., 2018), y un Variable Match Index (Belov, 2011) [12]. Todos comparten una estructura: señalan cuando dos evaluados dan la misma respuesta incorrecta más seguido de lo que el azar predice dada su habilidad individual — una tasa inusualmente alta de respuestas incorrectas idénticas es la firma. Esto solo es significativo cuando el banco de ítems es lo bastante grande para que dos personas converjan por azar en el mismo ítem rara vez.

5. Navegadores de bloqueo y proctoring remoto — y por qué no usarlos con niños

El proctoring remoto con cámara (Proctorio, ExamSoft, Honorlock, Respondus) se disparó durante el COVID-19 y dejó un rastro documentado de daño y rechazo legal:

• La efectividad es dudosa. Se reporta (vía resumen secundario) que la investigación de la Universidad de Twente encontró que la sensibilidad de Proctorio para detectar trampas era “very close to zero” [4].
• Un tribunal federal de EE. UU. declaró inconstitucional una práctica específica. Ogletree v. Cleveland State University trataba de un “room scan” obligatorio por webcam; el caso está documentado como un fallo bajo la Cuarta Enmienda contra la práctica por un tribunal federal de distrito en Ohio (2022) [3].
• Litigio bajo la BIPA de Illinois. Estudiantes alegaron que Proctorio recopiló información/identificadores biométricos sin el consentimiento requerido; Proctorio negó las alegaciones. La BIPA conlleva daños estatutarios de $1,000 (negligente) / $5,000 (intencional) por violación, razón por la cual los proveedores de proctoring enfrentan litigio recurrente de este tipo [13].
• El caso holandés que se cita a menudo va en sentido contrario. Rechtbank Amsterdam, ECLI:NL:RBAMS:2020:2917 (11 de junio de 2020): los Consejos Estudiantiles Central y de Facultad de la UvA buscaron una medida cautelar contra Proctorio; el tribunal rechazó todas las pretensiones, encontrando el tratamiento lícito bajo el Art. 6(1)(e) del GDPR, “necesario” dadas las clausuras por COVID-19, “proporcionado” (cribado automatizado, revisión humana limitada, borrado a 30 días) y “adecuadamente salvaguardado” (almacenamiento en la UE, acuerdo de encargado de tratamiento, DPIA archivada), señalando que Proctorio era “menos invasivo que la vigilancia continua por video en vivo” [5]. Es una victoria judicial genuina para el proctoring — condicionada a un conjunto estrecho y documentado de salvaguardas (retención corta, DPIA, estudiantes adultos, necesidad de pandemia) que no describe nada de una app de consumo para niños de cuatro años.
• Un hallazgo paralelo de discriminación. La VU Amsterdam enfrentó por separado una queja ante el Instituto Holandés de Derechos Humanos alegando que Proctorio discriminó a un estudiante negro; el instituto no encontró discriminación en ese caso, pero la queja se inscribe en el mismo patrón amplio de preocupación por sesgo algorítmico en torno al proctoring (unverified más allá del fragmento).

Conclusión para Math Challenge: el proctoring de niños con cámara/micrófono no tiene lugar en este producto en ningún nivel. Los daños documentados aplican con más fuerza a menores que a los adultos universitarios que involucraron estos casos, y ninguna de las condiciones atenuantes del tribunal de Ámsterdam (necesidad de pandemia, capacidad de consentimiento adulto, DPIA institucional) existe aquí.

6. Atestación de dispositivo en la web en 2026

• WebAuthn/passkeys: API estándar de navegador, funciona en cualquier navegador moderno incluidas las PWA instaladas; vincula una credencial de clave pública a un dispositivo, y un servidor puede almacenar múltiples IDs de credencial por cuenta — WebAuthn en sí no señala automáticamente un “dispositivo nuevo”; esa contabilidad es del lado del servidor [16].
• Private Access Tokens (Apple) / Privacy Pass (IETF): un esquema de tres partes (emisor, cliente, servidor) que prueba que una solicitud proviene de un dispositivo legítimo sin revelar identidad, mediante un flujo de reto-respuesta y validación por firma ciega RSA; integrado en iOS 16+/macOS Ventura+ para reducir CAPTCHAs, e incorporado a Cloudflare Turnstile — pero sin soporte de primera clase confirmado fuera de las plataformas Apple, así que hay que tratarlo como una señal adicional en el tráfico de Safari/iOS, no como un mecanismo general [14][15][18].
• Google Play Integrity API: exclusivamente para apps nativas de Android distribuidas vía Google Play, verificando la autenticidad del binario de la app, la fuente de instalación y la genuinidad del dispositivo — no aplica a una PWA; la propia guía web de Google apunta a otra parte (Privacy Sandbox) [17].
• Apple App Attest: atestación nativa análoga de iOS, atada a la distribución por App Store del mismo modo que Play Integrity está atada a Play Store — no disponible para una PWA no distribuida a través de la App Store.

Lectura práctica para un producto PWA-first: WebAuthn es la única primitiva de vinculación de dispositivo genuinamente disponible en todas partes; Play Integrity/App Attest están estructuralmente no disponibles sin apps nativas envoltorio; los Private Access Tokens son un extra real pero sesgado hacia Apple, ya incorporado a Turnstile.

7. Detección de bots y limitación de tasa

La pila de gestión de bots de Cloudflare combina un motor de ML que puntúa cada solicitud de 1-99 a partir de características de solicitud/encabezados/sesión, un motor de heurísticas que empareja huellas conocidas como maliciosas, y detección basada en JavaScript de navegadores headless, refinada por una cookie de sesión (__cf_bm) que suaviza los puntajes para reducir falsos positivos [18]. Turnstile es la versión de cara al consumidor: pequeños retos JS no interactivos (prueba de cómputo, prueba de espacio, sondeo de web-API, detección de peculiaridades del navegador) en lugar de un rompecabezas visual, tratando ya los tokens Privacy Pass como una entrada [15][18]. La limitación de tasa en los endpoints de envío/puntuación es la capa complementaria más simple: limitar los envíos por cuenta/IP/ventana atrapa el abuso automatizado de alto volumen sin importar si alguna solicitud individual parece humana.

8. Cómo manejan las trampas a escala las plataformas competitivas conocidas

• Codeforces: valora el rendimiento relativo a oponentes de rating conocido dentro de un concurso en lugar de puntos fijos por problema, reduciendo el incentivo de jugar con un valor de puntos crudo (ver la investigación del tema 18, docs/research/2026-07-31-mc-18-leaderboards-competition.md) [1].
• Chess.com: detecta juego sospechoso a partir de “over 100 gameplay factors”, explícitamente sin depender de un solo score de precisión (“Accuracy is not cheat detection”); los sistemas automatizados manejan ~85% de los cierres; ene-mar 2025 vio ~28,000 apelaciones revisadas de 314,000 cierres con una tasa de aprobación de 0.2%; el software Proctor obligatorio de dos cámaras solo se exige en eventos con premio en efectivo; la metodología fue validada externamente por el estadístico de Harvard Natesh S. Pillai (2016) y respaldada por US Chess (2020) [2].
• Duolingo: combate el farming de leaderboard/XP (bots que autocompletan, farming de contenido repetitivo, exploits de tiempo) monitoreando picos inusuales de XP y lecciones completadas irrealmente rápido, respaldado por baneos y reportes de la comunidad — el principio del valor atípico de tiempo de respuesta aplicado informalmente a escala de producto [19].
• Kaggle: es conocido en toda la industria que sus reglas restringen el compartir privado fuera de los límites del equipo, limitan el tamaño de equipo/ventanas de fusión y prohíben las cuentas múltiples, pero los detalles de esta sección son conocimiento general de la industria, no una cita confirmada (la documentación no fue directamente accesible durante esta investigación).
• Kahoot: no se pudo recuperar contenido citable de fuente primaria sobre herramientas de trampas/bots (p. ej., scripts “flooder” de terceros); esto sigue siendo un vacío abierto, no una afirmación con fuente.

Implicaciones de diseño

Una escalera progresiva concreta de seis niveles. Cada nivel solo añade controles sobre la base con autoridad en el servidor del nivel anterior — nada se quita al subir, y nada por encima del nivel 0 se empuja jamás hacia abajo al nivel de un niño más pequeño.

1. Nivel 0 — Kinder (4-6): solo cronometraje/puntuación con autoridad en el servidor, invisiblemente. El servidor fecha independientemente el momento de pregunta servida/respuesta recibida y verifica la corrección; el cliente nunca controla ninguno de los dos valores. Sin UI anti-trampas visible, sin bloqueo, sin mensajes sobre trampas — un padre resolviendo junto a su hijo es el caso de uso previsto, no una amenaza.
2. Nivel 0 — piso de tiempo de respuesta, solo registro. Se registra un tiempo mínimo plausible de resolución por tipo de ítem y se anota si se vulnera, nunca bloqueando ni puntuando cero. Telemetría pura para calibrar niveles posteriores; solo aflora en un futuro panel para padres/tutores, nunca ante el niño.
3. Nivel 1 — Primaria temprana (7-9): monitoreo silencioso de varianza. El servidor sigue la tendencia propia de precisión/velocidad de cada alumno por habilidad; una desviación súbita grande dispara solo una señal suave (dificultad adaptativa ligeramente más cautelosa) — nunca un bloqueo, advertencia o penalización visible.
4. Nivel 1 — limitación de tasa en endpoints de envío. Topes básicos de envíos por cuenta/IP (infraestructura compartida) protegen el backend contra abuso automatizado de este nivel en adelante.
5. Nivel 2 — Primaria tardía/secundaria (10-13): el piso de tiempo de respuesta se vuelve una señal activa y amable. Vulnerar el piso dispara un momento amable de UI (“eso fue rápido — ¿quieres revisarlo de nuevo?”) en lugar de un registro silencioso; vulneraciones repetidas bajan la confianza en la estimación de dominio, nunca anulan puntos. Sigue sin haber candado, ni proctoring, ni alarma a los padres.
6. Nivel 2 — la aleatorización del banco de ítems empieza a importar. La generación parametrizada de ítems (operandos aleatorizados por banda de dificultad) se vuelve el mecanismo de entrega por omisión, ya que este es el rango de edad donde un hermano o compañero de clase gana por primera vez incentivo para heredar un juego exacto de problemas.
7. Nivel 3 — Preparatoria/adolescente general (14-17): Turnstile + vinculación de dispositivo WebAuthn solo en acciones de leaderboard. Turnstile protege los endpoints de envío que afectan el leaderboard (invisible por omisión); las credenciales de dispositivo WebAuthn se introducen para reconocimiento de cuenta, no como requisito de login — señalando “un tercer dispositivo nuevo esta semana” como una entrada, nunca como puerta única.
8. Nivel 3 — se activan las estadísticas de tiempo de respuesta y similitud de respuestas, solo en el ámbito del leaderboard. Una vez que el banco de ítems es lo bastante grande (Hallazgo 4), el servidor corre una verificación simple de valores atípicos de tiempo de respuesta (Hallazgo 3) y, donde las cuentas comparten suficientes ítems comunes, una verificación de similitud de respuestas modelada sobre los índices publicados — circunscrita a la actividad de leaderboard, no a la práctica ordinaria.
9. Nivel 4 — Avanzado/pre-competitivo (16+, inscrito por opción en juego clasificado): control completo de exposición de ítems. La limitación de exposición estilo Sympson-Hetter (Hallazgo 2) acota con qué frecuencia se muestra incluso el siguiente ítem de mejor ajuste a usuarios de habilidad similar, protegiendo el vector de compartición “todos en este rango reciben el mismo siguiente problema” que importa una vez que existen apuestas reales.
10. Nivel 4 — las heurísticas de sesión/cuenta compartida se activan, no solo se registran. La detección de sesiones concurrentes y las señales de discontinuidad de habilidad ahora elevan activamente la volatilidad/RD del rating (como lo haría una cuenta nueva sospechosa), en lugar de solo aparecer en un panel.
11. Nivel 5 — Nivel máximo competitivo/elegible para beca (opt-in, apuestas explícitas, consentimiento del tutor cuando hay un menor): la suite estadística completa, todavía cero cámaras. La maquinaria psicométrica publicada (detección de colusión estilo omega/GBT, el modelo log-normal de tiempos de respuesta más completo) gana aquí su costo, ya que el banco es grande y las apuestas son altas. Incluso en este techo la respuesta es más estadística, nunca una webcam, navegador de bloqueo o captura biométrica — el historial del Hallazgo 5 no da ningún escenario donde el proctoring con cámara/biometría de un menor, o de un adulto sin mandato institucional, sea defendible.
12. Lado del servidor vs. lado del cliente, en cada nivel, sin excepción. Lado del cliente, siempre: renderizar el problema, recolectar la respuesta, retroalimentación local de UI. Lado del servidor, siempre, desde el nivel 0: el par de marcas de tiempo, la verificación de corrección, el score y (nivel 3 en adelante) cada señal estadística de los Hallazgos 3-4 y 7. La autoridad sobre tiempo/corrección nunca se mueve al cliente en ningún nivel — la escalera es progresiva en apuestas, no en confianza en el cliente, que nunca se concede.
13. Lo que deliberadamente nunca le haremos a un niño, en ningún nivel. Sin captura de webcam o micrófono. Sin recopilación de datos biométricos (rostro, voz, dinámica de tecleo, seguimiento de mirada). Sin navegador de bloqueo. Sin supervisor humano remoto. Sin penalización de score ni acción sobre la cuenta visible para un niño bajo el Nivel 3 — por debajo del Nivel 3, las señales son telemetría de calibración y, a lo sumo, un elemento del panel de padres/tutores. Sin encuadre punitivo (“te cachamos haciendo trampa”) en ninguna parte — el peor resultado visible en cualquier nivel es una estimación de dominio de menor confianza o una invitación amable, acorde con el diseño decidido: el anti-trampas permanece casi invisible para los niños pequeños y solo se endurece con apuestas crecientes.

Preguntas abiertas para el dueño del proyecto

1. ¿A qué edad/nivel, si acaso, debería un panel parental mostrar señales de anomalía (Niveles 1-2) — y debería alguna vez ser visible para el niño, siquiera indirectamente?
2. ¿Correrá Math Challenge algún evento con apuestas del mundo real (beca, premio en efectivo, competencia reconocida por escuelas) que justifique la suite estadística completa del Nivel 5, o “nivel competitivo” significa solo derechos de presumir en el leaderboard?
3. ¿Debería la adopción de WebAuthn/passkey ser alguna vez requerida, o siempre opcional, dado que es la única primitiva universal de vinculación de dispositivo pero añade fricción para la cuenta de un niño pequeño?
4. Para el compartir legítimo de cuenta familiar (padre e hijo en un solo login), ¿cómo deberían las heurísticas de sesión del Nivel 4+ evitar marcar por error como sospechoso el cambio normal de dispositivo en familia?
5. ¿Hay interés en publicar una declaración de confianza/seguridad de que Math Challenge nunca usará proctoring con webcam/biometría, como diferenciador frente a productos estilo Proctorio y como señal de confianza para los padres?