Cómo los bloqueadores evaden los scripts de detección: y qué pueden hacer los editores

Cuando los editores buscan bypass adblock detection, suelen encontrar dos conversaciones distintas a la vez. Un lado es el de los usuarios: personas con bloqueadores que quieren evitar los muros anti-adblock y los scripts de detección que los editores han instalado. El otro lado es el de los editores: personas cuyos scripts de detección han dejado de funcionar misteriosamente y necesitan entender por qué. Esta guía es el lado del editor, cómo los bloqueadores evaden la detección y qué se puede hacer al respecto.

La respuesta corta es que los bloqueadores modernos se mantienen activamente para derrotar los scripts de detección, no solo los anuncios. Tienen mecanismos dedicados a neutralizar el JavaScript del lado del editor que intenta observarlos. Entender esos mecanismos es el requisito previo para construir una detección que aguante en lugar de degradarse silenciosamente en semanas.

Hay tres vías de evasión principales: meter en una lista de filtros el script de detección para que nunca cargue, aprovechar el Manifest V3 para que el bloqueo no deje ninguna señal JavaScript observable, e inyectar scriptlets que neutralicen los vectores de detección que el script sí consigue ejecutar. Cada una requiere una estrategia de respuesta distinta.

La evasión más simple es meter el propio script de detección en una lista de filtros. EasyList, las listas suplementarias de uBlock Origin y el suplemento de AdGuard mantienen reglas que atacan no solo las URLs de anuncios sino también los scripts anti-adblock conocidos. Una vez que la URL de tu script de detección aparece en una lista de filtros pública, el bloqueador simplemente impide que cargue, y un detector que nunca carga no informa de nada. Desde tu panel el uso del adblock parece muy bajo; en realidad el detector está bloqueado.

Los elementos cebo están igual de expuestos. Un script de detección que crea un div con una clase como ad-banner y comprueba si el elemento fue ocultado depende de que un filtro cosmético se aplique. Pero si el nombre de la clase es estático y reconocible, se puede escribir una regla de lista de filtros que simplemente no aplique filtrado cosmético a ese cebo concreto, así que el elemento permanece visible, el detector no ve ningún ocultamiento e informa de que no hay bloqueador.

La defensa es una superficie en movimiento. Las clases e IDs de los elementos cebo deben aleatorizarse en cada carga de página, no ser cadenas estáticas que cualquier mantenedor de listas pueda copiar en una regla. El propio script de detección debe servirse desde una ruta firmada, anclada al origen y no predecible en lugar de una URL públicamente conocida. Los objetivos estáticos se listan; los objetivos aleatorizados no pueden capturarse con una regla fija.

El Manifest V3 de Chrome introdujo declarativeNetRequest, que traslada la decisión de bloqueo del JavaScript de la extensión a la capa de red nativa del navegador. uBlock Origin Lite, el sucesor MV3 del uBlock Origin clásico, bloquea por completo en este nivel. Nunca ejecuta JavaScript en la página, nunca toca el DOM y nunca lanza ningún evento que la página pueda observar, simplemente impide que ciertas peticiones se completen antes de que la página sepa que se hicieron.

Esto es una evasión directa del patrón de detección por cebo de DOM. Un elemento cebo cuyo src apunta a una ruta de anuncios no cargará, pero tampoco lanzará un evento onerror, porque el bloqueo ocurre antes de que el navegador procese la respuesta. Las comprobaciones basadas en tiempo ven una petición que resolvió al instante sin payload, lo que es difícil de distinguir de un servidor rápido. Muchos detectores heredados clasifican esto como 'no hay bloqueador' cuando la realidad es 'bloqueador MV3 activo'.

Las señales que sí sobreviven a MV3 son más sutiles. Una petición bloqueada de forma nativa tiene una huella de tiempo que difiere de un error de red real. Una petición redirigida a un recurso noop de la extensión devuelve un payload vacío identificable en lugar de un error real. Estas señales son reales y legibles, pero son invisibles para una simple comprobación de cebo y requieren sondas dedicadas de tiempo y huella de redirección para detectarlas.

Algunos bloqueadores van más lejos que simplemente bloquear u ocultar, inyectan scriptlets que se ejecutan dentro de la página y neutralizan activamente los vectores de detección. uBlock Origin y AdGuard admiten ambos inyección de scriptlets bajo Manifest V2. Los scriptlets pueden sobrescribir window.performance.now para reducir la resolución de tiempo, interceptar y suprimir las devoluciones de llamada de error de XMLHttpRequest, o normalizar el offsetHeight de los elementos ocultos a un valor no cero, de modo que las comprobaciones de cebo de DOM devuelvan falsos negativos aunque el bloqueador esté activo.

Estas contramedidas van dirigidas contra técnicas conocidas. Cuando un método de detección se vuelve lo suficientemente popular como para ser notado por un mantenedor de listas, se escribe un scriptlet contra él. El mantenedor publica el scriptlet; cada usuario con esa lista lo recibe en la siguiente sincronización; el vector de detección se apaga simultáneamente en toda esa base de usuarios. Este es el bucle adversario que hace que cualquier técnica única sea una ventaja de corta duración.

La implicación es que un detector con solo unos pocos vectores está a solo una regla de scriptlet de ser completamente neutralizado. Un ensemble que vota entre muchos vectores independientes, cada uno usando un mecanismo diferente, obliga a que el autor de una contramedida escriba y mantenga un scriptlet separado para cada uno. Ese es un coste mucho mayor que atacar un detector de un solo vector, y da a la detección una durabilidad considerablemente mayor.

Una detección resistente a la evasión necesita tres propiedades estructurales. Primera, una superficie en movimiento: elementos cebo, rutas de petición y nombres de variables que cambien en cada carga de página, de modo que ningún patrón fijo pueda ser listado. Un nombre que es diferente para cada visitante no tiene una forma canónica que pueda atacarse con una regla de filtro.

Segunda, un ensemble de vectores independientes. Los vectores deben usar mecanismos genuinamente distintos, observación de DOM, tiempo de red, huella de redirección noop, comprobaciones de assets autoalojados, sondas de API del navegador, de modo que no sean todos susceptibles a la misma contramedida. Cuando un vector se apaga, los demás siguen votando y el ensemble sigue alcanzando un veredicto fiable.

Tercera, reentrenamiento nocturno. Las listas de filtros, las versiones de bloqueadores y las bibliotecas de scriptlets cambian a diario. Un motor de detección que no se actualice contra esos cambios se queda obsoleto en semanas. AntiAdBlock Core reentrena sus heurísticas cada noche contra las deltas de EasyList, uBlock y AdGuard, de modo que cuando aparece una nueva contramedida las sondas se adaptan antes de que la tasa de detección caiga.

La guía de MV3 para editores en Chrome explica cómo Manifest V3 cambió el panorama de evasión para los usuarios de Chrome. Para ver cómo es la detección cuando todos estos escenarios están cubiertos, anti-adblock que funciona de verdad recorre el proceso de validación.