Oculte, ofusque ou evite a coleta de endereços de email [closed]

5

Estou desenvolvendo um webapp de repositório público para minha organização.

Será o webapp público, exposto à internet. Todas as pessoas e unidades organizacionais podem ser consultadas e seus dados de contato serão exibidos. É desenvolvido como um aplicativo de página única contra um back-end REST. Provavelmente também haverá um front-end móvel no futuro.

Um requisito é que os e-mails das pessoas sejam visíveis e sejam links clicáveis com o atributo mailto:[email protected] href, para que os usuários possam clicar no endereço para começar a escrever um e-mail rapidamente.

Por outro lado, quero dificultar a coleta de e-mails por spammers (sei que, com o requisito acima, sempre será possível obter os endereços de e-mail, mas não quero que seja mais fácil). Por isso, não quero expor os emails em texto não criptografado na minha API.

A versão anterior deste aplicativo usava texto para imagem gerado pelo servidor para mostrar o endereço e, em seguida, o manipulador onclick usava uma chamada AJAX para obter o endereço real do servidor (com base no ID da pessoa), então ative o link "mailto".

Não parece tão bom gerar uma ou duas chamadas de servidor extras para cada pessoa exibida, especialmente ao exibir uma lista de resultados de pesquisa. Eu estou pensando que provavelmente posso fazer melhor. Por exemplo, eu poderia apenas incluir o campo de e-mail na minha API, mas ofuscar / criptografá-lo. O aplicativo (ou qualquer cliente futuro feito por nós, como um aplicativo para dispositivos móveis) saberia como decodificar o endereço de e-mail.

Existe uma maneira melhor de fazer isso?

    
por Pierre Henry 26.11.2015 / 11:02
fonte

3 respostas

1

Primeiro, deixe-me dizer que a imagem é uma boa solução, e não requer nenhum passeio extra ao servidor enquanto exibe os resultados da pesquisa: uma vez gerada, a imagem pode ser salva em um arquivo de imagem no sistema de arquivos do servidor e serviu como um <img src="user337567.png"/> simples. Isso significa que o servidor estará essencialmente armazenando as imagens em cache, recalculando-as apenas no caso de um endereço de email ter sido alterado. As viagens de ida e volta extra para o servidor só serão necessárias quando o usuário clicar em uma imagem de endereço de e-mail, mas clicar em uma operação executada em hora humana representa, portanto, uma sobrecarga insignificante.

Um pequeno problema com essa abordagem é que os spammers podem estar usando a tecnologia de reconhecimento óptico de caracteres. Uma maneira de explicar essa possibilidade seria tornar os endereços de e-mail processados difíceis de ler, como um captcha, mas você nunca terá uma métrica informando o quanto foi bem-sucedido nessa questão.

Outras abordagens:

  1. Requer autenticação.

    Torne as páginas da Web do seu aplicativo de repositório público visíveis para todos os visitantes, mas oculte os endereços de e-mail. Quando um visitante clica em (ou passa sobre) um endereço de e-mail oculto, informe-o de que ele deve se registrar para visualizar essa informação. No processo de registro, exija um captcha. A lógica por trás disso:

    É justo que você possa ver nossos endereços de e-mail se nos informar primeiro, certo?

    Observe que você pode até usar essa abordagem além de exibir endereços de e-mail como imagens clicáveis, para maior segurança.

    Observe também que você pode usar essa abordagem para proteger muito mais informações do que apenas endereços de e-mail. (E se houver necessidade de também proteger números de telefone mais tarde?)

  2. Use medidas adicionais de combate à colheita.

    Uma abordagem comumente usada é exigir que os clientes usem cookies, para poder identificar cada cliente e, em seguida, controlar as solicitações recebidas pelo servidor de um cliente específico e se o cliente enviar muitas solicitações muito rapidamente , então, coloque-os na lista negra. Normalmente, blacklisting significa negar qualquer serviço, mas no seu caso, a lista negra poderia simplesmente significar que a partir desse momento você não mostrará mais endereços de e-mail, ou que a partir daquele momento você mostrará imagens em vez de endereços de e-mail.

    Observe que essa é uma ação geralmente útil, que pode evitar vários tipos diferentes de abuso, e você pode querer implementá-la independentemente do que fizer especificamente para os endereços de e-mail.

  3. Implementar "ligaremos de volta"

    Se você realmente quiser evitar a autenticação, em vez de exibir os endereços de e-mail, você pode ter um campo "contato" que, quando clicado, exibe uma caixa de diálogo que solicita ao visitante que insira seu endereço de e-mail um captcha,) e envia ao visitante uma mensagem de e-mail à qual o visitante pode responder.

por 26.11.2015 / 17:15
fonte
5

Não pense demais, a maneira óbvia (renderizar imagem em vez de texto) é exatamente a coisa certa a fazer aqui.

Hoje em dia, qualquer atraso ou custo de processamento envolvido em uma chamada de servidor extra será insignificante comparado com o tipo de tempo que o usuário leva para mover um mouse e realizar um clique em primeiro lugar. (Do ponto de vista de um computador, as pessoas se movem em movimento ultra-ultra-lento.)

    
por 26.11.2015 / 11:06
fonte
2

Por que não usar uma imagem conforme mencionado acima e incluir um endereço de e-mail criptografado (leve) para cada imagem, juntamente com uma função Javascript local para resolver o e-mail ofuscado após o clique? Dessa forma, tudo fica em uma única viagem, mas a maioria dos usuários de spam não vai se interessar pelo evento e procurar por um caminho de processo para um resultado, eles vão ler a tag e esperar que ela seja válida. Simples e eficaz, não? Não a cura tudo acaba com tudo, mas deve acontecer.

    
por 26.11.2015 / 16:25
fonte