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

Threat model table

Attack	Who does it	How detectable	Cost to defend
Looking up the answer (search, textbook)	Any age/tier	Response time far below the fastest‑plausible human solve time; near‑instant correctness after visible idle/tab‑blur	Low — server‑side response‑time floor per item, tab‑visibility events
Parent/sibling solves it for the child	Young children mostly	Style mismatch vs. the account’s own skill trend line	Low‑medium — trend‑based flag only, never punitive at this age
Solver app / calculator on a second device	Older children, teens, adults	Response‑time floor; a solver returns near‑instantaneously regardless of difficulty while a human’s time scales with it	Low‑medium — same floor mechanism, calibrated per item type
Second device answers while primary device is the “timer”	Teens, competitive tier	Hard without device attestation; mitigated structurally by keeping timing server‑side so a second device gains no measurable edge	Medium — architectural, not a bolt‑on check
Sharing answers between friends	Any age, class contexts	Answer‑similarity/collusion statistics (omega, GBT, K‑index); meaningful only once the item bank is large	Medium‑high — needs a real bank plus statistical machinery
Automated scripts/bots (API replay, headless browser)	Technical users, leaderboard farmers	Bot‑management signals (behavioral fingerprint, proof‑of‑work, TLS/JA3), rate limiting, Turnstile/Privacy Pass tokens	Low‑medium — off‑the‑shelf infrastructure
Account sharing (one login, many people)	Families, competitive tier	Concurrent‑session detection, WebAuthn credential mismatch, skill discontinuity	Medium — needs session/device tracking
Deliberately failing easy content to farm rank (“sandbagging”)	Competitive/leaderboard users	Variance anomaly vs. own history	Medium — needs a maintained skill/rating baseline (already required by topic 18)

Hallazgos

1. Puntuación autoritativa del servidor y por qué no se puede confiar en la temporización del cliente

Un navegador es totalmente inspeccionable y modificable por su propio usuario: las DevTools pueden pausar la ejecución, reescribir variables, reproducir peticiones de red editadas y sobrescribir Date.now()/performance.now(). Este es el mismo modelo de amenaza que hizo obsoletas las arquitecturas multijugador «client‑authoritative» (el cliente informa su propia puntuación/tiempo y el servidor simplemente le cree). El servidor debe registrar de forma independiente la hora en que se entrega la pregunta y la hora en que se recibe la respuesta, y verificar la corrección de forma independiente — el cliente solo renderiza y recoge. Nada más escala a una tabla de clasificación donde la velocidad otorga puntos, ya que una duración informada por el cliente es precisamente lo que la mayoría de recompensas manipulan.

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 examinados que ven un ítem concreto — tiende a 1 para los ítems más informativos en un algoritmo adaptativo ingenuo, lo que constituye un problema de seguridad: un ítem mostrado repetidamente se vuelve compartible [10]. Tres mitigaciones establecidas: el método Sympson‑Hetter (extraer un número aleatorio, compararlo con un parámetro de exposición por ítem antes de administrar incluso el ítem mejor ajustado); la selección aleatoria/estratificada (elegir aleatoriamente entre los 5‑10 ítems más informativos, no siempre el único mejor); y la prueba sombra (van der Linden — construir una prueba hipotética óptima completa en cada paso para decisiones globales, no solo locales) [10]. En la base de los tres está un gran banco de ítems, ampliado de forma económica mediante generación parametrizada/algorítmica de ítems (una plantilla como a + b = ? con operandos aleatorios según la banda de dificultad) en lugar de ítems redactados a mano — la forma práctica explícita de crecer los bancos de forma económica según la literatura de CAT [10].

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

El modelo lognormal de tiempo de respuesta de Van der Linden trata los tiempos de respuesta de un ítem como gobernados por un parámetro de «velocidad» a nivel de persona, junto a parámetros de intensidad temporal e discriminación a nivel de ítem, paralelamente a cómo el modelo logístico de dos parámetros (IRT) trata la corrección [11]. Ajustado, permite controles clásicos y bayesianos predictivos posteriores para la aberrancia — una respuesta notablemente más rápida o más lenta de lo previsto — ya aplicados para detectar conductas aberrantes en pruebas adaptativas informatizadas [11]. Para Math Challenge, la versión práctica no necesita inicialmente el modelo completo: un umbral empírico («ningún humano verificado resuelve esta clase de ítems en menos de X ms») constituye una primera línea de defensa legítima, escalando al modelo completo solo en los niveles donde los riesgos justifican la inversión.

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

La detección de copia/colusión de respuestas es un subcampo psicométrico consolidado, confirmado a través de ERIC: el índice omega (Ω) de Wollack (refinado por Maeda y Zhang 2017; Sunbul y Yormaz 2018), la prueba binomial generalizada (GBT) comparada con omega por potencia/error Tipo I (Zopluoglu y Davenport, 2012), el índice K (Holland) frente a la divergencia de Kullback‑Leibler (Belov y Armstrong, 2010; Ucar y Dogan, 2021), una medida basada en tiempo de respuesta KL (Man et al., 2018) y un índice de coincidencia variable (Belov, 2011) [12]. Todos comparten una estructura: señalan cuando dos examinados dan la misma respuesta incorrecta con mayor frecuencia de lo que el azar predice según su habilidad individual — una tasa inusualmente alta de respuestas idénticas incorrectas es la firma. Esto solo es significativo cuando el banco de ítems es lo suficientemente grande como para que dos personas coincidan en el mismo ítem por azar sea poco frecuente.

5. Navegadores de confinamiento y supervisión remota — y por qué no utilizarlos con menores

La supervisión remota basada en cámara (Proctorio, ExamSoft, Honorlock, Respondus) se disparó durante la COVID‑19 y dejó un rastro documentado de perjuicios y reacciones legales:

• Se duda de su efectividad. Investigaciones de la Universidad de Twente, según un resumen secundario, encuentran que la sensibilidad de detección de trampas de Proctorio es «muy cercana a cero» [4].
• Un tribunal federal de EE. UU. declaró inconstitucional una práctica concreta. Ogletree v. Cleveland State University trató un escaneo de habitación obligatorio mediante webcam; el caso se documenta como una sentencia del Cuarto Enmienda contra la práctica por un tribunal de distrito federal en Ohio (2022) [3].
• Litigio BIPA en Illinois. Estudiantes alegaron que Proctorio recopiló datos biométricos/identificadores sin el consentimiento requerido; Proctorio negó las acusaciones. BIPA establece daños estatutarios de 1.000 $ (negligente) / 5.000 $ (intencional) por infracción, razón por la que los proveedores de supervisión enfrentan litigios recurrentes de este tipo [13].
• El caso holandés a menudo citado va en sentido contrario. Rechtbank Amsterdam, ECLI:NL:RBAMS:2020:2917 (11 de junio de 2020): los Consejos Central y de Facultad de la UvA solicitaron una medida cautelar contra Proctorio; el tribunal rechazó todas las pretensiones, considerando el tratamiento lícito bajo el RGPD art. 6(1)(e), «necesario» por los cierres por COVID‑19, «proporcional» (cribado automatizado, revisión humana limitada, 30‑day deletion), y «adecuadamente salvaguardado» (almacenamiento en la UE, acuerdo de procesador, DPIA archivada), señalando que Proctorio era «menos invasivo que la vigilancia continua en vídeo» [5]. Es una victoria judicial genuina para la supervisión — condicionada a un conjunto estrecho y documentado de salvaguardas (retención corta, DPIA, estudiantes adultos, necesidad pandémica) que no describe nada sobre una aplicación de consumo para niños de cuatro años.
• Un hallazgo paralelo de discriminación. La VU de Ámsterdam enfrentó por separado una queja del Instituto Holandés de Derechos Humanos que acusaba a Proctorio de discriminar a un estudiante negro; el instituto no encontró discriminación en ese caso, aunque la queja forma parte del mismo patrón más amplio de preocupación por sesgos algorítmicos en la supervisión (no verificado más allá del fragmento).

Conclusión para Math Challenge: la supervisión mediante cámara/micrófono de niños no tiene cabida en este producto en ningún nivel. Los perjuicios documentados se aplican con mayor fuerza a menores que a los adultos universitarios involucrados en estos casos, y ninguna de las condiciones mitigadoras del tribunal de Ámsterdam (necesidad pandémica, capacidad de consentimiento adulto, DPIA institucional) existe aquí.

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

• WebAuthn/passkeys: API estándar del navegador, funciona en cualquier navegador moderno, incluidos los PWAs instalados; vincula una credencial de clave pública a un dispositivo, y el servidor puede almacenar varios IDs de credencial por cuenta — WebAuthn en sí no marca automáticamente «dispositivo nuevo», esa gestión corresponde al servidor [16].
• Private Access Tokens (Apple) / Privacy Pass (IETF): 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 desafío‑respuesta y validación de firma ciega RSA; integrado en iOS 16+/macOS Ventura+ para reducir CAPTCHAs, y incorporado en Cloudflare Turnstile — pero sin soporte de primera clase confirmado fuera de plataformas Apple, por lo que se trata como señal complementaria en tráfico Safari/iOS, no como mecanismo general [14][15][18].
• Google Play Integrity API: exclusivamente para aplicaciones Android nativas distribuidas vía Google Play, verifica la autenticidad del binario, la fuente de instalación y la genuinidad del dispositivo — no se aplica a un PWA; la propia guía web de Google apunta a otras soluciones (Privacy Sandbox) [17].
• Apple App Attest: atestación nativa de iOS, vinculada a la distribución a través de App Store de la misma forma que Play Integrity lo está con Play Store — no disponible para un PWA que no se distribuya por la App Store.

Lectura práctica para un producto centrado en PWAs: WebAuthn es el único primitivo de vinculación de dispositivo realmente disponible en todas partes; Play Integrity/App Attest son estructuralmente inaccesibles sin aplicaciones nativas; Private Access Tokens son una ventaja real pero centrada en Apple, ya integrada en Turnstile.

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

La pila de gestión de bots de Cloudflare combina un motor de IA que puntúa cada solicitud de 1-99 a partir de características de petición/encabezado/sesión, un motor heurístico que compara huellas digitales maliciosas conocidas y una detección basada en JavaScript de navegadores sin cabeza, refinada mediante una cookie de sesión (__cf_bm) que suaviza las puntuaciones para reducir falsos positivos [18]. Turnstile es la versión orientada al consumidor: pequeños desafíos JS no interactivos (prueba de trabajo, prueba de espacio, sondeo de API web, detección de peculiaridades del navegador) en lugar de un puzzle visual, ya tratando los tokens Privacy Pass como una entrada [15][18]. La limitación de velocidad en los puntos finales de envío/puntuación es la capa complementaria más sencilla: limitar el número de envíos por cuenta/IP/ventana captura abusos automatizados de gran volumen independientemente de si alguna solicitud individual parece humana.

8. How named competitive platforms handle cheating at scale

• Codeforces: valora el rendimiento relativo a oponentes con rating conocido dentro de un concurso en lugar de puntos fijos por problema, reduciendo el incentivo de manipular un valor bruto de puntos (ver tema 18 de la investigación, docs/research/2026-07-31-mc-18-leaderboards-competition.md) [1].
• Chess.com: detecta jugadas sospechosas a partir de “más de 100 factores de juego”, declarando explícitamente que no se basa en una única puntuación de precisión (“La precisión no es detección de trampas”); los sistemas automatizados gestionan ~85 % de los cierres; de enero a marzo de 2025 se revisaron ~28.000 recursos de 314.000 cierres con una tasa de concesión del 0,2 %; el software obligatorio de dos cámaras Proctor solo se requiere para eventos con premios en efectivo; la metodología fue revisada externamente por el estadístico de Harvard Natesh S. Pillai (2016) y respaldada por US Chess (2020) [2].
• Duolingo: combate la generación de tablas de clasificación y la acumulación de XP (bots de autocompletar, explotación de contenido repetitivo, exploits de temporización) monitorizando picos inusuales de XP y completaciones de lecciones irrealmente rápidas, respaldado por prohibiciones y denuncias de la comunidad — se aplica informalmente el principio de valores atípicos de tiempo de respuesta a escala de producto [19].
• Kaggle: las normas, conocidas en la industria, restringen el intercambio privado fuera de los límites del equipo, limitan el tamaño del equipo/ventanas de fusión y prohíben el uso de múltiples cuentas, pero los detalles de esta sección son conocimiento general de la industria, no una cita confirmada (la documentación no estuvo directamente accesible durante esta investigación).
• Kahoot: no se encontró contenido primario citable sobre trampas/herramientas de bots (p. ej., scripts de “flooder” de terceros); esto sigue siendo una laguna abierta, no una afirmación con fuente.

Design implications

Una escalera progresiva concreta de seis niveles. Cada nivel solo añade controles sobre la base autoritativa del servidor del nivel anterior — no se elimina nada al subir, y nada por encima del nivel 0 se impone nunca a un nivel inferior de un niño más pequeño.

1. Nivel 0 — Educación Infantil (4‑6): temporización/puntuación autoritativa del servidor únicamente, de forma invisible. El servidor marca de forma independiente la hora de entrega de la pregunta y de recepción de la respuesta y verifica la corrección; el cliente nunca controla ninguno de los valores. No hay UI anti‑trampa visible, ni bloqueo, ni mensaje de trampa — un padre que resuelve junto a su hijo es el caso de uso previsto, no una amenaza.
2. Nivel 0 — umbral de tiempo de respuesta, solo registro. Se registra un tiempo mínimo plausible por tipo de ítem y se registra si se supera, sin bloquear ni asignar puntuación cero. Telemetría pura para calibrar niveles posteriores; solo se muestra en un futuro panel de control para padres/tutores, nunca al niño.
3. Nivel 1 — Educación Primaria temprana (7‑9): monitorización silenciosa de la variación. El servidor sigue la propia tendencia de precisión/velocidad del alumno por competencia; una desviación grande y repentina genera 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 velocidad en los puntos de envío. Límites básicos por cuenta/IP en los envíos (infraestructura compartida) protegen el backend del abuso scriptado a partir de este nivel.
5. Nivel 2 — Educación Primaria tardía/educación secundaria (10‑13): el umbral de tiempo de respuesta se convierte en una señal activa y amable. Superar el umbral genera un mensaje amistoso en la UI («¡Eso fue rápido! ¿Quieres volver a comprobarlo?») en lugar de un registro silencioso; las superaciones repetidas reducen la confianza en la estimación de dominio, sin anular puntos. Sigue sin haber bloqueo, proctoring ni alarma parental.
6. Nivel 2 — comienza a importar la aleatorización del banco de ítems. La generación parametrizada de ítems (operandos aleatorios por banda de dificultad) pasa a ser el mecanismo de entrega por defecto, ya que este rango de edad es cuando un hermano o compañero de clase empieza a tener incentivo para pasar un conjunto exacto de problemas.
7. Nivel 3 — Educación Secundaria/general adolescente (14‑17): Turnstile + vinculación de dispositivo WebAuthn solo en acciones de tabla de clasificación. Turnstile protege los puntos de envío que afectan a la tabla de clasificación (invisible por defecto); las credenciales de dispositivo WebAuthn se introducen para el reconocimiento de la cuenta, no como requisito de inicio de sesión — señalando “un tercer dispositivo nuevo esta semana” como una entrada, nunca como única barrera.
8. Nivel 3 — se activan estadísticas de tiempo de respuesta y similitud de respuestas, solo en el ámbito de la tabla de clasificación. Cuando el banco de ítems es suficientemente grande (Hallazgo 4), el servidor ejecuta una simple comprobación de valores atípicos de tiempo de respuesta (Hallazgo 3) y, donde las cuentas comparten suficientes ítems comunes, una comprobación de similitud de respuestas basada en los índices publicados — limitado a la actividad de la tabla de clasificación, no a la práctica ordinaria.
9. Nivel 4 — Avanzado/pre‑competitivo (16 +, optado por juego clasificado): control total de exposición de ítems. La limitación de exposición al estilo Sympson‑Hetter (Hallazgo 2) restringe la frecuencia con la que incluso el ítem óptimo siguiente se muestra a usuarios de habilidad similar, protegiendo el vector de “todos en este rango obtienen el mismo próximo problema” que cobra importancia cuando existen apuestas reales.
10. Nivel 4 — las heurísticas de compartición de sesión/cuenta se vuelven activas, no solo registradas. La detección de sesiones concurrentes y las banderas de discontinuidad de habilidad ahora aumentan activamente la volatilidad/RD de la puntuación (como haría una cuenta sospechosa nueva), en lugar de aparecer solo en un panel.
11. Nivel 5 — Competitivo/elegible para becas (opt‑in, apuestas explícitas, consentimiento de tutor donde intervenga un menor): la suite estadística completa, sin cámaras. La maquinaria psicométrica publicada (detección de colusión estilo omega/GBT, modelo lognormal completo de tiempo de respuesta) justifica su coste aquí, pues el banco es amplio y las apuestas son altas. Incluso en este techo la respuesta es más estadística, nunca una webcam, navegador con bloqueo, ni captura biométrica — el registro del Hallazgo 5 no ofrece ningún escenario en que la supervisión 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: renderizado del problema, recogida de la respuesta, retroalimentación UI local. Lado del servidor, siempre, desde el nivel 0: el par de marcas temporales, la comprobación de corrección, la puntuación y (a partir del nivel 3) cada señal estadística en los Hallazgos 3‑4 y 7. La autoridad del tiempo/corrección nunca pasa al cliente en ningún nivel — la escalera es progresiva en apuestas, no en confianza del cliente, que nunca se concede.
13. Lo que deliberadamente nunca haremos a un niño, en cualquier nivel. No se capturará webcam ni micrófono. No se recopilarán datos biométricos (rostro, voz, dinámica de pulsación, seguimiento ocular). No se usará navegador con bloqueo. No habrá proctor humano remoto. No habrá penalización de puntuación ni acción de 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, como máximo, un elemento del panel de control para padres/tutores. No habrá encuadre punitivo (“has sido sorprendido haciendo trampa”) en ningún sitio — el peor resultado visible en cualquier nivel es una estimación de dominio de menor confianza o un mensaje amistoso, acorde con el diseño decidido: la anti‑trampa permanece casi invisible para los niños pequeños y se endurece solo con el aumento de las apuestas.

Open questions for the project owner

1. ¿A qué edad/nivel, si es que hay alguno, debería mostrarse en un panel de control parental las señales de anomalía (Niveles 1‑2) — y debería ser visible alguna vez para el niño, aunque indirectamente?
2. ¿Math Challenge organizará algún evento con apuestas reales (beca, premio en efectivo, competición reconocida por la escuela) que justifique la suite estadística completa del Nivel 5, o “nivel competitivo” significa solo derechos de presumir en la tabla de clasificación?
3. ¿Debería la adopción de WebAuthn/passkey ser obligatoria alguna vez, o siempre opcional, dado que es el único primitivo universal de vinculación de dispositivo pero añade fricción para la cuenta de un niño pequeño?
4. Para el uso legítimo de cuentas familiares compartidas (padre e hijo con un mismo inicio de sesión), ¿cómo deberían las heurísticas de sesión del Nivel 4+ evitar marcar como sospechoso el cambio normal de dispositivos dentro de la familia?
5. ¿Existe interés en publicar una declaración de confianza/seguridad en la que Math Challenge afirme que nunca usará supervisión con webcam/biometría, como diferenciador frente a productos estilo Proctorio y señal de confianza para los padres?