Fingerprinting de la Network Information API: revisión de política

La Network Information API ofrece a una página unas cuantas estimaciones de la conexión mediante navigator.connection. Se diseñó para que un sitio pueda elegir recursos más ligeros en un enlace lento, pero cualquier script de la página puede leer esos mismos valores, de modo que también pueden sumarse a la huella del navegador. Las secciones siguientes recorren qué informa cada propiedad, por qué la salida de un proxy puede contradecir lo que mide el navegador, cómo elegir entre una política nativa, una basada en el perfil y otra por campos, y cómo revisar el resultado sin adivinar. BotBrowser puede mantener coherentes los valores de información de red de un perfil en un contexto controlado; no puede cambiar la conexión real ni cómo usa un sitio esos valores.

Resumen

• navigator.connection expone effectiveType, rtt en milisegundos, downlink en megabits por segundo, type y saveData sin pedir permiso, así que cualquier script de la página lee los mismos cinco campos.
• --bot-network-info-override=false conserva los valores medidos del equipo, la opción sin valor o profile aplica todos los valores que define el perfil cargado, y una política JSON solo fija los campos que nombra.
• Un JSON mal formado, un campo desconocido, un valor inválido o un selector profile sobre un campo que el perfil no define descartan la política entera, y los valores nativos medidos permanecen.
• La política resuelta pertenece a un contexto del navegador y también alimenta las cabeceras RTT, Downlink, ECT y Save-Data, así que compara la página con las cabeceras que recibe un servidor tuyo.
• Haz la ejecución nativa y la de override seguidas, en el mismo equipo y la misma ruta, porque el proxy cambia el camino y no los valores que lee la página.

Contenido

• Qué expone navigator.connection
• Cómo los valores de conexión se suman a una huella
• Elegir una política de información de red
• Incoherencias que una revisión puede detectar
• Revisar una ejecución nativa frente a una con override
• Dónde encaja BotBrowser
• Conclusión práctica

Qué expone navigator.connection

El objeto NetworkInformation informa de pistas aproximadas sobre la conexión que el navegador usa en ese momento. Las páginas lo emplean para decidir si aplazan un vídeo opcional, eligen una imagen más pequeña o posponen una precarga. No pide ningún permiso, así que cualquier script que se ejecute en la página puede leerlo, y se dispara un evento change cuando se mueve la estimación del navegador.

• effectiveType clasifica las condiciones observadas como slow-2g, 2g, 3g o 4g. Etiqueta la calidad que el navegador ha visto, no la tecnología de radio.
• rtt es una estimación del tiempo de ida y vuelta en milisegundos. El navegador lo redondea, por lo que cambia por saltos.
• downlink es una estimación del ancho de banda de bajada en megabits por segundo, también redondeada.
• type nombra la tecnología de conexión, como wifi, cellular, ethernet o unknown, cuando el navegador la implementa.
• saveData es un booleano que indica si el usuario pidió reducir el consumo de datos.

Estos valores son estimaciones del navegador, no mediciones en las que una página pueda confiar hasta el último dígito. La especificación permite que el navegador los redondee y los agrupe en tramos, y dos lecturas separadas por unos segundos pueden diferir. La compatibilidad también varía según la familia de navegadores. Los basados en Chromium exponen el objeto, Firefox ofrece una superficie limitada y Safari no lo proporciona, así que una revisión debe partir de la marca de navegador que persigue el despliegue. Que falte el objeto en una marca que normalmente lo expone es una observación inusual por sí misma. Para el lado de la aplicación de esta misma API, incluido cómo tratar pistas ausentes o cambiantes, consulta Network Information API para contenido adaptable. La especificación describe además downlinkMax, un límite superior de la tecnología de conexión subyacente que solo implementan algunos navegadores, así que no des por hecho que una propiedad que puedes fijar en una política existe en todos los destinos.

Cómo los valores de conexión se suman a una huella

Ninguna propiedad identifica por sí sola a una persona. effectiveType tiene muy pocos valores posibles, type suele ser unknown o no estar presente, y saveData está desactivado en la mayoría de los visitantes. La aportación es estadística. Un effectiveType concreto, un rtt redondeado, un downlink redondeado y un ajuste de saveData reducen en conjunto el conjunto de navegadores que podrían haber generado una visita, y esa reducción se suma al resto de señales que recoja la página. Afirmar que estos valores identifican a un usuario por sí solos, o que alcanzan una tasa de identificación fija, va más allá de lo que respaldan la especificación pública y la documentación.

Los valores también aportan contexto sobre dónde está el navegador. Un escritorio con fibra, un teléfono con datos móviles y una conexión compartida de oficina tienden a informar combinaciones distintas. saveData es una preferencia del usuario, así que quien la activa destaca más que quien la deja desactivada. Como el objeto se puede leer sin pedir permiso, un script puede registrar los valores al cargar y compararlos con lecturas posteriores de la misma visita.

El redondeo es la medida de privacidad del propio navegador y limita cuánto revela una lectura aislada. La señal que queda trata sobre todo de estabilidad y verosimilitud. Un contexto que informa una sola clase de conexión durante toda la sesión, junto con una dirección IP, una zona horaria y un idioma que encajan con ella, parece una visita corriente. Un contexto cuyos valores de red cambian de formas que el resto de la visita no explica, o que contradicen sus otras señales, da a un script algo que comparar. Por eso, quien revisa mira el conjunto de valores a la vez en lugar de ajustar un número aislado.

El problema más práctico aparece con un proxy. Un navegador que envía el tráfico por una salida de otra región sigue midiendo la ruta que realmente usa, así que rtt y downlink describen esa ruta real y no una conexión típica de la región de salida. Cuando la dirección IP, la zona horaria y el idioma apuntan a un lugar y las estimaciones de conexión describen otro tipo de enlace, la combinación resulta inusual. Ni el proxy ni un perfil lo arreglan por sí solos, porque un proxy cambia la ruta y no los valores que lee la página. La guía de configuración de proxy cubre el lado del enrutamiento, y una política de información de red cubre los valores que la página puede ver.

Un segundo lugar donde los valores pueden discrepar es la propia petición. Las mismas estimaciones pueden llegar a los servidores que las solicitan mediante Client Hints, con las cabeceras de petición RTT, Downlink, ECT y Save-Data. Si JavaScript informa de una clase de conexión y las cabeceras de otra, la incoherencia se nota más que cualquiera de los dos valores por separado. Una política sensata trata la API de JavaScript y las Client Hints de red como una sola decisión. La guía de fingerprinting con Client Hints explica la familia más amplia de pistas.

Elegir una política de información de red

La opción --bot-network-info-override admite una sola política, y hay tres elecciones útiles. Elige la más pequeña que responda a la pregunta que tienes delante.

• Sin override, escrito como false: la página ve las estimaciones nativas del navegador con su redondeo habitual. Es la base adecuada para cualquier comparación.
• Base del perfil, escrita como la opción sin valor, true o profile: se usan todos los valores de red que define el perfil cargado. Encaja en un despliegue donde el perfil ya describe la clase de conexión prevista.
• JSON por campos: solo se fijan los campos nombrados y los omitidos siguen siendo nativos. Una política que nombra solo rtt deja todos los demás campos en su valor medido.

Usa la política nativa cuando quieras medir lo que informa la conexión del host, por ejemplo al depurar o cuando un despliegue no tiene motivo para presentar otra cosa. Usa la base del perfil cuando el perfil se haya elegido para describir el dispositivo y la conexión que quieres que vea una página, porque una sola opción aporta entonces todos los valores de red disponibles y los mantiene coherentes entre sí. Usa JSON por campos cuando un escenario necesite uno o dos valores concretos, como un rtt distinto para una salida lejana, y el resto de los campos deba quedarse como está.

# Valores nativos
--bot-network-info-override=false

# Todos los valores disponibles del perfil cargado
--bot-network-info-override=profile

# Solo los campos elegidos; los omitidos siguen siendo nativos
--bot-network-info-override='{"effectiveType":"3g","rtt":180,"downlink":1.8,"saveData":false}'

# Mezclar fuentes campo por campo
--bot-network-info-override='{"type":"profile","rtt":"host","downlink":2.5,"saveData":"profile"}'

Una política JSON acepta type, effectiveType, rtt, downlink, downlinkMax y saveData. Cada campo admite un valor soportado o un selector de origen, profile o host. El selector profile toma el campo del perfil cargado, y host conserva el valor medido a propósito. Los valores admitidos siguen la plataforma: type es uno de wifi, cellular, ethernet, bluetooth, wimax, other, none o unknown; effectiveType es uno de slow-2g, 2g, 3g o 4g; rtt es un entero no negativo dentro del rango admitido; downlink y downlinkMax son números no negativos dentro del rango admitido; saveData es true o false. Una política personalizada o con host puede funcionar sin perfil, mientras que un selector profile necesita que el perfil defina ese campo.

Trata cada valor como una base, no como una constante. El navegador sigue aplicando sus límites, su redondeo y su variación por host, de modo que dos orígenes pueden recibir números ligeramente distintos a partir de la misma base, y dos arranques del navegador no tienen por qué devolver exactamente el mismo rtt. Ninguna política promete un número fijo en todos los orígenes, y un valor constante sin redondear en cada sitio resultaría inusual por sí mismo.

Una entrada no válida no es fatal ni parcial. Un JSON mal formado, un campo desconocido, un valor no válido o un selector profile que apunta a un campo que el perfil no tiene hacen que se ignore toda la política y que permanezcan los valores nativos medidos. El resto de los ajustes del perfil siguen funcionando. La consecuencia para quien revisa es sencilla: unos números de aspecto nativo no son prueba de un override personalizado. Revisa primero el texto de la política y luego vuelve a leer los valores.

La política resuelta pertenece a un contexto del navegador. Las páginas, los workers, las navegaciones y las peticiones con Client Hints compatibles dentro de ese contexto usan el mismo resultado, y otro contexto puede usar una política distinta. Fija la política antes de crear la primera página del contexto. Una política pasada por línea de comandos tiene prioridad sobre el ajuste networkInfoOverride del perfil, así que revisa ambos cuando el resultado no sea el que sugiere el perfil.

Incoherencias que una revisión puede detectar

La mayoría de los problemas con los valores de red son incoherencias entre campos, o entre un campo y el resto del escenario, no un único número equivocado. Conviene comprobar estos casos antes de que un despliegue entre en producción.

Una clase de dispositivo que no encaja con el tipo de conexión. Un perfil que describe un navegador de escritorio suele informar ethernet, wifi o unknown, mientras que un perfil de teléfono es más probable que informe cellular. Si fijas type a mano, asegúrate de que sigue encajando con el dispositivo que describe el perfil.

Campos que no encajan entre sí. La especificación define effectiveType en función del tiempo de ida y vuelta y del downlink, así que un 4g escrito a mano junto a una estimación de ida y vuelta medida en segundos describe un enlace que rara vez existe. Cuando nombres varios campos, elige valores que describan una conexión verosímil, o deja que el perfil aporte el conjunto completo.

Una marca de ahorro de datos que nadie quería. La mayoría de los visitantes deja saveData desactivado, así que ponerlo en true hace al navegador más raro. Actívalo solo cuando el escenario represente de verdad a un usuario que pidió reducir datos y, en otro caso, deja que decida el perfil o el valor nativo.

Un selector host en un escenario con proxy. El selector host conserva el valor medido, lo que significa que la lectura vuelve a reflejar la ruta real, incluido el salto hasta el proxy. Es la elección correcta cuando quieres comportamiento medido y la equivocada cuando esperabas que la página pareciera una conexión típica de la región de salida.

Un worker que informa algo distinto. La política resuelta debe aplicarse por igual a páginas y workers del contexto. Si un worker dedicado o compartido que usa la aplicación informa valores distintos de los de la página, trátalo como un hallazgo y anota qué política y qué contexto lo produjeron.

Una base nativa tomada en otra conexión. Los valores nativos dependen de la conexión del host en el momento de la ejecución, así que dos ejecuciones nativas en redes distintas, o con horas de diferencia, no son directamente comparables. Haz las ejecuciones nativa y con override seguidas, en el mismo host y por la misma ruta.

Un contexto cambiado demasiado tarde. Como la política resuelta queda fijada para el contexto, un valor leído en una página que existía antes de aplicar la política puede diferir de uno leído en un contexto nuevo. Cuando dos lecturas discrepen, compáralas en contextos separados creados cada uno con la misma política.

Revisar una ejecución nativa frente a una con override

Una revisión es una comparación, no una lectura aislada. Ejecuta la página una vez con la política nativa y otra con la política que quieres probar. Mantén igual la versión del navegador, el perfil, la ruta del proxy, el viewport y el estado de la aplicación, y cambia solo el valor de la política. Usa un contexto nuevo para cada ejecución, de modo que la política nueva no se mezcle con una página que ya estaba establecida.

1. Anota el texto exacto de la política de cada ejecución, incluidos los nombres de los campos.
2. Abre una página de diagnóstico pequeña que muestre effectiveType, rtt, downlink, type y saveData, y nada más.
3. Lee los valores desde la consola como se muestra abajo, en la página y en un worker si la aplicación lo usa.
4. Compara las Client Hints de red que llegan a un servidor que administras, si ese servidor las solicita.
5. Repite la lectura tras una navegación para confirmar que el contexto mantiene un único resultado.

const c = navigator.connection;
console.log(c.effectiveType, c.rtt, c.downlink, c.type, c.saveData);

Imagina un despliegue que usa una salida de proxy en otra región junto con un perfil de escritorio con banda ancha. La ejecución nativa muestra los valores medidos del host. La ejecución con el perfil debería mostrar en su lugar la clase de conexión del perfil, con valores redondeados que se mantienen estables dentro del contexto. Una ejecución por campos que nombre solo rtt debería cambiar ese único valor y dejar effectiveType, downlink y los demás campos como los informó la ejecución nativa. Si la ejecución por campos cambia más campos de los que nombra, o no cambia nada, lo primero que hay que releer es el texto de la política.

Un buen resultado se ve así. Los campos nombrados en la política cambian juntos, tanto en la página como en las cabeceras de petición, mientras que los campos omitidos conservan sus valores nativos. Los valores pueden redondearse o variar un poco entre orígenes, algo esperable y que no es un fallo. Igual de importante es lo que no cambia. El rendimiento del proxy, el enrutamiento y cualquier latencia que un servidor mida en sus propias peticiones siguen siendo los mismos, así que una comparación que espere que el servidor observe otra velocidad está probando lo que no toca.

Cuando un valor parezca erróneo, revisa en este orden: el perfil que se cargó, la sintaxis del JSON, los nombres de los campos, si la política se fijó antes de la primera página del contexto, cuál de los ajustes de línea de comandos y de perfil prevaleció, y la ruta del proxy. Una política ignorada por no ser válida devuelve los valores medidos, así que una página que parece sin cambios no significa que el navegador haya dejado de funcionar. Un contexto separado es la forma más limpia de probar una política corregida.

Limita el registro de la revisión a la configuración y a los resultados visibles: la versión, el nombre del perfil, el texto de la política, una etiqueta de la ruta y los valores leídos. Deja fuera el contenido de la página, las credenciales y los datos privados de las peticiones. Eso basta para que otra persona repita la comparación y mantiene el registro seguro para compartirlo con el equipo.

Repite la comparación cada vez que cambien la versión del navegador, el perfil o el proveedor del proxy, porque las reglas de redondeo, las propiedades admitidas y la propia ruta pueden moverse. Una comparación guardada de la versión anterior es una buena referencia. Si los campos nombrados siguen cambiando juntos y los omitidos siguen siendo nativos, la política sigue haciendo lo que el despliegue espera. Si los números difieren pero las relaciones se mantienen, la causa suele ser el redondeo normal y la variación por host, no una política rota.

Dónde encaja BotBrowser

BotBrowser soporta una única política --bot-network-info-override, ya sea la base del perfil, los valores nativos o un JSON por campos, que fija las propiedades de navigator.connection y las Client Hints correspondientes en cada contexto del navegador, de modo que puedes mantener los valores de red que ve una página alineados con el perfil y el escenario de proxy que elegiste. No cambia la velocidad ni la latencia reales de un proxy, las mediciones del lado del servidor ni lo que un sitio deduce de otras señales de red, y una política no válida se ignora, con lo que permanecen los valores nativos medidos.

Los valores de red son una entrada entre muchas, así que mantenlos coherentes con la zona horaria, la configuración regional y el idioma elegidos para la misma ruta, como se describe en configuración de zona horaria y configuración regional. La compatibilidad de los navegadores y los detalles de la especificación cambian, así que consulta las fuentes de abajo cuando una propiedad o una pista se comporte de otra forma en una versión nueva del navegador.

Fuentes públicas

• WICG Network Information API
• MDN: NetworkInformation
• Documentación de propiedades de navigator de BotBrowser

Conclusión práctica

Una revisión de información de red deja tres piezas: el texto exacto de --bot-network-info-override, los cinco valores leídos en la página y en un worker, y las cabeceras RTT, Downlink, ECT y Save-Data que recibe un servidor tuyo. Cuando una ejecución parece nativa, lee el texto de la política antes que los números, porque un objeto JSON rechazado vuelve en silencio a los valores medidos. Repite el par de ejecuciones tras cualquier versión nueva del navegador, cambio de perfil o cambio de proveedor de proxy, y compara los dos registros campo por campo en lugar de mirar un solo número.