Integridade em avaliação online e anti-trapaça: um modelo progressivo para um app de matemática de consumo

Tabela de modelo de ameaças

Ataque	Quem faz	Como detectável	Custo para defender
Buscar a resposta (pesquisa, livro didático)	Qualquer idade/nível	Tempo de resposta muito abaixo do tempo humano mais rápido plausível; correção quase instantânea após inatividade visível/aba desfocada	Baixo — limite de tempo de resposta no servidor por item, eventos de visibilidade de aba
Pai/irmão resolve para a criança	Principalmente crianças pequenas	Descompasso de estilo em relação à linha de tendência de habilidade da conta	Baixo-médio — sinalização baseada em tendência apenas, nunca punitiva nessa idade
App solucionador / calculadora em um segundo dispositivo	Crianças mais velhas, adolescentes, adultos	Limite de tempo de resposta; um solucionador retorna quase instantaneamente independentemente da dificuldade, enquanto o tempo humano escala com ela	Baixo-médio — mesmo mecanismo de limite, calibrado por tipo de item
Segundo dispositivo responde enquanto o dispositivo principal é o “cronômetro”	Adolescentes, nível competitivo	Difícil sem atestação de dispositivo; mitigado estruturalmente mantendo a temporização no servidor, de modo que um segundo dispositivo não ganha vantagem mensurável	Médio — arquitetural, não um verificação adicional
Compartilhamento de respostas entre amigos	Qualquer idade, contextos de turma	Estatísticas de similaridade de respostas/colusão (ômega, GBT, K-index); significativo apenas quando o banco de itens é grande	Médio-alto — requer um banco real mais maquinaria estatística
Scripts/bots automatizados (replay de API, navegador headless)	Usuários técnicos, cultivadores de ranking	Sinais de gerenciamento de bots (impressão digital comportamental, prova de trabalho, TLS/JA3), limitação de taxa, tokens Turnstile/Privacy Pass	Baixo-médio — infraestrutura pronta
Compartilhamento de conta (um login, muitas pessoas)	Famílias, nível competitivo	Detecção de sessões concorrentes, incompatibilidade de credenciais WebAuthn, descontinuidade de habilidade	Médio — requer rastreamento de sessão/dispositivo
Falhar deliberadamente em conteúdo fácil para subir de ranking (“sandbagging”)	Usuários competitivos/de ranking	Anomalia de variância em relação ao histórico próprio	Médio — requer uma base de habilidade/ classificação mantida (já exigida pelo tópico 18)

Resultados

1. Pontuação autoritária no servidor e por que o tempo do cliente não pode ser confiável

Um navegador pode ser totalmente inspecionado e modificado pelo próprio usuário: o DevTools pode pausar a execução, reescrever variáveis, reproduzir solicitações de rede editadas e sobrescrever Date.now()/performance.now(). Esse é o mesmo modelo de ameaça que tornou obsoletas as arquiteturas multiplayer “client-authoritative” (o cliente relata sua própria pontuação/tempo e o servidor simplesmente acredita). O servidor deve registrar independentemente o horário em que a questão foi servida e a resposta recebida, e verificar independentemente a correção — o cliente apenas renderiza e coleta. Nada mais escala para um placar onde a velocidade gera pontos, já que a duração relatada pelo cliente é exatamente o que a maioria das manipulações de recompensas explora.

2. Estratégia de banco de itens: tamanho, parametrização, randomização, controle de exposição

A pesquisa em CAT fornece um manual diretamente aplicável. A exposição de itens — a proporção de candidatos que vê um determinado item — tende a 1 para os itens mais informativos em um algoritmo adaptativo ingênuo, o que por si só já é um problema de segurança: um item exibido repetidamente torna-se compartilhável [10]. Três mitigações estabelecidas: o método Sympson-Hetter (sorteia um número aleatório, compara com um parâmetro de exposição por item antes de administrar mesmo o item de melhor ajuste); seleção aleatória/estratificada (escolhe aleatoriamente entre os 5-10 itens mais informativos, não sempre o único melhor); e testes sombra (van der Linden — constrói um teste hipotético completo a cada passo para escolhas globalmente, não apenas localmente, ótimas) [10]. Por trás dos três está um grande pool de itens, ampliado de forma barata via geração parametrizada/algorítmica de itens (um modelo como a + b = ? com operandos randomizados por faixa de dificuldade) em vez de itens criados manualmente — explicitamente a forma prática de expandir pools economicamente segundo a literatura de CAT [10].

3. Detecção estatística: outliers de tempo de resposta

O modelo lognormal de tempo de resposta de Van der Linden trata os tempos de resposta de um candidato a um item como governados por um parâmetro de “velocidade” ao nível da pessoa, juntamente com parâmetros de intensidade de tempo e discriminação ao nível do item, paralelamente ao modelo logístico de dois parâmetros da IRT que trata a correção [11]. Ajustado, ele permite verificações clássicas e bayesianas posterior-predictivas para aberrância — uma resposta marcadamente mais rápida ou mais lenta que a prevista — já aplicadas para detectar comportamentos anômalos em testes adaptativos computadorizados [11]. Para o Math Challenge, a versão prática não precisa do modelo completo inicialmente: um piso empírico (“nenhum humano verificado resolve esta classe de itens em menos de X ms”) é uma primeira linha de defesa legítima, escalando para o modelo completo apenas em níveis onde os riscos justificam o investimento.

4. Detecção estatística: similaridade de respostas e índices de colusão

A detecção de cópia/colusão de respostas é um subcampo psicométrico consolidado, confirmado via ERIC: o índice ômega (Ω) de Wollack (refinado por Maeda & Zhang 2017; Sunbul & Yormaz 2018), o teste binomial generalizado (GBT) comparado ao ômega quanto a poder/erro Tipo I (Zopluoglu & Davenport, 2012), o índice K (Holland) versus divergência Kullback-Leibler (Belov & Armstrong, 2010; Ucar & Dogan, 2021), uma medida KL baseada em tempo de resposta (Man et al., 2018) e um Índice de Correspondência Variável (Belov, 2011) [12]. Todos compartilham a mesma estrutura: sinalizam quando dois candidatos dão a mesma resposta errada com mais frequência do que o acaso prevê, dado seu nível individual de habilidade — uma taxa anormalmente alta de respostas incorretas idênticas é a assinatura. Isso só faz sentido quando o banco de itens é grande o suficiente para que duas pessoas convergirem ao mesmo item por acaso seja raro.

5. Navegadores de lockdown e proctoring remoto — e por que não usá-los em crianças

O proctoring remoto baseado em câmera (Proctorio, ExamSoft, Honorlock, Respondus) disparou durante a COVID-19 e deixou um rastro documentado de danos e contestação legal:

• A eficácia é duvidosa. Pesquisa da University of Twente é relatada (via resumo secundário) como encontrando a sensibilidade de detecção de trapaça do Proctorio “muito próxima de zero” [4].
• Um tribunal federal dos EUA considerou uma prática específica inconstitucional. Ogletree v. Cleveland State University tratou de uma “varredura de sala” obrigatória por webcam; o caso está documentado como uma decisão do Quarto Emenda contra a prática por um tribunal distrital federal em Ohio (2022) [3].
• Litígio BIPA em Illinois. Estudantes alegaram que o Proctorio coletou informações/identificadores biométricos sem consentimento exigido; o Proctorio negou as alegações. O BIPA impõe danos estatutários de $1.000 (negligente) / $5.000 (intencional) por violação, razão pela qual fornecedores de proctoring enfrentam litígios recorrentes desse tipo [13].
• O caso holandês frequentemente citado segue o caminho oposto. Rechtbank Amsterdam, ECLI:NL:RBAMS:2020:2917 (11 de junho de 2020): os Conselhos Centrais e de Faculdades da UvA buscaram uma liminar contra o Proctorio; o tribunal rejeitou todas as alegações, considerando o tratamento lícito sob o GDPR Art. 6(1)(e), “necessário” diante do fechamento por COVID-19, “proporcional” (triagem automatizada, revisão humana limitada, exclusão em 30 dias) e “adequadamente salvaguardado” (armazenamento na UE, contrato de processador, DPIA em arquivo), observando que o Proctorio era “menos invasivo que vigilância de vídeo ao vivo contínua” [5]. É uma vitória judicial genuína para o proctoring — condicionada a um conjunto estreito e documentado de salvaguardas (retenção curta, DPIA, estudantes adultos, necessidade pandêmica) que não descreve nada sobre um aplicativo de consumo para crianças de quatro anos.
• Um achado paralelo de discriminação. A VU Amsterdam enfrentou separadamente uma queixa do Dutch Institute for Human Rights alegando que o Proctorio discriminava um estudante negro; o instituto não encontrou discriminação naquele caso, mas a queixa se insere no mesmo padrão mais amplo de preocupação com viés algorítmico em proctoring (não verificado além do trecho).

Conclusão para o Math Challenge: proctoring por câmera/microfone de crianças não tem lugar neste produto em nenhum nível. Os danos documentados se aplicam com ainda mais força a menores do que aos adultos universitários envolvidos nesses casos, e nenhuma das condições mitigadoras do tribunal de Amsterdã (necessidade pandêmica, capacidade de consentimento adulto, DPIA institucional) existe aqui.

6. Ativação de dispositivo na web em 2026

• WebAuthn/passkeys: API padrão de navegador, funciona em qualquer navegador moderno, inclusive PWAs instalados; vincula uma credencial de chave pública a um dispositivo, e o servidor pode armazenar múltiplos IDs de credencial por conta — o próprio WebAuthn não sinaliza automaticamente “novo dispositivo”, esse controle fica no lado do servidor [16].
• Private Access Tokens (Apple) / Privacy Pass (IETF): esquema de três partes (emissor, cliente, servidor) que prova que uma solicitação vem de um dispositivo legítimo sem revelar identidade, via fluxo de desafio-resposta e validação de assinatura cega RSA; incorporado ao iOS 16+/macOS Ventura+ para reduzir CAPTCHAs, e integrado ao Cloudflare Turnstile — mas sem suporte confirmado de primeira classe fora das plataformas Apple, portanto trate como sinal bônus em tráfego Safari/iOS, não como mecanismo geral [14][15][18].
• Google Play Integrity API: exclusivamente para apps Android nativos distribuídos via Google Play, verificando autenticidade do binário, origem da instalação e genuinidade do dispositivo — não se aplica a uma PWA; a própria orientação da Google para web aponta para outro caminho (Privacy Sandbox) [17].
• Apple App Attest: atestação nativa iOS análoga, vinculada à distribuição pela App Store da mesma forma que o Play Integrity está ligado ao Play Store — indisponível para uma PWA que não seja distribuída pela App Store.

Leitura prática para um produto focado em PWA: WebAuthn é a única primitiva de vinculação de dispositivo realmente disponível em todo lugar; Play Integrity/App Attest são estruturalmente indisponíveis sem apps nativos; Private Access Tokens são um bônus real, porém com peso Apple, já incorporado ao Turnstile.

7. Detecção de bots e limitação de taxa

A pilha de gerenciamento de bots da Cloudflare combina um motor de ML que pontua cada requisição de 1-99 a partir de recursos de request/header/sessão, um motor heurístico que combina impressões digitais conhecidas como maliciosas e detecção baseada em JavaScript de navegadores headless, refinado por um cookie de sessão (__cf_bm) que suaviza as pontuações para reduzir falsos positivos [18]. Turnstile é a versão voltada ao consumidor: pequenos desafios JS não interativos (prova de trabalho, prova de espaço, sondagem de APIs web, detecção de peculiaridades do navegador) em vez de um puzzle visual, já tratando tokens Privacy Pass como uma entrada [15][18]. A limitação de taxa nos endpoints de submissão/pontuação é a camada complementar mais simples: limitar submissões por conta/IP/janela captura abusos scriptados de alto volume independentemente de qualquer requisição individual parecer humana.

8. Como plataformas competitivas nomeadas lidam com trapaças em escala

• Codeforces: classifica o desempenho em relação a oponentes de rating conhecido dentro de um concurso, em vez de pontos fixos por problema, reduzindo o incentivo de manipular um valor bruto de pontos (veja o tópico 18 da pesquisa, docs/research/2026-07-31-mc-18-leaderboards-competition.md) [1].
• Chess.com: detecta jogadas suspeitas a partir de “mais de 100 fatores de jogabilidade”, explicitamente sem depender de uma única pontuação de precisão (“Accuracy is not cheat detection”); sistemas automatizados tratam ~85% dos fechamentos; de jan-mar de 2025 foram revisados ~28.000 recursos de 314.000 fechamentos, com taxa de concessão de 0,2%; software Proctor de duas câmeras é obrigatório apenas em eventos com prêmio em dinheiro; a metodologia foi revisada externamente pelo estatístico de Harvard Natesh S. Pillai (2016) e endossada pela US Chess (2020) [2].
• Duolingo: combate a “farm” de placares/XP (bots que completam automaticamente, cultivo de conteúdo repetitivo, exploração de temporização) monitorando picos incomuns de XP e conclusões de lições irrealisticamente rápidas, respaldado por banimentos e denúncias da comunidade — o princípio de outlier de tempo de resposta aplicado informalmente em escala de produto [19].
• Kaggle: as regras são amplamente conhecidas na indústria para restringir compartilhamento privado fora dos limites da equipe, limitar tamanho/tempo de fusão de equipes e proibir múltiplas contas, mas os detalhes desta seção são conhecimento geral da indústria, não uma citação confirmada (a documentação não foi acessada diretamente durante esta pesquisa).
• Kahoot: não há conteúdo de fonte primária citável sobre trapaças/ferramentas de bots (por exemplo, scripts “flooder” de terceiros) que tenha sido recuperado; isso permanece uma lacuna aberta, não uma afirmação com fonte.

Implicações de design

Uma escada progressiva de seis níveis. Cada nível apenas adiciona controles sobre a fundação autoritativa do servidor do nível anterior — nada é removido ao subir, nada acima do nível 0 é jamais empurrado para baixo em um nível de criança mais nova.

1. Nível 0 — Crianças (4-6): temporização/ pontuação autoritativa do servidor apenas, invisivelmente. O servidor registra independentemente o horário de entrega da pergunta/resposta recebida e verifica a correção; o cliente nunca controla nenhum desses valores. Nenhuma UI anti-trapaça visível, nenhum bloqueio, nenhuma mensagem de trapaça — um pai resolvendo ao lado da criança é o caso de uso pretendido, não uma ameaça.
2. Nível 0 — piso de tempo de resposta, apenas registro. Um tempo mínimo plausível por tipo de item é registrado e logado se violado, nunca bloqueando ou pontuando zero. Telemetria pura para calibrar níveis posteriores; aparece apenas em um futuro painel de pais/responsáveis, nunca para a criança.
3. Nível 1 — Ensino fundamental inicial (7-9): monitoramento silencioso de variância. O servidor acompanha a própria tendência de acurácia/velocidade de cada aprendiz por habilidade; um desvio grande repentino gera apenas um sinal suave (dificuldade adaptativa ligeiramente mais cautelosa) — nunca bloqueio, aviso ou penalidade visível.
4. Nível 1 — limitação de taxa nos endpoints de submissão. Limites básicos por conta/IP protegem o backend contra abuso scriptado a partir deste nível.
5. Nível 2 — Ensino fundamental tardio/ensino médio (10-13): o piso de tempo de resposta torna-se um sinal ativo e gentil. Violação do piso gera um momento UI amigável (“isso foi rápido — quer revisar?”) em vez de um log silencioso; violações repetidas reduzem a confiança da estimativa de domínio, nunca anulam pontos. Ainda sem bloqueio, sem proctoring, sem alarme parental.
6. Nível 2 — a randomização do banco de itens começa a importar. Geração parametrizada de itens (operandos aleatórios por faixa de dificuldade) torna-se o mecanismo padrão de entrega, já que nesta faixa etária um irmão ou colega de classe primeiro tem incentivo para repassar um conjunto exato de problemas.
7. Nível 3 — Ensino médio/adolescentes (14-17): Turnstile + vinculação de dispositivo WebAuthn apenas em ações de placar. Turnstile protege endpoints de submissão que afetam o placar (invisível por padrão); credenciais de dispositivo WebAuthn são introduzidas para reconhecimento de conta, não como requisito de login — sinalizando “um terceiro novo dispositivo esta semana” como um input, nunca como única barreira.
8. Nível 3 — estatísticas de tempo de resposta e similaridade de respostas ativam, apenas no escopo do placar. Quando o banco de itens é grande o suficiente (Finding 4), o servidor executa uma simples verificação de outlier de tempo de resposta (Finding 3) e, onde contas compartilham itens suficientes, uma verificação de similaridade de respostas modelada nos índices publicados — limitada à atividade de placar, não à prática ordinária.
9. Nível 4 — Avançado/pré-competitivo (16+, opt-in para jogo ranqueado): controle total de exposição de itens. Limitação de exposição ao estilo Sympson-Hetter (Finding 2) restringe a frequência com que até o melhor próximo item é mostrado a usuários de habilidade similar, protegendo o vetor de compartilhamento “todos neste rank recebem o mesmo próximo problema” que importa quando há apostas reais.
10. Nível 4 — heurísticas de sessão/compartilhamento de conta tornam-se ativas, não apenas registradas. Detecção de sessão concorrente e sinalizadores de descontinuidade de habilidade agora aumentam ativamente a volatilidade/RD da classificação (como faria uma conta nova suspeita), em vez de aparecer apenas em um painel.
11. Nível 5 — Competitivo/eligível a bolsa (opt-in, apostas explícitas, consentimento de responsável quando menor): a suíte estatística completa, ainda sem câmeras. A maquinaria psicométrica publicada (detecção de colusão estilo omega/GBT, modelo log-normal completo de tempo de resposta) justifica seu custo aqui, já que o banco é grande e as apostas são altas. Mesmo neste teto a resposta é mais estatística, nunca webcam, navegador bloqueado ou captura biométrica — o registro do Finding 5 não apresenta cenário em que proctoring com câmera/biometria de menor ou adulto sem mandato institucional seja defensável.
12. Lado-servidor vs. lado-cliente, em todo nível, sem exceção. Lado-cliente, sempre: renderização do problema, coleta da resposta, feedback UI local. Lado-servidor, sempre, a partir do nível 0: par de timestamps, verificação de correção, pontuação e (nível 3 em diante) cada sinal estatístico nos Findings 3-4 e 7. A autoridade de temporização/correção nunca migra para o cliente em nenhum nível — a escada é progressiva em apostas, não em confiança no cliente, que nunca é concedida.
13. O que nunca faremos deliberadamente a uma criança, em qualquer nível. Nenhuma captura de webcam ou microfone. Nenhuma coleta de dados biométricos (rosto, voz, dinâmica de teclas, rastreamento ocular). Nenhum navegador bloqueado. Nenhum proctor humano remoto. Nenhuma penalidade de pontuação ou ação de conta visível a uma criança abaixo do Nível 3 — abaixo do Nível 3, os sinais são telemetria de calibração e, no máximo, um item do painel de pais/responsáveis. Nenhuma formulação punitiva (“você foi pego trapaceando”) em nenhum lugar — o pior resultado visível em qualquer nível é uma estimativa de domínio de confiança menor ou um prompt amigável, alinhado ao design decidido: anti-trapaça permanece quase invisível para crianças pequenas e só se aperta com o aumento das apostas.

Perguntas abertas para o dono do projeto

1. Em que idade/nível, se houver, um painel parental deve exibir sinais de anomalia (Níveis 1-2) — e isso deveria ser visível para a criança, ainda que indiretamente?
2. O Math Challenge realizará algum evento com apostas reais (bolsa, prêmio em dinheiro, competição reconhecida pela escola) que justifique a suíte estatística completa do Nível 5, ou “nível competitivo” significa apenas direito de exibir no placar?
3. A adoção de WebAuthn/passkey deve ser exigida em algum momento, ou permanecer sempre opcional, considerando que é o único primitivo universal de vinculação de dispositivo, mas adiciona atrito para a conta de uma criança pequena?
4. Para compartilhamento legítimo de conta familiar (pai e filho usando o mesmo login), como as heurísticas de sessão a partir do Nível 4+ devem evitar sinalizar trocas normais de dispositivos familiares como suspeitas?
5. Existe interesse em publicar uma declaração de confiança/segurança de que o Math Challenge nunca usará proctoring com webcam/biometria, como diferencial dos produtos estilo Proctorio e sinal de confiança para os pais?