Si la diminution du rapport signal / bruit a été le premier argument avancé par les opposants du web 2.0, l’explosion du spam a été une des conséquences perverses de la démocratisation du web participatif. Là où le spam par courrier électronique vise à une transformation immédiate d’une parte extrêmement marginale des messages envoyés pour un coût nul par l’utilisation, entre autres, de machines zombies, le spam de sites web cherche à influer sur les résultats de Google pour des termes précis, la transformation se faisant alors en deux temps, mais avec un taux de réussite bien supérieur, la recherche du produit étant initiée par l’utilisateur et non subie. L’élaboration de protocoles de transmission des données plus ou moins normalisés (trackbacks) et la prolifération de systèmes de publication normalisés, blogs et forums, ont permis de véritablement automatiser la diffusion du spam sur la toile. Si des solutions sont rapidement apparues, elles ont cependant toujours un temps de retard, la lutte contre les nouvelles techniques de spam ne pouvant être proactive. Certaines exigent une intervention de l’utilisateur, d’autres sont entièrement automatisées, mais dans tous les cas elles présentent des avantages et des inconvénients qu’il faut absolument prendre en compte avant de choisir celle qui protégera votre future application web, aussi bien du point de vue infrastructure que du point de vue de l’utilisateur.

Antispams entièrement automatiques

Les antispams automatiques se basent principalement sur de l’analyse de motifs, ou pattern matching. Les messages entrants sont analysés en fonction d’un ensemble de règles prédéfinies : auteur, émetteur, destinataire, contenu… Les nouvelles règles sont mises à jour soit périodiquement, soit à chaque vérification auprès d’un serveur temps réel RBL (Real time Blacklist, liste noire en temps réel). Le message entrant reçoit une note pour chaque critère examiné. En fonction de la note globale obtenue, l’antispam accepte ou rejette le message. Concrètement, cela se traduit par la publication ou non du message, ce dernier étant systématiquement conservé quel que soit le verdict.

Le principal avantage de ce système d’antispam est sa capacité d’apprentissage. Pour chaque message analysé, l’administrateur de l’application est invité à confirmer ou infirmer la décision du programme. Chacune de ces actions permet à l’antispam d’affiner ses critères de choix en fonction des confirmations humaines.

Il existe en revanche un problème parfois important de faux positifs, c’est à dire de messages considérés comme étant du spam alors qu’ils n’en sont pas. Ces faux positifs sont le principal inconvénient de ce système de lutte contre le spam car ils impliquent une veille très régulière de l’administrateur de l’application. L’utilisation d’un serveur RBL peut également poser des problèmes de timeout lorsque ce dernier est hors-service, dont le principal effet, et non le moindre, est de faire purement et simplement planter votre application à la figure du client.

Ce genre d’antispam peut être hébergé localement, mais il existe également des services distants et gratuits permettant de se passer d’une infrastructure de lutte contre le spam. Là aussi, les deux solutions présentent des avantages et des inconvénients.

Services hébergés

L’utilisation d’un service hébergé, comme Akismet d’Automattic est d’une extrême simplicité pour l’administrateur de l’application. L’application web communique avec le service de lutte contre le spam via une API ouverte, la majorité des blogware disposant d’un greffon dédié. L’administrateur a simplement à indiquer la clé d’utilisation qui lui a été fournie par le service, le greffon s’occupant de communiquer avec ce dernier.

Cette simplicité a cependant un prix. Tous les contenus à filtrer sont envoyés à une société distante pour analyse, ces données pouvant ensuite utilisées à des fins marketing. Vous n’avez donc aucun contrôle sur le sort des données transmises. De plus, en cas de panne du service, c’est tout votre dispositif de lutte contre le spam qui se retrouve paralysé.

Services intégrés

L’utilisation d’un service local devrait satisfaire les plus paranoïaques d’entre vous en éliminant les principaux défauts des services hébergés : pas de transmission de données à un organisme tiers, pas de risques de paralysie en cas de coupure du prestataire, et un contrôle total de la solution. Un exemple bien connu est celui de Spam Karma, pour Wordpress.

En contrepartie, les services intégrés présentent des problèmes parfois graves de performances qu’il peut être confortable de déléguer à un tiers, surtout si votre application n’a pas été prévue pour être redimensionnée à mesure de la montée en charge. Les soucis de performances viennent le plus souvent d’un défaut d’architecture. Le spam est traité au niveau de l’application web, dans un langage interprété (PHP, ASP, Perl…), or, il devrait être traité à plus bas niveau, au niveau du serveur web, avant d’être retransmis à l’application si besoin, par exemple sur le modèle de mod_security pour Apache, mais sans les problèmes de performances de ce dernier.

Antispams mettant en jeu une intervention de l’utilisateur

Une autre solution beaucoup moins coûteuse en termes de ressources est l’installation de gardes-fous nécessitant une action de validation de la part de l’utilisateur. J’en ai retenu deux : le mail d’activation et le captcha.

L’e-mail d’activation

Utilisé sur la très grande majorité des services nécessitant une inscription, cette méthode exige de l’utilisateur qu’il clique sur un lien envoyé par e-mail afin de valider son inscription. Cette démarche remplit un triple rôle :

  1. Elle vérifie que l’adresse e-mail fournie à l’inscription existe bien.
  2. Elle permet de s’assurer que l’inscription ne se fait pas au nom d’un tiers.
  3. Enfin, elle permet de nettoyer la base des utilisateurs qui n’auraient pas activé leur compte au bout d’un certain laps de temps.

Corollaire, en exigeant une démarche de la part de l’utilisateur, on s’assure dans la très grande majorité des cas qu’il ne s’agit pas d’un robot.

Cette méthode présente toutefois deux inconvénients majeurs. Particulièrement lourde pour l’utilisateur, elle n’est véritablement utilisable qu’au moment de l’inscription ou d’une opération particulièrement délicate (paiement des impôts, par exemple). Enfin, il est très facile de la contourner avec un script de moins de 10 lignes pour automatiser les inscriptions de masse à un service donné. Et en cas de contournement de cette méthode, un antispam d’un autre genre devient nécessaire afin de contrôler les contenus publiés, particulièrement dans les cas où ces derniers seraient publics et indexés.

Le captcha

Le captcha est un test visant à démontrer que l’utilisateur est un être humain, en utilisant sa capacité d’analyse d’image ou de son. Dans la très grande majorité des cas, un captcha requerra que l’utilisateur tape les lettres et les chiffres visibles sur une image distordue qui apparait à l’écran. Dans d’autres cas, on préférera afficher une image contenant une question mathématique à résoudre.

Je ne dirai jamais assez tout le mal que je pense des captcha sur tous les plans, mais la fréquence de leur utilisation m’oblige à les mentionner.

Côté accessibilité, d’abord : ne comptez pas faire analyser un captcha graphique à une personne visuellement déficiente, puisque vous ne pouvez pas mettre le résultat dans le champs alt de l’image. Certains sites utilisent une alternative sonore, mais celle-ci est à peine mieux : il y a des gens sourds et aveugles, ça arrive.

Coté efficacité, il faut savoir qu’une librairie développée par Samuel Hocevar permet depuis longtemps aux robots d’analyser un grand nombre de captchas graphiques existants. La résolution d’un captcha graphique ne peut donc plus être une preuve de l’humanité de l’utilisateur. Le code n’est certes pas publique, mais cela implique que quelqu’un d’autre moins bien intentionné ait pu le faire (attention, Samuel Hocevar est loin d’être n’importe qui, et ce travail n’est pas à la portée de tout le monde). La remarque est également valable pour les captchas posant une question mathématique inscrite sur un support non graphique.

Question utilisabilité, c’est assez catastrophique. D’abord parce que le captcha ajoute à votre formulaire un champ qui n’a rien à voir avec ce que vous venez de remplir. Ensuite parce que vous partez du principe que votre visiteur est un robot jusqu’à ce qu’il vous prouve le contraire, ce qui est particulièrement insultant. Enfin parce que vos utilisateurs ne devraient pas avoir à subir la gestion de vos problématiques de spam.

Conclusion

Dans la mesure du possible, optez pour une solution totalement transparente pour vos visiteurs, les problèmes de gestion d’une application web sont du ressort de l’administrateur, pas des utilisateurs, même si le problème est réel. Et pour les contenus vraiment sensibles, vous pouvez toujours vous rabattre sur la modération à priori des commentaires, qui assure un taux de faux positifs proche de zéro, mais reste particulièrement frustrant pour l’utilisateur.

tombe ouverte au père Lachaise

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: