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 no presentar nada estático que una lista pueda capturar: cualquier cosa fija y pública, un nombre de clase, una ruta, una URL de script, acaba listada y deja de funcionar. Hacerlo de forma fiable, y que siga funcionando a medida que cambian las listas, es ingeniería continua y no un ajuste, y esa es la razón de fondo por la que un servicio mantenido aguanta donde un script de copiar y pegar no.

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 solo bloquear u ocultar, inyectan pequeños scripts que se ejecutan dentro de la página y neutralizan activamente las comprobaciones de un detector para que informe de que no hay bloqueador aunque lo haya. uBlock Origin y AdGuard lo admiten bajo Manifest V2. Lo importante para un publisher no es la mecánica sino la consecuencia: cualquier método de detección que se vuelve lo bastante común acaba con una contramedida dedicada escrita contra él.

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 señales independientes que se apoyan en mecanismos genuinamente distintos, de modo que no todas sean susceptibles a la misma contramedida. Cuando una se apaga, las demás siguen votando y el veredicto sigue siendo fiable. Construir y equilibrar ese ensemble es trabajo especializado, no un snippet.

Tercera, mantenimiento constante. Las listas de filtros, las versiones de bloqueadores y las contramedidas cambian a diario, así que un motor de detección que no se mantiene al día queda obsoleto en semanas. AntiAdBlock Core se mantiene al día frente a las principales listas de filtros, de modo que cuando aparece una nueva contramedida la detección se adapta antes de que la tasa 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.