J’emprunte un instant la plume de 20cent (merci, 20cent) afin de vous faire part d’un sujet qui me travaille depuis quelque temps : la protection des adresses emails publiées dans le rédactionnel de nos sites.
Attention, je ne parlerai pas ici des formulaires d’envoi d’email protégés par les CAPTCHA et autres techniques plus ou moins fiables, mais bien des adresses emails présentes textuellement dans le corps de nos sites.
Faire ça bien
Mon postulat de départ :
- je ne pense pas que mettre les adresses en dur soit forcément très malin, mais des fois, en tant que petite main du web, on n’a pas le choix ;
- je veux respecter au maximum l’accessibilité, c’est à dire que mon adresse email soit lisible par monsieur tout le monde (ça exclut déjà pas mal de bidouilles) ;
- je n’ai pas du tout envie d’utiliser la technique du remplacement de l’adresse texte par une image (façon Facebook), que je trouve disgracieuse et pénible à l’usage ;
- je n’exclue évidemment pas de compléter les techniques de protection front par d’autres méthodes, comme par exemple les filtres anti-spams des boîtes email.
Or donc
Habituellement, ma technique de protection des emails est relativement basique, voire simpliste. Dans mon corps de page, j’échappe manuellement les « @ » et « . » de mes adresses et je ne mets aucun lien « mailto » en dur :
info[AT]mon-site[DOT]com
Ensuite via JavaScript, je transforme ma source pour en faire ça :
<a href="mailto:info@mon-site.com">info@mon-site.com</a>
Je vous sens déjà muets d’admiration.
Les avantages :
- ça reste lisible par un humain sans JavaScript ;
- c’est très confortable à l’usage pour l’humain muni de JavaScript.
Cela dit, les spambots ne sont peut-être pas aussi bêtes que je l’espère…
Une autre piste
Nouvelle idée donc, utiliser l’attribut dir qui permet de définir en HTML le sens de lecture d’un conteneur. En écrivant l’adresse à l’envers et en ajoutant la balise bdo munie de l’attribut dir à la valeur rtl (right to left), on obtient le bon texte à l’écran avec son inverse dans le code source.
Par exemple :
<p>moc[TOD]etis-nom[TA]ofni</p>
apparaîtra comme ça dans votre navigateur :
info[AT]mon-site[DOT]com
Il ne reste plus qu’à compléter via Javascript l’écriture du « mailto » (etc.) de ma technique initiale, histoire de brouiller un peu plus les pistes pour les spambots.
Les avantages :
- les mêmes que ci-dessus en complexifiant encore l’affaire ;
- sans CSS ça reste parfaitement lisible puisque c’est HTML qui gère la mise en forme « à l’endroit » de l’adresse pour la rendre compréhensible ;
- donc a priori c’est plutôt accessible.
Hélas ! Les inconvénients :
- j’ai tenté l’expérience sous Lynx (navigateur en mode texte pour ceux qui vivent sous terre depuis 1995), et l’attribut
dirn’est pas actif… ce qui me laisse assez pessimiste sur l’accessibilité de la chose ; - un copier-coller sous Firefox restituera le texte à l’envers… encore un point faible ;
- sémantiquement, c’est une utilisation a priori (?) détournée de l’attribut
dir.
Ce serait peut-être pas mal de tester avec Jaws (hélas, je ne l’ai pas sous la main).
Bref, je suis quand même assez mitigé sur ce qui ressemblait à une belle idée.
Seriez-vous trop couard pour prendre mon gant ?
Voilà, j’ai fini. Si vous avez des compléments et des critiques à apporter, ou si vous souhaitez partager vos propres techniques, je suis tout ouï (c’est le but initial de ce sujet d’ailleurs).
Cordialement, STPo
15 commentaires ↓
mais quelle plume, mais quelle verve, mais quelle vivacité, je suis tout émoustillé rien qu’a lire cette éloquente « lis tes ratures » 😀
Nan sans blagues, je suis ok sur le fond la forme et tout le reste, ma seule interrogation est de savoir si les (love ?) bots ont pas déjà pris les string stamps de type [ZIZI] ou {CACA} en compte pour les appliquer a des données sensibles. (ce qui n’est manifestement pas le cas dans les deux exemples précédant… ..quoi que avec le web actuel…).
voilivoilou, ceci dit je dois dire que en matière de js je suis particulièrement friand de l’utilisation de stamps strings pour gérer depuis le serveur des appels de scripts front.. enfin, ça mériterais peut-être un article, parce que je pense que je suis un tantinet vague et en plus c’est totalement hors, je m’égare mais que c’est bon.
bisous, (je me permet, on es un peu en famille ici 😉
Etienne
Les robots sont encore plus bêtes que ce que tu espères en fait. Si je crois ceux qui ont fait des vrais tests sur le sujets, l’essentiel ne savent même pas décoder les entités HTML. En gros il suffit de mettre l’arobase et le point sous forme &xxx; pour que l’essentiel des robots soient perdus.
On peut complexifier (par exemple en codant aussi l’URL avec %xx) mais en général ça se ressent au moins sur le copier/coller ou sur la capacité des gens de cliquer sur le lien mailto:.
Pour les [at] ou techniques équivalents, dans toutes les études que j’ai vu, les robots ne les relisent pas. Après si c’est un gros site qui publie plein d’email quelqu’un fera peut être un robot exprès pour, mais ça tu ne pourras jamais l’empêcher, quelle que soit la technique.
Personnellement la première technique (tout texte puis remplacement en js) est aussi ce que j’utilise et qui me parait le plus adapté (maintenant je reçois énormément de spam et je n’ai pas cherché à savoir si certains mails venaient ou pas de ma page de contact)
Je ne suis pas sur que le
info[AT]mon-site[DOT]comsoit compris par monsieur tout le monde moi.Du coup je préfère de loin laisser faire les antispams côté serveur et limiter la casse avec la technique d’encodage qu’Éric évoque plus haut.
Quand à ton idée d’utiliser
bdo, elle semble intéressante mais en effet peu accessible… dommage.Pour info : http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/
Je suis déçu des robots, ça veut dire que cette niche mafieuse pourrait être bien plus lucrative qu’on ne l’imagine ?
Moi, j’applique rien et je laisse les serveurs se démerder. Mais si j’étais une bête de technique, ça se saurait, hein.
Belle plume, mais bon, je préfèrerais voir une nouvelle planche sur ton blog.
Feignasse.
(part en sifflotant)
Merci pour ces retours fournis.
@Eric : Surprenant ton retour d’expérience, presque trop beau ! Dommage que les 3 techniques les plus performantes dans le lien que tu proposes soient également les moins accessibles.
@20cent : Tu peux glisser dans le code de ta page aussi un texte genre « remplacez [AT] par @ … » et le virer via JS… comme ça même ta grand-mère devrait comprendre. Non ?
@Cédric : Venant de la part de « la Limace des updates » (c’est le nom qu’on t’a trouvé au 4e), tu penses bien que cette pique ne m’atteint pas…
@tous : bon, à… vendredi ? =D
@STPo: oui, les trois premières sont à éviter. Mais dans le liens le [AT] [DOT] (ou [chez] [point] si vous voulez) n’a reçu que 7 mails en 1 an et demi là où un email en dur a pris 1800 mails. AMHA c’est suffisant pour se permettre d’utiliser ça. Cumulé à un javascript qui réécrit l’adresse pour que les gens comme Vincent n’y voient que du feu … ça me parait bien
@Eric : Haha, vendu, je continuerai à faire comme ça donc (sauf pour les sites que je ferai avec 20cent) !
Salut,
vu ce matin en vitesse : http://www.alexandreval.info/cv/ne-plus-etre-spamme-sur-son-site-blog/
Une autre astuce que j’ai reprise de Fabrice Bonny : http://blog.creaone.fr/post/2007/09/17/Contourner-le-spam-ou-pourriel
Ami,
Entends-tu le cri de la foule qui réclame un nouvel article sur ce blog ?
Paix et amour, mais quand même.
Salut,
la technique donnée par Adrien semble fonctionner plutôt bien ; elle a d’ailleurs été intégrée par défaut à Dotclear 2… et ça a l’air de fonctionner plutôt bien
Oui certes, mais ça ne concerne en rien notre problème… qui était la présence d’adresse email en dur dans le corps du document (et pas le spam via formulaires). Cela dit, la technique est intéressante !
Oups… en effet. Désolé, en lisant les commentaires j’ai dérivé
Laisser un commentaire