Pour information, l’équipe Chrome n’a toujours rien fait.
La situation reste problématique sur Chrome ; nous pouvons facilement la corriger en remplaçant notre piège anti-spam par une sorte de preuve de travail.
Clôture pour encore deux mois.
L’équipe Chrome semble déterminée à résoudre ce problème, mais elle a besoin de journaux ici :
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
Je vais voir si je peux en rassembler certains demain. Si quelqu’un arrive avant moi, vous êtes mon héros, signalez ce message.
MODIFICATION … je leur ai envoyé les journaux.
@codinghorror cela tourne en rond chez Google. Ils affirment que ce comportement est intentionnel et qu’ils n’ont aucun moyen de détecter avec précision si un textarea est visible ou non.
La réponse générale ici est : « Il est trivial pour un bot de contourner cela, alors quel est l’intérêt ? ». Je n’ai pas vraiment de réponse à cela ; je suis en partie d’accord avec eux. Le piège à miel est un peu absurde, et je pourrais tout aussi facilement le remplacer par autre chose pour m’assurer qu’au moins un utilisateur exécute JavaScript lors de l’inscription.
J’ai déjà passé tellement de temps là-dessus et j’ai l’impression de me battre contre des moulins à vent. Je veux simplement mettre en place une correction et passer à autre chose.
Ok, mais je veux que ce soit une preuve de travail assez complexe. Existe-t-il du code existant que nous pouvons utiliser ?
Oui, je peux assembler quelque chose, ce sera certainement mieux que notre système actuel. Notre système actuel de « preuve de travail » consiste à « inverser une chaîne ».
J’ai passé bien trop de temps à réfléchir à ce problème, alors j’ai décidé qu’il était temps de le clore :
Selon ce commit, le problème soulevé par l’OP est « résolu » :
La correction est assez complexe et implique deux éléments dont je suis heureux d’avoir pu m’occuper.
-
J’ai considérablement renforcé la logique du piège à abeilles (honeypot) et du défi.
-
J’ai ajouté une solution de contournement côté client uniquement pour un bug de Chrome lié à l’autocomplétion. Je suis à l’aise avec cette approche car elle ne modifie en rien le protocole côté serveur.
Auparavant, nous réutilisions notre chaîne aléatoire de piège à abeilles et de défi pour toutes les inscriptions de comptes sur le site, ce qui rendait la création de comptes par script extrêmement simple : il suffisait de coder en dur une valeur une seule fois.
La nouvelle implémentation attribue à chaque utilisateur une chaîne unique de validation, liée à son stockage de cookies (dans notre magasin de sessions sécurisé). Cette chaîne expire après une heure.
Cela signifie que, lors de la création de scripts, vous êtes contraint de faire régulièrement des appels pour obtenir de nouveaux défis et pièges à abeilles entre les requêtes, et vous ne pouvez plus simplement créer des comptes en masse sans encombre.
La solution de contournement mentionnée en 2 consiste simplement à déplacer un champ INPUT qui prête à confusion pour Chrome et à le remplacer par un INPUT de type texte qui ne pose pas ce problème.
Dans l’ensemble, je ne pense pas que le point (2) rende plus facile pour un bot « générique » codé pour s’inscrire sur des sites inconnus. Pour commencer, le bot devrait utiliser le pilote Web de Chrome, analyser tout notre code Ember, puis suivre un flux très spécifique. Cette barrière est très faible et n’a rien à voir avec les nouveaux défis rotatifs par utilisateur.
Quant à l’ajout d’une preuve de travail, je préférerais attendre un peu, non pas parce que c’est particulièrement difficile à mettre en œuvre, mais plutôt parce que je ne veux pas devoir rechercher l’algorithme SHA1 le plus rapide disponible pour ensuite l’envoyer au client à la demande.
Je laisse cette discussion ouverte un moment afin que les personnes puissent confirmer que ma correction résout bien le problème. Je la fermerai dans une semaine.