Proteção de endereço de e-mail via SVG, em vez de JavaScript

• Para ocultar um endereço de e-mail público de bots de spam que fazem coleta, sem impedir que visitantes entrem em contato imediatamente, o método coloca o texto do e-mail e o link mailto: dentro do SVG
• A proteção baseada em JavaScript pode ser mais sofisticada, mas há o incômodo de a própria função de contato passar a ter dependência de JS
• Essa abordagem insere um documento SVG externo no HTML por meio de e coloca o link real não no HTML, mas em um elemento dentro do SVG
• O SVG ajuda a ocultar o conteúdo como se fosse uma imagem, mas como usa o elemento ``, o visitante ainda pode copiar o endereço de e-mail
• Não é uma solução capaz de bloquear até os spambots mais sofisticados, mas é útil para reduzir o risco de exposição a scripts simples de coleta de e-mails

---

Como ocultar um endereço de e-mail com SVG

• Um endereço de e-mail público fica facilmente exposto a spambots que fazem coleta de e-mails, por isso precisa de proteção
• As técnicas de proteção mais comuns combinam HTML, CSS e JavaScript, mas ao usar JavaScript a função de contato fica vinculada ao ambiente de execução obrigatório da página
• A abordagem com SVG cuida da exibição do e-mail e do funcionamento do link sem usar JavaScript algum
• Mesmo com o JavaScript desativado, o visitante ainda pode usar o endereço de e-mail exibido na página, e ele fica menos diretamente exposto a spambots do que um texto HTML comum
• Assim como outras técnicas de proteção baseadas em frontend, isso não protege completamente um endereço de e-mail público contra spambots persistentes e sofisticados
• Demo ao vivo: SVG-based Email Protection

Implementação em HTML e SVG

• O documento HTML insere um arquivo SVG externo com ``

• O mesmo documento gráfico SVG pode ser inserido uma ou várias vezes dentro do HTML
• O HTML de exemplo define para a classe .svg-email-protection os estilos width: 180px, height: 24px e vertical-align: middle, e no corpo da página carrega o arquivo SVG com ``
• O arquivo SVG é um documento `` com viewBox="0 0 200 24", e dentro dele ficam o texto do e-mail e o link mailto:[e-mail]
  • Dentro de ficam e ``
  • Em `` é exibido [e-mail]
  • Nos estados rect:hover e a:focus, mudam a cor de fundo, a cor do texto, o peso da fonte, o sublinhado e a sombra

Acessibilidade e materiais de referência

• O documento SVG inteiro usa aria-labelledby apontando para , e o dentro do SVG usa um aria-label com o mesmo call to action
• Quando o foco por Tab do teclado chega ao link dentro do SVG, e são destacados juntos, deixando visível o estado de foco
• Materiais relacionados:
  • Hacker News discussion
  • CSS Tricks article
  • Stack Overflow discussion

[GN⁺]

Opiniões no Hacker News

• Tenho minhas dúvidas se isso é mesmo verdade

  • É verdade. No começo dos anos 2000, lembro que, quando você colocava um e-mail na web, o spam realmente aumentava, e técnicas de ofuscação de e-mail ajudavam bastante
    Mas, pessoalmente, por volta de 2015 isso deixou de fazer qualquer diferença, e nem mesmo o spam a ser filtrado aumentou
    Hoje, como dá para comprar listas enormes de e-mails vendidas por empresas com listas de usuários ou vazadas de servidores invadidos, vasculhar a web para coletar e-mails é praticamente uma das formas menos eficientes de enviar spam
  • Coloquei endereços de e-mail em texto puro no rodapé de dois sites que criei no ano passado, e nenhum dos dois recebeu um único spam nesse período
    Ambos os sites têm milhares de visitantes e são sites populares, indexados por mecanismos de busca e bots de IA
  • Penso exatamente o mesmo. Em contrapartida, o endereço de e-mail que eu usava na Usenet por volta de 1999–2001 ainda recebe spam constantemente
    Os endereços de e-mail que coloquei em sites nem chegam à pasta de spam
    Algumas listas de e-mail parecem ser criadas adivinhando endereços do Gmail em formato NOME.SOBRENOME ou combinações de 1 a 10 caracteres, como em um ataque de dicionário
    Mesmo assim, o spam que chega para endereços do tipo [e-mail] é muito pouco, cerca de uma mensagem por ano
    No geral, o volume de spam por e-mail também caiu bastante, e o spam que ainda é enviado hoje parece misturar golpistas do 419 e aspirantes a golpistas enganados por terem comprado listas de e-mail de 20 anos atrás
  • A ofuscação de endereços de e-mail parece uma relíquia do passado. Nunca foi algo metodologicamente sólido, mas se espalhou e parece ter sobrevivido como uma espécie de culto à carga
  • Pessoalmente, mesmo que o spam não fique visível, prefiro que meu e-mail não seja coletado, se possível
    Não digo que seja um problema grave de privacidade ou segurança, mas é uma questão de preferência

• Meu domínio é um .com registrado há 24 anos, e o endereço de e-mail fica exposto no topo da primeira tela, em uma tag H3
  O spam nesse endereço não é um problema. São cerca de 15 mensagens por dia incluindo a pasta de lixo eletrônico, e graças ao Purelymail isso é tranquilo
  O verdadeiro problema são e-mails transacionais que não têm relação com transações, e-mails promocionais em formato de newsletter e redes sociais que continuam mandando alertas porque não as uso

  • 15 spams por dia me parece bastante. Acho que eu teria bloqueado o endereço com menos do que isso
  • O maior problema são as “redes sociais reclamando que você não usa”. O Facebook manda mais e-mails pedindo para eu fazer login do que praticamente todo o resto do spam
    Faz uns 7 anos que não uso a conta; a essa altura eles já deveriam ter percebido
  • Tenho alguns domínios antigos registrados no fim dos anos 90, e em alguns deles meu e-mail ainda aparece em links mailto
    Em alguns quase não há spam; em outros chegam dezenas por dia. O SpamAssassin faz um ótimo trabalho classificando spam

• Ao contrário da afirmação de que “mesmo que o visitante desative o JavaScript, o endereço de e-mail exibido na página continua utilizável”, a configuração padrão do NoScript no Firefox não renderiza a tag e a substitui por um placeholder, então essa técnica não funciona nesse caso
  https://imgur.com/2tCAgAf

  • O uBlock Origin também consegue bloquear JavaScript. Há um botão prático no menu da extensão
  • Isso é outro assunto, então não entendo bem por que você está trazendo esse ponto
  • No Chromium é igual

• Não há motivo para essa técnica em si não poder ser acessível, mas o exemplo do artigo é realmente ruim
  O artigo usa “Email us!” como rótulo do svg e do elemento a, o que faz o endereço de e-mail real ficar oculto para leitores de tela
  Usar rótulos aria desse jeito é uma prática muito ruim. A menos que haja um motivo muito especial, usuários de leitores de tela devem ter a mesma experiência que os demais; e, se você acha que o motivo é bom o bastante, na maioria das vezes provavelmente está errado
  O jeito correto é colocar o endereço de e-mail real no rótulo

  • O ponto central dessa abordagem não é justamente não colocar o endereço de e-mail no documento em um formato legível por máquina?
  • Isso também pode afetar softwares de ditado por voz, como o Dragon
    Se o usuário disser “Click [e-mail]”, o navegador expõe o texto do link como “Email us”, então talvez o link não seja ativado
    Dito isso, não sei se o Dragon consegue ativar links dentro de SVG

• Eu faço assim: [e-mail]
  Ainda recebo “spam”, mas são propostas B2B exatamente alinhadas ao tema do site, então parecem ter sido coletadas manualmente por uma pessoa

  • Se o scraper usar um navegador headless, acho que consegue contornar esse método
    Mas rodar um navegador headless para coletar e-mails tem um custo relativamente alto, então esse spam talvez nem tenha vindo do site

• Como outros já disseram, “proteger” e-mails não só é inútil como pode ser prejudicial na prática
  Há muitos sites em que quase todo o conteúdo aparece bem sem JavaScript, mas strings como “1920x1080@60Hz” acabam sendo exibidas literalmente como “[email protected]”

  • Tem algum exemplo que dê para ver agora? Isso é tão absurdo que nunca vi acontecer

• Fico pensando se isso tem mesmo alguma utilidade. É um experimento interessante, mas, se o objetivo é evitar spammers, é uma perda total de tempo
  É como publicar informações para o mundo inteiro e ainda esperar, de alguma forma, que só as “pessoas boas” tenham acesso
  A menos que você troque de endereço de e-mail pelo menos todo mês, basta alguém repassar seu contato para outra pessoa, colocá-lo em um banco de dados/CRM, ou um único serviço ser comprometido, para que esse endereço entre em uma lista e acabe se espalhando para spammers no mundo todo
  Se você usa esse e-mail de forma contínua, a probabilidade de isso acontecer é praticamente próxima de 100%
  Se esconder e-mails de scrapers realmente funcionasse, spam não existiria. Nunca publiquei meu contato pessoal em lugar nenhum e mesmo assim recebo dezenas de spams por semana, mas todos são filtrados como spam, então não é um grande problema

• Um amigo meu é realmente muito bom e está criando praticamente imagens responsivas usando SVG com JavaScript
  Elas se adaptam programaticamente ao tamanho, o que é bem interessante
  O simples fato de ser possível colocar JavaScript dentro de SVG ainda parece ao mesmo tempo subutilizado e um pouco perigoso

  • SVG já não é responsivo por padrão? Não entendo bem no que o JavaScript ajuda dentro de um SVG
  • Muito interessante. Se esse seu amigo tiver um GitHub ou site mostrando esse trabalho, você poderia mandar o link?
    Sou engenheiro de backend, então tecnicamente isso fica bem longe da minha área, mas parece muito legal
  • Isso já é conhecido há bastante tempo na comunidade de segurança

• Desisti desse tipo de abordagem. Hoje os filtros de spam são bons o suficiente, e expor um endereço de e-mail sem ofuscação não parece aumentar o spam
  Outras fontes de spam são outra história, como empresas ruins que têm meu e-mail por motivos legítimos e parecem vendê-lo a terceiros
  Em geral, recebo menos de 1 spam por dia na caixa de entrada, e isso é aceitável
  Claro que isso pode variar conforme o provedor de e-mail e o filtro de spam, então cada caso é diferente, mas para mim não foi um problema

• O e-mail ainda está em texto puro dentro de um documento XML referenciado pelo código-fonte da página

  • Ainda assim, é diferente se você consultar com algo como document.querySelectorAll('a'). Muitas técnicas de scraping usam essa abordagem, então serve como uma primeira linha de defesa
    Dito isso, existem navegadores headless para scraping; se eles fizerem um fetch da URL atual a partir da própria página, receberem o texto puro e aplicarem uma regex para encontrar e-mails, conseguirão obter o endereço. Admito que é uma abordagem bem estranha
    [0]: fetch('./').then((res) => res.text()).then((text) => console.log(text))
  • A ideia é que bots de spam não analisariam o SVG para encontrar endereços de e-mail e olhariam apenas o HTML da página
    Mas não sei bem o quanto isso é eficaz de verdade no ambiente moderno de proteção contra spam
  • Parece algo inútil apresentado como se fosse inteligente