Canvas, WebGL e Áudio: as três impressões digitais que sobrevivem a cada reinício do browser

Porquê precisamente estes três

Um script moderno de fingerprinting sonda cerca de 40 vectores numa página típica: User-Agent, tamanho do ecrã, headers de idioma, lista de fontes, plugins instalados, offset de fuso horário, precisão do ponteiro, hardware concurrency. Quase todos esses valores são inteiros ou strings curtas, e na prática cada um vale entre um e cinco bits de entropia. Servem como cola, não como identificadores.

Canvas, WebGL e AudioContext jogam noutra liga. Cada um atira uma carga determinista pelo dispositivo e calcula o hash do resultado. O hash depende do silício da GPU, da versão do driver, do rasterizador de fontes do SO, da estratégia de anti-aliasing e da implementação em vírgula flutuante do subsistema de áudio. É por isso que uma instalação acabada de fazer do Chrome, na mesma máquina, dá no dia seguinte quase os mesmos três hashes, enquanto a mesma máquina com outro driver de GPU sai com valores visivelmente diferentes.

Os números do dataset Cover Your Tracks da EFF e do corpus AmIUnique do Inria colocam o hash de canvas em cerca de dez bits de entropia, as informações do renderer WebGL entre seis e oito bits, e o AudioContext em quatro ou cinco. Uma sessão que exponha os três passa com folga os dezoito bits, o suficiente para te tirar de um bolo de um quarto de milhão de utilizadores. Mais do que de sobra para ad targeting, fraud scoring e quase todas as pipelines de analytics.

O fingerprinting de Canvas em detalhe

Um fingerprint de canvas é o hash de uma imagem que o teu browser desenhou sem que tu chegasses a vê-la. O script cria um <canvas> fora do ecrã, enche-o com algumas formas e uma string de texto em duas ou três fontes, chama toDataURL() e faz o hash dos bytes do PNG. Nada disto te aparece à frente, e tudo acontece em poucos milissegundos.

Numa dada máquina o hash mantém-se estável porque o caminho de renderização é determinista. Mesma GPU, mesmo driver, mesmo rasterizador de fontes, mesmo modo de anti-aliasing, mesmo PNG, byte a byte. Muda uma destas variáveis e o hash salta. É também por isso que um feature update do Windows pode fazer um utilizador antes estável parecer novo aos olhos de um tracker, e por isso que as máquinas das empresas com drivers bloqueados se parecem quase todas umas com as outras.

O esqueleto do ataque é mais ou menos isto:

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) torna-se o teu fingerprint canvas

O snippet não tem nada de exótico. É basicamente a rotina que o FingerprintJS, o ThreatMetrix e o Cloudflare Bot Management correm no primeiro contacto, com pequenas variações. O Brave e o uBlock Origin defendem-se a injectar um pequeno ruído por sessão antes da leitura, e o hash sai diferente de cada vez. Contra agregadores ingénuos resulta, mas a própria defesa é detectável: um hash que nunca se repete é, por si só, um sinal, e os trackers arrumam-te na gaveta «utilizador com randomização de canvas».

O fingerprinting de WebGL em detalhe

O WebGL dá à página acesso directo à tua GPU através de um wrapper JavaScript da API OpenGL ES. Há duas coisas que saltam logo à vista. Primeiro, uma pequena extensão chamada WEBGL_debug_renderer_info expõe sem rodeios o fabricante da GPU e a string do renderer. Na maior parte dos desktops aparece algo como ANGLE (NVIDIA, GeForce RTX 4070, OpenGL 4.5.0) ou outra coisa igualmente específica. Essa string sozinha pode trazer mais de dez bits de entropia, porque inclui o ramo do driver e por vezes até um hash de build.

Segundo, mesmo com a extensão mascarada ou desligada, o resultado renderizado de uma cena 3D moderadamente complexa (um toro texturado, uma esfera com gradiente, alguns triângulos rodados) continua a poder ser hashado. Compiladores de shaders, definições de precisão e implementações de blending diferentes movem os pixéis em quantidades pequenas mas consistentes. O script relê o framebuffer com readPixels(), faz o hash e guarda o resultado.

Desligar o WebGL por completo é a defesa mais limpa e a mais cara. O Google Maps, a maioria dos jogos no browser, metade das ferramentas SaaS modernas que renderizam gráficos na GPU e um número surpreendente de visualizadores 3D de e-commerce deixam de funcionar. O Firefox tem a preferência webgl.disabled para quem aceite a troca. O Tor Browser mantém o WebGL activo, mas normaliza a string do renderer para um único valor em todas as instalações de Tor de uma mesma plataforma. É por isso que dois utilizadores Tor em hardware completamente diferente devolvem à página a mesma assinatura WebGL.

O fingerprinting de AudioContext em detalhe

O fingerprinting de AudioContext é o mais silencioso dos três, em todos os sentidos. O script instancia um OfflineAudioContext, gera uma onda triangular ou sinusoidal a frequência fixa, passa-a por um compressor dinâmico com parâmetros fixos e relê as amostras como Float32Array. Nenhum som chega às colunas. O dispositivo não tem de ter o som ligado e os auscultadores também não pesam. O que pesa é a matemática em vírgula flutuante com que o teu stack de áudio gerou aquelas amostras.

Ao ouvido humano, a saída de áudio é idêntica (e também a qualquer analisador de espectro que só olhe para o conteúdo audível), mas os valores float32 por baixo mudam consoante a implementação do compressor. Builds de browser, motores de áudio do SO e até certas revisões de microcódigo de CPU deslocam os bits menos significativos seguindo padrões estáveis. Fazer o hash do buffer ou somá-lo dá um número que sobrevive a reboots, reposições de perfil e à maioria das extensões.

O AudioContext carrega menos entropia do que o canvas (tipicamente quatro a cinco bits), por isso isolado não identifica ninguém. O seu valor real para um tracker está em quase ninguém o defender. Canvas e WebGL apanham a atenção ruidosa das ferramentas de privacidade; o áudio escapa por baixo. Um script que encontre hashes de canvas e áudio coincidentes em duas sessões fica muito mais confiante na correspondência do que o canvas sozinho justificaria, porque o número de áudio quase nunca coincide por acaso.

Os três lado a lado

Postos lado a lado, os três vectores têm forças distintas. A tabela em baixo resume o que cada um vale para um tracker, quanto te custa a defesa e o quanto essa defesa salta à vista.

O padrão é sempre o mesmo. Cada vector isolado é duro de bater, e as defesas que funcionam dão nas vistas. Um tracker que vê canvas normal, WebGL normal e uma flag de AudioContext em falta está a olhar para uma fatia minoritária da população, e só isso já chega para identificar.

Porque o Tor continua a deixar escapar um

O Tor Browser é a defesa de consumo mais agressiva contra o fingerprinting estático. Por defeito, as leituras de canvas devolvem uma imagem branca uniforme (o utilizador é consultado antes de qualquer dado verdadeiro ser libertado). O WebGL fica activo, mas a string do renderer é normalizada para um único valor em todas as instalações Tor da mesma plataforma, e o resultado renderizado é arredondado para tirar a variância dos drivers. Dois dos três vectores estão, na prática, mortos dentro do Tor.

O AudioContext é a ponta solta. O modelo de ameaça do Tor Project tem-no em conta (o ticket tor-browser#13017 e os relatórios de bug do Mozilla relacionados arrastam-se há anos), mas a saída em vírgula flutuante de um OfflineAudioContext continua a depender da cadeia de build. Um Tor Browser em Linux x86_64 contra um Tor Browser em macOS arm64 produz hashes de áudio mensuravelmente diferentes, mesmo quando ambos anunciam a mesma string de plataforma. Há distinguishers de AudioContext que funcionam contra o Tor, publicados várias vezes, desde o trabalho original do AmIUnique até a seguimentos académicos mais recentes.

Corrigir isto é complicado, porque a alternativa é desligar por completo o OfflineAudioContext, e isso parte qualquer webapp que descodifique áudio em segundo plano (leitores de podcasts, videoconferência, jogos no browser, ferramentas de acessibilidade). O Tor Project tem-se mantido conservador quanto a esta mudança. Resultado: mesmo o browser de consumo mais endurecido continua a expor um dos três vectores.

O que funciona mesmo contra estes hashes

Os três vectores partilham uma propriedade: derivam todos do comportamento do hardware físico. A defesa só por software ajuda, mas as únicas respostas completas mudam o que a página vê da tua máquina, não aquilo que a tua máquina realmente é.

FAQ

O panorama final

Canvas, WebGL e AudioContext, juntos, passam os dezoito bits de entropia numa sessão típica. Chega para isolar um utilizador num conjunto de mais de 250 000, e todas as ferramentas pensadas para a era cookie (modo anónimo, VPN, a maioria das extensões de privacidade) deixam os três intactos. Os hashes saem da tua GPU, dos teus drivers, das tuas fontes e do teu stack de áudio, ou seja, precisamente a camada que essas ferramentas nunca alcançam.

Defender um vector de cada vez também se nota. A randomização do canvas, o mascaramento do WebGL e o ruído de áudio produzem anomalias detectáveis, por isso os trackers arrumam os utilizadores «defendidos» num grupo mais pequeno e provavelmente mais interessante. O Tor fecha dois dos três de forma convincente e continua a deixar escapar a assinatura de áudio. A única solução que fecha os três muda o hardware e o stack de software que a página tem autorização para ver, o que, na prática, significa outra máquina física, outra instalação de SO ou um browser remoto containerizado como o Browser.lol.