Los Creepy Crawlies de Kernel.org están convirtiendo el acceso abierto en un impuesto a la CPU
Konstantin Ryabitsev afirma que los creepy crawlies mantienen ahora ocupados entre 14 y 16 núcleos de CPU en git.kernel.org, pese a las defensas diseñadas para encarecer el scraping automatizado. Los rastreadores solicitan millones de páginas individuales de commits en lugar de clonar los repositorios Git subyacentes. Esa decisión convierte un archivo público eficiente en un servicio permanente de generación de HTML para máquinas no identificadas.
Ryabitsev, administrador de sistemas de la Linux Foundation involucrado en la infraestructura de kernel.org, publicó las cifras el 29 de agosto de 2026. Simon Willison las destacó el 7 de septiembre porque Datasette presenta un perfil de riesgo similar. Puede exponer una base de datos mediante una enorme colección de páginas útiles y rastreables.
La historia inmediata afecta a la infraestructura de Linux, pero el conflicto va mucho más allá. Los archivos técnicos abiertos fueron diseñados para ayudar a las personas a inspeccionar, consultar y preservar información. Los clientes a escala de máquina pueden convertir esa apertura en una obligación informática sin precio.
El contraste es particularmente marcado en git.kernel.org. Sus mantenedores ya ofrecen el historial completo de repositorios mediante Git, un protocolo creado para transferir ese historial de forma eficiente. Sin embargo, según los informes, los scrapers están tomando la ruta computacionalmente costosa: solicitan páginas renderizadas por separado para commits, parches y diffs.
Ese comportamiento presiona a los mantenedores para restringir interfaces que los desarrolladores legítimos utilizan. El servicio sigue respondiendo, según Ryabitsev, pero ya está desactivando funciones y colocando más acciones detrás de controles de acceso. Por tanto, el coste del aumento de rastreadores se mide tanto en apertura perdida como en tiempo de CPU.
Los Creepy Crawlies generan seis millones de solicitudes diarias
La escala es lo bastante grande como para consumir infraestructura de forma continua, incluso cuando el sitio parece funcionar correctamente para los visitantes humanos.
Las mediciones de rastreadores de Ryabitsev describen unos 6 millones de solicitudes diarias de commits aparentemente aleatorios. Anubis, un desafío de navegador situado antes del sitio principal, rechaza de inmediato cerca del 66 % de esas solicitudes. Otro 33 % resuelve el desafío y continúa hacia git.kernel.org.
Las cifras no demuestran que todas las solicitudes sometidas al desafío procedan de una empresa de IA. Ryabitsev dice explícitamente que los operadores no pueden identificar con certeza a cada cliente. Una persona puede abrir un commit antiguo, mientras que un bot puede imitar un navegador actual.
Los patrones de solicitudes aportan la evidencia más sólida. Un cliente que recorre commits no relacionados en forks antiguos e inactivos no se parece a un desarrollador que sigue una serie de parches. Ryabitsev estima que la actividad legítima representa cerca del 2 % del tráfico total, incluso tras utilizar supuestos favorables a los usuarios.
La carga de trabajo resultante ocupa entre 14 y 16 de los 90 núcleos de CPU repartidos entre cinco nodos distribuidos geográficamente. Esto equivale, de media, a aproximadamente el 20 % de la capacidad total de procesamiento del servicio. La demanda real llega en oleadas, por lo que la carga es menos ordenada que una asignación fija del 20 %.
Esos núcleos realizan una tarea limitada. Transforman objetos Git en páginas HTML para clientes que después analizan la salida renderizada. Ryabitsev afirma que esta actividad consume más tiempo de CPU que todas las formas de acceso legítimo combinadas, incluidos los clones de Git.
La distinción importa porque un clon transfiere un repositorio mediante el modelo nativo de objetos de Git. El cliente recibe el historial y puede recorrer los commits localmente. El servidor evita reconstruir una página de presentación para cada objeto que el cliente desea inspeccionar.
Las solicitudes HTML invierten esa eficiencia. Cada solicitud pide al servidor localizar datos del repositorio, ejecutar cgit y construir una respuesta legible para humanos. El cliente descarta gran parte de la interfaz circundante después de extraer el texto que busca.
Repetida a través de millones de URL, una página razonable por sí sola se convierte en un costoso endpoint para máquinas. La planificación tradicional de capacidad suele tratar las visualizaciones de página como unidades de trabajo comparables. El caso de git.kernel.org muestra por qué ese modelo falla cuando una URL puede desencadenar mucho más procesamiento que otra.
El servicio no ha colapsado bajo la carga actual de fondo. Ryabitsev afirma que los sistemas de integración continua mal diseñados todavía pueden provocar interrupciones más graves, especialmente cuando muchos nodos realizan clones superficiales simultáneos. El tráfico de rastreadores crea un problema diferente porque elimina permanentemente el margen operativo.
Ese margen perdido reduce la tolerancia a picos de tráfico, eventos de mantenimiento y automatización legítima. También obliga a los operadores a dedicar tiempo a estudiar comportamientos adversariales en lugar de mejorar los servicios para los desarrolladores del kernel. Por tanto, un sitio web aparentemente estable puede acarrear un coste oculto considerable.
El cambio crucial no es que el código fuente público pueda descargarse. Kernel.org respalda deliberadamente ese uso. El cambio es que clientes no identificados están eligiendo una representación costosa y exigiéndola a escala industrial.
Git hace que los datos sean baratos, pero HTML los encarece
El conflicto central no es acceso frente a secreto. Es acceso masivo eficiente frente a extracción derrochadora página por página.
El desarrollo de Linux siempre se ha beneficiado de la replicación. Los repositorios Git se pueden clonar, los archivos de listas de correo se pueden copiar y los espejos pueden preservar material más allá de la vida de un único servidor. Kernel.org fomenta esa redundancia en lugar de tratar cada descarga como una amenaza.
Git hace que este modelo sea económico al transferir objetos según sus relaciones. Un repositorio almacena commits, árboles y contenidos de archivos como objetos direccionables. El cliente y el servidor negocian qué objetos le faltan al cliente y luego transfieren los datos necesarios sin recrear una página web alrededor de cada commit.
La interfaz web cumple otro propósito. Ayuda a un desarrollador a inspeccionar un cambio, compartir un enlace estable, comparar revisiones o descargar un parche sin clonar un repositorio grande. cgit, la interfaz utilizada por git.kernel.org, ofrece varias vistas porque cada una respalda un flujo de trabajo humano legítimo.
Estas opciones también multiplican la superficie rastreable. El repositorio principal de Linux contiene unos 1,48 millones de commits, según el recuento de Ryabitsev. Git.kernel.org aloja cerca de 922 forks que comparten en gran medida los mismos objetos subyacentes.
Por tanto, un rastreador puede descubrir muchas URL que llevan a contenido de commits duplicado. También puede solicitar vistas de parches, renderizados de texto plano, árboles de repositorios y comparaciones arbitrarias. El contenido es finito, pero el espacio posible de URL se vuelve mucho mayor.
Este es un modo de fallo conocido en sitios web respaldados por bases de datos. Una base de datos puede contener una cantidad manejable de registros mientras su interfaz permite innumerables combinaciones de filtros, ordenación, paginación y comparación. Cada ruta generada parece otro documento para un rastreador indiscriminado.
Willison vinculó ese patrón con Datasette, su herramienta de código abierto para publicar bases de datos consultables en la web. Una instancia de Datasette puede convertir información estructurada en páginas navegables y resultados de consulta. Esa accesibilidad es valiosa para personas, motores de búsqueda, investigadores y herramientas de asistencia.
También puede exponer combinaciones costosas de parámetros. Un bot no necesita código malicioso para generar una carga dañina. Solo necesita enumerar enlaces o construir URL válidas más rápido de lo que la aplicación puede atenderlas de forma económica.
El mismo riesgo se aplica a sistemas de documentación, rastreadores de incidencias, navegadores de código, portales de registros públicos y archivos personales. Los sitios que transforman datos estructurados bajo demanda son más vulnerables que las páginas estáticas porque cada consulta puede activar trabajo de base de datos o renderizado del lado del servidor.
La caché ayuda cuando muchos clientes solicitan el mismo recurso. Ayuda menos cuando los rastreadores distribuyen deliberada o accidentalmente las solicitudes entre URL únicas. Los parámetros de consulta, los diffs arbitrarios y los forks antiguos pueden frustrar la reutilización que hace valiosa a una caché.
Los operadores pueden prerenderizar páginas populares, pero prerenderizar cada comparación posible es imposible. También pueden ofrecer exportaciones masivas, pero un rastreador diseñado alrededor de enlaces web quizá nunca descubra ni elija la ruta eficiente. La disponibilidad técnica no garantiza un comportamiento sensato por parte del cliente.
Para los desarrolladores que crean archivos consultables, esto es una advertencia arquitectónica. El acceso de máquinas debería usar API acotadas, feeds, exportaciones o protocolos de repositorio siempre que sea posible. Las interfaces humanas necesitan límites que reflejen el coste de generar cada respuesta.
Los equipos que documenten estas decisiones también deberían conservar las decisiones operativas junto al código. Una base de conocimiento de ingeniería consultable puede conectar políticas de rastreadores, rutas costosas y evidencia de incidentes antes de que llegue otra oleada de tráfico.
El incidente de kernel.org demuestra que el ancho de banda es solo una parte de la factura. El tiempo de CPU, la rotación de caché, los costes de observabilidad y la atención de los operadores pueden predominar cuando los clientes automatizados solicitan repetidamente representaciones dinámicas.
Anubis elevó el precio hasta que los rastreadores lo pagaron
La prueba de trabajo redujo temporalmente el tráfico abusivo, pero los rastreadores persistentes se adaptaron porque los datos subyacentes seguían siendo valiosos.
Kernel.org utilizó primero defensas conocidas. Los operadores identificaron cadenas sospechosas de user-agent, inspeccionaron registros y bloquearon direcciones asociadas a una recopilación automatizada evidente. Ese enfoque funcionaba mientras los rastreadores se identificaban o procedían de un conjunto manejable de redes.
Después, el tráfico se volvió más difícil de clasificar. Ryabitsev describe clientes que afirman ser navegadores normales y distribuyen las solicitudes entre subredes de nube. Bloquear toda una red podía detener el abuso, pero también podía negar comprobaciones automatizadas legítimas alojadas por el mismo proveedor.
El siguiente cambio debilitó aún más los controles basados en direcciones. Las solicitudes comenzaron a llegar desde un gran número de direcciones residenciales y móviles. Cada dirección generaba solo cuatro o cinco solicitudes antes de desaparecer de los registros, según Ryabitsev.
Este patrón se parece a las redes proxy que enrutan tráfico a través de dispositivos de consumidores. Un sitio ve lo que parece una amplia población de usuarios no relacionados en lugar de una operación de scraping concentrada. Para cuando una dirección parece sospechosa, esa fuente concreta quizá no vuelva nunca.
Kernel.org respondió con Anubis, un firewall web de código abierto que desafía a los clientes antes de permitirles llegar a un servicio ascendente. Su mecanismo central es la prueba de trabajo, una pequeña tarea matemática que resulta relativamente costosa para el cliente, pero barata de verificar para el servidor.
El proyecto Anubis describe el software como una defensa para servicios de internet pequeños que enfrentan tráfico sostenido de rastreadores de IA. Sus mantenedores también lo califican como una respuesta severa porque los desafíos pueden bloquear pequeños scrapers y bots legítimos de archivado.
En git.kernel.org, el desafío cambió inicialmente la economía. Los clientes automatizados dejaron de intentar el acceso, mientras que los visitantes humanos aceptaron una demora modesta. Ese periodo duró varios meses.
Más tarde, los bots comenzaron a resolver el nivel de dificultad cuatro. Los operadores elevaron el desafío al nivel cinco, que exigía más computación del cliente. Ryabitsev afirma que esa configuración puede tardar varios segundos en un dispositivo móvil y hacer que el teléfono se caliente de forma perceptible.
La mayor dificultad volvió a proporcionar varios meses de margen. También impuso un coste más alto a cada visitante legítimo que recibía el desafío. La accesibilidad se resiente cuando el hardware antiguo, los navegadores centrados en la privacidad, JavaScript desactivado o conexiones inestables no pueden completar el flujo previsto.
Los rastreadores acabaron resolviendo también el nivel cinco. En el momento del informe de Ryabitsev, aproximadamente un tercio de los 6 millones de solicitudes diarias de commits superaba el desafío. La prueba de trabajo no se había vuelto inútil, ya que seguía deteniendo a los otros dos tercios, pero ya no restablecía el equilibrio anterior.
Este resultado expone la debilidad central de la disuasión económica. Un desafío solo funciona mientras el coste supera el valor esperado para el raspador. Un historial técnico limpio y valioso da a los recolectores una razón para gastar más recursos.
Ryabitsev sostiene que el historial de commits de Linux resulta especialmente atractivo porque gran parte de él es anterior a la proliferación del texto generado. A los investigadores les preocupa que el entrenamiento repetido con material sintético pueda degradar la calidad de los modelos o amplificar artefactos. Eso convierte los registros técnicos bien estructurados y producidos por humanos en material de entrenamiento deseable.
Las identidades y propósitos exactos de los clientes siguen sin verificarse. Algunos pueden respaldar el entrenamiento de modelos, mientras que otros podrían crear índices de búsqueda, conjuntos de datos de código, productos de seguridad o archivos comerciales. Desde el punto de vista operativo, su comportamiento compartido importa más que la etiqueta.
El desarrollador de Anubis, Xe Iaso, también ha reconocido que la prueba de trabajo no es una respuesta completa. En una discusión técnica, Iaso explicó que el mecanismo apunta a la economía del raspado masivo, pero expresó escepticismo sobre sus beneficios frente a clientes distribuidos capaces.
Un cliente con automatización de navegador puede ejecutar JavaScript, almacenar cookies y resolver el mismo desafío público que una persona. Los clientes distribuidos pueden repartir el trabajo entre muchos dispositivos. Aumentar la dificultad entonces corre el riesgo de castigar a los visitantes legítimos más rápido de lo que disuade a los recolectores con buenos recursos.
La experiencia de Kernel.org confirma esa disyuntiva con datos de producción. La defensa tuvo éxito, los clientes adversarios se adaptaron y los operadores aumentaron el coste. La contienda no terminó porque tanto el atacante como el defensor tenían otro ajuste que modificar.
Los archivos abiertos se ven obligados a eliminar funciones útiles
El resultado más perjudicial no es una factura de servidor más alta. Es el retroceso gradual del acceso anónimo y fácil de usar para las personas.
Kernel.org planea reducir el número de URL rastreables y restringir operaciones costosas de ejecutar. Ryabitsev advierte que los usuarios anónimos deben esperar que desaparezca parte de la funcionalidad. Los datos subyacentes seguirán disponibles para descargar, pero obtenerlos puede requerir pasos adicionales.
Esa respuesta es racional para un operador de infraestructura. Si una interfaz genera una carga desproporcionada, restringirla protege el resto del servicio. Los clones de Git y los flujos de trabajo de los desarrolladores son más importantes que la representación anónima e ilimitada de comparaciones arbitrarias.
Sin embargo, cada restricción cambia quién puede usar el archivo. Un desarrollador con Git instalado puede clonar un repositorio e inspeccionarlo localmente. Un estudiante que sigue un enlace, un periodista que verifica un commit o una persona que usa un dispositivo limitado puede depender de la interfaz del navegador.
Las herramientas automatizadas de investigación también pueden tener fines legítimos. La indexación de búsqueda ayuda a los usuarios a encontrar correcciones antiguas. Los sistemas de archivo conservan pruebas. Los servicios de seguridad correlacionan commits con vulnerabilidades. Las herramientas de accesibilidad pueden recuperar páginas de formas que no se parecen a la navegación convencional.
Las restricciones amplias no pueden separar limpiamente a estos clientes de los recolectores abusivos. La autenticación genera responsabilidad, pero añade trabajo administrativo. Los límites de tasa reducen los picos, pero pueden fallar cuando las solicitudes llegan desde direcciones distribuidas.
Bloquear redes residenciales excluiría a hogares reales. Bloquear proveedores de nube interferiría con la automatización de desarrolladores. Exigir prueba de trabajo hace que cada visitante gaste electricidad y tiempo antes de que el servidor sepa si la solicitud es útil.
Robots.txt proporciona una señal de política, pero no es un mecanismo de control de acceso. El estándar oficial de robots establece que sus reglas no constituyen autorización. Los rastreadores cooperativos siguen las preferencias declaradas, mientras que un cliente no identificado puede ignorarlas o hacerse pasar por un navegador.
El resultado es una asimetría. Las organizaciones responsables identifican sus rastreadores, publican documentación, respetan exclusiones y se vuelven fáciles de bloquear. Los recolectores menos responsables ocultan su identidad y distribuyen el tráfico, lo que dificulta detenerlos.
Esto puede producir un resultado perverso en el que los rastreadores cumplidores pierden acceso mientras los evasivos continúan. También hace que la atribución del tráfico sea poco fiable. Los operadores pueden describir razonablemente una clase de comportamiento como raspado por IA sin poder conectar las solicitudes con un desarrollador de modelos identificado.
Esa incertidumbre es el principal motivo de escepticismo en esta historia. Las mediciones de tráfico de Ryabitsev son evidencia operativa directa, pero el propósito detrás de cada solicitud no se ha establecido de forma independiente. La estimación del 98% se refiere a un comportamiento aparente de raspado, no a una lista verificada de empresas de IA.
La distinción debería orientar tanto la política como la información periodística. Sería inexacto atribuir toda la carga a un proveedor específico sin evidencia de red. Sería igualmente inexacto desestimar el problema porque todos los clientes carecen de una identidad pública.
El daño medible existe en la capa de aplicación. Millones de solicitudes seleccionan commits antiguos, forks duplicados y representaciones costosas. Un desafío defensivo detiene muchas solicitudes, pero volúmenes considerables pagan el peaje computacional y continúan.
Cloudflare ha abordado el problema más amplio ofreciendo a los propietarios de sitios controles más granulares para rastreadores de búsqueda, agentes y entrenamiento. Sus controles de tráfico de IA reflejan una distinción importante, porque un rastreador de entrenamiento de modelos y un asistente solicitado por un usuario no tienen el mismo propósito.
Las grandes redes perimetrales pueden combinar inteligencia de direcciones, señales del navegador, historial de tráfico y observaciones de toda su base de clientes. Los pequeños servicios de código abierto rara vez disponen de esa visibilidad. Deben tomar decisiones con registros locales e identificadores imperfectos.
Esa brecha concentra el daño en las organizaciones menos capaces de absorberlo. Una gran plataforma comercial puede comprar más capacidad e implementar gestión especializada de bots. Un proyecto voluntario, un archivo académico o un editor independiente puede simplemente cerrar rutas costosas.
La web abierta pierde entonces más que unas pocas funciones de interfaz. Pierde la premisa de que publicar información útil y enlazable es económicamente seguro. Las páginas siguen siendo técnicamente públicas, pero el acceso pasa a ser condicional, sujeto a desafíos o disponible solo mediante flujos de datos masivos.
El conflicto real es entre apertura y computación sin precio
Los datos abiertos no exigen que toda representación posible siga siendo gratuita, anónima e ilimitada.
El debate ético sobre el rastreo suele centrarse en el permiso para copiar contenido. Kernel.org añade una segunda pregunta: ¿quién debe pagar para transformar ese contenido al formato que prefiere un recolector?
Los repositorios de Linux ya están disponibles mediante un mecanismo eficiente de transferencia. Los operadores no ocultan el historial ni exigen control exclusivo sobre él. Se oponen a clientes que hacen que el servicio público calcule repetidamente una representación más costosa.
Esa diferencia separa el caso de un simple debate sobre restringir el conocimiento. Un clon eficiente permite que un recolector asuma gran parte del coste de procesamiento tras la transferencia. El raspado HTML commit por commit traslada trabajo repetido a la fuente.
Un recolector responsable debería buscar primero exportaciones masivas, acceso al repositorio, feeds, mapas del sitio o API documentadas. Debería almacenar en caché el material recuperado, deduplicar forks y evitar combinaciones arbitrarias de parámetros. También debería identificarse y ofrecer un canal de contacto funcional.
La negociación de tasas también importa. Un rastreador que necesita un volumen inusual puede pedir a un operador un espejo o una exportación programada. Kernel.org afirma que pretende seguir proporcionando datos a quienes los soliciten, incluso mientras las interfaces anónimas se vuelven más restrictivas.
Estas prácticas parecen elementales porque los motores de búsqueda maduros las desarrollaron durante décadas. La demanda de IA ha ampliado el número de organizaciones que recopilan conjuntos de datos a escala web. No todos los equipos parecen haber heredado las mismas normas operativas.
Los incentivos también difieren. Un recolector que compite por adquirir material escaso anterior a la IA se beneficia de moverse con rapidez. El coste de una recopilación ineficiente recae sobre miles de operadores de sitios no relacionados. Sin contratos, aplicación de normas o identidad fiable, el rastreador no paga automáticamente ese coste externo.
La prueba de trabajo intenta trasladar parte del gasto de vuelta al solicitante. Los resultados de git.kernel.org muestran tanto el atractivo como el límite de ese modelo. Eleva el coste marginal, pero no puede distinguir una solicitud humana valiosa de una automatizada valiosa.
Cobrar por rastreo crea otra posible vía, pero el pago por sí solo no resuelve el diseño del sistema. Un rastreador aún puede sobrecargar un endpoint dinámico si los precios, las cuotas y los controles de capacidad están mal alineados. Los sitios pequeños también carecen de los sistemas de facturación necesarios para negociar el acceso de máquinas.
Una mejor detección mediante protocolos ayudaría. Una página legible por máquinas podría dirigir a los recolectores hacia un clon de repositorio, un archivo comprimido o una exportación de datos acotada. Los rastreadores seguirían necesitando incentivos o requisitos para respetar esa indicación.
El diseño de aplicaciones puede reducir la exposición antes de que llegue el tráfico. Los desarrolladores pueden limitar el tamaño de los resultados, rechazar comparaciones poco razonables, canonicalizar URL equivalentes y asignar límites independientes a rutas costosas. Pueden precalcular vistas comunes y exigir autenticación para consultas inusuales.
La observabilidad debe medir el trabajo, no solo las solicitudes. Un millón de respuestas estáticas almacenadas en caché puede costar menos que unos pocos miles de consultas de base de datos sin caché. Los operadores necesitan tiempo de CPU por ruta, efectividad de caché, tasas de finalización de desafíos y comportamiento de clientes agrupado entre direcciones.
La cuestión de política más profunda se refiere a la identidad exigible. Un rastreador que declara su operador y propósito puede recibir acceso adaptado. Un cliente distribuido que finge ser millones de navegadores impide la negociación y convierte cada solicitud en una decisión de confianza.
Hasta que mejore la identidad, los sistemas defensivos dependerán de inferencias de comportamiento. Eso significa que los falsos positivos seguirán siendo inevitables. El coste humano debe seguirse con la misma seriedad que el tráfico bloqueado, porque una protección que excluye a usuarios reales puede socavar el servicio que preserva.
Por tanto, los rastreadores inquietantes representan un fallo de gobernanza tanto como un problema de tráfico. La web tiene normas para el comportamiento voluntario de los rastreadores, pero carece de un marco fiable para clientes a escala de máquinas que ignoran esas normas.
Tres señales mostrarán si la presión se está aliviando
La siguiente fase se medirá mediante el comportamiento del tráfico, la funcionalidad perdida y una mejor rendición de cuentas de los rastreadores.
La primera señal es la tasa de aprobación del desafío de git.kernel.org. Cerca del 33% de las solicitudes aleatorias de commits superaban Anubis cuando Ryabitsev publicó sus cifras. Un descenso sostenido sugeriría que los nuevos controles restauraron la presión económica o mejoraron la clasificación de clientes.
Una tasa de aprobación estable o creciente apuntaría en la dirección contraria. Mostraría que los recolectores siguen valorando los datos lo suficiente como para absorber cada aumento defensivo. Otro incremento en la dificultad del desafío también revelaría que la contienda sigue centrada en el coste, no en la identidad.
La segunda señal es la cantidad de funcionalidad anónima que kernel.org elimine. Las restricciones limitadas a comparaciones inusualmente costosas respaldarían una respuesta focalizada. Pérdidas más amplias en vistas ordinarias de commits, parches o navegación mostrarían que la presión de los rastreadores está cambiando la experiencia pública.
Los operadores deberían documentar qué desaparece y por qué. Ese registro ayudaría a otros proyectos a identificar patrones de URL peligrosos antes de llegar al mismo punto. También revelaría si las defensas preservan los flujos de trabajo humanos habituales que pretendían proteger.
La tercera señal es si los principales operadores de crawlers adoptan identidades verificables y rutas de adquisición eficientes. Rangos de direcciones publicados, agentes de usuario específicos para cada propósito, información de contacto y políticas de límites de solicitudes exigibles permitirían a los sitios distinguir la automatización cooperativa del scraping evasivo.
Sin esa rendición de cuentas, el mercado de las defensas seguirá avanzando hacia la identificación por huella del navegador, los controles perimetrales gestionados, la autenticación y el acceso de pago. Estas herramientas pueden proteger la capacidad, pero también complican la publicación independiente.
Para los desarrolladores, la acción inmediata consiste en revisar qué rutas públicas consumen más CPU y cuántas URL distintas exponen el mismo registro subyacente. Prueben si un cliente masivo puede obtener la misma información mediante una interfaz más económica.
Publiquen esa ruta con claridad y, después, impongan presupuestos estrictos a la generación dinámica de HTML. Supervisen por separado las tasas de finalización de proof-of-work y los fallos de usuarios legítimos. Una defensa debería reducir el cómputo abusivo sin convertir a cada lector en daño colateral.
Para quienes desarrollan IA, la decisión responsable es más sencilla. Utilicen la representación autorizada de menor coste, identifiquen el crawler, respeten la política del sitio y contacten a los operadores antes de escalar. El acceso abierto es una invitación a utilizar conocimiento compartido, no un derecho ilimitado sobre los procesadores de otras personas.
Los creepy crawlies de git.kernel.org han hecho visible ese límite. La web abierta puede admitir lectores automáticos, pero solo si esas máquinas dejan de tratar cada URL pública como capacidad de cómputo gratuita.
