Protéger une adresse e-mail via SVG, à la place de JavaScript

• Pour masquer une adresse e-mail publique aux spambots tout en permettant aux visiteurs de vous contacter directement, cette méthode place le texte de l’e-mail et le lien mailto: à l’intérieur d’un SVG
• Une protection fondée sur JavaScript peut être plus sophistiquée, mais cela impose que la fonction de contact elle-même ait une dépendance à JS
• Cette approche insère un document SVG externe dans le HTML via et place le vrai lien non pas dans le HTML, mais dans un élément à l’intérieur du SVG
• Le SVG masque son contenu comme une image, tout en utilisant un élément `` qui permet au visiteur de copier l’adresse e-mail
• Ce n’est pas une solution contre les spambots les plus sophistiqués, mais elle est utile pour réduire le risque d’exposition aux scripts simples de collecte d’e-mails

---

Masquer une adresse e-mail avec SVG

• Une adresse e-mail publique est facilement exposée aux spambots de collecte d’e-mails, d’où la nécessité d’une protection
• Les techniques de protection classiques combinent HTML, CSS et JavaScript, mais l’usage de JavaScript lie la fonction de contact à l’environnement d’exécution indispensable de la page
• L’approche SVG gère l’affichage de l’e-mail et le fonctionnement du lien sans utiliser JavaScript
• Même si JavaScript est désactivé, le visiteur peut utiliser l’adresse e-mail affichée sur la page, tandis qu’elle est moins directement exposée aux spambots qu’un texte HTML ordinaire
• Comme les autres techniques de protection côté front-end, elle ne protège pas complètement une adresse e-mail publique contre des spambots tenaces et sophistiqués
• Démo en direct : SVG-based Email Protection

Implémentation HTML et SVG

• Le document HTML insère un fichier SVG externe via ``

• Le même document graphique SVG peut être inséré une ou plusieurs fois dans le HTML
• L’exemple HTML applique à la classe .svg-email-protection les styles width: 180px, height: 24px, vertical-align: middle, puis charge le fichier SVG dans le corps du document via ``
• Le fichier SVG est un document `` avec viewBox="0 0 200 24", qui contient le texte de l’e-mail et le lien mailto:[e-mail]
  • contient et ``
  • `` affiche [e-mail]
  • Dans les états rect:hover et a:focus, la couleur d’arrière-plan, la couleur du texte, l’épaisseur, le soulignement et l’ombre changent

Accessibilité et ressources de référence

• Le document SVG dans son ensemble utilise aria-labelledby pour pointer vers , et le à l’intérieur du SVG contient un aria-label avec le même appel à l’action
• Lorsque le focus clavier par tabulation atteint l’ancre dans le SVG, et sont mis en évidence ensemble pour indiquer l’état de focus
• Ressources liées :
  • Discussion Hacker News
  • Article CSS Tricks
  • Discussion Stack Overflow

[GN⁺]

Avis sur Hacker News

• J’ai du mal à y croire

  • Si. Au début des années 2000, mettre son e-mail sur le Web augmentait vraiment le spam, et je me souviens que les techniques d’obfuscation d’adresses e-mail aidaient pas mal.
    Mais personnellement, à partir d’environ 2015, ça n’a plus fait aucune différence, et même le spam à filtrer n’a pas augmenté.
    Aujourd’hui, des entreprises peuvent vendre des listes d’utilisateurs, ou on peut acheter d’énormes listes d’e-mails issues de serveurs compromis ; parcourir le Web pour collecter des adresses est donc probablement l’une des méthodes les moins efficaces pour spammer.
  • J’ai mis des adresses e-mail en clair dans le pied de page de deux sites que j’ai créés l’an dernier, et aucun des deux n’a reçu le moindre spam depuis.
    Les deux sites ont plusieurs milliers de visiteurs, et ce sont des sites populaires crawlés par les moteurs de recherche et les bots d’IA.
  • Exactement le même avis. À l’inverse, les adresses e-mail que j’utilisais sur Usenet vers 1999-2001 continuent encore aujourd’hui à recevoir du spam régulièrement.
    Les adresses e-mail publiées sur des sites Web n’arrivent même pas dans le dossier spam.
    Certaines listes de diffusion semblent générer des adresses Gmail en les devinant façon attaque par dictionnaire, avec des formats du type FIRSTNAME.LASTNAME ou des combinaisons de 1 à 10 caractères.
    Même ainsi, le spam envoyé à une adresse [e-mail] est très rare, environ un message par an.
    Globalement, le volume de spam par e-mail a beaucoup diminué, et le spam actuel semble être un mélange d’arnaqueurs 419 et d’apprentis escrocs qui se sont fait avoir en achetant des listes d’e-mails vieilles de 20 ans.
  • L’obfuscation d’adresses e-mail ressemble à un vestige du passé. Ça n’a jamais vraiment reposé sur une méthodologie solide, mais ça s’est répandu et ça semble avoir survécu comme une sorte de culte du cargo.
  • Personnellement, même si le spam n’est pas visible, je préfère que mon e-mail ne soit pas collecté si possible.
    Je ne dis pas que c’est un grave problème de confidentialité ou de sécurité, c’est plutôt une question de préférence.

• Mon domaine est un .com enregistré depuis 24 ans, et l’adresse e-mail est affichée en clair dans une balise H3 tout en haut de la première page.
  Le spam sur cette adresse n’est pas un problème. En comptant le dossier indésirable, j’en reçois environ 15 par jour, et grâce à Purelymail ça va.
  Le vrai problème, ce sont les e-mails transactionnels sans rapport avec de vraies transactions, les e-mails promotionnels façon newsletter, et les réseaux sociaux qui m’envoient sans cesse des notifications parce que je ne les utilise pas.

  • 15 spams par jour, ça me paraît quand même beaucoup. Je pense que j’aurais bloqué l’adresse pour moins que ça.
  • Le plus gros, ce sont les « réseaux sociaux qui se plaignent que je ne les utilise pas ». Les e-mails de Facebook me demandant de me connecter sont presque plus nombreux que tout le reste du spam.
    Ça fait environ 7 ans que je n’utilise plus le compte, ils devraient commencer à s’en rendre compte.
  • J’ai quelques vieux domaines enregistrés à la fin des années 90, et sur certains mon e-mail est encore présent en mailto.
    Certains reçoivent très peu de spam, d’autres plusieurs dizaines par jour. SpamAssassin fait un très bon travail de classement du spam.

• Contrairement à l’affirmation selon laquelle « même si le visiteur désactive JavaScript, l’adresse e-mail affichée sur la page reste utilisable », la configuration par défaut de NoScript dans Firefox ne rend pas la balise et la remplace par un espace réservé ; cette technique ne fonctionne donc pas dans ce cas.
  https://imgur.com/2tCAgAf

  • uBlock Origin peut aussi bloquer JavaScript. Il y a un bouton pratique dans le menu de l’extension.
  • C’est un autre sujet, je ne vois donc pas bien pourquoi tu soulèves ce point.
  • C’est pareil dans Chromium.

• Il n’y a pas de raison que cette technique soit intrinsèquement incompatible avec l’accessibilité, mais l’exemple de l’article est vraiment mauvais.
  L’article donne aux éléments svg et a le libellé « Email us! », ce qui masque l’adresse e-mail réelle aux lecteurs d’écran.
  Utiliser les libellés aria de cette façon est une très mauvaise pratique. Sauf raison très particulière, les utilisateurs de lecteurs d’écran devraient avoir la même expérience que tout le monde, et si vous pensez que la raison est suffisante, il y a de fortes chances que vous vous trompiez.
  La bonne approche consiste à mettre l’adresse e-mail réelle dans le libellé.

  • Le cœur de cette démarche n’est-il pas justement de ne pas mettre l’adresse e-mail dans le document sous une forme lisible par machine ?
  • Cela peut aussi affecter les logiciels de dictée vocale comme Dragon.
    Si l’utilisateur dit « Click [e-mail] », le navigateur expose le texte du lien comme « Email us », donc le lien pourrait ne pas s’activer.
    Cela dit, je ne sais pas si Dragon peut activer un lien à l’intérieur d’un SVG.

• Moi je fais comme ça : [e-mail]
  Je reçois quand même du « spam », mais il s’agit de propositions B2B très précisément adaptées au sujet du site, donc on dirait que quelqu’un les a collectées manuellement.

  • Si un scraper utilise un navigateur headless, il pourrait probablement contourner cette méthode.
    Cela dit, faire tourner un navigateur headless pour collecter des e-mails coûte relativement cher, donc ce spam ne vient peut-être pas du site.

• Comme d’autres l’ont déjà dit, « protéger » les e-mails est non seulement inutile, mais peut aussi être réellement nuisible.
  Même sans JavaScript, la plupart du contenu se lit bien, mais il y a pas mal de sites où des chaînes comme « 1920x1080@60Hz » s’affichent littéralement sous la forme « [email protected] ».

  • Tu as un exemple visible tout de suite ? C’est tellement absurde que je n’ai jamais vu ça.

• Je me demande si ce genre de chose a vraiment un intérêt. C’est une expérience amusante, mais si le but est d’éviter les spammeurs, c’est une perte de temps totale.
  C’est comme publier des informations dans le monde entier tout en espérant, somehow, qu’elles ne soient accessibles qu’aux « bonnes personnes ».
  À moins de changer d’adresse e-mail au moins tous les mois, il suffit que quelqu’un transmette le contact à quelqu’un d’autre, l’ajoute à une base de données ou à un CRM, ou qu’un service soit compromis pour que cette adresse se retrouve sur une liste, puis finisse par circuler chez les spammeurs du monde entier.
  Si vous utilisez régulièrement cet e-mail, la probabilité que cela arrive est pratiquement proche de 100 %.
  Si cacher les adresses e-mail aux scrapers était vraiment efficace, le spam n’existerait pas. Je n’ai jamais publié mes coordonnées personnelles nulle part et je reçois pourtant des dizaines de spams par semaine, mais tout est filtré comme spam donc ce n’est pas grave.

• Un ami est vraiment très fort, il utilise des SVG avec JavaScript pour créer en quelque sorte des images responsives.
  Elles s’adaptent programmatiquement à la taille, c’est assez intéressant.
  Le simple fait qu’on puisse mettre du JavaScript dans un SVG me semble à la fois encore sous-exploité et un peu dangereux.

  • Les SVG ne sont-ils pas responsives par nature ? Je ne vois pas très bien ce que JavaScript apporte à l’intérieur d’un SVG.
  • C’est super intéressant. Si ton ami a un GitHub ou un site qui montre ce travail, tu peux partager le lien ?
    Je suis ingénieur backend, donc techniquement c’est assez loin de mon domaine, mais ça a l’air vraiment cool.
  • C’est connu depuis assez longtemps dans la communauté sécurité.

• J’ai renoncé à ce genre de méthodes. Les filtres antispam sont assez bons aujourd’hui, et publier une adresse e-mail sans obfuscation ne semble pas augmenter le spam.
  Les autres sources de spam, par exemple les mauvaises entreprises qui ont mon e-mail pour des raisons légitimes et semblent le vendre à des tiers, c’est un autre sujet.
  En général, je reçois moins d’un spam par jour dans ma boîte de réception, et ça me va.
  Bien sûr, cela peut varier selon le fournisseur d’e-mail et le filtre antispam, donc chacun aura une expérience différente, mais pour moi ce n’est pas un problème.

• L’e-mail est toujours présent en clair dans un document XML référencé depuis le code source de la page.

  • Certes, mais si on interroge avec quelque chose comme document.querySelectorAll('a'), c’est différent. Beaucoup de techniques de scraping utilisent cette approche, donc comme première ligne de défense, ce n’est pas mal.
    Cela dit, avec un navigateur headless dédié au scraping, on peut simplement faire un fetch de l’URL courante depuis la page, récupérer le texte en clair et chercher les adresses e-mail avec une expression régulière. J’admets que c’est une approche assez étrange.
    [0]: fetch('./').then((res) => res.text()).then((text) => console.log(text))
  • L’idée est que les spambots ne vont pas parser jusqu’au SVG pour trouver l’adresse e-mail, et qu’ils ne regardent que le HTML de la page.
    Mais je ne sais pas vraiment à quel point c’est efficace dans un environnement moderne de protection contre le spam.
  • Ça donne l’impression d’emballer quelque chose d’inutile pour le faire passer pour malin.