Huella de audio explicada: cómo AudioContext te rastrea

BotBrowser puede hacer reproducible la lectura de AudioContext en una prueba autorizada con un perfil, nivel, modo de despliegue y --bot-noise-seed fijo declarados. No puede garantizar anonimato, aceptación por un sitio ni un renderizado de audio idéntico en todos los hosts, perfiles o pilas de audio.

Ver el video

Este video en inglés explica cómo una página silenciosa puede leer un número del motor de audio del navegador mediante renderizado sin conexión, y ejecuta en una comprobación local una rutina fija de Web Audio dos veces con una frecuencia de muestreo y una vez con otra mayor. No usa proxy ni perfil y no demuestra identidad, anonimato, acceso ni la decisión de un sitio remoto. El audio está en inglés.

Por qué el audio se convierte en una huella

Todo navegador web incluye un sistema de procesamiento de audio. La Web Audio API, en concreto AudioContext y OfflineAudioContext, permite que una página cree, conecte y analice señales de audio íntegramente por software. No hace falta acceso al micrófono, no se reproduce ningún sonido y no aparece ningún aviso de permiso. La API existe para usos legítimos como juegos, aplicaciones musicales y efectos de audio en tiempo real. La misma cadena de procesamiento puede producir mediciones distintas bajo condiciones de renderizado diferentes, y los sistemas de rastreo pueden combinar esa variación con otras señales. Este identificador se llama huella de audio; la repetibilidad depende de la medición y no está garantizada tras borrar cookies, actualizar versiones o cambiar de contexto. Cómo acceden las páginas a esta API y cómo se usa el audio en flujos de trabajo habituales se explica en Acceso a Web Audio API y flujos de audio prácticos.

La variación no es un defecto de un navegador concreto. La especificación de Web Audio describe lo que debe hacer cada nodo, pero los resultados en coma flotante que salen de una máquina real dependen de la implementación, de la pila de audio del sistema operativo y de la frecuencia de muestreo en uso. Dos dispositivos pueden ejecutar el mismo JavaScript y aun así producir búferes que difieren en los dígitos de menor peso. Esos dígitos son pequeños, pero se repiten en el mismo dispositivo, y esa combinación es lo que los hace útiles como señal.

Las secciones siguientes siguen la variación desde su origen hasta una comprobación práctica: de dónde viene, por qué las medidas de privacidad habituales dejan incoherencias visibles, qué documenta BotBrowser sobre la salida de audio y cómo confirmar la coherencia en tu propia configuración.

TL;DR

• Web Audio y OfflineAudioContext pueden exponer diferencias repetibles sin micrófono ni sonido audible.
• Un valor de audio describe versión, perfil, frecuencia, canales y contexto declarados; no prueba un dispositivo físico.
• Una VPN o borrar cookies no cambia el renderizado local, y una aleatorización parcial puede crear incoherencias.
• Un perfil válido con --bot-noise-seed fija permite reproducir sesiones autorizadas comparables bajo ENT Tier2.
• Comprueba audio junto con canvas, WebGL, fuentes y navigator; BotBrowser no garantiza anonimato ni aceptación.

Contenido

• Ver el video
• Por qué el audio se convierte en una huella
• Por qué las VPN, las extensiones de ruido y la aleatorización dejan incoherencias
• Comportamiento de audio de BotBrowser y opciones de lanzamiento
• Verificar la coherencia del audio en tu propia configuración
• FAQ: Preguntas sobre la huella de audio
• Conclusiones

El diagrama resume la idea en una sola imagen. La rutina se mantiene constante mientras las condiciones de renderizado declaradas pueden cambiar los números; un perfil con una semilla fija puede hacer reproducibles sesiones comparables cuando se mantienen la versión, el perfil, el despliegue y el contexto.

Impacto en la privacidad del renderizado de audio silencioso

La huella de audio resulta atractiva para quien rastrea porque es silenciosa. El usuario no recibe ninguna notificación, ningún cuadro de permiso ni ninguna indicación visual de que se está procesando audio. Una página puede crear un contexto de renderizado sin conexión, procesar un búfer corto y leer el resultado en una fracción de segundo, sin tocar nunca los altavoces.

La investigación pública de medición de la web, como el estudio de Englehardt y Narayanan de 2016 sobre un millón de sitios, ha documentado scripts que usan el renderizado de audio como una de varias señales para reconocer navegadores que vuelven. La señal rara vez se usa sola. Se combina con canvas, WebGL, fuentes, propiedades de pantalla y valores de navigator, y cada señal adicional reduce el grupo de dispositivos que podrían haber producido el resultado combinado. La frecuencia de refresco de la pantalla y el ritmo del vídeo forman otra señal relacionada con el tiempo, tratada en Huella de tasa de cuadros: frecuencia de pantalla y vídeo.

La salida de audio puede parecerse entre ejecuciones repetidas cuando se mantienen la versión, el perfil, los parámetros y las condiciones de sesión, pero es un resultado de medición y no una garantía. La navegación privada, las cookies o una VPN no necesariamente cambian un renderizado offline, mientras que una actualización o un cambio de implementación sí puede hacerlo. También importan las demás señales visibles para la página.

La cuestión de privacidad no es, por tanto, si un sitio puede usar AudioContext. El audio es una parte normal de la plataforma web y muchos sitios dependen de él para reproducir sonido. La cuestión es si los números que devuelve una rutina de audio reflejan tu hardware real y si siguen siendo coherentes con todo lo demás que el navegador informa sobre sí mismo.

Cómo difiere el renderizado de OfflineAudioContext entre dispositivos

La Web Audio API ofrece dos interfaces principales relevantes para este tema.

AudioContext gestiona el procesamiento de audio en tiempo real. Crea un grafo de audio en el que los nodos representan operaciones como oscilación, control de ganancia, compresión y análisis. Cada nodo procesa muestras de audio, y la salida depende del subsistema de audio subyacente.

OfflineAudioContext renderiza audio en un búfer sin producir sonido audible. Se ejecuta más rápido que el tiempo real, no necesita un gesto del usuario para renderizar y devuelve el resultado como una matriz de muestras en coma flotante. Por eso es la interfaz que más se usa cuando el audio se trata como señal del dispositivo. Una rutina típica, a nivel conceptual, conecta un oscilador a un compresor, renderiza un búfer corto y reduce las muestras resultantes a un solo número, por ejemplo una suma.

¿Por qué varía la salida entre dispositivos? Contribuyen varios factores.

• Implementación del navegador y parámetros de renderizado. OfflineAudioContext no reproduce por los altavoces; las diferencias deben atribuirse a la implementación, versión, frecuencia, canales y demás parámetros, salvo que una medición controlada demuestre otra causa.
• Configuración dependiente del host. El sistema operativo y el dispositivo pueden influir en los parámetros negociados, pero un único resultado offline no demuestra una causa de hardware sin una comparación controlada.
• Implementación del navegador. Chromium, Firefox y WebKit implementan la especificación de Web Audio de forma independiente. La precisión interna, las optimizaciones de ruta rápida y los ajustes de compilación difieren entre ellos.
• Negociación de la frecuencia de muestreo. La frecuencia por defecto depende del sistema operativo y del hardware. Un sistema que usa 44100 Hz por defecto produce una salida de compresor distinta de la de uno que usa 48000 Hz, aunque los nodos y los parámetros sean idénticos.
• Disposición de canales. El número de canales de salida y la forma en que se mezclan pueden cambiar el búfer que la rutina vuelve a leer.

El búfer renderizado puede contener diferencias numéricas sutiles bajo distintas implementaciones o parámetros. Una suma de muestras no es una puntuación y no significa nada por sí sola. Es el final de decisiones de implementación, versión, frecuencia, canales y aritmética que deben registrarse para comparar justamente.

Un modelo mental útil es que el resultado de audio es una medición de toda la pila de reproducción, tomada sin que el usuario lo note. Leer AudioContext.sampleRate indica a la página qué frecuencia negoció la pila. Renderizar un búfer le indica cómo trata esa pila la aritmética. Leer la salida de un analizador le indica cómo se comportan los nodos de análisis con la misma entrada. Cada una de estas lecturas es barata, ninguna necesita permiso, y juntas describen el equipo con mucha más precisión que cualquier valor aislado.

Por qué las VPN, las extensiones de ruido y la aleatorización dejan incoherencias

Algunas medidas habituales se presentan a veces como respuesta a la huella de audio. Cada una tiene un límite que conviene entender antes de confiar en ella.

Las VPN cambian tu dirección IP pero no tienen ningún efecto sobre el renderizado de audio. La Web Audio API se ejecuta íntegramente dentro del navegador y no tiene componente de red. El resultado de audio es el mismo tanto si te conectas mediante una VPN, un proxy o directamente.

Las extensiones del navegador que ofrecen protección de audio suelen interceptar llamadas de JavaScript y añadir ruido aleatorio a los valores devueltos. Este enfoque tiene tres límites que puedes comprobar en tus propias pruebas. Primero, un dispositivo genuino repite su propio resultado, así que una rutina que devuelve un valor distinto en cada ejecución de tu prueba indica que la salida no es estable. Segundo, una extensión puede cubrir solo algunos métodos, por ejemplo la lectura del búfer, y dejar intactos otros relacionados como AnalyserNode.getFloatFrequencyData, así que compara los valores relacionados entre sí para confirmar que concuerdan. Tercero, una extensión trabaja a nivel de página y no cambia cómo se renderizó el audio en primer lugar.

Aleatorizar parámetros de audio como la frecuencia de muestreo o el número de canales suele romper aplicaciones que dependen de una reproducción de audio precisa. Las herramientas musicales, las videollamadas y los juegos dependen de un comportamiento de audio estable. Además, un valor aleatorizado debe concordar con lo que realmente se renderizó. Una frecuencia de muestreo declarada que no coincide con la salida renderizada es una combinación que ningún dispositivo real produce.

Bloquear AudioContext por completo es la opción más drástica. Impide la señal, pero también impide el audio legítimo, y la ausencia de una interfaz de audio es en sí misma inusual en un navegador moderno.

Normalizar la salida para todos los usuarios reduce la información de la señal, pero crea un valor compartido que es distintivo para el grupo que lo usa. Puede ser un compromiso razonable en un entorno controlado, y es distinto de mantener el audio coherente con un perfil de dispositivo concreto.

El hilo común es la coherencia. Un enfoque eficaz debe mantener alineadas tres cosas: los valores que lee la página, las muestras que realmente se renderizan y el resto de la identidad que informa el navegador. Un cambio aplicado solo a una de ellas deja una incoherencia más difícil de explicar que la diferencia original.

Comportamiento de audio de BotBrowser y opciones de lanzamiento

Según la documentación de audio de BotBrowser, BotBrowser puede aplicar ruido determinista a la salida de Web Audio bajo un perfil válido y las condiciones documentadas de nivel y despliegue. La documentación enumera el comportamiento siguiente; cada resultado debe validarse con la versión, el perfil, las opciones y el contexto exactos.

Ruido guiado por el perfil, activado por defecto. El ruido de AudioContext está activado por defecto. La opción --bot-noise-audio-context lo controla de forma explícita, con true como valor por defecto y false para desactivarlo.

Reproducibilidad con una semilla de ruido. --bot-noise-seed está pensada para reproducir la salida en sesiones comparables. Reutilizar la misma semilla también puede hacer que las sesiones sean vinculables; no garantiza resultados idénticos en todas las versiones, hosts, despliegues o contextos. Requiere ENT Tier2. Sin una semilla fija, el ruido varía por sesión por diseño.

Coherencia entre contextos de ejecución. La documentación describe coherencia entre el hilo principal, Web Workers y Service Workers dentro de una sesión. Trátala como una capacidad documentada que debe verificarse en la versión y contexto exactos, no como una garantía universal.

Una herramienta de grabación para tu propia revisión. BotBrowser ofrece AudioLab, una herramienta que registra las llamadas a la Web Audio API que hace una página durante una sesión. Está documentada como una forma de estudiar cómo se recogen las señales de audio y de verificar tu propia configuración.

También hay límites. La salida de BotBrowser sigue el perfil solo cuando se carga un perfil válido. La reproducibilidad con semilla fija depende del nivel ENT Tier2. Algunas configuraciones headless pueden no inicializar el audio en absoluto, así que confirma que tu modo de despliegue admite audio antes de fiarte de un resultado. El audio es una señal entre muchas, y un resultado de audio coherente no garantiza cómo tratará un sitio concreto una sesión. Esos límites se repiten en las conclusiones al final de este artículo.

Carga básica de perfil

La configuración más simple carga un perfil que incluye parámetros de audio:

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Esta única opción configura el comportamiento de audio para que siga el perfil cargado.

Audio reproducible con una semilla de ruido

Para obtener resultados de audio reproducibles entre sesiones:

chrome --bot-profile="path/to/profile.enc" \
       --bot-noise-seed=42 \
       --user-data-dir="$(mktemp -d)"

La misma combinación de perfil y semilla da la misma salida de audio. Cambia la semilla para obtener un resultado distinto pero igualmente estable. La semilla acepta valores enteros desde 1 hasta el mayor entero sin signo de 32 bits, y un valor de 0 mantiene los valores por defecto del perfil sin semilla determinista. Esta opción requiere ENT Tier2.

Integración con Playwright

const { chromium } = require('playwright');

const browser = await chromium.launch({
  executablePath: 'path/to/botbrowser/chrome',
  args: ['--bot-profile=path/to/profile.enc', '--bot-noise-seed=42'],
});

Puppeteer acepta los mismos argumentos mediante su opción args. Las opciones son argumentos normales del navegador, así que el mismo perfil y la misma semilla funcionan en cualquiera de las dos bibliotecas.

Ver la salida base del perfil

Si quieres la salida de audio base del perfil sin ruido aplicado:

chrome --bot-profile="path/to/profile.enc" \
       --bot-noise-audio-context=false \
       --user-data-dir="$(mktemp -d)"

Es un paso de comparación, no un valor por defecto recomendado. Muestra lo que aporta el perfil antes de añadir ruido.

Verificar la coherencia del audio en tu propia configuración

Para confirmar que la salida de audio sigue el perfil cargado, compara resultados entre tus propias sesiones. Usa una página de prueba que controles o una página pública de pruebas de huella, y anota los valores de audio que muestra en cada lanzamiento.

Comprobación de reproducibilidad. Lanza dos sesiones separadas con el mismo perfil y el mismo --bot-noise-seed, ejecuta la misma rutina de audio en cada una y compara la salida. Los dos resultados deberían coincidir. Lanza una tercera sesión con otra semilla y confirma que su resultado es distinto pero estable al repetirlo. La semilla fija requiere ENT Tier2.

Comprobación entre máquinas. Ejecuta el mismo perfil y semilla en dos máquinas y compara. Registra versión, modo de despliegue, parámetros de audio y condiciones del host; una coincidencia solo es evidencia de esa configuración, no una garantía para todas las máquinas.

Comprobación de contextos. Ejecuta la rutina en la página principal y en un Web Worker. La documentación describe coherencia entre esos contextos; verifica la versión, perfil, nivel y opciones exactos antes de tratar una diferencia como defecto.

Comprobación de valores relacionados. Compara la frecuencia de muestreo que informa tu configuración, el búfer que produce un renderizado sin conexión y los datos de frecuencia de un nodo analizador. Todos deberían parecer procedentes del mismo dispositivo. Un valor informado que no concuerda con la salida renderizada indica que conviene revisar tu configuración.

Registro de llamadas. Para una revisión más profunda, AudioLab puede registrar las llamadas de Web Audio que hace una página en una sesión, de modo que veas qué funciones de audio usa realmente antes de decidir qué comparar.

Estas comprobaciones se ejecutan en tus propias máquinas. No requieren permiso de micrófono y no dependen de tu red, por eso las comprobaciones útiles se hacen dentro del navegador.

Cómo leer tus propios resultados de audio

Los números de audio son fáciles de malinterpretar porque parecen arbitrarios. Estas tres preguntas ayudan al revisar la salida de tu propia configuración.

Primero, ¿concuerda la configuración informada con la salida renderizada? Puedes leer directamente la frecuencia de muestreo y el número de canales, renderizar un búfer corto sin conexión y comparar el resultado con lo que esa configuración debería producir. Cuando ambos proceden de lugares distintos, por ejemplo una frecuencia modificada sobre un renderizado sin modificar, la combinación no es una que produzca un dispositivo real. La concordancia entre los valores informados y las muestras renderizadas importa más que cualquier número aislado.

Segundo, ¿concuerda el resultado de audio con el resto del perfil? Un perfil que presenta un sistema operativo no debería devolver el comportamiento de audio de otro. El audio por sí solo no prueba nada, y por eso un perfil debe considerarse en conjunto, junto con canvas, WebGL, fuentes y propiedades de navigator.

Tercero, ¿es estable el resultado cuando debe serlo? Un dispositivo genuino devuelve el mismo valor cada vez que ejecuta la misma rutina. Si tu propia prueba devuelve un valor distinto en cada llamada, tu configuración no es reproducible y conviene revisar el perfil y las opciones. Con BotBrowser, lanzar dos sesiones con el mismo perfil y el mismo --bot-noise-seed y comparar la salida es la forma más sencilla de confirmar que tu configuración es reproducible. Una semilla distinta con el mismo perfil debería dar un resultado distinto pero igualmente coherente consigo mismo.

La opción --bot-noise-audio-context=false tiene un propósito concreto. Muestra la salida base del perfil sin ruido, lo que ayuda cuando quieres entender qué aporta el propio perfil. Trátala como un paso de comparación y no como un valor por defecto, porque el ruido está activado por defecto y la mayoría de las configuraciones deberían dejarlo así.

Cambiar la IP, borrar cookies o abrir una ventana privada no prueba por sí solo las condiciones de renderizado. Registra versión, perfil, opciones, frecuencia y contexto antes de decidir si cambió un resultado.

Mantén expectativas realistas. Un resultado de audio coherente es una pieza de una identidad de navegador coherente. No te dice si un sitio concreto aceptará o cuestionará una sesión, y debe revisarse junto con las demás superficies y no de forma aislada.

Hábitos de configuración que mantienen el audio coherente

• Carga siempre un perfil. Ejecutar BotBrowser sin --bot-profile significa que la salida de audio procede de tu hardware nativo. El perfil es lo que hace que la salida de audio siga una plataforma declarada.
• Ajusta el perfil a tu caso de uso. Un perfil de Windows produce una salida de audio típica de Windows. Elige un perfil que coincida con la plataforma que estás probando.
• Deja el ruido de audio activado salvo que estés comparando. La opción --bot-noise-audio-context=false elimina una capa de variación. Úsala para una comparación con el perfil base y vuelve a activarla después.
• Comprueba la salida antes de comparar. En headless, crea un AudioContext y registra si devuelve muestras; una ausencia de salida es un resultado del modo, no una variación de la red.
• Fija las versiones mientras comparas. Si cambian la versión del navegador o el perfil entre dos sesiones, una diferencia en la salida de audio puede deberse a ese cambio y no a tus opciones.

FAQ: Preguntas sobre la huella de audio

P: ¿La huella de audio requiere acceso al micrófono? R: No. Usa las funciones de síntesis y procesamiento de la Web Audio API. No intervienen micrófono, permisos ni sonido audible, y toda la rutina se ejecuta por software.

P: ¿Puedo saber si un sitio web está usando procesamiento de audio? R: En principio, puedes observar la creación de AudioContext y OfflineAudioContext en las herramientas de desarrollo del navegador, y AudioLab puede registrar las llamadas de Web Audio que hace una página durante una sesión. Los scripts suelen estar ofuscados, así que la ausencia de una llamada evidente no prueba que no ocurra nada.

P: ¿La semilla de ruido afecta a la calidad de la reproducción de audio? R: La semilla de ruido controla la pequeña variación numérica de los valores de audio que se usan como señal del dispositivo. La documentación de audio de BotBrowser la describe como ruido aplicado a la salida de Web Audio, y conviene probar el flujo de audio concreto del que dependes en tu propio despliegue.

P: ¿Qué estabilidad tiene la salida de audio con una semilla de ruido fija? R: Según la documentación, el mismo perfil y la misma semilla dan la misma salida de audio entre sesiones. Considéralo el comportamiento documentado para un perfil válido en el nivel ENT Tier2 y confírmalo con la comprobación de dos sesiones descrita arriba.

P: ¿Qué ocurre si uso semillas de ruido distintas con el mismo perfil? R: Cada semilla da un resultado de audio distinto pero estable. Es útil cuando sesiones separadas necesitan valores de audio distintos y repetibles.

P: ¿Por qué mi resultado difiere entre ejecuciones headless y con ventana? R: Comprueba primero que tu modo de despliegue crea un AudioContext y que la rutina de prueba devuelve muestras. Si la creación falla en headless, registra ese resultado como una limitación del modo, no como un cambio de red.

P: ¿Una VPN o un proxy cambian el resultado de audio? R: No. El resultado de audio procede del renderizado dentro del navegador, así que un cambio en la ruta de red no lo altera.

P: ¿Basta con la coherencia del audio por sí sola? R: No. Comprueba también canvas, WebGL, fuentes y propiedades de navigator; una coincidencia de audio solo describe la rutina y el perfil que mediste.

Conclusiones

La huella de audio aprovecha la variación natural en cómo distintos dispositivos procesan señales de audio mediante la Web Audio API. Como no requiere permisos y no produce efectos visibles, es uno de los métodos de rastreo más difíciles de notar o evitar para los usuarios. BotBrowser proporciona ruido determinista basado en el perfil a la salida de AudioContext y Web Audio dentro del propio renderizado de audio del navegador, activado por defecto, de modo que el resultado de audio sigue el perfil cargado y no el hardware de tu equipo. Con un --bot-noise-seed fijo, que requiere el nivel ENT Tier2, la salida es reproducible entre sesiones, y puedes comprobarlo lanzando dos sesiones con el mismo perfil y la misma semilla y comparando la salida de audio. Los límites son claros: BotBrowser no puede garantizar que un sitio no detecte ni bloquee la automatización, no sustituye las demás superficies de huella (canvas, WebGL, fuentes, navigator) que un perfil completo también debe cubrir, y no cambia la superficie de la Web Audio API ni el comportamiento de las llamadas que ven los sitios; solo los valores de salida siguen el perfil. Los resultados de audio siguen dependiendo de un perfil válido, de tu nivel y de una semilla fija. Consulta el conjunto completo de protecciones en la página de funciones o verifica tú mismo la coherencia del audio en el Centro de pruebas.

Para temas relacionados, consulta Qué es la huella del navegador y Protección de huella WebGL. Las comprobaciones de canvas y del modo determinista siguen siendo superficies de regresión separadas.

Fuentes

Referencias públicas usadas para las afirmaciones sobre Web Audio y BotBrowser en este artículo:

• Especificación W3C Web Audio API
• MDN: Web Audio API
• MDN: OfflineAudioContext
• Documentación de audio de BotBrowser
• Englehardt y Narayanan, Online Tracking: A 1-million-site Measurement and Analysis