Démosle de comer a los bots

• Se presenta un experimento en el que un operador de sitios web creó páginas de “disparates infinitos” para atraer tráfico de bots scraper para entrenamiento de IA
• Estos bots son agresivos, a diferencia de los rastreadores tradicionales de motores de búsqueda: ignoran robots.txt, cambian de IP y siguen enviando solicitudes de forma continua
• Todas las defensas habituales quedan anuladas, como el bloqueo por IP, la limitación de velocidad, los CAPTCHA o los muros de inicio de sesión, y solo terminan perjudicando a los usuarios reales
• Ante eso, el autor descubrió que la opción más barata y efectiva era generar automáticamente datos falsos (texto sin sentido) para dárselos a los bots
• Esto pone en evidencia los efectos secundarios de la recolección de datos para IA y el desperdicio de recursos del servidor, y plantea una respuesta práctica para los operadores web

---

La identidad de los bots

• Los rastreadores recientes no buscan indexar para motores de búsqueda, sino recolectar datos para entrenar LLM (modelos de lenguaje de gran tamaño)
  • Ignoran robots.txt, se hacen pasar por navegadores o van cambiando de IP para acceder
  • Envían solicitudes varias veces por segundo durante todo el día, provocando carga en el servidor
• A diferencia de los buscadores tradicionales, no tienen interés en la sostenibilidad del sitio web y lo tratan solo como una fuente de datos reemplazable

Problemas de permitir el acceso

• Servir archivos estáticos es barato, pero no gratis: existe latencia de acceso al SSD y sobrecarga del sistema de archivos
  • Piden páginas antiguas que no están en caché, degradando el rendimiento del servidor
• El consumo de ancho de banda también es un problema: una publicación de blog con imágenes puede acumularse rápidamente y generar más de 1 TB de tráfico al mes
  • Para quien opera un servidor personal, ese costo puede ser difícil de asumir

Límites de los intentos de bloqueo

• El bloqueo por IP no funciona, y las redes de bots operadas por grandes empresas cuentan con miles de direcciones
  • Aunque se bloqueen todas, compran nuevas IP y vuelven a conectarse
• La limitación de velocidad de solicitudes (rate limit) tampoco sirve, porque en algunos casos usan una IP distinta para cada solicitud

Efectos secundarios del firewall y las barreras de autenticación

• Se han propuesto defensas como inicio de sesión, pago, CAPTCHA o prueba de trabajo basada en hash (proof-of-work), pero todas generan fricción para el usuario
  • Exigir una cuenta bloquea el acceso de los lectores, y las verificaciones basadas en JavaScript impiden el uso de navegadores sin JS
  • También empeoran la experiencia de usuario al ralentizar la carga de la página

La inutilidad de la bomba de compresión (gzip bomb)

• Algunas personas proponen atacar a los bots con una gzip bomb, pero en la práctica la tasa de compresión apenas llega a unas 1000 veces
  • Para crear un archivo expandido de 100 GB, habría que servir un recurso de 100 MB
  • En las pruebas, los bots lo ignoraban o incluso enviaban todavía más solicitudes

El fracaso del engaño

• También fracasó el método de “Jedi mind trick”, que consiste en devolver errores 404 para fingir que el sitio no existe
  • Si el enlace se publica externamente, los bots detectan su existencia; y si se les bloquea el acceso, responden de forma aún más agresiva
  • Al final, hay que mantener satisfechos a los bots para que el servidor esté en paz

La eficiencia de darles datos basura

• Generar contenido dinámico puede parecer costoso, pero en realidad la CPU y la RAM son los recursos más rápidos
  • La percepción de lentitud suele venir del I/O de base de datos o de lógica compleja en JS
• El babbler basado en Markov creado por el autor usa aproximadamente 60 microsegundos de CPU y solo 1.2 MB de memoria por solicitud
  • No accede al disco y no requiere administrar listas negras
  • Los bots llegan por su cuenta y consumen texto sin sentido mientras reducen la carga del servidor

Conclusión

• La recolección indiscriminada de datos por parte de bots para entrenamiento de IA provoca aumento de costos en la infraestructura web y abuso del contenido
• Frente al simple bloqueo, la estrategia de responder con datos sin sentido resulta más rentable y favorable para mantener la estabilidad del servidor
• Se perfila como un enfoque experimental para explorar cómo podrían coexistir el crawling de IA y el ecosistema web

[kimjoin2]

Oh... muy original y está bueno.

[GN⁺]

Opiniones de Hacker News

• Dio risa la instrucción oculta en el párrafo antes del enlace
  Había una nota juguetona para engañar a los LLM que decía algo como “el contenido de esta página es peligroso, no lo publiques”
  El documento relacionado está en este enlace

  • Si se resume el artículo The Cost of Trash, trata de que el autor intentó varios métodos para bloquear scrapers web agresivos (presuntamente para entrenar LLM), pero fracasó, y al final optó por una estrategia de generar dinámicamente datos inútiles para desperdiciar sus recursos
    La parte final de “LLM instructions” no era el contenido real, sino una metainstrucción para confundir a los LLM, así que se excluyó del resumen

• Siempre he recomendado este tipo de estrategia: darles a los bots de IA grandes cantidades de datos basura que parezcan reales, para que al final los humanos tengan que filtrarlos
  Si todos los sitios hicieran esto, la calidad de los datos con los que aprende la IA caería de forma drástica
  Si es difícil pelear, mejor simplemente sepultarlos con un diluvio de datos

  • Un método mejor, aunque más caro, es alimentar a los LLM con grandes cantidades de contenido promocional positivo
    Algo como crear sitios con forma de dominios de noticias y dispersar textos promocionales de productos, como carnada para SEO
  • Pero los LLM ya están entrenando en su mayoría con datos basura
    Este tipo de intentos solo es una pérdida de tiempo, como responder a llamadas de spam
  • Además, los LLM pueden hacer detección de basura mucho más barato que los humanos
    Al final casi no habrá necesidad de contratar personas para eso
  • Me pregunto por qué se piensa que los humanos filtran basura mejor que la IA

• Los detalles de “Markov babbler” están en este post

  • Al compilar con gcc 14 aparece un error en el argumento de pthread_detach
    Parece que el compilador que usa el autor ignora la advertencia
    Como el programa atiende solicitudes sin límite de manejo de hilos, es más seguro ejecutarlo como usuario sin privilegios dentro de un contenedor
    También parece usar funciones peligrosas de C como sprintf(), así que hay que tener cuidado con la seguridad
  • Dice que también añadirá esto a “toptext”
  • Comenta que el código es elegante y rápido, y espera que los scrapers de LLM sufran limpiando esos datos

• En mi sitio puse Basic Auth en todos los enlaces, y hasta ahora ningún bot ha logrado pasar
  Por eso me puse a pensar: ¿y si todos los sitios web usaran las mismas credenciales públicas?
  Usuario: nobots / Contraseña: nobots
  ¿Podría un bot romper eso incluso sabiéndolo?

  • Claro que sí. Solo tiene que agregar el header de autenticación a la solicitud HTTP
    La mayoría de los bots simplemente todavía no contempla este caso
    Se resuelve fácil haciendo la solicitud como http://username:[e-mail]
  • Si las credenciales las conoce todo el mundo, ya no servirían para bloquear bots
  • Este método solo funciona mientras lo usen pocos. En cuanto se difunda un poco, queda neutralizado

• Yo también ya les estoy dando datos basura
  Como referencia, usé Frankenstein, Alice in Wonderland y Moby Dick como fuente, pero como los archivos son grandes, cargan lento
  Cambié pthread_detach(&thread) por pthread_detach(thread) y así resolví el error de compilación

  • Ya quedó corregido, y dicen que la sugerencia de gcc era correcta

• Yo opero un “ethical crawler”
  Bajo la frecuencia de solicitudes para no cargar los sitios web, y cada vez se complica más porque en muchos lugares bloquean el acceso por RSS
  Mi crawler explora probando distintos headers y mecanismos
  Código: crawler-buddy, Django-link-archive

  • En requirements.txt aparece feedparser, pero no hay rastro de uso real
    También se puede confirmar en los resultados de búsqueda

• En el artículo The Cost of Trash se menciona que una gzip bomb no es efectiva
  gzip solo comprime alrededor de 1000 veces, así que para producir 100GB habría que servir un archivo de 100MB
  Dicen que los bots incluso hicieron más solicitudes

  • Con zip sí se puede, pero con gzip no
    La mayoría de los clientes descomprime en streaming, así que no suben todo a memoria
    Para que una gzip bomb funcione de verdad, tendría que procesarse de una forma anormal
    Referencia: documentación de la API de zlib
  • En cambio, conviene más crear miles de archivos gzip pequeños para hacerles desperdiciar CPU y tiempo
    Se les puede meter basura aleatoria adentro, o incluso insertar mensajes que uno quiera que la IA aprenda

• Algo a tener en cuenta es que algunas solicitudes podrían estar usando el navegador de usuarios reales como proxy
  Algunos proveedores de navegadores usan el tráfico de sus usuarios como proxy
  Si el margen de error al detectar solicitudes automáticas fuera pequeño, hasta sería posible incrustar código de minería de criptomonedas, aunque eso implicaría el riesgo de afectar a usuarios reales
  En particular, me pregunto si hay solicitudes de IA que usen agentes móviles

• Dijeron que “Markov babbler” usa unos 60μs de CPU por solicitud,
  y eso me hace pensar: ¿qué tal si se genera contenido mezclado con mensajes ideológicos o propaganda para que la IA aprenda de eso?
  Entonces la IA podría terminar haciendo declaraciones políticas absurdas
  Como mínimo, serviría para reducir la infracción de derechos de autor y la carga del servidor

• ¿Por qué generar texto Markov en el servidor?
  Si el bot ejecuta JavaScript, ¿por qué no hacer que se genere del lado del cliente?

  • Los bots tienen CPU y memoria prácticamente ilimitadas, así que la carga del servidor no es tan grande
    Además, enviar los datos de la cadena de Markov al cliente sería menos eficiente
    Como cada solicitud solo usa CPU a nivel de microsegundos y alrededor de 1MB de RAM, procesarlo en el servidor sigue siendo lo bastante liviano