Navegadores Chromium parcheados: explicación

¿Qué es un navegador Chromium parcheado?

Un navegador Chromium parcheado es un build de Chromium cuyo código fuente se ha modificado para eliminar las huellas que lo identifican como un navegador automatizado. Los cambios van compilados. Cuando el binario arranca, las señales que normalmente lo delatarían ya no están: variables inyectadas, flags reveladores, propiedades del runtime fuera de lugar.

Es distinto de los plugins stealth como puppeteer-extra-stealth, que sobrescriben propiedades con JavaScript al cargar la página. Los shims en runtime dejan su propio rastro. Los builds parcheados no, porque aquello que se iba a sobrescribir nunca estuvo ahí.

Los proyectos más usados son undetected-chromedriver, rebrowser-patches, Patchright (un fork de Playwright), nodriver y, en el lado de Firefox, camoufox. La premisa compartida: arreglar el leak en C++, no en JavaScript. Desde que Chrome unificó sus bases de código headful y headless en noviembre de 2022, buscar la cadena `HeadlessChrome` en el user-agent ya casi no atrapa nada (Castle, 2025).

Por qué Headless Chrome vanilla se detecta

Si lanzas Puppeteer o Selenium con la configuración por defecto contra un sitio con detección real, pierdes. `navigator.webdriver` es `true` por especificación cuando una herramienta de automatización controla el navegador, y cualquier JavaScript en la página lo lee en una línea. El string `$cdc_asdjflasutopfhvcZLmcfl_` que ChromeDriver inyecta en cada página es igual de fácil de detectar con una regex (DataDome, 2024). A eso se suman las propiedades del runtime que difieren entre un navegador real y uno controlado: plugins que faltan, `navigator.languages` vacío, `screen.colorDepth` incorrecto, ausencia de `window.chrome`.

Arreglar cada uno de estos leaks es un cambio de una línea. Por eso un navegador parcheado se monta en aproximadamente una hora, y por eso con esa hora solo se superan las comprobaciones de un sistema de detección de 2019. Los sistemas modernos miran otra cosa.

La señal real vive en el Chrome DevTools Protocol

Puppeteer, Playwright y Selenium hablan con Chromium por el mismo canal: el Chrome DevTools Protocol (CDP), una interfaz WebSocket para depuración. Alrededor del 95 % de las acciones automatizadas terminan pasando por `Page.evaluate`, la forma en que CDP ejecuta JavaScript dentro de la página (Rebrowser, 2024). `Page.evaluate` requiere activar el dominio `Runtime` de CDP, y esa activación emite eventos observables desde la página.

Durante años, el patrón estándar de detección consistía en colocar un objeto Error con un getter personalizado en `.stack`, llamar a `console.debug()` sobre él y ver si el getter se disparaba. Si lo hacía, el dominio Runtime estaba serializando el objeto por el WebSocket. En mayo de 2025, dos commits en V8 liquidaron ese truco: "Avoid error side effects in DevTools" el 7 de mayo y "Apply getter guard throughout error preview" el 9 de mayo. Desde entonces los getters definidos por el usuario ya no se ejecutan durante la previsualización de errores (Castle, 2025). El check basado en `console.debug` dejó de funcionar, y la mayoría de los proveedores tardaron meses en notarlo.

Cómo funcionan los parches y qué cuesta mantenerlos

El ecosistema se divide en tres generaciones. La primera ataca la superficie de fingerprint directamente: undetected-chromedriver renombra las variables `$cdc_` en el binario de ChromeDriver, y rebrowser-patches modifica el código de Puppeteer y Playwright para que no activen el dominio Runtime en cada carga. La segunda ataca el propio protocolo: Patchright ejecuta JavaScript a través de `Page.createIsolatedWorld` para que la página nunca vea los eventos que busca la detección. La tercera abandona CDP del todo — nodriver y su fork asíncrono zendriver controlan el navegador con APIs del sistema operativo, y camoufox hace lo mismo en Firefox parcheando el protocolo Juggler a nivel de C++ antes de compilar.

Mantener tu propio fork de Chromium es caro, y por eso casi nadie lo hace. Chrome libera una nueva versión mayor cada cuatro semanas (proyecto Chromium). Cada release mueve código, renombra estructuras internas y abre nuevas superficies de detección. Los parches en sí son pequeños, pero cada cuatro semanas hay que rebasarlos, probarlos contra los sistemas de detección en producción y compilar un binario nuevo antes de que el anterior quede obsoleto. La larga interrupción en el mantenimiento de camoufox durante casi todo 2025 ilustra lo que pasa cuando una sola persona carga con el trabajo. Por eso Bright Data, Browserless y servicios similares llenan el hueco ofreciendo Chromium parcheado como API gestionada. La contrapartida: benchmarks independientes encuentran que el flag de automatización del CDP sigue siendo legible desde dentro del navegador en todas las sesiones que sirven (benchmark de ScrapeOps, 2026).

Qué sigue atrapando a los navegadores parcheados

Detectar un fingerprint headless es fácil de eludir. Detectar comportamiento no. Las señales que sobreviven al parcheo son las que dependen de *cómo* se usa el navegador, no de cómo se ve al cargar la página. Trayectorias de ratón en líneas rectas entre elementos. Ritmos de tecleo idénticos entre sesiones. Formularios rellenados más rápido de lo que un humano podría leer. Patrones de sesión que se repiten en intervalos de peticiones que ningún usuario real genera.

La escala del tráfico automatizado en la web actual fuerza este cambio. Cloudflare midió en 2025 que alrededor del 30 % de todo el tráfico de internet eran bots, y durante la primera semana de marzo de 2025 más del 94 % de las peticiones de autenticación venían de bots (Cloudflare, 2025). Imperva observa cada día más de 10.000 IPs únicas ejecutando Headless Chrome para scraping y carding (Imperva, 2024). A ese volumen, un sistema de detección que solo mira una petición aislada está midiendo ruido. A principios de 2025, puppeteer-extra-stealth — durante años la forma estándar de ocultar automatización — dejó de saltarse Cloudflare de forma fiable, y los mantenedores pararon la actividad (ZenRows, 2025; Castle, 2025).

Qué significa para tu stack de detección

Si defiendes un sitio, la conclusión práctica es acotada: `navigator.webdriver` y los checks de substring en el user-agent ya no sirven como detección de bots. Atrapan herramientas viejas y nada más. Los builds de Chromium parcheados son baratos y accesibles, y ocultan exactamente las señales que esos checks buscan.

Lo que sigue funcionando es la detección multi-señal: fingerprints a nivel de petición combinados con patrones de comportamiento a lo largo de una sesión, en lugar de un único flag. Centinel detecta y bloquea crawlers de IA y tráfico automatizado a nivel de petición, combinando señales en runtime con análisis de comportamiento construido para la clase de tráfico que generan los navegadores parcheados. Cuando el 94 % de las peticiones de autenticación en internet están automatizadas (Cloudflare, 2025), la pregunta no es si conviene detectarlas. Es en qué señales confías para distinguirlas.