Navegador no detectado: qué lee un detector

Un navegador no detectado es una afirmación sobre un veredicto, y un veredicto pertenece a quien ejecutó la comprobación. Una página de desafío no pregunta si un navegador es honesto: muestrea un conjunto de superficies, las compara con un modelo propio y devuelve una puntuación cuyas líneas de corte y pesos pertenecen al proveedor. Dos detectores pueden muestrear superficies distintas de la misma sesión y llegar a conclusiones opuestas sin que ninguno esté averiado. BotBrowser proporciona un entorno de ejecución Chromium configurable y documenta qué señales puede mantener coherentes, pero no garantiza ningún veredicto de terceros ni publica una tasa de aprobación, porque esa tasa es propiedad de una versión de detector más un objetivo más una sesión, no de un navegador. El recorrido siguiente cubre qué puede leer un detector, por qué las lecturas discrepan y qué registrar en lugar de una afirmación.

TL;DR

• navigator.webdriver es un solo valor booleano. MDN documenta que Chrome lo activa cuando se usan --enable-automation, --headless o --remote-debugging-port=0, de modo que la marca informa cómo se inició el navegador, no si una página confiará en él.
• performance.now() se redondea a propósito para proteger contra ataques de temporización y huellas: MDN documenta una resolución de 5us en un documento aislado entre orígenes y de 100us en los demás casos. Una sonda de temporización ejecutada con una resolución no se puede comparar con la misma sonda ejecutada con la otra.
• Un veredicto es una función del modelo propio del detector. Dos proveedores que muestrean superficies distintas pueden discrepar sobre una sesión, y ninguno está necesariamente equivocado sobre lo que midió.
• La afirmación se sustituye por un registro: nombre y versión del detector, superficies que reportó, línea de corte aplicada, configuración de la sesión y marca temporal. Un registro se puede comparar; una afirmación no.
• El entregable defendible es una tabla de resultados por detector con los modos de fallo nombrados, no un adjetivo en el nombre del producto.

Contenido

• Qué puede muestrear una página de desafío
• Por qué dos detectores discrepan sobre una misma sesión
• Sustituir la afirmación por un registro de medición
• Conclusión práctica

Qué puede muestrear una página de desafío

Un detector lee lo que puede leer cualquier script de una página. Esa es toda la superficie, y merece una lista porque es finita y poco glamurosa.

Señales de navegación y automatización

navigator.webdriver es el miembro de este grupo que una página ve primero, y por sí solo aporta un único bit. MDN lo define como una propiedad de solo lectura que indica si el agente de usuario está controlado por automatización, y documenta las condiciones concretas de Chrome que lo hacen verdadero: la marca --enable-automation, la marca --headless o --remote-debugging-port con el puerto 0. Cada una describe una configuración de lanzamiento. Una página que lee el valor booleano aprende cómo se inició el proceso, y una página que lee solo ese valor ha decidido confiar en un único bit.

Las señales adyacentes describen el mismo lanzamiento desde otros ángulos. La presencia de un enlace específico de automatización en el objeto window, un puerto de depuración que responde en loopback, una cadena de agente de usuario que nombra una compilación sin interfaz y un objeto window.chrome cuya forma difiere de una instalación estándar apuntan a la misma pregunta: ¿se inició este navegador como se inicia el de una persona? Ninguna responde si la sesión será aceptada, porque un detector puede asignarles peso cero.

La cadena de agente de usuario y los Client Hints ofrecen porciones distintas de una misma declaración. navigator.userAgent devuelve una sola cadena, mientras que navigator.userAgentData devuelve un arreglo brands de pares { brand, version }, un valor booleano mobile y una cadena platform. El método getHighEntropyValues() acepta una lista de campos, entre ellos architecture, bitness, model, platformVersion y uaFullVersion, y devuelve una promesa con los valores solicitados. Un detector que lee solo brands ve menos que uno que pide uaFullVersion y bitness, otro ejemplo de dos conjuntos de superficies distintos.

Señal	Qué describe	Por qué es débil por sí sola
navigator.webdriver	Si se usaron marcas de automatización	Un solo valor booleano, y los proveedores pueden ignorarlo
Enlace de automatización en window	Qué biblioteca inyectó scripts	Ausente en un lanzamiento directo, presente en algunos marcos
Puerto de depuración accesible	Si hay abierto un extremo del protocolo	Un puerto cerrado es normal en el navegador de una persona
Cadena de agente de usuario	Qué dice ser el navegador	Configurable, y una declaración en lugar de una medición
Forma de window.chrome	Qué familia de compilación Chromium	Varía según la compilación, no según la confiabilidad

Superficies de almacenamiento y permisos

El almacenamiento es un cuarto grupo, y es el que cambia con el historial de una persona en lugar de con la compilación del navegador. La disponibilidad de cookies, la partición del almacenamiento de terceros, la repetición del mismo número en una sonda de cuota y la visita previa a un origen describen el pasado de una sesión, no su configuración. Un detector que las lee pregunta si este perfil ya estuvo aquí, una cuestión distinta de si el navegador está automatizado.

La cuota y el uso están disponibles mediante navigator.storage.estimate(), que devuelve una promesa con quota y usage en bytes. La enumeración de bases de datos con indexedDB.databases() devuelve nombres y versiones, y caches.keys() lista los nombres de caché. Esas tres llamadas dan a un detector información sobre el estado acumulado sin leer contenido alguno: la mera presencia de una base de datos con un nombre o de una caché con una versión ya separa un perfil nuevo de uno usado.

Los permisos funcionan del mismo modo. El conjunto de permisos que un documento puede consultar, el estado que devuelve cada uno y si una solicitud abre un aviso son observables sin interacción de la persona. El valor de Notification.permission y el resultado de navigator.permissions.query({ name: 'geolocation' }) son dos ejemplos de esa lectura. Una página puede construir así una imagen de las decisiones de consentimiento previas de un perfil, y un perfil nuevo responde de forma distinta a uno de larga duración aunque la compilación del navegador sea idéntica.

Por eso una carga de trabajo de monitorización o comparación debe decidir de forma deliberada si quiere un perfil nuevo o persistente, y registrar la elección. Ambos producen respuestas diferentes en esta superficie, y ninguno es más fiable que el otro: son simplemente sesiones distintas.

Superficies de temporización y rendimiento

La temporización es fácil de pasar por alto, porque parece una medición de la máquina y no del navegador. MDN documenta que performance.now() se redondea a propósito: 5us de resolución en un documento aislado entre orígenes y 100us en los demás casos. Es una diferencia de veinte veces en el intervalo observable más pequeño, y es una propiedad del estado de aislamiento del documento, no del hardware.

La consecuencia para una comparación es directa. Una sonda que mide el delta no nulo más pequeño entre dos llamadas a performance.now() lee la resolución, no la máquina. La misma sonda en un documento aislado y en uno no aislado produce números que difieren en un factor de veinte. Un detector que muestrea el comportamiento del temporizador observa, por tanto, el estado de aislamiento del documento en el que se ejecuta, y un equipo que cambia ese estado entre ejecuciones ha cambiado la medición.

La propiedad crossOriginIsolated está disponible para la página como un valor booleano, lo que permite a un detector clasificar un documento en uno de los dos grupos de resolución sin medir ningún intervalo. Un registro de sesión sin ese campo deja abierto cuál de los dos valores pudo haber observado un temporizador.

Un segundo reloj se comporta de otro modo. Date.now() devuelve milisegundos enteros, así que una sonda construida sobre él no puede resolver un intervalo menor que un milisegundo y no muestra el redondeo de performance.now(). Una devolución de llamada de requestAnimationFrame llega a la frecuencia de refresco de la pantalla, unas sesenta veces por segundo a 60 Hz y unas ciento veinte veces por segundo en un panel de 120 Hz. Un detector que mezcla las tres fuentes de tiempo obtiene tres suelos de precisión distintos, y una razón más para registrar la configuración del documento.

Superficies de red y medios

RTCPeerConnection expone información de candidatos locales a una página que crea una conexión, y por eso la recopilación de candidatos es una forma de inspeccionar una fuga de WebRTC. La misma llamada también revela si una ruta de conexión admite el protocolo, y una página puede distinguir una ruta bloqueada de una operativa sin completar nunca una llamada. Los dispositivos multimedia, el renderizado de canvas, los parámetros de WebGL, las métricas de fuentes y el procesamiento de audio pertenecen a la misma clase de superficie: cada uno es una API legítima cuyo resultado depende del entorno, y cada uno se puede muestrear sin que la página solicite un permiso inusual.

navigator.mediaDevices.enumerateDevices() devuelve una lista de dispositivos cuyo contenido depende del permiso: MDN documenta que los dispositivos distintos de los predeterminados solo se listan cuando se ha concedido permiso, así que un documento que nunca lo pidió ve los predeterminados y ninguna etiqueta. El campo kind sigue poblado, por eso un detector puede contar clases de dispositivo sin mostrar un aviso; deviceId, label y groupId vuelven como cadenas vacías hasta que se concede la captura. La salida de canvas depende del controlador, del ajuste de suavizado de bordes y de las fuentes instaladas, WebGLRenderingContext.getParameter() nombra al fabricante y al modelo del renderizador, y un AudioContext informa su sampleRate, mientras que un DynamicsCompressorNode expone ratio, knee, attack y release. Las lecturas de canvas, WebGL y audio no exigen llamar a getUserMedia; los identificadores y etiquetas de dispositivo poblados sí exigen permiso multimedia o captura.

Las métricas de red añaden otra porción independiente. navigator.connection.effectiveType toma los valores slow-2g, 2g, 3g o 4g, los campos rtt y downlink estiman la latencia y el rendimiento, y saveData informa un modo de ahorro de datos. Las entradas de performance.getEntriesByType('resource') llevan nextHopProtocol, transferSize, encodedBodySize y decodedBodySize, así que una página puede distinguir el protocolo de conexión y el tamaño del cuerpo transferido sin acceso al contenido de la respuesta.

El registro de detectores BotD muestra qué comprobaciones ejecuta realmente un detector de código abierto, y qué prueban realmente las suites de detección públicas compara los conjuntos de superficies que muestrean varias suites públicas. El motivo para enumerarlas juntas es que son independientes. Un detector que muestrea solo la temporización, solo el canvas o solo las marcas de navegación observa una porción distinta de la misma sesión, y un cambio en el navegador que satisface una porción puede mover otra.

Por qué dos detectores discrepan sobre una misma sesión

La discrepancia es estructural, no un defecto de ninguno de los dos productos.

Cada proveedor posee su modelo

La salida de un detector es una puntuación producida por pesos y líneas de corte que el proveedor elige y revisa. Dos proveedores pueden muestrear la misma sesión y alcanzar veredictos distintos por tres razones ordinarias: muestrean conjuntos de superficies diferentes, ponderan de forma distinta una superficie compartida y sitúan su línea de corte en puntos diferentes. Nada de eso es visible desde el lado del navegador.

Por eso una tasa de aprobación no es una propiedad de un navegador. Es una propiedad de un navegador más una versión de detector más un objetivo más una sesión. Citar un número sin los otros tres es citar una medición a la que se le quitaron sus condiciones.

Motivo de la discrepancia	Qué difiere	Qué puede hacer el navegador
Conjuntos de superficies distintos	Un proveedor lee temporización y otro lee canvas	Nada directo; la superficie es elección del proveedor
Pesos distintos	La misma señal cuenta más o menos	Nada; los pesos son internos
Líneas de corte distintas	La línea de corte está en otro punto	Nada; la línea de corte no se publica
Versión de detector distinta	El modelo cambió entre versiones	Volver a probar tras cada versión
Objetivo distinto	Otro sitio ejecuta otra configuración	Probar el objetivo real

El mismo navegador, dos veredictos

Una sesión que pasa un proveedor y falla otro es el caso normal, no la contradicción que parece. Puede que el proveedor que aprueba no muestree la superficie que cambió; puede que el que falla muestree solo esa superficie. Un equipo que lee el par como un navegador medio no detectado ha inventado una métrica que ningún proveedor reporta.

La lectura útil es más estrecha. Cada veredicto es una declaración sobre el modelo de un detector aplicado a una sesión. Dos veredictos juntos dicen que la sesión está cerca de un límite en un modelo y cómodamente dentro de otro, lo que informa sobre el límite y no sobre el navegador.

Qué no puede significar la palabra no detectado

La palabra promete un resultado que ningún cambio local puede entregar, porque el resultado se produce en otro lugar mediante un modelo que el operador no controla. Una configuración puede eliminar una marca concreta, alinear un conjunto concreto de señales y mantener un perfil coherente durante una ejecución. No puede decidir qué hará el modelo de un proveedor con el resultado, ni prometer que el modelo seguirá igual el mes siguiente.

Tratar la palabra como una afirmación de producto en lugar de como la descripción de una observación pasada es un error que esta categoría invita a cometer. Un proveedor que publica una tasa de aprobación ha publicado una medición en condiciones que pueden no coincidir con las del lector.

Sustituir la afirmación por un registro de medición

La alternativa a una afirmación es un registro que se puede volver a comprobar. Tiene cinco partes, y cada una es barata.

Los cinco campos

El primero es el detector: su nombre y la versión o fecha del modelo que produjo el veredicto. Sin una versión, un resultado no se puede reproducir después de que el proveedor actualice. El segundo es el conjunto de superficies que reportó el detector, con las palabras del propio detector, porque las categorías del proveedor son el único vocabulario compartido disponible. El tercero es la línea de corte o la categoría en la que cayó el veredicto, no un porcentaje convertido. El cuarto es la configuración de la sesión: compilación del navegador, identificador del perfil, marcas de lanzamiento, ruta, idioma, zona horaria y estado de aislamiento del documento. El quinto es la marca temporal y el objetivo.

Campo	Forma de ejemplo	Por qué debe registrarse
Identidad del detector	nombre del proveedor más fecha del modelo	Un cambio de modelo invalida una comparación
Superficies reportadas	etiquetas de categoría del propio proveedor	Esas etiquetas son el único vocabulario compartido
Categoría del veredicto	aprobado, desafío, bloqueo o el término del proveedor	Un porcentaje convertido pierde la línea de corte
Configuración de la sesión	compilación, perfil, marcas, ruta, idioma, aislamiento	Dos configuraciones no son una medición
Objetivo y hora	clase de URL más marca temporal	El mismo proveedor puntúa distinto objetivos distintos

Registrar la configuración que produjo un veredicto

El campo de configuración es fácil de omitir, y es el que hace útil el registro. Un identificador de compilación del navegador, un identificador de perfil, las marcas de lanzamiento vigentes, la región de salida de la ruta, el idioma negociado y el estado de aislamiento entre orígenes del documento describen la sesión con suficiente detalle para preparar una segunda ejecución equivalente. Registrar el estado de aislamiento importa por la razón que dio la sección de temporización: cambia en un factor de veinte la resolución que puede observar una sonda.

Hay que registrar los valores efectivos, no los solicitados. Un idioma solicitado que el sitio sobrescribió, o una ruta solicitada que conmutó por error, produce una sesión que no coincide con el registro salvo que este capture lo que realmente se aplicó.

Una tabla de resultados en lugar de un adjetivo

El entregable que resiste el escrutinio es una tabla con una fila por detector y una columna por cada campo anterior, más una columna para el veredicto observado y otra para el modo de fallo cuando un detector bloqueó. Un lector puede ver entonces que un navegador pasó dos detectores y recibió un desafío de un tercero, y decidir si el tercero importa para su objetivo.

Esa tabla también es la respuesta honesta a la pregunta que insinúa el nombre del producto. Dice qué se midió, quién lo midió, con qué configuración y cuándo. No dice no detectado, porque esa frase borraría todas sus columnas.

Qué volver a probar tras un cambio

Tres cambios invalidan un resultado guardado. Una versión de detector cambia el modelo, así que la fila debe medirse de nuevo en lugar de releerse. Una actualización del navegador o del perfil cambia la configuración de la sesión, así que el campo de configuración de la fila ya no coincide. Un cambio de objetivo, incluida una nueva versión del desafío en el mismo sitio, cambia aquello que se está probando.

Todo lo demás se puede reutilizar. Ese es el beneficio práctico del registro: convierte una pregunta abierta en un conjunto pequeño de filas que necesitan actualización cuando cambia algo concreto.

FAQ

¿Poner navigator.webdriver en false hace que un navegador no sea detectado?

No. MDN documenta la propiedad como una señal que informa si se usaron marcas de automatización, y un detector es libre de asignarle peso cero o de contrastarla con otras observaciones. Una página que lee el valor booleano ha leído un bit; el modelo de un proveedor lee muchos, y los pesos del modelo no se publican.

¿Por qué el mismo navegador pasa un detector y falla otro?

Porque los dos proveedores muestrean superficies diferentes, ponderan de forma distinta las superficies compartidas y sitúan sus líneas de corte en puntos diferentes. Una sesión cerca de un límite en un modelo puede estar cómodamente dentro de otro. El par de veredictos describe dos modelos, no dos mitades de un mismo navegador.

¿Puede publicarse una tasa de aprobación como propiedad de un producto?

Una tasa solo se puede publicar con sus condiciones: detector y versión del modelo, objetivo, configuración de la sesión y ventana de medición. Sin ellas, el número describe una medición que no se puede reproducir, y una actualización posterior del proveedor puede invalidarla sin ningún cambio del lado del navegador.

Conclusión práctica

El punto de partida es la lista de superficies, no el adjetivo. Hay que leer qué puede muestrear una página de desafío, anotar que navigator.webdriver informa sobre una marca de lanzamiento y que la resolución de performance.now() depende del estado de aislamiento del documento, y aceptar que un veredicto lo produce un modelo que el operador no controla.

La siguiente acción es una tabla. Elegir el detector que importa para el objetivo, registrar su nombre y la fecha del modelo, las superficies que reportó, la categoría que devolvió y la configuración completa de la sesión, incluido el estado de aislamiento, y ejecutarlo dos veces con la misma configuración para comprobar si la fila es estable. Dos filas coincidentes demuestran que la medición se repite; no demuestran un veredicto, y esa distinción es el centro del asunto.

Sources

• MDN: Navigator.webdriver
• MDN: Performance.now
• MDN: RTCPeerConnection
• BotBrowser: Browser fingerprinting privacy threat
• BotBrowser: Automation consistency