Para tu información @codinghorror, el equipo de Chrome sigue sin hacer nada.
La situación sigue rota para Chrome; podemos solucionarlo trivialmente reemplazando nuestra trampa antispam (honeypot) con algún tipo de prueba de trabajo.
Cerrado por 2 meses más.
El equipo de Chrome parece estar muy interesado en solucionar esto, pero necesitan registros aquí:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
Veré si puedo recopilar algunos mañana. Si alguien me precede en esto, eres mi héroe, marca este mensaje.
EDIT … les envié los registros.
@codinghorror esto está dando vueltas en Google. Dicen que el comportamiento es intencional y que no tienen forma de detectar con precisión si un textarea es visible o no.
La respuesta general aquí es: “Es trivial para un bot eludir esto, así que ¿cuál es el punto?”. No tengo realmente una respuesta; en cierto modo estoy de acuerdo con ellos. La trampa es un poco absurda y puedo reemplazarla bastante fácilmente con otra cosa para asegurarme de que el usuario, al menos, esté ejecutando JavaScript al registrarse.
Ya he dedicado tanto tiempo a esto que siento que estoy luchando contra molinos de viento. Solo quiero implementar una solución y seguir adelante.
Vale, pero quiero que sea una prueba de trabajo bastante compleja. ¿Existe algún código que podamos utilizar?
Sí, puedo armar algo, sin duda será mejor que nuestro sistema actual. Nuestro sistema actual de «prueba de trabajo» es «invertir una cadena».
He pasado demasiado tiempo pensando en este problema, así que decidí que era hora de dejarlo atrás:
Según este commit, el problema del OP aquí está “solucionado”:
La solución es un poco complicada e involucró dos partes de las que me alegra haberme ocupado.
Ajusté mucho la lógica del honeypot y del desafío.
Añadí una solución alternativa solo del lado del cliente para un error de Chrome en la autocompletación. Me siento cómodo con esto porque no cambia en nada el protocolo del lado del servidor.
Antes reutilizábamos nuestra cadena aleatoria de honeypot y desafío para todos los registros de cuentas en el sitio, lo que hacía que scriptear la creación de cuentas fuera muy trivial, ya que solo tenías que codificar un valor una vez.
La nueva implementación otorga a cada usuario una cadena única para validar, la cual está vinculada a tu almacenamiento de cookies (en nuestro almacenamiento seguro de sesión). Esta cadena expira después de una hora.
Esto significa que al scriptear este tipo de cosas, estás obligado a realizar llamadas regularmente para obtener nuevos desafíos y honeypots entre solicitudes, y no puedes simplemente crear cuentas sin control.
La solución alternativa mencionada en el punto 2 consiste simplemente en reemplazar un INPUT que confunde a Chrome por otro INPUT de tipo texto que no lo confunde.
En general, no creo que el punto (2) haga que sea más fácil para un bot “genéricamente” programado registrar cuentas en sitios desconocidos. Para empezar, el bot tendría que usar Chrome WebDriver, analizar todo nuestro Ember y luego seguir un flujo muy específico. Esta barrera es muy baja y nada comparada con los nuevos desafíos rotativos por usuario.
En cuanto a agregar una prueba de trabajo, me gustaría esperar un poco, no porque sea particularmente difícil de implementar, sino más bien porque no quiero tener que buscar el algoritmo SHA1 más rápido disponible y luego enviarlo al cliente bajo demanda.
Dejaré esto abierto por un tiempo para que la gente pueda confirmar que mi solución resuelve el problema. Lo cerraré en una semana.