Undetected Chromedriver: alternativas a nivel del navegador

La etiqueta «sin detección» describe un resultado que atribuye un detector, no una propiedad estable del binario del navegador. El proyecto público undetected-chromedriver se presenta como un ChromeDriver parcheado, mientras que un perfil a nivel del navegador ofrece otra forma de configurar el navegador. Cada enfoque tiene responsables, superficies de actualización y requisitos de evidencia distintos. Para compararlos, primero hay que identificar qué capa modifica un valor y medir después únicamente una página autorizada que el equipo controle. BotBrowser documenta la configuración de perfiles del navegador y los límites de consistencia de la automatización; no parchea undetected-chromedriver, no mantiene la compatibilidad con ese paquete ni promete el veredicto de un sitio o detector.

Resumen

• El README de undetected-chromedriver describe un driver que se descarga y parchea automáticamente. Es la descripción del proyecto, no un resultado verificado de forma independiente para cada versión o destino.
• Un paquete de navegador, un driver de WebDriver y el núcleo del navegador tienen responsables distintos. Cambiar una capa no demuestra que haya cambiado otra ni que un sitio haya aceptado la sesión.
• Registra las versiones exactas del paquete y del navegador, las opciones solicitadas, las capabilities devueltas, el origen de la fixture, la API observada y la comparación con el valor esperado. Si el registro es de ejemplo, identifícalo como tal.
• Utiliza solo una fixture propia o autorizada expresamente. Esta comparación no enseña a evadir un detector ni a interactuar con un desafío de terceros.
• Un valor visible para la página, como navigator.webdriver, aporta evidencia sobre esa sesión, no prueba identidad, autorización ni la decisión de un detector.

Contenido

• El alcance de la descripción pública del proyecto
• Tres capas tienen responsables distintos
• Los cambios de versión implican distinto mantenimiento
• Medir una fixture propia sin emitir un veredicto
• Interpretar el registro según la capa que falla
• Dónde encaja la configuración del navegador
• Conclusión práctica

El alcance de la descripción pública del proyecto

El README del repositorio presenta undetected-chromedriver como un proyecto para parchear ChromeDriver. Dice que el paquete descarga y parchea automáticamente el binario del driver; su ejemplo crea un driver de Python con headless=True y use_subprocess=False. Estas afirmaciones permiten describir cómo se presenta públicamente el proyecto y qué invoca el ejemplo. No establecen una matriz de compatibilidad vigente, no prueban que todos los parches estén activos en una instalación concreta ni muestran qué decidirá un sitio distinto.

La distinción importa cuando un README emplea lenguaje de resultados contundentes. La introducción del repositorio nombra servicios anti-bot y afirma que el proyecto no los activa. Puede informarse con precisión de que el README incluye esa afirmación, pero no es una medición universal: no especifica todas las versiones del servicio, compilaciones del navegador, cuentas, redes, perfiles ni fechas. Aquí no se realizan pruebas contra esos servicios, por lo que esa introducción no se presenta como resultado. El resultado de un detector pertenece a su configuración y a las condiciones en las que se ejecutó la comprobación.

La página del proyecto y un paquete instalado también representan momentos distintos. La rama predeterminada del repositorio puede cambiar después de instalar una versión. Por ello, la versión del paquete Python, el commit de origen, el driver descargado, la versión de Chrome y las opciones de sesión deben figurar en campos separados de un registro reproducible. El nombre del paquete por sí solo no basta para reproducir una configuración ni interpretar un fallo.

Selenium documenta por separado el comportamiento específico del driver para Chrome y las opciones del navegador, frente a la respuesta de un sitio. La documentación de Chrome explica la integración del driver para ese navegador; la documentación general de WebDriver describe la creación de sesiones y sus capabilities. Estas fuentes respaldan la distinción entre solicitar configuración y observar una sesión negociada. No validan un parche de terceros ni determinan qué considera aceptable un sitio remoto.

La superficie observable debe describirse con la misma precisión. MDN documenta navigator.webdriver como una propiedad de solo lectura que indica si el agente de usuario está controlado por automatización. Es una señal expuesta mediante la API del navegador. No es una identidad del navegador, un permiso ni una descripción pública de todas las señales que un servicio remoto podría recopilar. Una página que la lee puede informar del valor; no puede deducir únicamente de ese valor todos los detalles de la implementación del driver o del paquete.

Este límite de las fuentes evita dos errores de categoría habituales. Primero, el código fuente puede demostrar que un proyecto contiene una ruta de código; por sí solo no demuestra que esa ruta se ejecutara en un proceso concreto. Segundo, una fixture local puede demostrar lo que leyó esa fixture; no demuestra que otro sitio recopilara los mismos campos ni que les aplicara la misma interpretación. Cada afirmación debe permanecer ligada a su fuente y a las condiciones de medición.

Tres capas tienen responsables distintos

La expresión «parche del navegador» es demasiado amplia para identificar qué cambió. Una comparación útil distingue JavaScript de página, código de WebDriver o del paquete del driver, y comportamiento del núcleo del navegador. Cada capa tiene entradas y responsabilidades de actualización propias. Un problema de mantenimiento en una no debe atribuirse automáticamente a otra; el inventario de señales que ve un detector y la referencia de integración de perfiles con Selenium cubren las superficies de navegador relacionadas.

Capa	Responsable habitual	Qué puede demostrar su artefacto	Superficie de actualización	Qué no demuestra por sí sola
Script de página	Aplicación o script inyectado	Qué código JavaScript se cargó y qué API intentó envolver	Paquetes del sitio, extensión o script de precarga, orden de ejecución	Que cambió el comportamiento nativo del navegador o un veredicto remoto
Driver o paquete	Implementación de WebDriver y su paquete	Opciones de sesión solicitadas, código del driver y quizá versión del ejecutable descargado	Versión del paquete, descarga del driver, compatibilidad entre Selenium y navegador	Que cambió un valor del núcleo del navegador o que un sitio aceptó la sesión
Núcleo del navegador	Compilación y configuración admitida del navegador	Valores y comportamiento de esa compilación bajo condiciones de inicio registradas	Versión del navegador, opciones de compilación, configuración del perfil y plataforma	Que todas las páginas leen esos valores o les atribuyen el mismo significado

Un wrapper de página se ejecuta en un contexto JavaScript. Puede afectar las lecturas de los objetos que modifica, pero la página podría tener otros contextos, rutas nativas o valores controlados por el navegador que el wrapper no posee. Si esas rutas son relevantes debe comprobarse mediante una fixture acotada y autorizada. Que un archivo de parche enumere APIs no demuestra que cada consumidor observe un resultado modificado.

Un paquete de driver gestiona la creación de sesiones y los artefactos de driver que distribuye o modifica. El objeto de opciones de Selenium describe solicitudes enviadas al crear la sesión. Las capabilities devueltas describen la sesión negociada por el extremo remoto. Por tanto, una opción solicitada y una capability devuelta son evidencias distintas. Ninguna constituye un inventario completo del comportamiento visible para la página: para eso hace falta medir una página con una compilación y una configuración de ejecución especificadas.

El núcleo del navegador establece otro límite. Un perfil del navegador puede proporcionar valores o ajustes admitidos durante el inicio, en vez de depender de que un script reemplace una API después de empezar a ejecutar el documento. Esto describe dónde se aporta la configuración; no afirma que se admita cualquier propiedad, que todas las plataformas se comporten igual ni que un detector remoto acepte el resultado. La documentación del perfil es la fuente para los campos y entradas admitidos; este texto no deduce comportamientos no documentados de la palabra «perfil».

Estas capas pueden coexistir en una ejecución. Selenium puede crear la sesión, el navegador cargar un perfil configurado y la página ejecutar sus scripts. Un inventario útil asigna cada dato a su responsable. Por ejemplo, requestedOptions corresponde a la solicitud de WebDriver, returnedCapabilities a la sesión negociada, profileInput al inicio del navegador y pageReads a la fixture propia. Agruparlos bajo una etiqueta que afirme ausencia de detección oculta justo los límites necesarios para diagnosticar.

La superficie de actualización sigue al responsable. Un paquete de página puede cambiar sin actualizar el navegador; un paquete del controlador puede cambiar mientras el binario permanece igual; y una versión del navegador puede modificar APIs o valores predeterminados aunque el wrapper de Python no cambie. Si varía un resultado, compara primero los artefactos versionados. De lo contrario, puede atribuirse una regresión a un componente que no cambió mientras la entrada real sigue siendo desconocida.

Los cambios de versión implican distinto mantenimiento

La gestión automática del driver resulta cómoda, pero la automatización debe saber qué artefacto seleccionó. El README dice que el paquete descarga y parchea un driver. Por eso son evidencias importantes la versión resuelta del paquete, la decisión de descarga, la ruta del driver resultante y la versión del navegador. No deduzcas el ejecutable descargado a partir de una instrucción de importación ni el ejecutable del navegador a partir de la versión del paquete del driver.

Como mínimo, conserva un manifiesto de ejecución con campos como estos:

Campo	Significado del ejemplo	Por qué importa
packageVersion	Versión instalada de la distribución Python	Identifica el código del paquete, no necesariamente el binario Chrome seleccionado
sourceRevision	Etiqueta o commit si se instaló desde el código fuente	Distingue una rama móvil de una versión publicada
driverVersion	Versión informada por el ejecutable WebDriver seleccionado	Ayuda a diagnosticar el inicio de sesión y la compatibilidad driver/navegador
browserVersion	Versión devuelta por la sesión del navegador	Identifica el entorno de ejecución de la página
requestedOptions	Opciones configuradas explícitamente, sin secretos	Muestra qué pidió el cliente al driver
returnedCapabilities	Campos públicos seleccionados de la sesión	Muestra qué devolvió la negociación de sesión
fixtureRevision	Commit de la página o fixture propia	Mantiene estable el objetivo observado
observedAt	Fecha, hora e identificador del entorno	Permite comparar ejecuciones controladas

La política exacta de compatibilidad corresponde al proyecto y a su documentación de versiones. No conviertas «probado hasta las versiones beta actuales de Chrome», que figura en un README, en una promesa para una versión de Chrome, sistema operativo, driver o imagen de CI concretos. Si una combinación es importante, regístrala y prueba esa combinación en un entorno controlado. Si el proyecto no documenta una tabla de compatibilidad para ella, marca el campo como desconocido en vez de completarlo mediante inferencias.

La descarga gestionada por el paquete también afecta a la reproducibilidad. Un agente de CI limpio podría descargar un artefacto distinto al de una estación de trabajo de larga duración si varían la versión del paquete, la caché o el navegador seleccionado. Registra la ruta resuelta y la versión del binario, pero evita publicar detalles privados del sistema de archivos o secretos locales. Un hash estable del artefacto puede distinguir binarios cuando la política permita compartirlo; tampoco informa de lo que el binario hizo en un servicio remoto.

Un cambio de versión puede generar al menos cuatro clases de fallo:

1. Cambió la resolución: el paquete seleccionó o descargó otro driver. Compara la versión del paquete, la ruta resuelta y la versión del driver antes de examinar el comportamiento de la página.
2. Cambió la negociación de sesión: Selenium no pudo crear la sesión solicitada o las capabilities devueltas difieren. Conserva la solicitud y respuesta saneadas y consulta las opciones de navegador y la compatibilidad documentada para esa versión.
3. Cambió la ejecución del navegador: la sesión se inicia, pero un valor de la fixture difiere. Compara versión, plataforma, entrada del perfil y revisión de la fixture, cambiando una variable cada vez.
4. Cambió el resultado de la aplicación: la fixture lee los valores esperados, pero la prueba a nivel de aplicación falla por otro motivo. Separa navegación, autorización y aceptación de la aplicación de la configuración del navegador.

Estas categorías son operativamente distintas. Reinstalar un paquete no explica un selector roto en la fixture; cambiar un perfil no arregla un handshake de WebDriver; y una respuesta 403 no demuestra que una señal concreta de fingerprint la causara. El registro debe identificar el primer límite que falló y conservar los datos que necesita el responsable de esa capa.

Conviene revisar un cambio del paquete aunque no cambie la versión del navegador. El paquete puede modificar la resolución del driver o la construcción de la sesión. A la inversa, el navegador puede cambiar el resultado aunque el código del paquete siga fijado. Registra ambos lados para identificar el componente modificado, en lugar de guardar solo el resultado final.

Medir una fixture propia sin emitir un veredicto

Una fixture propia puede comprobar si el arnés de prueba observa los valores esperados. No debe enviar tráfico a un detector ni intentar clasificar un servicio comercial de protección. Puede ser una aplicación local o un dominio de pruebas interno donde el equipo controle el marcado, las llamadas a la API y el resultado esperado. Siempre que sea posible, la prueba debe ser de solo lectura y utilizar valores sintéticos, no datos de cuentas o clientes reales.

La primera ejecución debe ser una línea base con una configuración de navegador declarada. La segunda debe cambiar una sola variable, como la compilación del navegador o una entrada de perfil documentada. No cambies a la vez el paquete, navegador, perfil, bundle de página, viewport y sistema operativo. Un cambio de varias variables puede producir una diferencia, pero la observación no permitirá identificar cuál fue la causa.

El siguiente JSON es un esquema de recibo propuesto, no un resultado medido. Los valores entre corchetes angulares son marcadores de posición; aquí no se afirma ninguna ejecución de BotBrowser ni de undetected-chromedriver.

{
  "fixtureOrigin": "https://owned-fixture.example.test",
  "fixtureRevision": "<commit-sha>",
  "package": {
    "name": "<package-name>",
    "version": "<resolved-version>",
    "sourceRevision": "<release-tag-or-commit>"
  },
  "browser": {
    "driverVersion": "<reported-driver-version>",
    "browserVersion": "<reported-browser-version>",
    "platformName": "<reported-platform>"
  },
  "requestedOptions": ["<sanitized-option-name>"],
  "observations": [
    {
      "surface": "navigator.webdriver",
      "expected": "<fixture-specific-expectation>",
      "observed": "<actual-fixture-value>",
      "match": false
    }
  ],
  "applicationResult": {
    "httpStatus": 200,
    "fixtureSchemaValid": true
  },
  "observedAt": "<UTC-timestamp>"
}

Sustituye todos los marcadores por datos de una ejecución real antes de tratar el recibo como evidencia. El valor esperado debe ser específico de la fixture; una expectativa booleana no es una política para sesiones de navegador no relacionadas. Si no se obtuvo un campo, utiliza null y explica el motivo. No etiquetes un ejemplo como «correcto», no inventes una fecha ni conviertas JSON de muestra en una observación afirmada.

La fixture debería exponer una respuesta pequeña y explícita, no recopilar una huella amplia del navegador. Por ejemplo, un endpoint puede devolver la revisión de la fixture y el valor observado de navigator.webdriver. Un registro separado del servidor puede anotar que la página se cargó. Para comparar el paquete y el navegador no es necesario recopilar canvas, fuentes, direcciones locales, identificadores de cuenta ni atributos de dispositivo no relacionados. Minimizar los datos mantiene la prueba ligada a su caso de aceptación.

Una tabla de comparación útil incluye una fila por ejecución controlada:

Ejecución	Entrada modificada	Identificadores del paquete y navegador	Observación de página	Resultado de la fixture	Interpretación
A	Línea base	Versiones registradas de paquete, driver y navegador	Valor exacto devuelto por la página propia	Esquema y estado	Describe solo la línea base
B	Una entrada documentada	Mismas versiones salvo que sean la variable	Valor exacto devuelto por la página propia	Esquema y estado	La diferencia se asocia a la entrada modificada, no a un veredicto externo

Repite únicamente si el resultado puede deberse a condiciones de prueba no deterministas, y registra cada intento. Repetir no autoriza a sondear continuamente un destino remoto. Si la fixture controlada responde con un error, el recibo debe indicar el estado HTTP y si se cumplió el contrato de la fixture. El estado y la validación del esquema son campos distintos: una respuesta HTTP correcta puede contener datos inválidos, mientras que un estado de rechazo puede indicar correctamente que la fixture bloqueó una solicitud no autorizada.

Interpretar el registro según la capa que falla

Empieza por el primer límite que falló. Si el proceso del navegador no se inició, todavía no hay observaciones de página. Si falló la creación de la sesión, no interpretes un valor antiguo de una página como salida de la nueva sesión. Si la fixture cargó pero falló su esquema, informa del problema de extracción por separado de la versión del navegador. Así se evita reducir hechos independientes a una sola etiqueta roja o verde.

Evidencia	Qué respalda	Qué sigue siendo desconocido
Lock del paquete y revisión de origen	Qué versión del paquete o snapshot de origen se instaló	Si se ejecutó cada rama del paquete en esta ejecución
Registro de inicio y versión informada del controlador	Qué controlador se inició y si avanzó la creación de sesión	Cómo interpretó la sesión un sitio remoto
Capabilities WebDriver devueltas	Qué campos de sesión devolvió el extremo remoto	Si cada opción modificó la salida visible para la página
Observación de una fixture propia	Qué leyó la fixture en las condiciones registradas	Qué recopiló o decidió un servicio no relacionado
Estado HTTP y esquema de la fixture	Si la aplicación controlada devolvió un registro aceptado	Si está autorizado acceder a un sitio de terceros

Si se conocen las versiones del paquete y navegador pero las capabilities solicitadas y devueltas difieren, investiga la creación de sesión. Si existe sesión pero cambia el valor de la fixture, compara navegador, perfil, sistema operativo y revisión de la fixture. Si la fixture obtiene el resultado esperado mientras un sitio externo devuelve una página de bloqueo, detente y sigue la política de acceso publicada por ese sitio. Esa respuesta no identifica la señal responsable sin evidencia del propio servicio.

Mantén breves los fragmentos de registros y redacta cookies, cabeceras de autorización, datos de cuenta, contenido de perfiles y secretos específicos de la máquina. Un manifiesto puede resultar útil sin contener el registro completo del controlador. Conserva la revisión de origen, las opciones saneadas, las categorías de resultado y las marcas temporales suficientes para relacionar el recibo con el trabajo de integración continua. El objetivo es reproducibilidad, no recopilar todos los datos posibles.

Al comparar dos paquetes, normaliza primero las entradas controladas. Usa la misma revisión de fixture propia y los mismos datos de aplicación. Si los paquetes requieren configuraciones de driver distintas y documentadas, inclúyelas como parte de la comparación en vez de presentarlas como idénticas. No mezcles una comparación de paquetes con una actualización del navegador. La conclusión debe indicar exactamente qué combinaciones se observaron y cuáles no se probaron.

Dónde encaja la configuración del navegador

La configuración del navegador responde a una pregunta de mantenimiento distinta del parche de un paquete WebDriver. Sitúa ajustes documentados durante el inicio del navegador o en su perfil, en lugar de depender solo de un wrapper de página o de una modificación del driver gestionada por un paquete. La opción adecuada depende de la configuración admitida, la interfaz de automatización necesaria, la cobertura de sistemas operativos y la política de actualizaciones del equipo.

La documentación de perfiles de BotBrowser describe la entrada de perfil admitida. La documentación de consistencia de automatización describe los límites del producto en torno a esa automatización. Esas referencias respaldan afirmaciones sobre configuración y alcance documentados. No demuestran que Selenium, un Grid concreto o undetected-chromedriver tengan soporte, salvo que la integración correspondiente esté documentada de forma explícita. Poder iniciar un ejecutable de navegador tampoco equivale a validar una integración WebDriver.

La comparación no consiste en decidir «qué herramienta gana». Formula tres preguntas más concretas: ¿qué componente es responsable del cambio?, ¿qué versión hay que seguir?, ¿qué evidencia confirma el valor en una página controlada? Un equipo cuya aplicación necesita una capability específica puede elegir un flujo WebDriver documentado. Si necesita configuración en el nivel del navegador, debe evaluar las entradas de perfil admitidas y la integración exacta. Quien mantiene scripts de página debe probar los contextos que esos scripts afectan realmente. Son decisiones de ingeniería, no resultados universales de detección.

Mantén las afirmaciones de producto dentro del alcance publicado. BotBrowser aporta mediante la configuración de perfiles valores documentados a nivel del navegador; no parchea un driver de terceros ni sigue el ciclo de versiones de ese proyecto. No puede garantizar un veredicto de detector, la respuesta de un sitio, identidad, autorización ni acceso. La existencia de un perfil no prueba que se haya cargado; para afirmarlo hace falta la evidencia de carga documentada por el producto. La fixture del lector sigue siendo la evidencia de los valores que observó esa fixture.

El alcance es deliberadamente más acotado que una guía de elusión. No proporciona una secuencia para alcanzar una página protegida, cambiar el resultado de un detector ni modificar señales hasta que un destino acepte una sesión. El resultado es una comparación de mantenimiento y un diseño de registro para pruebas propias. Cuando un sitio deniega acceso, respeta su política y utiliza una integración o vía de permiso aprobada.

Preguntas frecuentes

¿El README demuestra que un lanzamiento actual funciona en todas partes?

No. Documenta el objetivo declarado y un resumen de implementación del proyecto. No proporciona una matriz completa y fechada con versiones de servicios, cuentas, compilaciones y entornos que respalde un resultado universal.

¿Una capability WebDriver demuestra que se cargó el perfil del navegador?

No. Una capability es información de sesión devuelta por WebDriver. La carga del perfil es un hecho distinto del inicio del navegador y necesita la evidencia que admite el producto.

¿navigator.webdriver es una puntuación del detector?

No. MDN lo describe como una propiedad del navegador que indica el control mediante automatización. Una página puede observar la propiedad, pero su valor no codifica el modelo ni la decisión de un proveedor.

¿Una fixture local puede predecir la decisión de un servicio comercial?

No. Solo puede validar su propio contrato bajo condiciones registradas. Un servicio externo controla sus entradas, política y resultado.

¿Qué hay que incluir en una comparación de versiones?

Registra la versión del paquete y la revisión de origen, versión del driver y del navegador, opciones saneadas, revisión de la fixture, valor de API observado y resultados HTTP y de esquema por separado. Cambia una entrada por comparación.

Lecturas relacionadas

Para conocer los límites de los parches JavaScript de página, consulta dónde terminan las modificaciones de página; para las entradas del perfil, consulta la integración de perfiles con Selenium.

Fuentes

• Repositorio y README públicos de undetected-chromedriver
• Selenium: funciones específicas de Chrome
• Selenium: opciones del navegador
• Consistencia de automatización de BotBrowser
• Configuración de perfiles de BotBrowser
• MDN: Navigator.webdriver

Conclusión práctica

Compara quién es responsable antes de comparar afirmaciones. El README describe un paquete que descarga y parchea un driver; Selenium registra la negociación de sesión; los perfiles del navegador configuran valores documentados de inicio; y una página propia informa únicamente de lo que lee. Sigue esas versiones por separado, cambia una entrada controlada cada vez y conserva un recibo que distinga inicio del navegador, negociación de sesión, observaciones de página y resultados de aplicación. Ninguno de esos registros demuestra identidad ni predice un veredicto de terceros. Utiliza la comparación para elegir una integración mantenible y documentada para una tarea autorizada, y respeta los límites de acceso del sitio.