Funcionalidade — recolher
Proteção contra spam que nunca tem de passar.
O NumoForms filtra submissões de lixo com três camadas impostas por um acionador de base de dados e não pelo formulário: um campo honeypot fora do ecrã, um tempo mínimo de permanência de 3 segundos por predefinição e configurável por inquérito, e um limite de frequência de 30 respostas por minuto por inquérito. Deliberadamente, não há reCAPTCHA. Uma resposta que as verificações assinalem não é descartada — quem responde é informado do que aconteceu e pode confirmá-la.
A verificação vive na base de dados, não na página
No NumoForms, as respostas são inseridas diretamente do navegador para a base de dados. Isso significa também que qualquer regra escrita apenas na interface é meramente indicativa. Um script que publique diretamente na API nunca chega a executar o seu JavaScript, pelo que nunca vê a verificação.
Por isso, as três verificações correm num acionador de base de dados. Toda e qualquer inserção passa por ele, quer venha da página alojada do inquérito, de um inquérito integrado noutro site, ou de um script que alguém escreveu às três da manhã. É o mesmo raciocínio que está por trás das datas de fecho e dos limites de respostas, também eles impostos ao nível da base de dados e não escondendo um botão.
O sítio onde as verificações correm importa mais do que a sua engenhosidade. Dois dos três sinais — o valor do honeypot e o tempo decorrido — são enviados pelo navegador, pelo que um script feito à medida pode deixar o campo oculto vazio e não enviar temporização nenhuma. O limite de frequência não precisa de nada vindo do cliente, e é por isso que é a camada que se mantém quando as outras duas são retiradas.
As três camadas
1. Honeypot
Um campo colocado fora do ecrã, que uma pessoa a preencher o inquérito nunca vê nem seleciona. Os preenchedores automáticos de formulários tendem a completar todos os campos que encontram. Tudo o que chegue com esse campo preenchido não foi preenchido por alguém que estivesse a ler a página.
2. Tempo de permanência
Um mínimo, em segundos, para o tempo que uma resposta demorou. A predefinição é 3 e define-se por inquérito, para que uma consulta de 40 perguntas possa exigir mais do que um formulário de opinião com duas. A ausência de temporização não é tratada como spam, pelo que clientes mais antigos e respostas retomadas através de uma ligação de guardar e continuar continuam a funcionar.
3. Limite de frequência
Respostas por minuto por inquérito, com predefinição de 30. Esta não precisa de absolutamente nada vindo do cliente, e é esse o objetivo: mantém-se perante um robô que retire todos os metadados de que as outras duas camadas dependem.
Porque é que não há reCAPTCHA
É a decisão com maior probabilidade de surgir num processo de aquisição, pelo que fica aqui o argumento completo.
Torna a Google um subcontratante na sua consulta
Colocar o reCAPTCHA num formulário de consulta pública significa que todos os residentes que o abram enviam dados à Google antes sequer de responderem a uma pergunta. Alguém na sua organização tem depois de registar essa transferência, justificá-la e defendê-la numa política de privacidade, para um formulário que existe para recolher opiniões sobre a recolha do lixo. O NumoForms mantém o conteúdo dos inquéritos e as respostas na região de Londres do Supabase, e a página do RGPD e proteção de dados explica o que isso significa na prática. Acrescentar uma empresa de publicidade à cadeia de tratamento para apanhar meia dúzia de linhas de lixo é um mau negócio para uma autarquia que realiza consultas públicas.
Deixa de fora quem tem deficiência
Os desafios de imagem e áudio são uma causa bem documentada de submissões falhadas por pessoas com deficiência. A nossa página sobre acessibilidade argumenta precisamente contra esse padrão. Lançar um CAPTCHA contradiria uma posição que publicamos, e um inquérito que uma pessoa que usa leitor de ecrã não consegue terminar não é um inquérito com boa proteção contra spam. É um inquérito com uma amostra enviesada.
As três verificações que o NumoForms faz são invisíveis. Não se pede a ninguém que prove seja o que for, que identifique um autocarro ou que transcreva áudio distorcido. Não há nenhum desafio que se possa falhar.
A rejeição nunca é definitiva
Todas as heurísticas aqui descritas têm um caso honesto de falso positivo, e fingir o contrário seria a forma de perder dados reais.
Um inquérito de duas perguntas responde-se mesmo em poucos segundos. Uma sala com trinta pessoas numa sessão de consulta, a quem se entregou a ligação ao mesmo tempo, produz mesmo trinta submissões no mesmo minuto. Do ponto de vista da base de dados, ambos os casos são indistinguíveis de um ataque.
Por isso, uma resposta assinalada não vai discretamente para o lixo. É mostrado a quem responde o que aconteceu, as respostas são preservadas e pode enviá-las de novo — a segunda tentativa dispensa o sinal de temporização, porque uma pessoa acabou de responder por ele. O honeypot e o limite de frequência continuam a aplicar-se, pelo que uma verdadeira enxurrada é convidada a tentar de novo dentro de momentos em vez de passar sem mais. Isso transforma o filtro em atrito para um script e num único toque adicional para uma pessoa. Perder uma resposta genuína a uma consulta é pior do que aceitar uma de lixo, e uma de lixo torna-se evidente mais tarde na sua análise de resultados e de abandono.
O que isto não faz
Dito com clareza, porque mais cedo ou mais tarde acabaria por descobrir.
- Não há Cloudflare Turnstile. É o desafio respeitador da privacidade mais frequentemente sugerido como alternativa ao reCAPTCHA, e hoje não está integrado.
- Não há bloqueio por IP. Nada aqui bloqueia nem limita por endereço, pelo que um atacante determinado que distribua as submissões por muitas origens e as espace abaixo do limite não é travado por estas três camadas.
- Dois dos três sinais vêm do navegador. O valor do honeypot e o tempo decorrido são fornecidos pelo cliente, pelo que um script escrito especificamente para o seu inquérito pode recusar-se a enviar qualquer um deles. Travam preenchedores automáticos genéricos, não um atacante dirigido; o limite de frequência é a camada que não depende de colaboração.
- Não há filtragem de conteúdos. As verificações olham para o modo como uma resposta chegou, não para o que ela diz. Texto livre ofensivo é um problema de moderação; as aprovações de passo único retêm as respostas até alguém as validar.
Aquilo em que estas camadas são boas é no caso comum: preenchedores automáticos de formulários, submissões em massa a partir de um único script e o duplo envio acidental.
Perguntas frequentes sobre spam em inquéritos
O NumoForms usa reCAPTCHA?
Não, e isso é uma decisão deliberada e não uma lacuna. Acrescentar o reCAPTCHA tornaria a Google um subcontratante em todas as consultas públicas, algo que o encarregado da proteção de dados teria depois de justificar. Os seus desafios de imagem e áudio são também uma causa bem documentada de submissões falhadas por parte de pessoas com deficiência. As três verificações que o NumoForms faz são invisíveis: não há nenhum desafio que se possa falhar.
O que acontece se alguém responder genuinamente mais depressa do que o tempo mínimo de permanência?
É-lhe mostrado o que aconteceu e pode confirmar a submissão, que segue então o seu curso. Um inquérito de duas perguntas é mesmo respondível em menos de três segundos, pelo que uma rejeição definitiva deitaria fora respostas verdadeiras. Perder uma resposta genuína a uma consulta é pior do que aceitar uma resposta de lixo.
Porquê impor as verificações de spam na base de dados em vez de no formulário?
Porque as respostas são inseridas diretamente do navegador para a base de dados. Tudo o que seja verificado apenas na interface pode ser contornado por um script que publique diretamente, pelo que uma verificação ao nível da interface é uma sugestão e não um controlo. O NumoForms executa as verificações de honeypot, tempo de permanência e limite de frequência num acionador de base de dados, por onde passa toda e qualquer inserção, venha ela de onde vier.
Qual é o tempo de permanência e o limite de frequência predefinidos?
O tempo mínimo de permanência é de 3 segundos por predefinição e é configurável por inquérito. O limite de frequência é de 30 respostas por minuto por inquérito. O limite de frequência não precisa de nada vindo do cliente, pelo que continua a aplicar-se a um robô que retire por completo os metadados de temporização.
O NumoForms bloqueia spam por endereço IP?
Não. Não existe bloqueio por IP nem integração com o Cloudflare Turnstile. A proteção é o honeypot, o tempo mínimo de permanência e o limite de frequência por inquérito, todos impostos na base de dados.
Filtre o lixo sem um quebra-cabeças.
O honeypot, o tempo mínimo de permanência e o limite de frequência por inquérito correm num gatilho da base de dados, pelo que todas as respostas passam por eles, seja qual for a via por onde chegaram. Nunca se pede a quem responde para identificar um autocarro.
- Três camadas: honeypot, tempo de permanência, limite de frequência
- Tempo mínimo de permanência configurável por inquérito, 3 segundos por omissão
- Uma resposta assinalada pode confirmar e prosseguir
