performance.now: resolución del reloj y fingerprinting

performance.now() es la superficie temporal que una revisión de privacidad examina primero: ninguna petición de permisos la bloquea, y su resolución junto con sus pequeñas irregularidades describen la máquina que hay debajo. BotBrowser puede hacer reproducibles ciertos valores para pruebas autorizadas, pero no sustituye el hardware del host ni promete la aceptación de todos los detectores.

TL;DR

• La resolución y el jitter de performance.now() son la señal principal aquí; hardwareConcurrency y deviceMemory son los dos valores que suelen leerse junto a ella.
• Una VPN, una ventana privada o borrar cookies no cambia las superficies de hardware locales.
• Las opciones de tiempo de BotBrowser permiten validar de forma reproducible; no garantizan anonimato ni aceptación por un detector.

Contents

• Qué expone performance.now() sobre el reloj
• Por qué la combinación es más distintiva
• Lo que dejan intacto las VPN, las ventanas privadas, las extensiones y el ruido
• Configurar el tiempo informado con un perfil de BotBrowser
• Verificar que el tiempo se mantiene coherente
• Hasta dónde llega BotBrowser y dónde se detiene
• Conclusión práctica

Qué expone performance.now() sobre el reloj

Las API de tiempo se crearon para que los desarrolladores midan su propio código, pero el mismo reloj permite que un sitio web observe algo de la máquina que lo ejecuta. performance.now() es la superficie que más información aporta por byte, porque dos propiedades de la lectura se deciden fuera de la página: cuán fino es el reloj y cuánto oscilan las lecturas sucesivas.

La llamada devuelve una marca de tiempo de alta resolución medida desde el inicio del origen temporal de la página. Los navegadores reducen a propósito la precisión de ese reloj, y la referencia de MDN explica que la resolución más fina solo se ofrece a páginas aisladas de origen cruzado, mientras que algunos modos del navegador orientados a la privacidad la redondean todavía más. El redondeo cambia la resolución, no la forma. Un script que repite el mismo trabajo sigue midiendo cuánto tarda ese trabajo, y la duración depende de la velocidad de la CPU, del comportamiento de la caché, de la planificación y de lo ocupada que esté la máquina en ese momento.

Esa reducción tiene una historia. Se demostró que los relojes de alta resolución podían servir para ataques de canal lateral del tipo Spectre, de modo que los fabricantes de navegadores redujeron la precisión del temporizador, añadieron variación y vincularon la mejor precisión al aislamiento de origen cruzado. Esa medida se diseñó para proteger el contenido de la memoria, no para quitar la forma del hardware del cuadro. Un temporizador grueso que se lee muchas veces sigue aportando información sobre cuánto tarda una tarea en una máquina concreta, y la dispersión entre esas lecturas dice tanto como las lecturas mismas.

Dos valores más suelen acompañar al reloj, y este artículo los trata como contexto y no como su tema. hardwareConcurrency indica el número de procesadores lógicos disponibles para el navegador, y los equipos reales se agrupan en torno a valores como 4, 8, 12 y 16. deviceMemory devuelve una clase de RAM aproximada en gigabytes, redondeada a una potencia de dos y con un límite superior, y los navegadores basados en Chromium solo la exponen en contextos seguros. La guía de planificación de workers explica cómo dimensionar un pool a partir de ese número de núcleos; aquí lo relevante es solo que una lectura de tiempo es más distintiva cuando se compara con ellos.

Ninguno de estos valores necesita un aviso de permisos, ninguno muestra un indicador visible y ninguno se borra al eliminar las cookies. Por eso aparecen en la investigación sobre huellas digitales, aunque cada número parezca inofensivo por separado. Las secciones siguientes explican cómo se combinan las lecturas, qué medidas de privacidad habituales las dejan intactas y cómo puedes configurar y verificar un tiempo informado coherente con BotBrowser.

Por qué la combinación es más distintiva

Por sí sola, cada una de estas señales aporta poca información. Muchos dispositivos comparten el mismo número de núcleos y la clase de memoria tiene pocos valores posibles. La combinación es distinta, porque un sitio puede leer las tres de una vez y añadir una breve muestra de tiempo. Un dispositivo que devuelve una dispersión concreta de deltas de performance.now(), ocho núcleos y una clase de memoria de 8 GB cae en un grupo mucho más pequeño que el descrito por cualquiera de esos datos aislados.

La combinación también se compara con el resto del navegador. Es habitual que los revisores vean los valores de tiempo y de hardware leídos junto al renderizador gráfico, el tamaño de pantalla, la cadena de plataforma y la lista de fuentes, y una página puede comprobar si describen la misma máquina. Un perfil que afirma ser un portátil modesto pero devuelve los tiempos de una estación de trabajo rápida, o al revés, es más distintivo que un perfil simplemente ordinario.

Imagina la revisión de un perfil de prueba que describe un portátil de gama media con ocho núcleos lógicos y una clase de memoria de 8 GB. En una página que controlas, el número de núcleos y la clase de memoria se leen como se espera. Después, una muestra de tiempo muestra que el bucle termina mucho más rápido de lo que lograría un portátil de esa clase, porque el equipo real es un servidor de gama alta. Cada valor de hardware coincide con el perfil, pero el tiempo no coincide con ellos. En la práctica, el rango documentado de la escala, de 0.80 a 0.99, es estrecho, por lo que puede suavizar un desvío moderado pero no convertir una clase de hardware en otra, y solo quien lee las superficies en conjunto notará la diferencia.

La estabilidad importa tanto como los valores. Un número de núcleos que cambia entre cargas de página, o un tiempo que se comporta de una forma en una pestaña y de otra en la siguiente, es más distintivo que un valor estable pero corriente. Esa es la razón principal por la que una semilla repetible resulta útil en una revisión: elimina una fuente de variación, de modo que cualquier diferencia que quede entre ejecuciones apunta a otra causa.

Por eso este tema trata de coherencia y no de ocultación. El objetivo de una revisión de privacidad cuidadosa no es dejar cada número lo más pequeño posible. Es asegurarse de que la forma del hardware informada por una superficie coincide con la informada por las demás, y de que esa coincidencia se mantiene en cada carga de página, en cada worker y a lo largo del tiempo.

Tres preguntas ayudan a estructurar una revisión:

• ¿hardwareConcurrency y deviceMemory describen la misma clase de máquina que el perfil cargado?
• ¿Las muestras de tiempo repetidas en una página se parecen a esa misma clase de máquina y se mantienen similares de una ejecución a otra?
• ¿Las entradas de Navigation Timing y Resource Timing resultan coherentes con el perfil en lugar de reflejar la conexión real del equipo?

Lo que dejan intacto las VPN, las ventanas privadas, las extensiones y el ruido

Una comparación útil conserva hardwareConcurrency=8, deviceMemory=8 y una muestra de performance.now() de 100 iteraciones; una VPN no cambia esos tres campos locales.

Una VPN cambia la ruta de red y la dirección IP que ve un servidor. No cambia lo rápido que tu procesador ejecuta un bucle, cuántos núcleos lógicos informa el navegador ni qué clase de memoria expone. Los tres valores se leen en local, así que dos máquinas distintas detrás del mismo punto de salida de una VPN siguen informando formas de hardware diferentes.

Las ventanas de navegación privada descartan cookies, historial y datos del sitio al cerrarlas. No cambian el número de núcleos, la clase de memoria ni la velocidad del hardware subyacente, por lo que los valores de tiempo y de hardware en una ventana privada coinciden con los de una ventana normal en la misma máquina.

Reinstalar el navegador, cambiar a otro navegador en el mismo ordenador o borrar todos los datos del sitio deja el mismo procesador, el mismo número de núcleos y la misma memoria. Distintos navegadores pueden informar valores diferentes por sus propias reglas de redondeo y límites, pero un navegador en una máquina es estable, y precisamente por eso estos valores funcionan como una señal de larga duración.

Las extensiones que sobrescriben propiedades de hardware suelen inyectar un script que redefine una propiedad en la página. Eso puede dejar rastros visibles, como descriptores de propiedad distintos de los propios del navegador, o un marco nuevo que lee el valor real antes de que la extensión se ejecute. También puede crear contradicciones: una página que informa de cuatro núcleos mientras un conjunto de workers ejecuta claramente más tareas en paralelo se nota con más facilidad que un valor sin modificar.

El ruido aleatorio añadido a los valores de tiempo tiene un problema parecido. Una secuencia de marcas con variación artificial no se parece a la variación del hardware real, puede romper la monitorización legítima del rendimiento en las páginas que visitas, y un ruido que cambia en cada llamada es en sí mismo un patrón visible. Los valores informados estables y verosímiles suelen ser más fáciles de defender que los aleatorios.

Algunos navegadores incluyen sus propias protecciones, como una precisión de temporizador reducida o un número de núcleos limitado. Reducen la información que una página puede leer, pero se aplican a todo el que usa el mismo modo, de modo que los valores informados se vuelven comunes en lugar de únicos. Tampoco hacen que los valores coincidan con una clase de hardware concreta, así que la coherencia con un perfil elegido sigue debiendo comprobarse por separado.

Nada de esto hace inútiles esas herramientas. Una VPN protege la capa de red, las ventanas privadas protegen el historial local y las extensiones pueden bloquear muchos rastreadores antes de que carguen. Cubren superficies distintas. La forma del tiempo y del hardware es una superficie para la que no se diseñaron, así que una revisión debe tratarla por separado y comprobarla directamente.

Configurar el tiempo informado con un perfil de BotBrowser

Empieza por un perfil, porque el perfil define los valores de hardware con los que deben mantenerse coherentes las opciones de tiempo. Un arranque solo con perfil te da una línea base con la que comparar antes de añadir cualquier opción de tiempo. Después añade las opciones de una en una y anota qué cambia. Guarda la salida de la consola de cada paso en un archivo de texto plano junto al comando de arranque.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-time-scale=0.92 \
  --bot-time-seed=42

--bot-time-scale comprime los intervalos de tiempo de alta resolución que se informan. El rango documentado es de 0.80 a 0.99, y un valor más cercano a 0.80 comprime los intervalos más que uno cercano a 0.99. La documentación describe el efecto como emular una carga de sistema menor y reducir las señales de desvío de tiempo. Es una opción ENT Tier2.

--bot-time-seed acepta un entero de 1 a 4294967295, y 0 la desactiva. Cada semilla produce un perfil de tiempo estable que reparte una diversidad determinista entre las operaciones del navegador y las entradas de navigation timing, de modo que la misma semilla con el mismo perfil da el mismo comportamiento en la siguiente ejecución. También es una opción ENT Tier2.

Usa una semilla distinta para cada instancia cuando quieras que las instancias se diferencien, y mantén una semilla fija cuando quieras que una prueba sea repetible. La documentación de rendimiento señala el tiempo idéntico entre instancias como el síntoma de reutilizar una misma semilla. La escala y la semilla abordan aspectos distintos del tiempo, y la documentación indica que pueden usarse juntas.

--bot-performance-timing es una opción independiente para las entradas de tiempo visibles desde el navegador, como las fases de conexión en Navigation Timing y Resource Timing. Acepta basic y advanced, necesita ENT Tier3 y solo funciona cuando el paquete de perfil activo habilita Performance Timing Protection. Debe establecerse antes de que arranque la primera página o el primer worker y se resuelve por contexto del navegador. Omítela, o pasa false, para dejar la política desactivada.

Trabaja en un orden fijo. Ejecuta la línea base solo con perfil y guarda la salida de verificación. Añade la escala de tiempo y compara. Añade la semilla y vuelve a comparar. Añade --bot-performance-timing al final, y solo cuando tu nivel y tu perfil lo admitan, porque afecta a un conjunto de superficies distinto del de las otras dos. Cambiarlo todo a la vez impide saber qué opción produjo cada diferencia. Consulta la referencia de opciones de la CLI para tu nivel antes de planificar una prueba, de modo que un resultado que parezca erróneo no sea simplemente una opción que tu nivel no cubre.

Verificar que el tiempo se mantiene coherente

Ejecuta la verificación solo en páginas y sesiones de prueba que estés autorizado a usar. Abre una página en blanco que controles, arranca con el perfil y las opciones anteriores y compara lo que leas con lo que describe el perfil. Anota el perfil con el que arrancaste antes de leer ningún valor, para que la comparación no se haga de memoria. El fragmento siguiente puede pegarse en la consola de desarrollo de esa página.

const { hardwareConcurrency, deviceMemory } = navigator;
const samples = [];
for (let run = 0; run < 5; run += 1) {
  const start = performance.now();
  for (let i = 0; i < 100000; i += 1) Math.sqrt(i);
  samples.push(performance.now() - start);
}
console.log({ hardwareConcurrency, deviceMemory, samples });

El fragmento lee los dos valores de hardware y reúne cinco muestras de tiempo breves. Trata la salida como una comprobación de coherencia y no como una prueba de rendimiento: los números absolutos dependen del equipo, y lo que buscas es que los valores informados coincidan con el perfil.

Qué comprobar:

1. hardwareConcurrency coincide con el número de núcleos que describe el perfil.
2. deviceMemory coincide con la clase de memoria que describe el perfil.
3. Las cinco muestras se parecen entre sí, y un segundo arranque con el mismo perfil, escala y semilla produce un patrón coherente.
4. Cambiar solo la semilla cambia el patrón, lo que confirma que la semilla se aplica.
5. Leer los mismos valores dentro de un worker dedicado y de un iframe da los mismos valores de hardware que la página principal.

Las muestras de tiempo nunca serán idénticas, y no deben serlo. El hardware real varía ligeramente de una ejecución a otra por la planificación y el estado de la caché. Un conjunto de muestras perfectamente plano, o uno que oscila sin control, merece más sospecha que uno con una variación natural pequeña.

Los valores de hardware y de tiempo deberían leerse igual allí donde se ejecute un script. Un sitio puede crear workers dedicados y marcos con la misma facilidad con que lee la página principal, de modo que una discrepancia entre ellos es fácil de encontrar. Prueba también esos contextos y trata cualquier diferencia como un hallazgo que registrar, no como una anomalía que justificar.

Si un resultado no coincide, cambia un ajuste cada vez y repite la ejecución, que es el método que recomienda la documentación de rendimiento para resolver problemas. Las causas habituales son una semilla ausente o equivocada, un perfil que no incluye la función o un nivel ENT que no cubre la opción.

Las páginas públicas de prueba de huellas pueden dar una segunda opinión, pero no publican criterios de aprobación garantizados, y un resultado limpio en una página no es una promesa sobre ningún otro sitio. Trata cada página como un único dato y compara varias ejecuciones antes de sacar una conclusión. Conserva el comando de arranque exacto junto con los resultados para que otro revisor pueda repetir la ejecución más adelante.

Hasta dónde llega BotBrowser y dónde se detiene

BotBrowser documenta --bot-time-scale y --bot-time-seed (ENT Tier2) para comprimir los intervalos de tiempo de alta resolución informados al contenido de la página y para dar a cada instancia un perfil de tiempo estable y reproducible con semilla junto a los valores de hardware que define el perfil, de modo que puedas repetir un tiempo coherente entre sesiones de prueba. BotBrowser no puede cambiar la rapidez con la que el equipo ejecuta realmente JavaScript, no sustituye el hardware físico y no garantiza que cada superficie de tiempo o cada detector de terceros acepte el resultado; las opciones solo cambian los valores informados al contenido de la página y dependen del nivel ENT y de la compatibilidad del perfil, y --bot-performance-timing necesita además ENT Tier3 y un perfil que lo habilite.

En la práctica, el resultado útil es una línea base reproducible. Puedes anotar el perfil, la escala y la semilla, repetir las mismas comprobaciones otro día y ver si algo de la forma del hardware o del tiempo ha cambiado. Es una afirmación más acotada que ocultar un dispositivo, y es la que las opciones están documentadas para respaldar.

Estos valores describen un dispositivo y no a una persona. La forma del tiempo y del hardware es una entrada entre muchas, y ningún valor aislado decide cómo trata un sitio a un visitante. Esta página no afirma nada sobre la precisión con la que un rastreador identifica un dispositivo; el objetivo es ayudarte a comprobar que lo que informa tu navegador es internamente coherente y está documentado con honestidad.

Un registro de revisión es más útil cuando enumera:

• El archivo de perfil y la versión de BotBrowser utilizada.
• Las opciones exactas, incluidas la escala y la semilla.
• El nivel ENT disponible para la ejecución.
• Los valores de hardware y las muestras de tiempo que se leyeron.
• La fecha y la página usada para la comprobación.

Estas lecturas cubren las superficies vecinas. La guía general sobre huellas del navegador explica cómo se combinan las señales, hardwareConcurrency y la planificación de workers analiza con más detalle el número de núcleos y el control de la tasa de cuadros trata la opción de tiempo de la pantalla.

Fuentes públicas

• MDN: Performance.now()
• MDN: Navigator.hardwareConcurrency
• MDN: Navigator.deviceMemory
• Documentación de BotBrowser: Performance Fingerprinting
• Documentación de BotBrowser: Performance Timing Protection

Conclusión práctica

Usa los valores de tiempo y hardware como evidencia de coherencia, no como una promesa de que el navegador será indistinguible de otra máquina. Empieza con una línea base solo con el perfil, cambia una opción compatible cada vez, registra el comando exacto y el nivel ENT, y repite las comprobaciones autorizadas en la página, el worker y el iframe. Si los valores no coinciden, registra la diferencia e investiga el perfil o el host en vez de añadir ruido sin explicar.