Huella de audio explicada: Cómo AudioContext te rastrea

Introducción

Cada navegador web contiene un motor de procesamiento de audio integrado. La Web Audio API, específicamente AudioContext y OfflineAudioContext, permite a los sitios web crear, manipular y analizar señales de audio completamente en software. No se necesita acceso al micrófono, no se reproduce ningún sonido y no aparece ningún aviso de permiso. La API fue diseñada para propósitos legítimos: juegos, aplicaciones musicales, efectos de audio en tiempo real. Pero el mismo pipeline de procesamiento que hace funcionar las aplicaciones de audio también produce una salida que varía de un dispositivo a otro. Los sistemas de rastreo explotan esta variación para generar un identificador estable, una huella de audio, que persiste entre sesiones y sobrevive a la eliminación de cookies. Comprender cómo funciona esto es el primer paso para proteger tu privacidad.

Impacto en la privacidad

La huella de audio es una de las señales de rastreo más efectivas disponibles para los sitios web actualmente. La investigación del proyecto WebTap de la Universidad de Princeton encontró que más de 500 de los principales 1 millón de sitios web desplegaban scripts de huella de audio. La técnica es particularmente preocupante porque opera silenciosamente en segundo plano. Los usuarios no reciben notificación, ni diálogo de permisos, ni indicación visual de que se está realizando procesamiento de audio.

A diferencia de las cookies, las huellas de audio no pueden ser borradas por el usuario. A diferencia de las direcciones IP, no cambian cuando cambias de red. Un estudio de 2019 publicado en el IEEE Symposium on Security and Privacy demostró que las huellas de audio permanecen estables entre sesiones del navegador y pueden alcanzar tasas de unicidad superiores al 95% cuando se combinan con solo dos o tres señales adicionales. El proyecto Panopticlick de la Electronic Frontier Foundation confirmó que los resultados del procesamiento de audio contribuyen significativamente a la unicidad general del navegador, incluso en configuraciones de hardware comunes.

El diagrama siguiente muestra el pipeline completo que un rastreador usa para convertir el renderizado silencioso de audio en un identificador estable entre sitios. Cada paso se ejecuta enteramente en JavaScript, sin aviso de permiso ni sonido audible.

El paso de recolección es barato y silencioso. El valor real está aguas abajo en el grafo de dispositivos: cada sitio que incluye el mismo rastreador aporta la misma suma de muestras para el mismo dispositivo, y esos clústers se enlazan entre dominios no relacionados. La tarea del defensor no es bloquear AudioContext, sino hacer que las muestras renderizadas sean estables, realistas y consistentes con el resto de la identidad del navegador.

Antecedentes técnicos

La Web Audio API proporciona dos interfaces principales relevantes para la generación de huellas: AudioContext y OfflineAudioContext.

AudioContext gestiona el procesamiento de audio en tiempo real. Crea un grafo de audio donde 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 salida audible. Esta es la interfaz más utilizada para generar huellas porque se ejecuta rápidamente y en silencio. Una rutina típica de huella crea un OfflineAudioContext, conecta un OscillatorNode a un DynamicsCompressorNode, renderiza un búfer corto y lee las muestras float resultantes.

¿Por qué varía esta salida entre dispositivos? Varios factores contribuyen:

• Diferencias de hardware de audio. Diferentes tarjetas de sonido y chipsets de audio implementan el procesamiento de señal digital con ligeras variaciones en la precisión de punto flotante y el comportamiento de redondeo.
• Pilas de audio del sistema operativo. Windows (WASAPI, DirectSound), macOS (CoreAudio) y Linux (PulseAudio, ALSA) cada uno aplica sus propios algoritmos de remuestreo, manejo de búfer y estrategias de mezcla.
• Implementación del motor del navegador. Chromium, Firefox y WebKit implementan la especificación Web Audio con diferente precisión interna, diferentes optimizaciones de ruta rápida y diferentes flags de compilación.
• Negociación de tasa de muestreo. La tasa de muestreo predeterminada varía según el sistema operativo y hardware. Un sistema de 44100 Hz produce una salida de compresor diferente a un sistema de 48000 Hz, incluso con nodos y parámetros idénticos.

La combinación de estos factores significa que el búfer de audio renderizado contiene diferencias numéricas sutiles. Sumar todas las muestras float del búfer, o hacer un hash de un rango específico, produce un valor que es notablemente estable para un dispositivo dado pero diferente entre dispositivos.

La tabla siguiente muestra lo que los rastreadores realmente ven cuando la misma rutina OfflineAudioContext se ejecuta en cuatro clases de dispositivo comunes. Cada fila es una configuración real cuya suma de muestras se convierte en una entrada en una base de datos de huellas.

Enfoques comunes de protección y sus limitaciones

Varios enfoques intentan abordar la huella de audio, pero cada uno tiene inconvenientes significativos.

Las VPN cambian tu dirección IP pero no tienen ningún efecto en la salida del procesamiento de audio. La Web Audio API opera completamente dentro del navegador, sin componente de red. Tu huella de audio es idéntica ya sea que te conectes a través de una VPN, un proxy o directamente.

Las extensiones de navegador que dicen proteger las huellas de audio típicamente funcionan interceptando llamadas JavaScript y añadiendo ruido aleatorio al búfer devuelto. Este enfoque tiene tres problemas. Primero, el patrón de ruido en sí puede ser detectado: si un sitio llama a la misma rutina de audio dos veces y obtiene resultados diferentes, sabe que la inyección de ruido está activa. Segundo, muchas extensiones solo interceptan métodos específicos de la API dejando otros (como AnalyserNode.getFloatFrequencyData) sin modificar, creando inconsistencias detectables. Tercero, las extensiones operan en el espacio JavaScript y no pueden modificar el pipeline de renderizado real.

La aleatorización de parámetros de audio (tasa de muestreo, conteo de canales, etc.) frecuentemente rompe aplicaciones web que dependen de la reproducción precisa de audio. Las herramientas de producción musical, videoconferencia y audio de juegos dependen de un comportamiento de audio consistente. Los valores aleatorios también fallan en las comprobaciones de consistencia: un sitio puede verificar que la tasa de muestreo reportada coincida con la salida de renderizado real.

Tor Browser toma un enfoque más principista estandarizando la salida de audio en todos los usuarios. Sin embargo, esto crea una única huella compartida que en sí misma se convierte en un identificador, señalando que eres un usuario de Tor.

El problema fundamental es que la protección efectiva de huellas de audio requiere control sobre el motor de renderizado real, no solo sobre la superficie de la API JavaScript.

El diagrama siguiente apila los cuatro modelos comunes de defensa de audio frente a la verificación cruzada que ejecuta un sistema moderno de huella. Cada modelo por encima de la capa del motor deja una discrepancia medible entre los parámetros reportados y las muestras renderizadas.

Enfoque a nivel del motor de BotBrowser

BotBrowser aborda la huella de audio en la fuente: el motor de renderizado de Chromium. En lugar de interceptar llamadas JavaScript o inyectar ruido desde una extensión, BotBrowser modifica cómo se procesa el audio internamente.

Cuando cargas un perfil de huella, BotBrowser configura el subsistema de audio para coincidir con el dispositivo objetivo. Esto incluye:

Alineación de tasa de muestreo. La propiedad AudioContext.sampleRate y la tasa de muestreo de renderizado real coinciden con la plataforma objetivo del perfil. Un perfil de Windows 10 reporta y renderiza a la tasa de muestreo típica para esa configuración.

Control del pipeline de procesamiento. Los nodos internos de procesamiento de audio (OscillatorNode, DynamicsCompressorNode, BiquadFilterNode y otros) producen una salida consistente con el dispositivo perfilado. No se trata de cambiar un solo número. Toda la cadena de procesamiento, incluyendo la precisión float intermedia y el comportamiento de redondeo, se alinea con la plataforma objetivo.

Renderizado de OfflineAudioContext. El búfer renderizado por OfflineAudioContext contiene valores de muestra que coinciden con lo que produciría el dispositivo perfilado. Debido a que BotBrowser controla el renderizado a nivel del motor, la salida es consistente independientemente de tu hardware real.

Consistencia de AnalyserNode. Métodos como getFloatFrequencyData, getByteFrequencyData, getFloatTimeDomainData y getByteTimeDomainData devuelven valores derivados del mismo pipeline de procesamiento controlado. No hay brechas donde una API devuelva salida controlada y otra devuelva salida nativa.

Integración de semilla de ruido. Con el flag --bot-noise-seed, BotBrowser aplica variación determinista a la salida de audio. La misma semilla siempre produce la misma huella de audio, lo cual es útil para mantener identidades estables entre sesiones. Diferentes semillas producen huellas diferentes pero internamente consistentes.

La ventaja clave de este enfoque es la completitud. Toda la superficie de API relacionada con audio devuelve valores derivados del mismo motor controlado. No hay inconsistencias entre lo que AudioContext reporta y lo que OfflineAudioContext renderiza.

Configuración y uso

Carga básica de perfil

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

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

Este único flag configura todo el comportamiento relacionado con audio para coincidir con el dispositivo perfilado.

Audio determinista con semilla de ruido

Para huellas 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 siempre produce la misma huella de audio. Cambia la semilla para obtener una huella diferente pero igualmente consistente.

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'
  ]
});

const page = await browser.newPage();
await page.goto('https://example.com');

Integración con Puppeteer

const puppeteer = require('puppeteer');

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

const page = await browser.newPage();
await page.goto('https://example.com');

Desactivar ruido de audio

Si necesitas la huella de audio base del perfil sin variación de ruido adicional:

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

Verificación

Para confirmar que la protección de huella de audio está funcionando, puedes comparar la salida entre sesiones.

Comprobación de consistencia. Ejecuta la misma rutina de huella de audio (crea un OfflineAudioContext, renderiza un búfer, suma las muestras) en dos sesiones separadas del navegador con el mismo perfil y semilla de ruido. Los resultados deben ser idénticos.

Comprobación entre hardware. Ejecuta la misma prueba en dos máquinas físicas diferentes con el mismo perfil y semilla. La huella de audio debe coincidir, confirmando que tu hardware real no está influyendo en la salida.

Comprobación de completitud de API. Verifica que AudioContext.sampleRate, la salida del búfer de OfflineAudioContext y los datos de frecuencia de AnalyserNode se alineen con el perfil cargado. Las inconsistencias entre estas APIs indicarían protección incompleta.

Puedes visitar sitios de prueba de huellas como BrowserLeaks o CreepJS para comparar tu huella de audio con los valores esperados para tu perfil cargado.

La matriz de verificación siguiente muestra cómo se ve el éxito en tres hosts ejecutando el mismo perfil. sampleRate idéntico, suma de muestras del compresor idéntica, hash de AnalyserNode idéntico, independientemente del hardware del host o del sistema operativo.

Mejores prácticas

• Siempre usa un perfil. Ejecutar BotBrowser sin --bot-profile significa que la salida de audio proviene de tu hardware nativo. El perfil es lo que proporciona protección.
• Usa --bot-noise-seed para identidades estables. Si necesitas la misma huella entre sesiones, configura una semilla consistente. Sin semilla, el ruido varía entre lanzamientos.
• Asocia tu perfil con tu caso de uso. Un perfil de Windows produce salida de audio típica de Windows. Si tu IP de proxy geolocaliza a una región donde macOS es común, considera un perfil de macOS.
• No desactives el ruido de audio sin razón. El flag --bot-config-noise-audio-context=false elimina una capa importante de variación. Mantenlo habilitado a menos que tengas una necesidad específica de la huella base del perfil.
• Combina con otras protecciones. La huella de audio es una señal entre muchas. Usa un perfil completo que también controle Canvas, WebGL, fuentes y propiedades del navigator.

FAQ

P: ¿La huella de audio requiere acceso al micrófono? R: No. La huella de audio utiliza las capacidades de síntesis y procesamiento de la Web Audio API. No se involucra ningún micrófono, ningún permiso y ningún sonido audible. Opera completamente en software.

P: ¿Puedo detectar si un sitio web está ejecutando un script de huella de audio? R: En principio, podrías monitorear la creación de AudioContext y OfflineAudioContext en DevTools. En la práctica, los scripts de rastreo frecuentemente ofuscan sus llamadas. BotBrowser te protege independientemente de si detectas el script.

P: ¿La semilla de ruido afecta la calidad de reproducción de audio? R: No. La semilla de ruido controla la variación numérica sutil en las salidas de API relevantes para huellas. La reproducción normal de audio (música, video, llamadas de voz) no se ve afectada.

P: ¿Qué tan estable es la huella de audio con una semilla de ruido fija? R: Completamente estable. El mismo perfil y semilla siempre producen los mismos valores de huella de audio entre sesiones, reinicios y diferentes máquinas.

P: ¿Qué pasa si uso diferentes semillas de ruido con el mismo perfil? R: Cada semilla produce una huella de audio diferente que sigue siendo internamente consistente. Esto es útil para ejecutar múltiples sesiones que necesitan huellas distintas pero válidas.

P: ¿BotBrowser protege contra la huella basada en AudioWorklet? R: Sí. AudioWorklet se ejecuta dentro del mismo pipeline de procesamiento de audio que BotBrowser controla. La salida del worklet se deriva de los mismos componentes internos controlados del motor.

P: ¿La huella de audio es consistente entre el modo headless y con ventana? R: Sí. El control de audio de BotBrowser opera a nivel del motor, independientemente de si la ventana del navegador es visible.

Resumen

La huella de audio explota la variación natural en cómo diferentes dispositivos procesan señales de audio a través de la Web Audio API. Debido a que no requiere permisos y no produce efectos visibles, es uno de los métodos de rastreo más difíciles de detectar o prevenir para los usuarios. BotBrowser controla la salida de audio a nivel del motor de Chromium, asegurando que AudioContext, OfflineAudioContext y AnalyserNode produzcan resultados consistentes con el perfil de huella cargado. Combinado con el flag --bot-noise-seed para salida determinista, BotBrowser proporciona protección de huella de audio completa y verificable.

Para temas relacionados, consulta Qué es la huella del navegador, Protección de huella WebGL, Huella Canvas y Comportamiento determinista del navegador.