FYI @codinghorror, a equipe do Chrome ainda não fez nada.
A situação continua quebrada no Chrome; podemos resolver trivialmente substituindo nossa armadilha de proteção contra spam por algum tipo de prova de trabalho.
Fechando por mais 2 meses.
A equipe do Chrome parece interessada em corrigir isso, mas precisa de logs aqui:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
Vou ver se consigo coletar alguns amanhã. Se alguém fizer isso antes de mim, você será meu herói; marque esta postagem.
EDIT … enviei os logs para eles.
@codinghorror isso está dando voltas no Google. Eles afirmam que o comportamento é intencional e que não há como detectar com precisão se uma textarea está visível ou não.
A resposta geral aqui é: “É trivial para um bot contornar isso, então qual é o ponto?”. Eu não tenho realmente uma resposta; de certa forma, concordo com eles. A armadilha (honeypot) é meio tola e posso substituí-la facilmente por outra coisa para garantir que o usuário esteja executando JavaScript ao registrar uma conta.
Já perdi tanto tempo com isso e sinto que estou lutando contra moinhos de vento. Só quero implementar uma correção e seguir em frente.
Ok, mas eu quero que seja uma prova de trabalho bem complexa. Existe algum código existente que possamos utilizar?
Sim, consigo montar algo, com certeza será melhor do que nosso sistema atual. Nosso sistema atual de “proof of work” é “inverter uma string”.
Gastei muito tempo demais pensando neste problema, então decidi que era hora de deixá-lo para trás:
De acordo com este commit, o OP aqui está “corrigido”:
A correção é um pouco complicada e envolveu duas partes das quais estou feliz por ter conseguido resolver.
-
Reforcei bastante a lógica para honeypot e desafio.
-
Adicionei uma solução alternativa apenas no lado do cliente para um bug do Chrome no preenchimento automático. Estou confortável com isso porque não altera em nada o protocolo do lado do servidor.
Anteriormente, reutilizávamos nossa string aleatória de honeypot e desafio para todas as registros de contas no site, o que tornava a criação de contas via script bastante trivial, pois bastava codificar um valor fixo uma única vez.
A nova implementação fornece uma string única para cada usuário validar, que está vinculada ao seu armazenamento de cookies (no nosso armazenamento seguro de sessão). Essa string expira após uma hora.
Isso significa que, ao automatizar esse tipo de coisa, você é forçado a fazer chamadas regulares para obter novos desafios e honeypots entre as requisições, e não pode simplesmente criar contas em massa sem obstáculos.
A solução alternativa mencionada em 2 consiste simplesmente em remover um campo INPUT que o Chrome está confundindo e substituí-lo por um INPUT do tipo texto com o qual ele não se confunde.
No geral, não sinto que (2) facilite a vida de um bot “genérico” programado para registrar contas em sites desconhecidos. Para começar, o bot precisaria usar o Chrome WebDriver, analisar todo o nosso Ember e seguir um fluxo muito específico. Essa barreira é muito baixa e nada comparada aos novos desafios rotativos por usuário.
Quanto à adição de prova de trabalho, gostaria de esperar um pouco, não porque seja particularmente difícil de implementar, mas mais porque não quero ficar procurando pelo algoritmo SHA1 mais rápido disponível e depois enviá-lo ao cliente sob demanda.
Deixo isso aberto por um tempo para que as pessoas possam confirmar se minha correção resolve o problema. Vou fechar isso em uma semana.