Integridade da avaliação em linha e antifraude: um modelo progressivo para uma aplicação de matemática de consumo

Threat model table

Attack	Who does it	How detectable	Cost to defend
Procurar a resposta (pesquisa, livro‑texto)	Qualquer idade/nível	Tempo de resposta muito abaixo do tempo de resolução humana mais rápido plausível; correção quase instantânea após inatividade visível/tab‑blur	Baixo — piso de tempo de resposta no servidor por item, eventos de visibilidade de aba
Pai/irmão resolve por a criança	Principalmente crianças pequenas	Desajuste de estilo vs. a linha de tendência de habilidade da conta	Baixo‑médio — sinalização baseada em tendência apenas, nunca punitiva nesta idade
Aplicação de resolução / calculadora num segundo dispositivo	Crianças mais velhas, adolescentes, adultos	Piso de tempo de resposta; um resolvedor devolve quase instantaneamente independentemente da dificuldade, enquanto o tempo humano escala com ela	Baixo‑médio — mesmo mecanismo de piso, 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 ao manter a temporização no servidor, de modo que um segundo dispositivo não ganha vantagem mensurável	Médio — arquitetónico, não um controlo adicional
Partilha de respostas entre amigos	Qualquer idade, contextos de turma	Estatísticas de similaridade de respostas/colusão (omega, 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 (repetição de API, navegador sem cabeça)	Utilizadores técnicos, cultivadores de classificação	Sinais de gestão de bots (impressão digital comportamental, prova de trabalho, TLS/JA3), limitação de taxa, tokens Turnstile/Privacy Pass	Baixo‑médio — infraestrutura pronta a usar
Partilha de conta (um login, muitas pessoas)	Famílias, nível competitivo	Deteçã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 melhorar classificação (“sandbagging”)	Utilizadores competitivos/da classificação	Anomalia de variância vs. histórico próprio	Médio — requer uma base de habilidade/rating mantida (já exigida no tópico 18)

Constatações

1. Pontuação autoritativa 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 utilizador: as DevTools podem pausar a execução, reescrever variáveis, reproduzir pedidos de rede editados e substituir Date.now()/performance.now(). Este é o mesmo modelo de ameaça que tornou obsoletas as arquiteturas multijogador «client‑authoritative» (o cliente reporta a sua própria pontuação/tempo e o servidor simplesmente acredita nele). O servidor tem de registar independentemente o horário em que a questão foi apresentada e a resposta recebida, e verificar independentemente a correção — o cliente apenas renders e collects. Nada mais escala para uma tabela de classificação onde a rapidez atribui pontos, uma vez que a duração reportada pelo cliente é exatamente o que a maioria das recompensas manipula.

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

A investigação em CAT fornece um manual diretamente aplicável. A exposição de itens — a parte dos candidatos que vê um determinado item — tende a 1 para os itens mais informativos num algoritmo adaptativo ingénuo, o que por si só constitui um problema de segurança: um item apresentado repetidamente torna‑se partilhá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 randomesque/estratificada (escolhe aleatoriamente entre os 5‑10 itens mais informativos, não sempre o único melhor); e shadow testing (van der Linden — constrói um teste hipotético ótimo completo a cada passo para escolhas globalmente, não apenas localmente, ótimas) [10]. Por baixo de todos eles está um grande pool de itens, cultivado economicamente via geração parametrizada/algorítmica de itens (um modelo como a + b = ? com operandos aleatórios por faixa de dificuldade) em vez de itens criados manualmente — explicitamente a forma prática de crescer pools de forma económica segundo a literatura de CAT [10].

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

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

4. Deteção estatística: índices de semelhança de respostas e colusão

A deteção de cópia/colusão de respostas é um sub‑campo psicométrico estabelecido, confirmado via ERIC: o índice ômega (Ω) de Wollack (refinado por Maeda & Zhang 2017; Sunbul & Yormaz 2018), o teste binomial generalizado (GBT) comparado ao ômega para potência/erro Tipo I (Zopluoglu & Davenport, 2012), o K‑index (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 Variable Match Index (Belov, 2011) [12]. Todos partilham uma estrutura: sinalizam quando dois candidatos dão a mesma resposta errada com mais frequência do que o acaso prevê, dado o nível de habilidade individual — uma taxa incomumente alta de respostas incorretas idênticas é a assinatura. Isto só é significativo quando o banco de itens é suficientemente grande para que duas pessoas convergirem ao mesmo item por acaso seja raro.

5. Browsers de lockdown e proctoring remoto — e por que não os usar em crianças

O proctoring remoto baseado em câmara (Proctorio, ExamSoft, Honorlock, Respondus) aumentou durante a COVID‑19 e deixou um rasto documentado de danos e resistência legal:

• A eficácia é duvidosa. Uma investigação da Universidade de Twente é relatada (via resumo secundário) como tendo encontrado a sensibilidade de deteçã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 envolveu 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 recolheu informações/identificadores biométricos sem o consentimento exigido; o Proctorio negou as alegações. O BIPA prevê danos estatutários de $1.000 (negligente) / $5.000 (intencional) por violação, razão pela qual os 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 Faculdade da UvA solicitaram uma liminar contra o Proctorio; o tribunal rejeitou todas as alegações, considerando o tratamento lícito ao abrigo do GDPR Art. 6(1)(e), “necessário” face ao encerramento por COVID‑19, “proporcional” (triagem automatizada, revisão humana limitada, eliminação em 30 dias) e “adequadamente salvaguardado” (armazenamento na UE, acordo de processador, DPIA em ficheiro), observando que o Proctorio era “menos invasivo do que a 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 uma aplicação de consumo para crianças de quatro anos.
• Uma constatação paralela de discriminação. A VU Amsterdam enfrentou separadamente uma queixa do Instituto Holandês de Direitos Humanos alegando que o Proctorio discriminava um estudante negro; o instituto não encontrou discriminação nesse caso, mas a queixa insere‑se no mesmo padrão mais amplo de preocupação com viés algorítmico no proctoring (unverified beyond snippet).

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

6. Atestação de dispositivos na web em 2026

• WebAuthn/passkeys: API padrão do navegador, funciona em qualquer navegador moderno, inclusive PWAs instaladas; associa 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 controlo é feito no lado do servidor [16].
• Private Access Tokens (Apple) / Privacy Pass (IETF): esquema de três partes (emissor, cliente, servidor) que prova que um pedido provém de um dispositivo legítimo sem revelar identidade, via fluxo de desafio‑resposta e validação de assinatura cega RSA; incorporado no iOS 16+/macOS Ventura+ para reduzir CAPTCHAs, e integrado no Cloudflare Turnstile — mas sem suporte de primeira classe confirmado fora das plataformas Apple, pelo que deve ser tratado como um sinal de bónus no tráfego Safari/iOS, não como um mecanismo geral [14][15][18].
• Google Play Integrity API: exclusivamente para aplicações Android nativas distribuídas via Google Play, verificando a autenticidade do binário da aplicação, a origem da instalação e a genuinidade do dispositivo — não se aplica a uma PWA; as próprias orientações web da Google apontam para outro lado (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 através da App Store.

Leitura prática para um produto PWA‑first: WebAuthn é a única primitiva de ligação a dispositivo realmente disponível em todo o lado; Play Integrity/App Attest são estruturalmente indisponíveis sem aplicações nativas; Private Access Tokens são um bónus real, mas com peso Apple, já integrado no Turnstile.

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

A pilha de gestão de bots da Cloudflare combina um motor de ML que pontua cada pedido de 1‑99 a partir de características de pedido/cabeçalho/sessão, um motor heurístico que corresponde a impressões digitais conhecidas como maliciosas, e deteçã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]. O Turnstile é a versão voltada ao consumidor: pequenos desafios JS não interativos (proof‑of‑work, proof‑of‑space, sondagem de APIs web, deteçã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 pontos 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 pedido individual parecer humano.

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

• Codeforces: classifica o desempenho em relação aos oponentes com classificação conhecida dentro de um concurso, em vez de pontos fixos por problema, reduzindo o incentivo a manipular um valor bruto de pontos (ver tópico 18 da pesquisa, docs/research/2026-07-31-mc-18-leaderboards-competition.md) [1].
• Chess.com: deteta jogadas suspeitas a partir de “mais de 100 fatores de jogabilidade”, explicitamente sem depender de uma única pontuação de precisão (“Precisão não é deteção de trapaça”); sistemas automatizados tratam ~85 % dos encerramentos; de Jan‑Mar de 2025 foram revistos ~28.000 recursos de 314.000 encerramentos a uma taxa de concessão de 0,2 %; o software obrigatório de duas câmaras Proctor é exigido apenas para eventos com prémios em dinheiro; a metodologia foi verificada externamente pelo estatístico de Harvard Natesh S. Pillai (2016) e endossada pela US Chess (2020) [2].
• Duolingo: combate a manipulação de tabelas de classificação/XP (bots que completam automaticamente, cultivo de conteúdo repetitivo, exploração de temporizações) ao monitorizar picos de XP incomuns e a conclusão de lições irrealisticamente rápida, apoiado por banimentos e relatos da comunidade — o princípio de outlier de tempo de resposta aplicado informalmente à escala do produto [19].
• Kaggle: as regras são conhecidas em toda a indústria para restringir a partilha privada fora dos limites da equipa, limitar o tamanho da equipa/janelas de fusão e proibir múltiplas contas, mas os detalhes desta secção são conhecimento geral da indústria, não uma citação confirmada (a documentação não foi diretamente acessível durante esta pesquisa).
• Kahoot: não foi possível obter conteúdo de fonte primária citável sobre trapaça/ferramentas de bots (por exemplo, scripts de “flooder” de terceiros); isto continua uma lacuna aberta, não uma afirmação com fonte.

Implicações de design

Uma escada progressiva concreta de seis níveis. Cada nível apenas adiciona controlos sobre a base autoritária do servidor do nível anterior — nada é removido ao subir, nada acima do nível 0 é jamais empurrado para baixo para o nível de uma criança mais nova.

1. Tier 0 — Kinder (4-6): temporização/pontuação autoritária do servidor apenas, invisivelmente. O servidor regista independentemente a hora em que a questão é apresentada/resposta recebida e verifica a correção; o cliente nunca controla nenhum dos valores. Sem interface anti‑trapaça visível, sem bloqueio, sem mensagens de trapaça — um pai a resolver ao lado do filho é o caso de uso pretendido, não uma ameaça.
2. Tier 0 — piso de tempo de resposta, apenas registo. Um tempo mínimo plausível de resolução por tipo de item é registado e registado se ultrapassado, nunca bloqueando ou atribuindo zero. Telemetria pura para calibrar níveis posteriores; aparece apenas num futuro painel de pai/guarda, nunca para a criança.
3. Tier 1 — Ensino básico inicial (7-9): monitorização silenciosa de variância. O servidor acompanha a tendência de precisão/velocidade de cada aprendiz por competência; um desvio súbito e grande aciona apenas um sinal suave (dificuldade adaptativa ligeiramente mais cautelosa) — nunca um bloqueio, aviso ou penalização visível.
4. Tier 1 — limitação de taxa nos pontos de submissão. Limites básicos de submissão por conta/IP (infraestrutura partilhada) protegem o backend contra abuso scriptado a partir deste nível.
5. Tier 2 — Ensino básico tardio/ensino secundário (10-13): o piso de tempo de resposta torna‑se um sinal ativo e suave. Ultrapassar o piso aciona um momento amigável na interface (“foi rápido — queres rever?”) em vez de um registo silencioso; violações repetidas reduzem a confiança na estimativa de domínio, nunca anulam pontos. Ainda sem bloqueio, sem supervisão, sem alarme parental.
6. Tier 2 — a randomização do banco de itens começa a ser relevante. A geração parametrizada de itens (operandos aleatórios por faixa de dificuldade) torna‑se o mecanismo de entrega predefinido, pois esta é a faixa etária em que um irmão ou colega de turma primeiro tem incentivo para repassar um conjunto de problemas exato.
7. Tier 3 — Ensino secundário/adolescente geral (14-17): Turnstile + vinculação de dispositivo WebAuthn apenas em ações da tabela de classificação. Turnstile protege os pontos de submissão que afetam a tabela de classificação (invisível por predefinição); as credenciais de dispositivo WebAuthn são introduzidas para reconhecimento da conta, não como requisito de início de sessão — sinalizando “um terceiro dispositivo novo esta semana” como uma entrada, nunca como única barreira.
8. Tier 3 — ativam‑se as estatísticas de tempo de resposta e semelhança de respostas, apenas no âmbito da tabela de classificação. Quando o banco de itens é suficientemente grande (Finding 4), o servidor executa uma simples verificação de outlier de tempo de resposta (Finding 3) e, onde as contas partilham itens comuns suficientes, uma verificação de semelhança de respostas modelada nos índices publicados — limitada à atividade da tabela de classificação, não à prática ordinária.
9. Tier 4 — Avançado/pré‑competitivo (16+, optado por jogo classificado): controlo total de exposição de itens. A limitação de exposição ao estilo Sympson‑Hetter (Finding 2) limita a frequência com que até o próximo item mais adequado é mostrado a utilizadores de habilidade semelhante, protegendo o vetor de partilha “todos neste nível recebem o mesmo próximo problema” que passa a importar quando existem apostas reais.
10. Tier 4 — as heurísticas de partilha de sessão/conta tornam‑se ativas, não apenas registadas. A deteção de sessões concorrentes e os indicadores de descontinuidade de competência agora aumentam ativamente a volatilidade/rating RD (como faria uma conta nova suspeita), em vez de apenas aparecerem num painel.
11. Tier 5 — Nível superior competitivo/ elegível a bolsas (opt‑in, apostas explícitas, consentimento de guardião quando um menor está envolvido): o conjunto completo de estatísticas, ainda sem câmaras. A maquinaria psicométrica publicada (deteção de colusão ao estilo omega/GBT, o modelo de tempo de resposta log‑normal mais completo) justifica o seu custo aqui, pois o banco é grande e as apostas são altas. Mesmo neste patamar a resposta é mais estatísticas, nunca uma webcam, navegador de bloqueio ou captura biométrica — o registo da Finding 5 não apresenta nenhum cenário em que a supervisão por câmara/biométrica de um menor, ou de um adulto sem mandato institucional, seja defensável.
12. Server-side vs. client-side, em todos os níveis, sem exceção. Lado do cliente, sempre: renderizar o problema, recolher a resposta, feedback da interface local. Lado do servidor, sempre, a partir do nível 0: o par de timestamps, a verificação de correção, a pontuação e (a partir do nível 3) todos os sinais estatísticos nas Findings 3‑4 e 7. A autoridade de temporização/correção nunca passa para o cliente em nenhum nível — a escada é progressiva nas apostas, não na 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 recolha de dados biométricos (rosto, voz, dinâmica de teclas, rastreio de olhar). Nenhum navegador de bloqueio. Nenhum supervisor humano remoto. Nenhuma penalização de pontuação ou ação de conta visível a uma criança abaixo do Tier 3 — abaixo do Tier 3, os sinais são telemetria de calibração e, no máximo, um item do painel de pai/guarda. Nenhuma formulação punitiva (“foste apanhado a trapacear”) em lado nenhum — o pior resultado visível em qualquer nível é uma estimativa de domínio com menor confiança ou um prompt amigável, correspondendo ao design decidido: a anti‑trapaça permanece quase invisível para crianças pequenas e só se aperta com o aumento das apostas.

Questões abertas para o proprietário do projeto

1. Em que idade/nível, se houver, o painel parental deve apresentar sinais de anomalia (Níveis 1‑2) — e deve alguma vez ser visível para a criança, mesmo indiretamente?
2. O Math Challenge realizará algum evento com apostas reais (bolsa de estudo, prémio em dinheiro, competição reconhecida pela escola) que justifique o conjunto completo de estatísticas do Tier 5, ou o “nível competitivo” significa apenas direitos de exibição na tabela de classificação?
3. A adoção de WebAuthn/passkey deve ser alguma vez obrigatória, ou sempre opcional, dado que é o único primitivo universal de vinculação de dispositivo mas acrescenta atrito à conta de uma criança pequena?
4. Para a partilha legítima de conta familiar (pai e filho numa única sessão), como as heurísticas de sessão do Tier 4+ devem evitar sinalizar erroneamente a troca normal de dispositivos familiares como suspeita?
5. Existe interesse em publicar uma declaração de confiança/segurança de que o Math Challenge nunca usará supervisão por webcam/biométrica, como diferencial em relação a produtos ao estilo Proctorio e como sinal de confiança para os pais?