Como os testes de digitação detectam trapaça? Como verificamos o nosso

Os testes de digitação detectam trapaça conferindo o registro de teclas por trás de cada resultado. O nosso recalcula todo resultado a partir do registro de teclas, confere um hash, testa a estrutura e o ritmo do registro e segura fora dos rankings públicos qualquer resultado cronometrado acima de 130 WPM cujo ritmo também pareça incomum, até você passar num novo teste. As verificações de ritmo pegam bots descuidados; o novo teste obriga um bot caprichado a fazer tudo de novo.

O primeiro bot que passou pelas nossas verificações de ritmo foi o nosso.

O nosso auxiliar de testes de ponta a ponta apertava teclas num intervalo fixo de 40 ms, porque é isso que um script de teste faz. O servidor recalculou o resultado, confirmou o hash e marcou a sessão como suspeita: variação zero entre os toques, rollover zero, tempos de pressão idênticos. Tivemos de acrescentar uma variação aleatória por palavra e pausas ocasionais de "reflexão" de 80 a 300 ms antes que a nossa própria bateria de testes conseguisse enviar um resultado com cara de humano. A opção continua no código, com o nome humanLike.

As verificações funcionam contra qualquer coisa que não se esforce, e qualquer coisa que se esforce consegue passar por elas; por isso, o projeto põe o peso de verdade num novo teste.

Passo um: recalcular tudo

O seu navegador não nos envia um WPM. Ele envia o registro de teclas (todos os eventos keydown, keyup, input e de composição, com a hora marcada pelo relógio monotônico performance.now()), as métricas que calculou e um hash SHA-256 do resultado canônico.

O servidor roda o mesmo código de métricas sobre o registro e compara. Se qualquer número diferir em mais de 0,01, o resultado é rejeitado como metrics_mismatch. Se o hash não bater, é rejeitado como hash_mismatch. Uma extensão de navegador que edita o campo de WPM, a trapaça mais comum em sites que confiam no cliente, falha aqui. As mesmas funções produzem o número na sua tela e no banco de dados, e é por isso que a nossa página de métricas pode garantir que o exemplo resolvido dela se reproduz até a segunda casa decimal.

Por que não cronometrar o teste no servidor? Porque aí o seu resultado incluiria a rede. Cada toque chegaria até nós um pouco atrasado, num valor que varia com a sua conexão, e quem digita rápido numa linha lenta perderia velocidade que realmente tem. O registro nos dá o relógio do cliente para a precisão e o recálculo do servidor para a honestidade.

Passo dois: o registro faz sentido?

Antes de qualquer análise de ritmo, verificações simples sobre o formato do envio:

  • O teste precisa durar pelo menos 15 segundos ou 10 palavras. Sessões mais curtas têm ruído demais para entrar no ranking e são as mais fáceis de inflar.
  • Um resultado não pode chegar antes de o teste ter podido terminar: o início dele mais a própria duração. Um resultado de 60 segundos que chega vinte segundos depois de começar não aconteceu.
  • O número de eventos precisa ser compatível com os caracteres digitados.
  • No computador, todo evento input precisa vir depois de um keydown em até 50 ms. Isso pega texto colado, eventos input gerados por script e a maioria das ferramentas de injeção de teclas, que disparam texto sem uma tecla física. Digitar com um editor de métodos de entrada (composição IME) é exceção, e os resultados de celular ficam fora dos rankings públicos.
  • Um registro sem início, sem fim ou com marcações de tempo não monotônicas está malformado e é rejeitado de cara.

Nada disso é engenhoso, mas elimina a maior parte do volume.

Passo três: o que o ritmo das teclas pode revelar?

Esta é a parte que, de propósito, não documentamos por inteiro: a lista de características é pública; os limites e os pesos, não. Um limite publicado vira alvo. Se disséssemos "um desvio-padrão abaixo de N milissegundos é marcado", a próxima versão de todo script acrescentaria N mais um. As características que pontuamos:

O intervalo médio entre teclas e o quanto ele varia. A digitação humana é irregular. No estudo de Dhakal e colegas de 2018, com 168.960 digitadores, o intervalo médio entre teclas foi de cerca de 239 ms, com desvio-padrão de cerca de 112 ms. Um script que digita em intervalo fixo quase não tem variação; um estudo de 2025 publicado no arXiv sobre um CAPTCHA baseado em toques de teclado viu exatamente isso no seu bot de teste, que digitava com um atraso fixo de 50 ms. Este é o nosso sinal mais forte, e foi nele que o nosso auxiliar tropeçou.

A proporção de intervalos abaixo de 40 ms. Um intervalo de 40 ms, mantido, dá 1.500 caracteres por minuto, ou 300 WPM a cinco caracteres por palavra. Os dedos produzem, sim, intervalos isolados tão curtos quando sobrepõem teclas durante o rollover, então um intervalo curto não quer dizer nada. Um registro em que uma grande parte dos intervalos é tão curta não é digitação.

O tempo que as teclas ficam pressionadas. Dedos de verdade variam em dezenas de milissegundos; eventos sintéticos muitas vezes têm tempos de pressão idênticos ou quase zero, porque a ferramenta dispara keydown e keyup um logo após o outro.

A taxa de rollover. Com que frequência a próxima tecla desce antes de a anterior subir. Dhakal mediu uma taxa média de rollover de 25%, com a maioria dos digitadores rápidos fazendo rollover em 40 a 70% dos toques, e as teclas se sobrepondo em 30 ms, em média. Quem digita devagar quase não faz rollover, então um resultado rápido sem rollover chama a atenção. Bots raramente sobrepõem teclas.

A pausa mais longa, as oscilações de velocidade de um segundo para o outro e a proporção de intervalos acima de um segundo. As pessoas hesitam de maneiras que um script precisa ser instruído a imitar.

Um modelo de pontuação combina tudo isso e pode marcar um resultado como suspeito. Abaixo de 130 WPM, uma marcação não rejeita nada sozinha. O seu resultado nunca fica escondido de você; essas verificações só decidem se ele entra no ranking.

A trapaça em testes de digitação consegue passar pelas verificações de ritmo?

Sim, se a trapaça for feita com cuidado. Um artigo de janeiro de 2026 no arXiv, de David Condrey, testou detectores baseados no ritmo de digitação criados para separar texto digitado por humanos de texto gerado por IA. Eles separaram perfeitamente a injeção totalmente automatizada, mas ataques com ritmo humano (uma pessoa redigitando texto de IA, ou um programa que sorteia atrasos a partir de dados de digitação humana) escaparam dos cinco classificadores em pelo menos 99,8% dos casos. O artigo trata de detecção de autoria, não de testes de digitação, mas a lição vale do mesmo jeito: o passo três pega os descuidados e não muito mais.

O nosso próprio auxiliar de testes mostra o mesmo em pequena escala: uma variação aleatória e algumas pausas o levaram de obviamente sintético a plausível.

Então o passo três é um filtro. O veredito vem do passo quatro.

Passo quatro: o teste de verificação

Se um resultado cronometrado passa de 130 WPM e o ritmo dele também parece incomum, você o vê e ele é salvo, mas fica fora dos rankings públicos até você passar num teste de verificação. É um novo teste de 30 segundos, e você precisa chegar a pelo menos 75% da velocidade alegada. Um golpe de sorte isolado ou um registro emprestado não sobrevive a uma segunda rodada.

Por que 130 WPM? É cerca de duas vezes e meia a média de 51,56 WPM dos dados de Dhakal, bem acima da maioria dos digitadores, e quem realmente digita tão rápido consegue repetir. Um resultado rápido repentino com ritmo estranho é o formato que um registro emprestado ou um script produz e, se for honesto, um teste a mais é um preço pequeno.

O teste de verificação é um teste de digitação comum, com texto comum, e não uma imagem distorcida ou uma página de símbolos estranhos. Texto difícil de ler deixa todo mundo mais lento, e quem mais perde são justamente os digitadores rápidos e honestos que o teste existe para liberar. Uma verificação em que os digitadores rápidos e honestos são reprovados é pior do que nenhuma. O texto comum também torna a verificação justa: o próprio registro do teste de verificação passa pelas mesmas verificações de ritmo que qualquer outro resultado.

Limites de envio e banimentos

Os envios têm limite de frequência: trinta por minuto por usuário conectado, sessenta por endereço IP. Uma conta que vive acionando as verificações recebe um shadow ban, ou seja, é escondida dos rankings sem aviso, e três eventos antifraude graves em 24 horas acionam isso automaticamente. Contar eventos dentro de uma janela de tempo faz com que um resultado estranho isolado nunca custe uma conta, enquanto um script que falha repetidamente é barrado rápido.

Os rankings de todos os tempos também exigem 30 minutos de digitação na conta, então uma conta nova com uma única sessão perfeita não consegue chegar ao topo.

O que faz você ser marcado sem querer

A maioria dos resultados marcados não é trapaça. Os jeitos honestos de acionar uma verificação:

Corretor automático no celular. Uma substituição chega como um único evento input que muda vários caracteres. Contamos isso como um toque, marcamos o resultado e o deixamos fora dos rankings públicos com uma observação, não com uma rejeição.

Texto colado. Colar é bloqueado, e um resultado em que houve tentativa de colar fica fora dos rankings.

Trocar de aba. Se o foco sair da página por mais de dois segundos durante um teste, ele é marcado como interrompido; é salvo e mostrado, mas não entra no ranking.

Pausar. Um intervalo de mais de cinco segundos num teste de palavras ou de citação marca o resultado como pausado. Mesmo tratamento.

Composição IME. Japonês, coreano e chinês chegam por eventos de composição, então pulamos a regra do keydown para eles. Se algo ainda parecer errado, é um bug, e gostaríamos de ver o registro.

Resultados off-line. Um resultado sincronizado mais de dez minutos depois de terminar fica no seu histórico sem ranking, porque não conseguimos validar o relógio dele.

Ser rápido de verdade. Acima de 130 WPM você vai dar de cara com o teste de verificação, provavelmente no seu primeiro dia bom.

Como contestar

Toda exclusão mostra o motivo no seu histórico. Se você acha que erramos sobre um resultado ou uma restrição, mande um e-mail para o endereço de contestação da nossa página antifraude, a partir do e-mail da sua conta, com o link do resultado ou a data e a hora do teste. Uma pessoa assiste à reprodução dos toques e responde em poucos dias. As contestações nunca são decididas só pelo modelo automático.

Acabamos de publicar um manual de como passar pelas verificações? Em parte. A lista de características sempre pôde ser descoberta pelo comportamento, e os limites continuam privados. O teste de verificação é a parte que importa, e o jeito de passar nele é digitar.

Perguntas frequentes

Como os testes de digitação detectam bots?

Os bons leem o registro de teclas: se cada caractere tem um toque de tecla por trás, o quanto os intervalos entre as teclas variam e como as teclas são pressionadas e sobrepostas. Scripts tendem a ser regulares demais; bots caprichados conseguem imitar humanos, e é por isso que acrescentamos um teste de verificação.

Um bot consegue passar pelo antifraude de um teste de digitação?

Um bot caprichado consegue passar pelas verificações de ritmo: uma pesquisa sobre detectores baseados no ritmo de digitação descobriu que um ritmo humano falsificado escapava deles quase sempre. É por isso que seguramos os resultados rápidos para um teste de verificação, no qual o bot tem de passar de novo com um segundo registro que supere as mesmas verificações.

Por que o meu resultado no teste de digitação não entrou no ranking?

Normalmente por um teste com menos de 15 segundos ou 10 palavras, uma pausa de mais de cinco segundos, uma troca de aba ou um resultado acima de 130 WPM aguardando o teste de verificação. O seu histórico mostra o motivo.

Fontes