La infraestructura FOSS está bajo ataque de empresas de IA

• Varias infraestructuras FOSS —como SourceHut, KDE GitLab, GNOME GitLab, LWN, Fedora, Inkscape, Diaspora y Read the Docs— están sufriendo caídas, bloqueos y carga operativa por crawlers de IA e informes de seguridad generados por IA
• Los crawlers ignoran robots.txt o solicitan repetidamente endpoints costosos como git blame, logs de Git y páginas de commits, e intentan mezclarse con el tráfico de usuarios normales usando decenas de miles de IP y User-Agents falsificados
• GNOME introdujo la prueba de trabajo Anubis, pero durante unas 2 horas y 30 minutos solo el 3% de 81,000 solicitudes la superó, lo que sugiere que la mayor parte del tráfico podría ser de bots
• Se han aplicado medidas como bloquear versiones de Edge, limitar a usuarios no autenticados, bloquear subredes y países, listas de bloqueo de IP, y robots.txt/.htaccess para crawlers de IA; aun así, usuarios reales también sufren demoras o bloqueos de acceso
• Los proyectos open source, al depender de la colaboración pública, tienen una superficie de exposición mayor que los servicios privados, por lo que el scraping de IA y los informes de seguridad con alucinaciones de LLM consumen directamente el tiempo y la capacidad operativa de los mantenedores

---

Fallas repetidas en varias infraestructuras FOSS

• Drew DeVault, fundador y CEO de SourceHut, criticó que las empresas de LLM estén rastreando datos sin respetar robots.txt, causando fallas graves en SourceHut
• La infraestructura de KDE GitLab se sobrecargó por crawlers de IA provenientes de IP en rangos de Alibaba, y los desarrolladores de KDE no pudieron acceder temporalmente a GitLab
• En GNOME GitLab empezó a aparecer la pantalla de carga predeterminada del desafío de prueba de trabajo Anubis, implementado para bloquear scrapers de IA que causan interrupciones
• A medida que se acumulan los casos, aumenta la agresividad de los scrapers de IA y también la carga operativa para las comunidades FOSS, que se basan en la colaboración pública

Cómo operan los crawlers y por qué es difícil bloquearlos

• Según Drew DeVault, los crawlers de LLM no respetan las reglas de robots.txt y recorren repositorios completos, incluso páginas de alto costo
  • Entre los objetivos están git blame, todas las páginas de logs de Git y todos los commits de los repositorios
  • Los crawlers usan User-Agents aleatorios desde decenas de miles de IP, y cada IP envía una o menos solicitudes HTTP para mezclarse con el tráfico de usuarios
• Este comportamiento dificulta crear mitigaciones, y en SourceHut trabajos de alta prioridad se han retrasado semanas o meses
• Como es difícil distinguir bots de personas, los usuarios reales también se vieron afectados de forma intermitente, lo que derivó en fallas de SourceHut
• Drew no distingue si todas las empresas de IA tratan robots.txt o el reporte de User-Agent de la misma manera

Respuestas de KDE y GNOME

• Según Ben, del equipo de sysadmin de KDE, las IP que provocaron el DDoS contra KDE GitLab afirmaban ser MS Edge, y el origen eran empresas chinas de IA
  • Ben considera que operadores occidentales de LLM como OpenAI y Anthropic al menos configuran User-Agents correctos
  • La solución temporal fue bloquear la versión de Edge que los bots decían usar
  • Como los bots tienden a cambiar el User-Agent para mezclarse, esto es difícil de usar como solución definitiva
• GNOME venía sufriendo el problema desde noviembre del año pasado, y aplicó limitación de velocidad para impedir que usuarios no autenticados vieran merge requests y commits
  • Esta medida también causó problemas a usuarios reales no autenticados
• Luego GNOME migró a Anubis
  • Anubis presenta al navegador una tarea computacional y permite el acceso cuando el navegador dedica tiempo a resolverla y envía la solución al servidor
  • Un desarrollador la describió como una “medida cercana a una respuesta nuclear”, y consideró que fue una elección forzada porque los bots scrapers de IA no siguen estándares como robots.txt
• Anubis también deja impacto en usuarios
  • Si muchas personas abren enlaces desde el mismo lugar, pueden recibir desafíos de mayor dificultad
  • Un usuario sufrió una demora de 1 minuto, y otro esperó alrededor de 2 minutos desde el teléfono
  • Esto ocurrió cuando se pegaban enlaces de GitLab en salas de chat o cuando una merge request de Triple Buffering GNOME llegó a Hacker News y atrajo atención
• Según cifras compartidas por Bart Piotrowski, sysadmin de GNOME, durante unas 2 horas y 30 minutos solo el 3% superó la prueba de trabajo de Anubis de un total de 81,000 solicitudes
  • Tasa de aprobación de Anubis: {p:3}
  • Esto sugiere que el 97% del tráfico podría ser de bots

Casos de bloqueo en LWN, Fedora e Inkscape

• Jonathan Corbet, operador de LWN, avisó a los usuarios que el sitio “puede estar lento ocasionalmente” debido a un DDoS de bots scrapers de IA
  • Dijo que el tráfico servido a lectores humanos reales es apenas una pequeña parte del total
  • Según él, en un momento los bots accedían simultáneamente desde cientos de IP, no se identificaban como bots y lo único que no leían era robots.txt
• Kevin Fenzi, sysadmin del proyecto Fedora, también sufrió problemas con scrapers de IA
  • Hace un mes tuvo que responder para mantener vivo pagure.io
  • Después la situación empeoró, bloqueó varias subredes y los usuarios reales también se vieron afectados
  • En una situación desesperada, bloqueó todo Brasil, y se entiende que ese bloqueo sigue vigente
• Neal Gompa señaló que incluso bloquear países completos tiene límites, y que la infraestructura de Fedora estuvo “caída regularmente durante semanas” por los scrapers de IA
• Inkscape también sufrió el mismo problema la semana pasada
  • Martin Owens considera que no se trató del DDoS chino común del año pasado, sino de varias empresas ignorando la configuración de spiders y falsificando información del navegador
  • Creó la lista de bloqueo Prodigius y dijo que, si alguien trabaja en una gran empresa dedicada a IA, quizá ya no pueda acceder al sitio web de Inkscape

Listas de bloqueo de IP e intentos de respuesta conjunta

• BigGrizzly, de Frama software, también fue inundado por malos crawlers de LLM y creó una lista de bloqueo de 460,000 IP que usan User-Agents falsificados
  • Dijo que puede compartir esa lista
• El proyecto ai.robots.txt es un intento más amplio de crear una lista pública de crawlers web relacionados con empresas de IA
  • Proporciona un robots.txt que implementa el Robots Exclusion Protocol
  • También ofrece un archivo .htaccess que devuelve una página de error a las solicitudes de crawlers de IA incluidos en la lista

Cifras de tráfico de Diaspora y Read the Docs

• En el análisis de Dennis Schubert sobre la infraestructura de Diaspora, una parte considerable del tráfico web total aparece como bots de empresas de IA
  • Los bots con User-Agent de OpenAI representan una cuarta parte de todo el tráfico web
  • Amazon representa el 15% y Anthropic el 4.3%
  • En total, alrededor del 70% de las solicitudes provienen de empresas de IA
• Schubert dice que estos bots no rastrean una vez y se van, sino que vuelven cada 6 horas y no prestan atención a robots.txt
  • Si se les aplica limitación de velocidad, cambian a otra IP
  • Si se bloquean por cadena de User-Agent, cambian a una cadena de User-Agent que no corresponde a un bot
  • Lo describió como un DDoS contra todo Internet
• Read the Docs afirmó en el artículo “AI crawlers need to be more respectful” que, al bloquear todos los crawlers de IA, el tráfico se redujo 75%
  • Reducción de tráfico: {p:75}
  • El tráfico bajó de 800 GB diarios a 200 GB
  • Esto permitió ahorrar alrededor de 1,500 dólares al mes
  • También hubo casos en los que crawlers descargaron decenas de TB de datos en pocos días
  • Como usan múltiples IP, es difícil bloquearlos por completo
• Según Schubert, los crawlers “normales” como Google y Bing juntos representan menos del 1%

La carga de mantenimiento creada por informes de seguridad generados por IA

• El problema no se limita a los scrapers, sino que también se extendió a reportes de bugs generados por IA
• Daniel Stenberg, del proyecto Curl, trató el problema de los reportes de bugs generados por IA en el artículo “The I in LLM stands for Intelligence”
  • Curl opera un programa de bug bounty
  • Recientemente, muchos reportes de bugs fueron generados por IA y, a primera vista, parecen plausibles, lo que consume tiempo de verificación de los desarrolladores
  • Pero los reportes contienen las alucinaciones típicas que se esperan de la IA
• Seth Larson, que participa en equipos de triage de reportes de seguridad de CPython, pip, urllib3 y Requests, también enfrenta un problema similar
  • Están aumentando los reportes de seguridad con alucinaciones de LLM, de calidad extremadamente baja y estilo spam, dirigidos a proyectos open source
  • Como al verlos por primera vez pueden parecer legítimos, hace falta tiempo para refutarlos
• Responder a reportes de seguridad es costoso, y lidiar con reportes de bugs plausibles pero inventados agrega una carga importante para los mantenedores
• Larson pidió no usar sistemas de IA o LLM para detectar vulnerabilidades
  • Afirma que los sistemas actuales no pueden entender el código, y que detectar vulnerabilidades de seguridad requiere comprensión del código y de conceptos de nivel humano como intención, formas habituales de uso y contexto

Una carga estructural mayor para FOSS

• Los proyectos FOSS suelen tener menos recursos que los productos comerciales
• En proyectos impulsados por la comunidad, una mayor parte de la infraestructura es pública, por lo que queda expuesta a crawlers
• Como necesitan issues públicos, reportes de seguridad e infraestructura de colaboración, los scrapers de IA y los issues generados por IA se convierten simultáneamente en una carga
• Al final, responder a interrupciones, definir políticas de bloqueo, mitigar daños a usuarios y revisar reportes de seguridad falsos consume el tiempo de los mantenedores open source

[GN⁺]

Opiniones en Hacker News

• También está este caso: https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse... Es un artículo citado también en el original, y todos mis conocidos que operan infraestructura de Internet a gran escala están pasando por cosas parecidas.
  Este artículo reúne bien esos casos en un solo lugar. Como dije cuando lo escribí, simplemente están quemando por completo su capital de confianza.
  Una de las principales startups de este sector colaboró directamente con nosotros, nos reembolsó los costos y corrigió el bug de su crawler. En cambio, Facebook no respondió los correos, y el enlace en el User Agent daba 404. Un ingeniero de la empresa vio el artículo y nos dio el correo correcto, pero envié 3 mensajes ahí y aun así no hubo respuesta.

  • Las empresas de IA parecen actuar como si el capital de confianza no importara. Hacen lo que quieren, como un gorila de 800 libras con 100 mil millones de dólares de capital.
    La actitud es que, quieras o no, la IA va a meterse en todos los productos y, quieras o no, va a absorber todos los datos.
  • La parte de “un crawler descargó 73 TB de archivos HTML comprimidos en mayo de 2024, y los costos de ancho de banda superaron los 5,000 dólares” me hizo volver a leer.
    Opero una infraestructura que maneja cientos de TB de tráfico al mes, principalmente en servidores dedicados, y el costo de tráfico ronda aproximadamente entre 0.50 y 3 dólares por TB. Depende de la región, pero los costos de tráfico saliente de AWS son realmente una locura.
  • Si no responden, en vez de mandar correos basta con enviar la factura al equipo de cuentas por pagar.
  • Si no hubo respuesta después de enviar 3 correos, ¿no habría que considerar el crawling, desde ese momento, como un DDoS y no como un bug o un error?
  • ¿Y si simplemente les alimentamos basura generada dinámicamente? Suena más divertido que no darles ninguna información.

• Ver que mi proyecto aparece así en la imagen de vista previa se siente totalmente irreal. ¡Increíble! Si quieren probarlo, está aquí: https://github.com/TecharoHQ/anubis
  Por lo que he visto hasta ahora, parece que realmente funciona. Lo tengo desplegado en xeiaso.net para ver cómo falla en producción en mi blog.

  • Sería bueno agregar una pequeña explicación para las personas sobre qué deben hacer ahora y qué está pasando en esa página.
    Hay algo como un widget de animación de carga, pero cuando lo vi por primera vez hace unas semanas en el tracker de issues de Gnome, la prueba de trabajo tardó unos 20 segundos y no entendía qué estaba pasando. Al principio pensé que me habían bloqueado o que el captcha no había cargado.
    Ahora ya sé qué es, pero viendo solo la página de “verificando si eres un bot”, no parece 100% claro.
  • Me gusta mucho este enfoque. No me molesta que Internet se comporte como el Lejano Oeste, pero sí detesto que no haya responsabilidad.
    Es una buena forma de que quienes quieren mantener un sitio abierto gratis trasladen la carga económica a los crawlers. Si quieren los datos, que quienes los toman gasten el dinero.
    La desventaja es que podrías quedar fuera de los motores de búsqueda, pero tampoco hay razón para no registrar el servicio en indexadores globales o P2P.
  • Me gusta; como siempre, está bien hecho.
    Y respecto a https://news.ycombinator.com/item?id=43422781, si se le agregara una forma de calcular micropagos con la shitcoin que uno quiera, quizá habría otro caso de uso realmente útil para las criptomonedas.
  • Anubis funcionará solo mientras no se vuelva famoso. Cuando se haga famoso, los crawlers empezarán a resolver la prueba de trabajo con GPU/ASIC, y ahí se acaba todo.
  • Me gusta toparme de vez en cuando, de forma aleatoria, con cosas que creaste. También me gusta el estilo de explicación en formato blog, así que pienso revisar más a fondo Anubis.

• A este ritmo, no es un problema exclusivo de la infraestructura libre y de código abierto. Claro que eso resuena especialmente porque es el canario en la mina, pero al final es un problema de todo el acceso anónimo a Internet
  Puedes poner un sitio detrás de un muro de autenticación, pero los bots nuevos, a diferencia de los de antes, resuelven captchas e imitan a usuarios reales. Más aún si usan IP residenciales y User Agents falsos, o incluso User Agents reales conectados a algo como Playwright, como se menciona en el artículo
  Al final, ¿qué queda además de que los sitios empiecen a pedir tarjeta de crédito, Worldcoin o algún sustituto igual de deprimente?

  • Ya estamos más o menos a medio camino. Lo noto cada vez que, al mapear en OpenStreetMap, busco negocios locales que no tienen su propio sitio web
    Usan Facebook, Instagram, X, etc. como tarjetas de presentación digitales. No uso Facebook ni Instagram normalmente, dejé X y ni siquiera tengo cuenta; cuando sigo esos enlaces, solo veo parte de la información y luego aparece un cuadro de diálogo que me dice que cree una cuenta o me vaya, o aparece algún error desconocido
    Está bien unirse a comunidades privadas, pero es realmente molesto que aparezcan estas barreras sobre información que fue publicada suponiendo que sería visible públicamente
  • Para decir en voz alta la parte silenciosa: una de las razones principales por las que esto es deprimente es que no es simple deterioro, sino un deterioro que acumula beneficios compuestos para los villanos involucrados. Raspar contenido es apenas el comienzo
    ¿Los costos suben y el sitio cae para siempre? Excelente, porque la gente tendrá que usar IA para toda la documentación. ¿Se rinden con los captchas y empiezan a pedir tarjetas de crédito o números de teléfono? Excelente, porque así se reduce el anonimato en Internet
    ¿Las filtraciones de datos aumentan las estafas? Excelente, porque hará falta IA para frenarlas. Para los actores maliciosos, casi todo es una jugada ganadora
    La balcanización de Internet se viene discutiendo desde hace mucho. Uno pensaría que esa amenaza, o el hecho de que ya sea un basurero fuera de control, generaría cierta cautela antes de empeorar las cosas, pero al final no importa empujar los límites del acoso y la fricción que la gente puede soportar. Porque no tienen una opción real
  • No sé. Opero un pequeño juego de navegador, y aunque el servidor recibe palizas periódicas de scrapers de LLM, todavía no he visto una sola cuenta nueva que parezca creada por un bot
    La tasa de nuevos registros tampoco cambió de forma perceptible. Es así tanto en el juego como en la wiki, y la mayor parte del tráfico de scraping se concentró en la wiki. Si el scraping no baja, es muy probable que tenga que poner la wiki casi por completo detrás de un muro de autenticación
  • Podría ser algo como: para hacer las próximas X solicitudes, hay que procesar esta cantidad de tokens. Aunque, claro, suena bastante utópico
  • No hace falta ponerlo necesariamente detrás de un muro de autenticación. También es perfectamente posible usar un servicio de micropagos anónimos por cada solicitud
    Si vivimos en un Internet donde que un sitio web reciba demasiados visitantes se convierte en una amenaza existencial para ese sitio, entonces la estructura de nuestro Internet no está hecha para sobrevivir mucho tiempo

• Cuando los motores de búsqueda provocaron esto en el pasado, la industria llegó a un acuerdo para evitar que se creara regulación legal y creó la especificación robots.txt. Por eso no se formó un marco legal
  Ahora hay una nueva generación de indexadores hambrientos que no participaron en ese acuerdo y que, por presión competitiva, quieren raspar la mayor cantidad de datos posible, y simplemente ignoran robots.txt
  De todos modos debió haberse legislado, y quienes ignoraran robots.txt deberían haber recibido bloqueos, multas, limitaciones de velocidad, etc.

  • No sé si me gusta este plan. No hay que permitir que la IA ilegal tenga más conocimiento y utilidad que la IA legal
    Hay otras opciones además de una prohibición total
  • Me sorprendería que hubiera siquiera una persona en la Cámara de Representantes o en el Congreso de EE. UU. que sepa qué es robots.txt
  • ¿Cómo podrían las leyes de EE. UU. o de la UE bloquear el tráfico que viene de China, Tailandia o Rusia? Como mucho fragmentarían Internet, y eso no es “lo mejor”, sino una idea terrible

• A mí también me atacaron hace poco [0]. Es una pequeña instancia de Forgejo donde publico el código de varios paquetes de código abierto, así que tiene que estar abierta al público, pero quedó completamente destrozada y el disco se llenó con archivos ZIP generados
  No soy el único al que le pasó lo mismo. En mi caso, al bloquear los rangos de IP de Alibaba Cloud, el ataque por ahora se redujo
  Si operas una instancia de Forgejo, recomiendo firmemente configurar DISABLE_DOWNLOAD_SOURCE_ARCHIVES en true. Los crawlers seguirán aferrándose a la CPU, pero al menos el disco no se llenará de archivos ZIP
  [0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

  • Que “el disco se llenó con archivos ZIP generados” significa que es un mal diseño de software que crea ZIP al vuelo
  • Quizás sería mejor cambiarlo por software bien hecho, diseñado correctamente para servirse en la Internet pública
    Un diseño que genera archivos ZIP, los escribe completos en disco y luego los envía de una vez al cliente es completamente horrible e inutilizable. Un diseño correcto debería generarlos de forma incremental y transmitirlos al cliente usando un mínimo de memoria y sin usar disco en absoluto
    Que exista un diseño tan absurdo es señal de que los desarrolladores casi no prestaron atención a la eficiencia, y es probable que haya muchas otras fallas graves similares
    Por ejemplo, al mirar por encima el código fuente de Forgejo, parece que lanza procesos “git” para todas las operaciones de Git, en lugar de usar una biblioteca dedicada. No lo confirmé, pero no me sorprendería que esas operaciones estén muy lejos de la forma más eficiente de realizarse
    Si corres software tan extremadamente deficiente, no sorprende que la CPU quede fija al 100% y el servidor se vuelva inutilizable

• La gran conclusión aquí es que el dominio de la web por parte de Google y de la publicidad en general está desapareciendo.
  La única forma de bloquear bots es con captchas, pero entonces los indexadores de búsqueda tampoco pueden indexar el sitio. Al final, los motores de búsqueda no pueden indexar el sitio y dejan de aportar valor.
  Habrá cierto desfase hasta que se seque el conocimiento que hoy está dentro de los LLM, pero ya nadie podrá raspar la web de forma automatizada.
  Parece que todo va a arder.

  • En realidad, creo que será algo como la estabilidad de Lyapunov de poblaciones de lobos y conejos. En este escenario, nosotros somos los conejos.
    Si baja la población de IA, aumenta el contenido humano, lo que se convierte en más alimento para la IA y hace que vuelva a crecer. Entonces la expresión humana queda sepultada y los humanos se vuelven más silenciosos. Al reducirse el alimento de la IA, la IA disminuye; baja el ruido y los humanos vuelven a crecer. Este ciclo se repite hasta el cansancio.
  • Personalmente, creo que esta fue una de las motivaciones reales detrás de Web Environment Integrity. Permitir que Google pueda indexar y que los demás no.
    Estamos atrapados en una disyuntiva difícil: ¿queremos a los actores dominantes ya atrincherados o queremos hosting barato y abierto?
  • Google ya raspa los sitios y muestra respuestas directamente en los resultados de búsqueda. Si me importa el tráfico y quiero vender espacios publicitarios, ¿por qué debería querer ahora que Google indexe mi sitio?
    Muchos sitios basados en publicidad se apagarán. Sus visitantes serán solo bots.
  • Si tenemos que pasar al crawling basado en autenticación, la posición de los motores de búsqueda existentes se fortalecerá aún más, porque solo podrán acceder los crawlers invitados.
    Si hay una herramienta sencilla, la mayoría permitirá solo a Google, Bing y, como mucho, uno o dos más.
  • Ganará la empresa de IA que tenga la mejor tecnología para eludir captchas, e insertará anuncios en las salidas de los LLM de formas más sofisticadas.

• Si a alguien le interesa el pequeño sabotaje, creo que logré “ahogar” en cierta medida la información real de mi microblog.
  Con LLaMa generé decenas de publicaciones contradictorias por cada publicación real y las enlacé de forma invisible para que las personas no hicieran clic. Es, por así decirlo, inundar la zona con basura al estilo Bannon.

  • He visto que se usa este enfoque, aunque no sé qué tan exitoso es. Lógicamente suena plausible.
    Se hace referencia explícita a rutas que una persona no puede ver realmente, y el tráfico que visita esas rutas se considera bot. Los bots no pueden resistirse.
  • Exacto. Pero hay que agregarlo sí o sí a robots.txt para que solo los robots malos salgan perjudicados.
  • Ayer leí esto y pensé en cómo mitigarlo a mayor escala. La idea sería que un sitio web genere rutas o endpoints virtuales aleatorios, lleve a los bots a una Library of Babel[0] servida localmente y contamine a las arañas con texto inútil.
    No funcionaría con sitios bien estructurados donde el bot conoce el endpoint exacto que quiere raspar, pero creo que podría ralentizar los hilos de arañas más exploratorios.
    [0] https://libraryofbabel.info/
  • En lugar de inundar con basura, ¿qué tal un sabotaje directo, como servir algo parecido a una bomba ZIP o hacerles desperdiciar recursos de cómputo?

• Soy de VideoLAN.
  A nosotros también nos están golpeando los foros y Gitlab los bots de empresas de IA.
  La mayoría no respeta robots.txt.

  • ¿Documentaron las medidas que tomaron para resolver esto?

• Es una locura. Me pregunto si al final terminaremos con una versión de la web que no esté indexada por motores de búsqueda, más parecida a la navegación de los 90, donde los sitios se conocían porque se enlazaban entre sí.
  Me gusta que la solución al scraping de LLM sea hacer que el navegador realice una prueba de trabajo antes de permitir el acceso. Me pregunto si los sitios nuevos empezarán a adoptar algo así.
  Entonces no quedarían indexados por los motores de búsqueda, pero ayudaría a proteger la propiedad intelectual.

  • ¡Hola! Yo estoy haciendo eso. Para más detalles, mira https://github.com/TecharoHQ/anubis.

• No lo había pensado hasta ahora, pero es una locura que las empresas que ofrecen tanto productos LLM como servicios de computación en la nube ganen por partida doble.
  Obtienen un producto LLM que pueden vender y, al mismo tiempo, también cobran los costos de tráfico saliente y de cómputo de la carga aumentada. Visto así, ¿qué incentivo tienen para preocuparse por el scraping ineficiente de los LLM? Cuanto más desordenado lo dejen, más ganan con otro de sus imperios: los costos de tráfico saliente del almacenamiento en la nube.