¿A quién bloquea realmente Anubis?

 (fzakaria.com)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Anubis, que exige una prueba de trabajo (Proof-of-Work) antes del acceso HTTP, impone un costo persistente mayor a los usuarios comunes, los dispositivos de bajos recursos y los clientes sin soporte de JavaScript que a los scrapers de IA
  • anubis-fetch, creado por un LLM, resuelve directamente la prueba de trabajo y, si hace falta, ejecuta Chromium; además imita la huella TLS/JA3 de Chrome para pasar incluso bloqueos manuales de Cloudflare
  • Los scrapers pueden cachear y reutilizar las cookies emitidas para amortizar el costo a lo largo de varias solicitudes, pero las personas deben asumir segundos de espera y consumo de batería en cada visita
  • La dificultad base 4 exige en promedio 65,536 hashes; una implementación nativa en Go tarda unos 1.3 ms, mientras que JavaScript en el navegador tarda unos 130 ms, pero la espera percibida real es de aproximadamente 1 a 5 segundos
  • Suponiendo 2 segundos de tiempo percibido y 20 J de energía por intento, 1 millón de desafíos diarios consumen al año alrededor de 23 años-persona y 2 MWh, y 100 millones al día consumen alrededor de 2,300 años-persona y 200 MWh

Anubis, evadido por la IA

  • Mientras trabajaba en un parche para soportar $ORIGIN en PT_INTERP del intérprete mediante bpf de binfmt_misc en el kernel de Linux, se le pidió a un LLM que leyera un hilo de la lista de correo del kernel de Linux
  • lore.kernel.org ya había incorporado el proxy HTTP Anubis, que exige una prueba de trabajo antes de permitir el acceso a recursos
  • El LLM creó anubis-fetch para manejar esa restricción
    • Primero resuelve la prueba de trabajo de forma nativa y, si falla, visita la URL con Chromium
    • Con req imita la huella TLS/JA3 de Chrome real y también pasa bloqueos manuales de Cloudflare
    • anubis-fetch <URL> envía el HTML a la salida estándar, y la opción --text entrega texto plano legible
  • La IA y los bots a los que Anubis apunta pueden evadirlo con facilidad una vez que agregan soporte para la prueba de trabajo
    • Los scrapers, tras resolver el desafío, pueden cachear y reutilizar la cookie recibida para amortizar el costo entre múltiples solicitudes
    • En cambio, las personas deben esperar el spinner y gastar batería en cada visita, sin poder compartir ese costo con otros usuarios
    • Cuanto más limitado sea el dispositivo o smartphone, mayor es la carga, y clientes que no usan JavaScript como w3m, lynx, lectores de pantalla y lectores RSS no pueden acceder
  • Un mecanismo pensado para frenar a la IA termina siendo fácil de evadir para la propia IA, mientras sigue imponiendo una carga regresiva a las personas y a la web abierta

El costo en tiempo y energía que genera la prueba de trabajo

  • La dificultad d es la cantidad de caracteres hexadecimales iniciales en 0 que debe tener el hash, y el trabajo esperado por resolución es W = 16^d hashes
    • El valor por defecto común, dificultad 4, exige 65,536 hashes
      • Implementación nativa en Go de unos 50 MH/s: ~1.3 ms
      • JavaScript en navegador de unos 0.5 MH/s: ~130 ms
      • Tiempo percibido, incluyendo carga de página, ejecución del worker y recarga: ~1 a 5 segundos
    • La dificultad 5 exige 1,048,576 hashes
      • Implementación nativa en Go: ~20 ms
      • JavaScript en navegador: ~2 segundos
      • Tiempo percibido: ~5 a 15 segundos
  • Se asume C como el número diario mundial de resoluciones de desafíos Anubis, tiempo percibido por intento t = 2 segundos y energía del dispositivo E = 20 J, incluyendo pantalla y CPU
    • El tiempo humano anual se calcula como C × t × 365 / 3.15×10⁷
    • La energía anual se calcula como C × E × 365 / 3.6×10⁶ kWh
  • Bajo estas suposiciones, el costo anual es el siguiente
    • 1 millón por día: alrededor de 23 años-persona y unos 2 MWh
    • 10 millones por día: alrededor de 230 años-persona y unos 20 MWh
    • 100 millones por día: alrededor de 2,300 años-persona y unos 200 MWh
  • Todas las cifras son estimaciones aproximadas, y no buscan argumentar un problema ambiental solo con este cálculo, ya que las granjas de bots y las herramientas de IA consumen varios órdenes de magnitud más energía
  • Para los robots, el tiempo no es una limitación, pero el tiempo de las personas sí es finito; por eso, los usuarios terminan dedicando colectivamente una cantidad significativa de tiempo a esperas para acceder a sitios web, algo que no existía antes de la era de la IA

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Lobste.rs

  • Cuesta coincidir con la idea de que Anubis apunta a algo que su objetivo puede neutralizar fácilmente. El objetivo principal de Anubis no es frenar agentes LLM ni programas hechos con vibe coding, sino detener a los scrapers web indiscriminados que usan las empresas de LLM
    Puede haber formas de evadirlo y también se pueden usar agentes o LLM, pero la mayoría de los scrapers son simples y sus operadores tampoco intentan necesariamente saltarse Anubis en el pequeño número de sitios que lo implementan. El objetivo está más cerca de subir un poco el costo de evasión para que deje de valer la pena recolectar datos

    • Anubis probablemente funcione bien para evitar situaciones en las que scrapers que usan proxies residenciales saturan el servidor. Las solicitudes de agentes individuales no son muy distintas de que un usuario recorra el sitio por su cuenta
      Aun así, para ese propósito Anubis está sobrediseñado. También se podría lograr el mismo efecto de protección haciendo que el usuario pulse un botón una vez y luego emitiendo una cookie de acceso; al implementarlo en Apache, funcionó lo bastante bien incluso sin una prueba de trabajo compleja
    • Más que los scrapers de empresas de LLM, el objetivo son los scrapers web toscos y abusivos en general. Solo se supone que una parte de ellos es operada por compañías de LLM
    • El aumento de tráfico en los sitios web viene de otros actores, no de lugares como OpenAI, Anthropic o Meta, así que no está claro qué se define como empresa de LLM
      Incluso en mi trabajo de minería de datos, las herramientas modernas de scraping son tan buenas que esquivan casi todos los obstáculos, y Anubis también se puede evadir con facilidad
    • También quiero bloquear el acceso tipo RAG a sitios personales y software, así que aplico un bloqueo básico por user-agent. Probé pidiéndole a ChatGPT que accediera directamente al sitio y lo bloqueó bien
      Algunas configuraciones muy específicas pueden colarse, pero el objetivo no es detener a un adversario malicioso, sino a uno perezoso
    • Lo que Anubis bloquea principalmente son scrapers rudimentarios en Python requests que se disfrazan torpemente de Chrome; cualquier otro efecto de bloqueo es casi un extra

  • Anubis no filtra bots; limita la velocidad de las solicitudes del cliente

  • Más que bloquear el acceso de agentes de IA, Anubis se parece a una herramienta de defensa contra ataques de denegación de servicio, y en la práctica también es difícil identificar y bloquear agentes de IA
    Pero junto con ellos también bloquea a usuarios como yo, que visitan sitios desconocidos desde dispositivos móviles con JavaScript desactivado

  • Viendo cómo funciona en operación real, cuesta estar de acuerdo con la conclusión del artículo. Serví el sitio web de mi homelab con un proxy público de fly.io y reenvío de Tailscale, y por scrapers como el de Facebook terminé pagando unos 20 dólares mensuales de ancho de banda
    Después de aplicar Anubis al proxy, volví al nivel gratuito. Aunque se pueda evadir si alguien lo necesita, está bien; basta con bloquear la mayor parte del tráfico de recolección masiva de unos pocos actores maliciosos que ignoran robots.txt

  • En trabajos de scraping que aprovechan botnets de dispositivos de bajos recursos, como Smart TV, la prueba de trabajo de Anubis sí podría ser un obstáculo real. Este problema también se menciona un poco en https://lobste.rs/s/kpaxih/update_on_scraper_situation

    • Si no estoy equivocado, las Smart TV solo se usan como proxy, y no realizan la prueba de trabajo en sí

  • Lo que más me preocupa de Anubis es su choque con la web abierta. Mi sitio web se consume sobre todo por feed RSS, pero si protejo el RSS con Anubis el feed deja de funcionar, y si no lo protejo, todo el contenido queda expuesto a scrapers en un formato fácil de leer por máquinas
    Este tipo de barrera de prueba de trabajo es, en el fondo, difícil de reconciliar con la web abierta o la indieweb que queríamos

    • Durante el último año he estado atrapado entre estas concesiones imposibles, y yo tampoco he encontrado una buena respuesta

  • Se nota abiertamente una actitud de no respetar las decisiones que tomaron otras personas

  • Lo más desagradable es que esto parece una violación evidente de leyes como la CFAA, y aun así ocultan su identidad, como otros servicios DDoS de carácter criminal
    Ya es ridículo esperar que una empresa cuyo modelo de negocio entero depende de robar el trabajo ajeno y blanquear código open source vaya a cumplir la ley

  • Anubis normalmente no bloquea Dillo, pero según la configuración del sitio puede hacerlo, y eso alimenta mucho la idea de que si no tienes JavaScript, ni siquiera mereces existir: https://paste.rs/jNgwd.png
    Estoy pensando si sería posible recopilar y mantener una lista de todas las IP incluidas en proxies residenciales y bloquearlas por cierto tiempo; quizá ipset pueda manejar algo de este tamaño. Según los logs, los bots no cargan otros recursos como CSS o imágenes y en cambio recorren todos los archivos de todos los commits del repositorio de Dillo, así que son relativamente fáciles de identificar
    Aunque en cada sitio solo se vea una solicitud por IP, es probable que la misma IP esté trayendo varios sitios, así que se podrían bloquear las IP denunciadas repetidas veces. En lugar de simplemente cortar la conexión, habría que redirigirlas a una página informativa en otro puerto para explicar por qué fueron bloqueadas y cómo resolverlo
    Eso también reduciría el incentivo para incrustar backdoors de proxy inverso en extensiones de navegador o apps móviles. Porque los usuarios empezarían a quedar realmente bloqueados
    Es una pena tener que depender de un sistema de reputación de IP, pero no se ven muchas otras respuestas efectivas. Los dispositivos vulnerables, incluso si se elimina el servidor de comando y control de la botnet, pueden ser comprometidos de nuevo por el siguiente atacante y terminar en otra botnet

  • En el artículo se decía: “por supuesto, estoy haciendo esto con ayuda de un LLM”; entonces me pregunto por qué no le pusieron la etiqueta de vibe coding

    • Así como no le pondrías esa etiqueta porque el autor usó un compilador o un editor, no corresponde aquí porque el tema de este texto no es el vibe coding. La etiqueta vibecoding la quitó pushcx
    • Al publicarlo, el texto decía explícitamente que se había hecho con vibe coding algo para evadir el bloqueo, así que le puse esa etiqueta. Me sorprende que la hayan eliminado, porque a veces se etiqueta incluso contenido que menciona menos la programación con IA que este, así que termino aceptando que el criterio para aplicar esta etiqueta no es nada consistente