Canvas, WebGL y Audio: los tres fingerprints que sobreviven a cada reinicio del navegador

Por qué precisamente estos tres

Un script moderno de fingerprinting sondea unos 40 vectores en una página típica: User-Agent, tamaño de pantalla, cabeceras de idioma, lista de fuentes, plugins instalados, offset de zona horaria, precisión del puntero, hardware concurrency. Casi todos esos valores son enteros o cadenas cortas, y cada uno aporta en la práctica entre uno y cinco bits de entropía. Sirven como pegamento, no como identificadores.

Con Canvas, WebGL y AudioContext la cosa cambia. Cada uno mete una carga determinista por el dispositivo y hashea el resultado. El hash depende del silicio de la GPU, de la versión del driver, del rasterizador de fuentes del SO, de la estrategia de anti-aliasing y de la implementación en coma flotante del subsistema de audio. Por eso una instalación recién hecha de Chrome sobre la misma máquina devuelve al día siguiente casi los mismos tres hashes, mientras que la misma máquina con otro driver de GPU saca valores claramente distintos.

Los números del dataset Cover Your Tracks de la EFF y del corpus AmIUnique de Inria sitúan el hash de canvas en torno a diez bits de entropía, la información del renderer de WebGL entre seis y ocho bits y AudioContext en cuatro o cinco. Una sesión que exponga los tres pasa con holgura de los dieciocho bits, suficiente para señalarte entre un cuarto de millón de usuarios. Más que de sobra para targeting publicitario, fraud scoring y casi cualquier pipeline de analítica.

Fingerprinting de Canvas a fondo

Un fingerprint de canvas es el hash de una imagen que tu navegador ha dibujado sin enseñártela. El script crea un <canvas> fuera de pantalla, lo rellena con algunas formas y una cadena de texto en dos o tres fuentes, llama a toDataURL() y hashea los bytes del PNG resultante. Tú no ves nada, y todo ocurre en unos pocos milisegundos.

El hash se mantiene estable en una máquina concreta porque el camino de renderizado es determinista. Misma GPU, mismo driver, mismo rasterizador de fuentes, mismo modo de anti-aliasing: mismo PNG, byte a byte. Cambia cualquiera de esas piezas y el hash salta. De ahí que una actualización de características de Windows convierta a un usuario antes estable en uno aparentemente nuevo para un tracker, y que los equipos corporativos con drivers congelados se parezcan casi todos entre sí.

El esqueleto del ataque queda así:

const c = document.createElement("canvas");
const ctx = c.getContext("2d");
ctx.textBaseline = "alphabetic";
ctx.font = "14px 'Arial'";
ctx.fillStyle = "#069";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 2, 15);
ctx.fillStyle = "rgba(102,204,0,0.7)";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 4, 17);
const png = c.toDataURL();
// hash(png) se convierte en tu fingerprint canvas

El snippet no tiene nada de exótico. Es prácticamente la rutina que FingerprintJS, ThreatMetrix y Cloudflare Bot Management lanzan en el primer contacto, con sus variantes. Brave y uBlock Origin se defienden inyectando un poco de ruido por sesión antes de la lectura, con lo que el hash sale distinto cada vez. Frente a agregadores ingenuos cuela; el problema es que la propia protección es detectable. Un hash que nunca se repite ya es una señal en sí mismo, y los trackers te etiquetan como «usuario con randomización de canvas».

Fingerprinting de WebGL a fondo

WebGL da a la página acceso directo a tu GPU a través de una capa JavaScript sobre la API OpenGL ES. Hay dos detalles que saltan a la vista. Primero, una pequeña extensión llamada WEBGL_debug_renderer_info expone tal cual al fabricante de la GPU y a la cadena del renderer. En la mayoría de los equipos de escritorio aparece algo como ANGLE (NVIDIA, GeForce RTX 4070, OpenGL 4.5.0) o igual de específico. Esa sola cadena puede acarrear por sí misma más de diez bits de entropía, porque incluye la rama del driver y a veces hasta un hash de build.

Segundo, incluso si la extensión está enmascarada o deshabilitada, el resultado de renderizar una escena 3D moderadamente compleja (un toro texturizado, una esfera con degradado, algunos triángulos rotados) sigue siendo hashable. Compiladores de shaders, ajustes de precisión e implementaciones de blending distintos mueven los píxeles cantidades pequeñas pero consistentes. El script lee el framebuffer con readPixels(), lo hashea y guarda el resultado.

Desactivar WebGL del todo es la defensa más limpia y la más cara. Google Maps, casi todos los juegos de navegador, la mitad de las herramientas SaaS modernas que pintan gráficos por GPU y un número sorprendente de visores 3D de e-commerce dejan de funcionar. Firefox expone la preferencia webgl.disabled para quien asuma el coste. Tor Browser mantiene WebGL activo, pero normaliza la cadena del renderer a un valor único en todas las instalaciones de Tor de una misma plataforma. Por eso dos usuarios de Tor con hardware completamente distinto le devuelven la misma firma WebGL a la página.

Fingerprinting de AudioContext a fondo

El fingerprinting de AudioContext es el más silencioso de los tres, en todos los sentidos. El script instancia un OfflineAudioContext, genera una onda triangular o sinusoidal a una frecuencia fija, la pasa por un compresor dinámico con parámetros prefijados y lee las muestras de vuelta como un Float32Array. Ningún sonido llega a los altavoces. El equipo no necesita estar sin silenciar y los auriculares no pintan nada. Lo que importa es la matemática en coma flotante que tu pila de audio usó para generar esas muestras.

La salida suena idéntica al oído humano (y a cualquier analizador de espectro que solo se fije en el contenido audible), pero los valores float32 subyacentes cambian según la implementación del algoritmo de compresor. Los builds de navegador, los motores de audio del SO e incluso ciertas revisiones de microcódigo de CPU mueven los bits menos significativos siguiendo patrones estables. Hashear el buffer o sumarlo entrega un número que sobrevive a reinicios, reseteos de perfil y a casi todas las extensiones.

AudioContext aporta menos entropía que canvas (típicamente cuatro o cinco bits), así que por sí solo no identifica a nadie. Su verdadero valor para un tracker es que casi nadie lo defiende. Canvas y WebGL acaparan la atención ruidosa de las herramientas de privacidad; el audio se cuela por debajo. Un script que encuentra hashes de canvas y de audio coincidentes en dos sesiones confía mucho más en el match de lo que canvas por sí solo justificaría, porque el número de audio prácticamente no se repite por azar.

Los tres en comparación

Puestos uno al lado del otro, los tres vectores tienen fortalezas distintas. La tabla siguiente resume qué le aporta cada uno a un tracker, cuánto te cuesta defenderte y cómo de visible queda esa defensa.

El patrón se repite. Cada vector es difícil de derrotar por separado, y las defensas que sí funcionan se notan. Un tracker que ve canvas normal, WebGL normal y una marca de AudioContext ausente está mirando una rebanada minoritaria de la población, y eso por sí solo ya identifica.

Por qué Tor sigue filtrando uno

Tor Browser es la defensa de consumo más agresiva contra el fingerprinting estático. Por defecto, las lecturas de canvas devuelven una imagen blanca uniforme (al usuario se le pregunta antes de soltar datos reales). WebGL queda activo, pero la cadena del renderer se normaliza a un valor único en todas las instalaciones de Tor de una misma plataforma, y la salida renderizada se redondea para borrar la varianza entre drivers. Dos de los tres vectores están prácticamente muertos dentro de Tor.

AudioContext es el cabo suelto. El modelo de amenazas del Tor Project lo contempla (el ticket tor-browser#13017 y los reportes de bug de Mozilla relacionados llevan años abiertos), pero la salida en coma flotante de un OfflineAudioContext sigue dependiendo de la cadena de build. Un Tor Browser sobre Linux x86_64 frente a uno sobre macOS arm64 produce hashes de audio medibles diferentes, aunque ambos declaren la misma cadena de plataforma. Se han publicado varias veces distinguishers de AudioContext para Tor, desde el AmIUnique original hasta trabajos académicos más recientes.

Arreglarlo cuesta porque la alternativa es desactivar del todo OfflineAudioContext, lo que rompe cualquier webapp que descodifique audio en segundo plano (reproductores de podcast, videoconferencia, juegos en el navegador, herramientas de accesibilidad). El Tor Project se ha mantenido prudente con ese cambio. El resultado es que ni el navegador de consumo más blindado deja de exponer uno de los tres vectores.

Qué funciona de verdad contra estos hashes

Los tres vectores comparten una propiedad: todos derivan del comportamiento del hardware físico. La defensa solo por software ayuda, pero las únicas respuestas completas cambian lo que la página ve de tu máquina, no lo que tu máquina realmente es.

FAQ

En qué punto te deja todo esto

Canvas, WebGL y AudioContext suman juntos más de dieciocho bits de entropía en una sesión típica. Suficiente para aislar a un usuario entre más de 250 000, y todas las herramientas pensadas para la era cookie (modo incógnito, VPN, la mayoría de las extensiones de privacidad) las dejan intactas. Los hashes salen de tu GPU, tus drivers, tus fuentes y tu pila de audio, y esa es precisamente la capa a la que esas herramientas nunca llegan.

Defender un vector cada vez también se nota. La randomización de canvas, el enmascaramiento de WebGL y el ruido de audio producen anomalías detectables, así que los trackers acaban metiendo a los usuarios «defendidos» en un grupo más pequeño y probablemente más interesante. Tor cierra dos de los tres con bastante solvencia y sigue filtrando la firma de audio. El único arreglo que cierra los tres a la vez cambia el hardware y la pila de software que la página tiene derecho a ver. En la práctica eso significa otra máquina física, otra instalación de SO o un navegador remoto en contenedor como Browser.lol.