Los scrapers agresivos de IA están complicando bastante la operación de las wikis

• El tráfico de scrapers de IA está desestabilizando los costos y la estabilidad de las wikis públicas, y sin mitigación puede consumir cerca de 10 veces más recursos de cómputo que toda la actividad humana combinada
• Los bots van más allá de User Agents identificables como GPTBot y disfrazan sus encabezados para parecer Chrome reciente, además de evadir controles con proxies residenciales que rotan 1 millón de IP al día
• Las wikis exponen muchísimas URL de versiones anteriores, pantallas de edición y páginas especiales además de los artículos, por lo que un crawling ingenuo evita la caché y puede resultar entre 50 y 100 veces más caro que una solicitud normal
• Cloudflare Challenge, Anubis, reglas manuales de firewall y la detección basada en solicitudes de comportamiento humano funcionan, pero también generan falsos positivos, carga de mantenimiento y fricción para los lectores
• Los bloqueos extremos, como exigir inicio de sesión o aplicar desafíos a todo el tráfico, pueden reducir las nuevas contribuciones, por lo que hace falta discusión pública entre operadores y acceso por API que cambie los incentivos de recolección de los bots

---

La carga que los scrapers de IA imponen a la operación de las wikis

• El scraping automatizado para datos de entrenamiento de LLM ha crecido a una escala sin precedentes y está sacudiendo los costos y la estabilidad de los sitios web públicos: el problema también se aborda en FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline? y Smart TV web crawler AI
• Weird Gloop aloja grandes wikis de juegos como Minecraft Wiki, OSRS Wiki y League Wiki, y en los últimos 3 años ha dedicado cada vez más tiempo a responder al tráfico de bots
• Sin mitigación continua, los bots pueden consumir cerca de 10 veces más recursos de cómputo que todo lo demás combinado, incluyendo decenas de millones de páginas vistas por humanos y decenas de miles de ediciones por día
• La Wikimedia Foundation también publicó un artículo sobre el impacto de los crawlers en la operación, grandes granjas de wikis han sufrido incidentes de distintos niveles y algunas wikis independientes pequeñas han quedado completamente fuera de línea
• Se estima que alrededor del 95% de los problemas de servidor del ecosistema wiki este año fueron causados por scrapers maliciosos

Scrapers que intentan parecer humanos

• Los bots “oficiales” de grandes empresas de IA, como GPTBot, ClaudeBot y PerplexityBot, a veces no han respetado robots.txt, pero normalmente pueden identificarse por su cadena de User Agent y es fácil bloquearlos con el bloqueo de bots de IA de Cloudflare o con nginx
• A medida que los webmasters empezaron a bloquear scrapers de IA según el User Agent, los bots pasaron a tener un fuerte incentivo para disfrazarse como tráfico humano
• La mayor parte del tráfico de scrapers de IA que llega hoy a las wikis envía encabezados para parecer Google Chrome reciente y construye las solicitudes con bastante sofisticación
• Han desaparecido las señales claras que antes permitían distinguir entre “bot o persona real”, lo que hace más difícil bloquearlos

Decenas de millones de IP y evasión con proxies

• Antes de 2023, el 95% del scraping problemático venía de una sola dirección IP o de una subred pequeña de datacenter, así que bloquear por IP o por características del ISP solía funcionar razonablemente bien
• Con proxies residenciales es posible lavar solicitudes de scraping a través de redes de millones de direcciones IP con solo una tarjeta de crédito
• Las wikis a veces se topan con operaciones de scraping que rotan 1 millón de IP por día y aparentan ser solicitudes legítimas desde ISP residenciales como Comcast, AT&T y Charter
• Es muy probable que esos clientes no sepan que su IP se está usando como nodo de salida de un proxy residencial
• Algunos actores maliciosos también usan previsualizaciones de enlaces de facebookexternalhit o Google Translate para hacer que las solicitudes parezcan venir de servidores de Google/Facebook y ocultar su origen real
• En algunos casos, 99.99% de las solicitudes que entran por la herramienta de URL de Google Translate son abusivas, al punto de que durante un tiempo hubo que romper esa herramienta en todas las wikis

Crawling de “URL tontas” especialmente costoso para las wikis

• Muchos scrapers de IA visitan la página principal de una wiki y luego recorren todos los enlaces de esa página, después todos los enlaces de esas páginas, y así sucesivamente
• Parecen no reconocer que robots.txt y los sitemaps ya indican qué URL vale la pena scrapear
• La OSRS Wiki tiene unas 40 mil páginas de artículos, y esas URL contienen la mayor parte de la información útil del sitio
• Pero si se incluyen versiones anteriores, pantallas de edición y páginas especiales, el número de URL navegables llega como mínimo a 1,000 millones
• Este crawling ingenuo nunca termina y parece gastar muchos recursos en URL que no sirven para entrenamiento de LLM
• Las solicitudes extrañas evitan capas de caché como MediaWiki parser cache, que sí usan las solicitudes de usuarios reales, elevando el costo del servicio
• Una solicitud que da en caché suele procesarse en menos de 20 milisegundos, pero solicitudes como diffs antiguos con frecuencia tardan 1 a 2 segundos
• Métricas de alto nivel como “8 millones de solicitudes de bots por día” o “los bots usan 65% del ancho de banda” subestiman el problema
• El verdadero cuello de botella suele ser la capacidad de CPU, y las solicitudes de bots con parámetros de consulta extraños a menudo cuestan entre 50 y 100 veces más que una solicitud normal

Picos de tráfico que no aparecen en los promedios

• Las solicitudes mensuales de bots rondan los 250 millones, con un promedio de unas 100 por segundo, pero eso es solo un promedio de largo plazo
• Los scrapers con frecuencia lanzan ráfagas de más de 1,000 solicitudes por segundo durante lapsos cortos, casi indistinguibles de un ataque DDoS tradicional
• Aunque a largo plazo los bots representen solo alrededor del 50% del uso total de CPU, los picos de tráfico malicioso causan cerca del 95% de las ralentizaciones e incidentes de caída en las wikis

Una estructura donde es difícil saber quién está detrás

• Se habla de “scrapers de IA”, pero como todos se disfrazan de Google Chrome, es difícil identificar a los verdaderos responsables o saber para qué usan los datos de las wikis
• Entre los posibles actores hay brokers de datos, recolección redundante de frontier labs y proyectos independientes con acceso a proxies residenciales
• Tampoco está claro qué tan baja se volvió realmente la barrera de entrada
• Si existiera una mejor forma, se preferiría contactar directamente a quienes hacen la recolección para encontrar métodos menos ineficientes

Respuestas que sí han funcionado hasta ahora

• Cloudflare Challenge y Anubis

  • Poner un sitio detrás de Cloudflare challenge o de herramientas como Anubis se ha vuelto común en internet durante el último año
  • Funciona hasta cierto punto, pero hay periodos en los que algunos bots superan de forma constante el desafío
  • Parece haber una carrera armamentista invisible entre Cloudflare y los desarrolladores de bots: Cloudflare gana cerca del 90% de las veces, pero el 10% restante sigue siendo muy duro en la práctica operativa
  • A los lectores reales no les gusta encontrarse con un desafío antes de llegar a la wiki
  • Para no afectar a la mayoría de las personas, hacen falta buenas reglas heurísticas para decidir a qué tráfico aplicarle el desafío, pero detectar tráfico automatizado de forma confiable ya es un problema difícil por sí mismo

• Reglas manuales de firewall

  • La mayoría de los operadores tiene reglas manuales de firewall adaptadas a su propia infraestructura y a ataques anteriores
  • Estos filtros suelen basarse en cadenas específicas de User Agent, grupos de IP o ASN
  • Weird Gloop maneja la mayor parte de esto a nivel de Cloudflare/CDN, aunque otras wikis lo hacen en nginx o del lado del servidor web
  • Hoy en muchos casos ya no basta con User Agent/IP; hay que mirar propiedades más complejas de la solicitud, como la versión de HTTP, los headers, el cifrado TLS y hashes relacionados con ja4

• Buscar “cosas que los humanos hacen y los bots no”

  • Un enfoque útil es buscar comportamientos que los humanos hacen en conjunto y los bots no
  • En las wikis basadas en MediaWiki hay varios tipos de solicitudes HTTP que los navegadores reales generan con frecuencia cuando una persona usa la wiki, y los bots normalmente no las generan
  • Si un bloque de tráfico distinguible por headers, hashes ja4 u otras señales visita muchos artículos pero no genera esas solicitudes típicas de “persona”, eso es una señal fuerte para aplicarle un desafío
  • Observar las solicitudes de comportamiento humano ausentes en el tráfico de bots es un método potente
  • Ya comenzaron a construir un sistema que analiza el tráfico “faltante” y propone automáticamente heurísticas basadas en árboles de decisión para decidir a qué tráfico desafiar
  • En pruebas, parecía detectar casi todos los scrapers, pero no está claro qué falsos positivos podría generar en personas con hábitos de navegación atípicos, como usuarios de NoScript, lectores de pantalla o dispositivos inesperados
  • También sigue siendo una carga crear y mantener de forma permanente una infraestructura propia de ML/análisis de datos

• Técnicas de detección más exóticas

  • Hay casos exitosos de identificación de proxies residenciales mediante desajustes de tiempo TCP/TLS
  • También hay empresas que venden bases de datos en tiempo real de IP de proxies residenciales
  • Sin embargo, como la mayoría de los proxies residenciales también la usan personas reales al mismo tiempo, no está claro hasta qué punto eso puede servir como señal de bloqueo operativamente viable
  • Da la impresión de que actores con información de red a nivel de paquetes de volúmenes masivos de tráfico, como Cloudflare o grandes proveedores de nube, sí podrían construir buenas heurísticas a gran escala
  • Aun así, ni siquiera con productos comerciales de detección de bots que cuestan seis cifras al año se han encontrado operadores realmente impresionados por las heurísticas comerciales

Opciones extremas que perjudican a los lectores

• La “opción nuclear” para bloquear scrapers de IA es mucho más destructiva para los usuarios reales
• Una medida común es exigir inicio de sesión para ver páginas cuyo costo de generación puede ser alto
• Fandom aplicó hace unos meses este tipo de medida en todas sus wikis
• Otra opción es mostrar un Cloudflare challenge a todo el tráfico
• Desde la perspectiva del webmaster es comprensible, pero es malo para la salud de largo plazo de la wiki y de su comunidad
• Una lección clave aprendida tras 16 años construyendo comunidades wiki es que la mejor forma de atraer nuevos colaboradores es eliminar fricción
• Hay que facilitar la edición, hacer más fácil navegar la estructura interna de la wiki y reducir la barrera de entrada entre lectores y editores
• Las técnicas antibot extremas crean nueva fricción y producen resultados previsibles
• Después de que Fandom ocultó las “páginas internas” a más del 95% de los lectores sin cuenta, las nuevas contribuciones de usuarios en todo Fandom cayeron cerca de 40%
• Es difícil considerar que ese intercambio valga la pena

Hacia dónde ir ahora

• Weird Gloop sigue alojando wikis y también continúa ayudando a las wikis que quieren salir de Fandom
• A largo plazo, “AI Overviews” podría matar el canal que convierte lectores de wikis en colaboradores, pero eso queda como un problema aparte
• Algunas personas cercanas creen que la ola de bots incluso podría beneficiar a Weird Gloop, pero si la gente ya no puede alojar wikis fácilmente, internet empeora
• Un escenario donde para alojar una wiki de forma estable se necesiten rotaciones on-call, ingenieros de ML y productos empresariales sería una muy mala noticia para las comunidades wiki independientes
• Es probable que la carrera armamentista entre dueños de bots y webmasters continúe hasta que aparezca una forma inteligente de cambiar los incentivos estructurales del scraping
• La nueva crawling API de Cloudflare podría cambiar el panorama si para los bots resulta más fácil usar una API que construir sus propios sistemas problemáticos que ignoran robots.txt
• Sería mejor que el scraping no ocurriera en absoluto, pero es difícil deshacer algo que ya está en marcha

Necesidad de discusión pública y colaboración

• Miles de operadores están administrando sus propios sitios web y buscando técnicas más inteligentes para responder a los bots
• En conversaciones privadas con otros administradores de sistemas ya han surgido ideas concretas y buenas, y seguramente también hay mucha discusión en Slack, Discord y grupos pequeños
• Hace falta más discusión pública sobre detalles concretos de la operación real
• Muchos administradores de sistemas no saben lo suficiente que el problema que están viviendo es casi idéntico al de otros operadores
• No todo el mundo quiere publicar sus propios métodos de defensa, y existe la preocupación de perder ventaja si se hacen públicos
• Aun así, si se logra que la gente piense en conjunto, vale la pena asumir el riesgo de que parte de algunas tácticas pierda efectividad
• Los administradores de sistemas que lidian con scrapers de IA harían bien en compartir qué métodos les han funcionado en los espacios que les resulten adecuados
• Las empresas que venden productos para resolver el problema de los bots deberían publicar más estudios de caso con datos reales sobre tasas de precision and recall en condiciones no artificiales
• Quienes toman decisiones de compra no valoran casillas marcadas en una lista, sino resultados reales
• Si administras una wiki o un sitio web independiente y quieres hablar sobre detección de bots, puedes contactar por correo electrónico o mensaje de Discord

[GN⁺]

Opiniones en Lobste.rs

• Probé usar un desafío de prueba de espera (proof-of-wait) para compensar las desventajas de Anubis, y funcionó bastante bien
  Básicamente, si la tasa global de solicitudes está por debajo de cierto umbral, se desactiva el filtro; si lo supera, se obliga al usuario a esperar N segundos antes de poder continuar
  Después se emite un token vinculado a esa IP y, hasta que expire, solo se permite una pequeña cantidad de solicitudes, y el propio token también tiene limitación de velocidad
  Si siguen entrando solicitudes exitosas, el tiempo de espera va aumentando poco a poco
  Fue bastante exitoso, se degrada de forma gradual para no perjudicar demasiado a los dispositivos móviles, y funciona incluso sin JavaScript

  • Vi este enfoque funcionando en marginalia.nu, y me gusta que no desperdicie la batería del teléfono con prueba de trabajo
  • Si esto forma parte de código público, me gustaría recibir un enlace al código fuente que lo implementa
  • Genial. Me pregunto si hay esfuerzos por convertir algo así en parte de TLS. Se siente parecido a lo que intenta hacer draft-venhoek-tls-client-puzzles-00 con desafíos de prueba de trabajo
    Esto parece algo que debería estar en una capa mucho más baja, como TLS o incluso la pila IP del sistema operativo
    No he pensado mucho en la prueba de espera, pero ¿no termina afectando mucho peor a los usuarios legítimos que a los scrapers automáticos? La gente se irrita esperando, pero el scraper puede guardar el token y volver N segundos después
    La prueba de trabajo también me genera sentimientos encontrados, pero al menos impone a los scrapers un costo real proporcional a la escala
  • Me pregunto si es fácil de configurar. Me interesa para mi wiki también
  • Parece un enfoque útil. Me pregunto si planeas documentarlo con más detalle
    La prueba de espera podría tranquilizar a quienes tienen preocupaciones sobre la prueba de trabajo

• También funciona bastante bien hacer que ciertas páginas especiales solo sean accesibles para clientes que hayan iniciado sesión una vez y tengan esa cookie configurada; si no, se les rechaza
  Como la mayoría de los crawlers apuntan a páginas especiales para recorrer la wiki, se las puede restringir a usuarios con sesión iniciada
  En esta configuración, la wiki no permite crear usuarios
  <If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
  ErrorDocument 403 "Acceso denegado, por favor inicia sesión."
  Require all denied
  </If>
  Con esto bajó muchísimo la carga de nuestro sistema. Antes había picos frecuentes en los que rastreaban agresivamente las páginas especiales y la wiki quedaba prácticamente inutilizable
  Aparte de eso, bloqueamos de inmediato con 403 los user agents conocidos de crawlers de IA, y también ciertos rangos de IP como Alibaba o Amazon Cloud
  Curiosamente, se dieron cuenta. Empezaron recorriendo páginas con vista Diff y, cuando eso se restringió, intentaron lo mismo con la vista MobileDiff
  Hubo algo de ida y vuelta, pero desde hace unos meses esto ha funcionado sin problemas

  • El bloqueo basado en user agent es prácticamente de lo peor que se puede hacer
    Si bloqueas por user agent, el crawler vuelve a intentarlo con un user agent que parezca humano y explora el sitio
    Si determina que el disparador del bloqueo es el user agent, entra en modo infierno, se vuelve mucho más difícil de identificar y golpea el sitio hasta matarlo
    Bloquear rangos de IP también ayuda, pero no basta ni permite atraparlos a todos, porque rastrean mediante proxies de malware móvil
    Si no los bloqueas desde el principio, por lo general se quedan relativamente tranquilos
    Por eso el truco no es bloquearlos, sino darles datos basura baratos de generar sin activar el modo infierno; yo uso https://iocaine.madhouse-project.org/
  • Para referencia, esto también se puede hacer con permisos de MediaWiki. Si dejas por defecto todos los permisos denegados y luego vuelves a dar a los usuarios anónimos solo lectura de páginas del espacio de nombres principal, desaparece el juego del gato y el ratón
    Aunque en ese caso MediaWiki tiene que servir directamente las respuestas, así que también hay una ventaja en hacerlo desde Apache
  • Me pregunto si realmente se dieron cuenta al instante. Yo supondría que los autores de scrapers ya tenían preparadas varias técnicas alternativas, y que en cuanto el bot empezó a recibir 403 fue probando el siguiente truco de la lista

• Como comentario al margen, Weird Gloop es un servicio excelente. La calidad de las wikis que opera es muy alta, y mover contenido hecho por fans fuera de la horrible plataforma de Fandom le hace bien al mundo

• Gergely Nagy, a.k.a. algernon, además de desarrollador de iocaine, ha estado lidiando con este problema desde hace tiempo, y probablemente tenga ideas útiles para Weird Gloop

• Odio decirlo, pero la propuesta de ajustarlo al comportamiento humano me parece algo que luego les va a jugar en contra
  Los bots van a empezar a pedir también todos los recursos estáticos de la página, asumiendo que eso forma parte del comportamiento que identifica a una persona
  Interesante juego, profesor Falken

• Si el scraper llega a este tipo de páginas siguiendo recursivamente enlaces normales de <a href=...>, me pregunto si se podría desviar suavemente haciendo que páginas caras y no cacheadas, como las diferencias de historial, solo se puedan abrir enviando un <form method="POST" action=...>
  No bloqueas nada y, de hecho, también beneficia al scraper porque evita que termine ingiriendo recursivamente una cantidad casi infinita de información duplicada
  Los usuarios normales probablemente casi no notarían la diferencia, y parece una buena relación esfuerzo/beneficio. Para usuarios anónimos podría ser mejor que Anubis
  Esto depende de asumir que el scraper no envía formularios HTTP con method="POST"
  Si eso no fuera cierto en general, creo que ya habríamos visto titulares sobre scrapers de IA enviando ediciones anónimas masivas y convirtiendo el contenido de Wikipedia en basura aleatoria

  • Si haces eso, la respuesta también pasa a ser no cacheable, así que podría ser un problema si dependes de un CDN
    Me pregunto si los bots también seguirían <form method="GET">. Eso encajaría mejor con caché y aun así podría exigir lógica adicional al crawler

• El 95% del tráfico de mi pequeño blog viene de scrapers de LLM de Singapore y China

• ¿Cómo es que después de tantos años nadie ha encontrado una sola IP de un ISP pequeño que se pueda rastrear, contactar y visitar en persona? ¿Nadie ha ido a hablar con ese usuario y pedirle cortésmente revisar su computadora? ¿De verdad nadie ha logrado averiguar qué software está haciendo el crawling?
  Si los operadores de sitios ni siquiera pueden hacer eso, ya no me interesa seguir preocupándome. Se ganan a los bots por hacer todo lo posible para evitar el contacto humano directo y desordenado
  Y los bots que corren en botnets residenciales a veces, por supuesto, tienen suficiente capacidad de cómputo para pasar un CAPTCHA o Anubis
  Es imposible ganar permanentemente desde el lado del servidor. El usuario de esa computadora también genera tráfico legítimo
  Así que, salvo que quieras atestación remota, hay que ir a buscar esas IPs

  • Creo que estás subestimando la escala de las botnets residenciales
  • El problema es que el tráfico viene de decenas de miles de IP distintas
    Incluso dejando de lado cosas prácticas como el costo de gasolina para manejar por todo el mundo, se vuelve un enorme problema del viajante
  • Es una opinión realmente asombrosamente mala
    La idea de que por unos cuantos bots los administradores del sistema deberían pasarse el fin de semana manejando a cualquier parte para pedirles que sean un poco más educados es risible, sobre todo considerando que la mayoría vienen de ISPs grandes o extranjeros
    Dan ganas de preguntar qué te fumaste
    ¿Qué software está haciendo crawling hoy? Alguien le pide a un chatbot “hazme algo para scrapear esto”, y cada scraper se genera de forma individual
  • La pregunta de “nadie” solo es razonable si puedes decir quién tiene la capacidad, la motivación o la responsabilidad de hacer ese trabajo
    Si no, solo estás culpando al universo entero en abstracto
  • Contactar a un ISP pequeño e ir hasta allá no es realista
    Casi te garantizo que a la mayoría de los proveedores no les importa en absoluto si sus IP se usan para scrapear algún sitio web
    Además, también te garantizo que esos proveedores no van a darte la dirección asociada a una IP
    Lo que funciona mucho mejor es tirar a la basura de una vez todo el tráfico ASN asociado con varios proveedores como Alibaba o AWS
    No siempre es una opción posible. Por ejemplo, si tienes un blog con feed Atom, también podrías bloquear lectores de feeds
    Pero en muchos casos puedes eliminar el 80% del tráfico basura

• ¿Alguien sabe por qué ocurre este comportamiento? En particular, me intriga por qué se producen los picos

  • Una hipótesis que escuché es que la botnet es poco confiable, y que quienes venden acceso a ella mediante proxies residenciales compensan esa inestabilidad con solicitudes duplicadas
    No sé si sea cierto, pero al menos suena plausible
    Es difícil decirlo sin entender mejor la infraestructura. También podría ser una limitación de mando y control
    Si la botnet fue construida para DDoS, puede que por su propia estructura no tenga control fino suficiente