Os testes de dactilografia detetam batota verificando o registo de teclas por trás de cada pontuação. O nosso recalcula cada resultado a partir do registo de teclas, verifica um hash, testa a estrutura e os tempos do registo e mantém fora das classificações públicas qualquer resultado cronometrado acima de 130 WPM cujos tempos também pareçam invulgares, até passar num teste de verificação. As verificações de tempos apanham os bots descuidados; o teste de verificação obriga um bot cuidadoso a fazer tudo outra vez.
O primeiro bot a passar as nossas verificações de tempos foi o nosso.
O nosso auxiliar de testes automáticos de ponta a ponta carregava nas teclas com um intervalo fixo de 40 ms, porque é isso que um script de testes faz. O servidor recalculou o resultado, confirmou o hash e classificou a tentativa como suspeita: variância zero entre 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 de a nossa própria bateria de testes conseguir publicar um resultado com ar humano. A opção continua no código, com o nome humanLike.
As verificações funcionam contra tudo o que não se esforça, e tudo o que se esforça consegue passá-las, por isso o desenho põe o verdadeiro peso num teste de verificação.
Primeiro passo: recalcular tudo
O seu navegador não nos envia umas WPM. Envia o registo de teclas (cada evento keydown, keyup, input e composition, 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 corre o mesmo código de métricas sobre o registo e compara. Se algum número diferir mais de 0,01, o resultado é rejeitado como metrics_mismatch. Se o hash não coincidir, é rejeitado como hash_mismatch. Uma extensão do navegador que edita o campo das WPM, a batota mais comum nos sites que confiam no cliente, falha aqui. São as mesmas funções que produzem o número no seu ecrã e na base de dados, e é por isso que a nossa página de métricas pode prometer que o seu exemplo resolvido se reproduz com duas casas decimais.
Porque não cronometrar o teste no servidor? Aí a sua pontuação incluiria a rede. Cada toque chegar-nos-ia um pouco atrasado, num valor que varia com a sua ligação, e quem escreve depressa numa linha lenta perderia velocidade que tinha de facto. O registo dá-nos o relógio do cliente para a precisão e o recálculo do servidor para a honestidade.
Segundo passo: o registo faz sentido?
Antes de qualquer análise de tempos, verificações simples à forma do envio:
- O teste tem de durar pelo menos 15 segundos ou 10 palavras. Tentativas mais curtas têm demasiado ruído para serem classificadas e são as mais fáceis de inflacionar.
- Um resultado não pode chegar antes de o teste poder ter terminado: o seu início mais a sua 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 tem de corresponder aos caracteres escritos.
- No computador, cada evento input tem de vir depois de um keydown, no máximo 50 ms antes. Isto apanha texto colado, eventos input gerados por script e a maioria das ferramentas de injeção de teclas, que produzem texto sem uma tecla física. Escrever através de um editor de métodos de introdução (composição IME) está isento, e os resultados de telemóvel ficam fora das classificações públicas.
- Um registo sem início, sem fim ou com marcas de tempo não monotónicas está mal formado e é rejeitado de imediato.
Nada disto é engenhoso, mas elimina a maior parte do volume.
Terceiro passo: o que podem revelar os tempos das teclas?
Esta é a parte que propositadamente não documentamos por completo: a lista de características é pública, os limiares e os pesos não. Um limiar publicado é um alvo. Se disséssemos «um desvio-padrão abaixo de N milissegundos é assinalado», a versão seguinte de todos os scripts acrescentaria N mais um. As características que pontuamos:
O intervalo médio entre teclas e quanto varia. A escrita humana é irregular. No estudo de Dhakal e colegas de 2018, com 168 960 pessoas, o intervalo médio entre teclas era de cerca de 239 ms, com um desvio-padrão de cerca de 112 ms. Um script que escreve com um intervalo fixo quase não tem variação; um estudo de 2025 no arXiv sobre um CAPTCHA baseado em toques viu exatamente isso no seu bot de teste, que escrevia com um atraso fixo de 50 ms. Este é o nosso sinal mais forte, e foi o que o nosso auxiliar fez disparar.
A parte dos intervalos abaixo de 40 ms. Um intervalo de 40 ms, mantido, dá 1500 caracteres por minuto, ou 300 WPM a cinco caracteres por palavra. Os dedos produzem de facto intervalos isolados assim tão curtos quando sobrepõem teclas durante o rollover, por isso um intervalo curto não significa nada. Um registo em que uma grande parte dos intervalos é assim tão curta não é escrita.
Os tempos de pressão das teclas. Os dedos reais variam dezenas de milissegundos; os eventos sintéticos têm muitas vezes tempos de pressão idênticos ou quase nulos, porque a ferramenta dispara keydown e keyup seguidos.
A taxa de rollover. Com que frequência a tecla seguinte desce antes de a anterior subir. Dhakal mediu uma taxa média de rollover de 25%, com a maioria dos mais rápidos a fazer rollover em 40 a 70% dos toques e as teclas sobrepostas em média 30 ms. Quem escreve devagar quase não o usa, por isso um resultado rápido sem rollover destaca-se. Os bots raramente sobrepõem teclas.
A pausa mais longa, as oscilações de velocidade de segundo para segundo e a parte dos intervalos acima de um segundo. As pessoas hesitam de maneiras que um script tem de ser instruído a imitar.
Um modelo de pontuação combina estas características e pode assinalar um resultado como suspeito. Abaixo de 130 WPM, um alerta não rejeita nada por si só. O seu resultado nunca lhe é escondido; estas verificações só decidem se é classificado.
A batota num teste de dactilografia consegue passar as verificações de tempos?
Sim, se a batota for feita com cuidado. Um artigo de janeiro de 2026 no arXiv, de David Condrey, testou detetores baseados nos tempos de teclas feitos para distinguir texto escrito por pessoas de texto gerado por IA. Separaram na perfeição a injeção totalmente automática, mas os ataques com tempos humanos (uma pessoa a reescrever texto de IA, ou um programa a tirar atrasos de dados de escrita humana) escaparam aos cinco classificadores em pelo menos 99,8% dos casos. O artigo trata de deteção de autoria, não de testes de dactilografia, mas a lição aplica-se: o terceiro passo apanha os descuidados e pouco mais.
O nosso próprio auxiliar de testes mostra o mesmo em pequena escala: uma variação aleatória e algumas pausas fizeram-no passar de obviamente sintético a plausível.
Por isso, o terceiro passo é um filtro. O veredicto vem do quarto passo.
Quarto passo: o teste de verificação
Se um resultado cronometrado estiver acima de 130 WPM e os seus tempos também parecerem invulgares, vê-o e ele é guardado, mas fica fora das classificações públicas até passar num teste de verificação. É um teste novo de 30 segundos, e precisa de atingir pelo menos 75% da velocidade que reclamou. Um acaso isolado ou um registo emprestado não sobrevivem a uma segunda tentativa.
Porquê 130 WPM? É cerca de duas vezes e meia a média de 51,56 WPM nos dados de Dhakal, muito acima da maioria das pessoas, e quem escreve mesmo assim tão depressa consegue fazê-lo duas vezes. Um resultado rápido repentino com tempos estranhos é a forma que um registo emprestado ou um script produzem, e, se for honesto, um teste a mais é um preço pequeno.
O teste de verificação é um teste de dactilografia normal, com texto normal, não uma imagem distorcida nem uma página de símbolos estranhos. Texto difícil de ler abranda toda a gente, e quem mais abranda são precisamente as pessoas honestas e rápidas que o teste de verificação existe para validar. Uma verificação em que as pessoas honestas e rápidas chumbam é pior do que nenhuma. O texto normal também torna a verificação justa: o registo do próprio teste de verificação passa pelas mesmas verificações de tempos que qualquer outro resultado.
Limites de envio e banimentos
Os envios têm um limite: trinta por minuto por utilizador com sessão iniciada, sessenta por endereço IP. Uma conta que continua a fazer disparar as verificações é alvo de um shadow ban, ou seja, fica discretamente escondida das classificações, e três eventos anti-batota graves em 24 horas desencadeiam isso automaticamente. Contar eventos dentro de uma janela de tempo significa que um resultado estranho nunca lhe custa a conta, enquanto um script que falha uma e outra vez é travado depressa.
As classificações de sempre também exigem 30 minutos de escrita na conta, por isso uma conta nova com uma tentativa perfeita não consegue chegar ao topo.
O que o pode fazer ser assinalado por engano
A maioria dos resultados assinalados não é batota. As formas honestas de fazer disparar uma verificação:
A correção automática num telemóvel. Uma substituição chega como um único evento input que muda vários caracteres. Contamo-la como um toque, assinalamo-la e mantemos o resultado fora das classificações públicas com uma nota, não com uma rejeição.
Texto colado. Colar está bloqueado, e um resultado em que se tentou colar fica excluído das classificações.
Mudar de separador. Se a página perder o foco durante mais de dois segundos durante um teste, este fica marcado como interrompido; é guardado e mostrado, mas não é classificado.
Fazer pausas. Um intervalo de mais de cinco segundos num teste de palavras ou de citação marca o resultado como em pausa. O mesmo tratamento.
Composição IME. O japonês, o coreano e o chinês chegam através de eventos de composição, por isso não aplicamos a regra do keydown nesses casos. Se mesmo assim algo parecer errado, é um erro nosso, e gostaríamos de ver o registo.
Resultados offline. Um resultado sincronizado mais de dez minutos depois de terminar fica no seu histórico sem classificação, porque não conseguimos validar o seu relógio.
Ser mesmo rápido. Acima de 130 WPM vai encontrar o teste de verificação, provavelmente no seu primeiro dia bom.
Como recorrer
Cada exclusão mostra o motivo no seu histórico. Se achar que nos enganámos sobre um resultado ou uma restrição, envie um email para o endereço de recurso indicado na nossa página anti-batota a partir do endereço da sua conta, com a ligação do resultado ou a data e hora do teste. Uma pessoa vê a repetição dos toques e responde em poucos dias. Os recursos nunca são decididos só pelo modelo automático.
Acabámos de publicar um guia para passar as verificações? Em parte. A lista de características sempre se pôde descobrir pelo comportamento, e os limiares continuam privados. O teste de verificação é a parte que importa, e a forma de passar nele é escrever.
Perguntas frequentes
Como é que os testes de dactilografia detetam bots?
Os bons leem o registo de teclas: se cada carácter tem um toque por trás, quanto variam os intervalos entre teclas e como as teclas são mantidas e sobrepostas. Os scripts tendem a ser demasiado regulares; os bots cuidadosos conseguem imitar pessoas, e é por isso que acrescentamos um teste de verificação.
Um bot consegue passar o sistema anti-batota de um teste de dactilografia?
Um bot cuidadoso consegue passar as verificações de tempos: a investigação sobre detetores baseados nos tempos de teclas concluiu que tempos falsificados com ar humano os enganavam quase sempre. É por isso que retemos os resultados rápidos para um teste de verificação, que um bot tem de passar outra vez com um segundo registo que supere as mesmas verificações.
Porque é que o meu resultado não foi classificado?
Normalmente por um teste com menos de 15 segundos ou 10 palavras, uma pausa de mais de cinco segundos, uma mudança de separador ou um resultado acima de 130 WPM à espera do teste de verificação. O seu histórico mostra o motivo.