Empreinte audio expliquée : comment AudioContext vous piste

BotBrowser peut rendre la relecture d'AudioContext reproductible dans un test autorisé avec un profil, un niveau, un mode de déploiement et un --bot-noise-seed fixe déclarés. Il ne garantit ni l'anonymat, ni l'acceptation par un site, ni un rendu audio identique sur tous les hôtes, profils ou piles audio.

Voir la vidéo

Cette vidéo en anglais explique comment une page silencieuse peut lire une valeur du moteur audio du navigateur grâce au rendu hors ligne, puis exécute dans une vérification locale une routine Web Audio fixe deux fois à une fréquence d'échantillonnage et une fois à une fréquence plus élevée. Elle n'utilise ni proxy ni profil et n'établit ni identité, ni anonymat, ni accès, ni la décision d'un site distant. L'audio est en anglais.

Pourquoi l'audio devient une empreinte

Tout navigateur web contient un système de traitement audio intégré. L'API Web Audio, en particulier AudioContext et OfflineAudioContext, permet à une page de créer, relier et analyser des signaux audio entièrement par logiciel. Aucun accès au microphone n'est nécessaire, aucun son n'est émis et aucune demande de permission n'apparaît. L'API existe pour des usages légitimes comme les jeux, les applications musicales et les effets audio en temps réel. La chaîne de traitement peut produire des mesures différentes selon les conditions de rendu, et les systèmes de pistage peuvent combiner cette variation avec d'autres signaux. Cet identifiant s'appelle une empreinte audio ; sa reproductibilité dépend de la mesure et n'est pas garantie après la suppression des cookies, une mise à niveau ou un changement de contexte. L'accès des pages à cette API et son usage dans des flux audio ordinaires sont décrits dans Accès à Web Audio API et flux audio pratiques.

Cette variation n'est pas un défaut d'un navigateur en particulier. La spécification Web Audio décrit ce que chaque nœud doit faire, mais les résultats en virgule flottante produits par une machine réelle dépendent de l'implémentation, de la pile audio du système d'exploitation et de la fréquence d'échantillonnage utilisée. Deux appareils peuvent exécuter le même JavaScript et produire pourtant des tampons qui diffèrent dans les chiffres de poids faible. Ces chiffres sont minuscules, mais ils se répètent sur un même appareil, et c'est cette combinaison qui en fait un signal utile.

Les sections suivantes suivent cette variation depuis sa source jusqu'à une vérification pratique : d'où elle vient, pourquoi les mesures de confidentialité courantes laissent des incohérences visibles, ce que BotBrowser documente pour la sortie audio, et comment confirmer la cohérence dans votre propre configuration.

TL;DR

• Web Audio et OfflineAudioContext peuvent exposer des différences répétables sans microphone ni son audible.
• Une valeur audio décrit la version, le profil, la fréquence, les canaux et le contexte déclarés; elle ne prouve pas un appareil physique.
• Un VPN ou la suppression des cookies ne change pas le rendu local, et une randomisation partielle peut créer des incohérences.
• Un profil valide avec --bot-noise-seed fixe permet de reproduire des sessions autorisées comparables sous ENT Tier2.
• Vérifiez l'audio avec canvas, WebGL, les polices et navigator; BotBrowser ne garantit ni anonymat ni acceptation.

Sommaire

• Voir la vidéo
• Pourquoi l'audio devient une empreinte
• Pourquoi les VPN, les extensions de bruit et la randomisation laissent des incohérences
• Comportement audio de BotBrowser et options de lancement
• Vérifier la cohérence audio dans votre propre configuration
• FAQ : Questions sur l'empreinte audio
• À retenir

Le schéma résume l'idée en une seule image. La routine reste constante tandis que les conditions de rendu déclarées peuvent modifier les nombres ; un profil avec une graine fixe peut rendre des sessions comparables reproductibles lorsque le build, le profil, le déploiement et le contexte restent constants.

Impact sur la vie privée d'un rendu audio silencieux

L'empreinte audio est attrayante pour les systèmes de pistage parce qu'elle est discrète. L'utilisateur ne reçoit aucune notification, aucune boîte de dialogue de permission et aucune indication visuelle qu'un traitement audio a lieu. Une page peut créer un contexte de rendu hors ligne, traiter un court tampon et lire le résultat en une fraction de seconde, sans jamais toucher aux haut-parleurs.

Des recherches publiques de mesure du web, comme l'étude d'Englehardt et Narayanan de 2016 sur un million de sites, ont documenté des scripts qui utilisent le rendu audio comme l'un des signaux servant à reconnaître des navigateurs qui reviennent. Ce signal est rarement utilisé seul. Il est combiné avec le canvas, WebGL, les polices, les propriétés d'écran et les valeurs de navigator, et chaque signal supplémentaire réduit le groupe d'appareils qui pourraient avoir produit le résultat combiné. La fréquence d'affichage et le rythme de la vidéo forment un autre signal lié au temps, traité dans Empreinte de fréquence d'images : affichage et vidéo.

Un résultat audio peut rester similaire lors de mesures répétées lorsque la version du navigateur, le profil, les paramètres audio et les conditions de session restent déclarés et inchangés. Ce n'est pas une persistance garantie : les mises à niveau, les paramètres de rendu et le contexte peuvent modifier la mesure. Les fenêtres privées, l'effacement des cookies ou un VPN ne suffisent donc pas à conclure qu'un signal audio a changé ou non.

La question de confidentialité n'est donc pas de savoir si un site peut utiliser AudioContext. L'audio fait partie normale de la plateforme web, et de nombreux sites s'en servent pour produire du son. La question est de savoir si les nombres renvoyés par une routine audio reflètent votre matériel réel, et s'ils restent cohérents avec tout ce que le navigateur déclare par ailleurs sur lui-même.

Comment le rendu d'OfflineAudioContext diffère d'un appareil à l'autre

L'API Web Audio fournit deux interfaces principales pertinentes pour ce sujet.

AudioContext gère le traitement audio en temps réel. Il crée un graphe audio dans lequel les nœuds représentent des opérations comme l'oscillation, le réglage du gain, la compression et l'analyse. Chaque nœud traite des échantillons audio, et la sortie dépend du sous-système audio sous-jacent.

OfflineAudioContext rend l'audio dans un tampon sans produire de son audible. Il s'exécute plus vite que le temps réel, ne nécessite aucun geste de l'utilisateur pour le rendu et renvoie le résultat sous forme de tableau d'échantillons à virgule flottante. C'est l'interface la plus utilisée lorsque l'audio est traité comme un signal d'appareil. Une routine typique, au niveau conceptuel, relie un oscillateur à un compresseur, rend un court tampon et réduit les échantillons obtenus à un seul nombre, par exemple une somme.

Pourquoi la sortie varie-t-elle d'un appareil à l'autre ? Plusieurs facteurs y contribuent.

• Paramètres de rendu et implémentation du navigateur. La version, la précision interne, les optimisations et les paramètres de rendu peuvent modifier les échantillons produits. Un rendu hors ligne ne passe pas directement par les haut-parleurs ni par le matériel audio.
• Configuration négociée. La fréquence d'échantillonnage, la disposition des canaux et le contexte peuvent varier selon l'hôte et le mode de déploiement. Une différence mesurée ne prouve donc pas à elle seule une cause matérielle ou un pilote précis.
• Implémentation du navigateur. Chromium, Firefox et WebKit implémentent la spécification Web Audio de manière indépendante. La précision interne, les optimisations de chemin rapide et les options de compilation diffèrent entre eux.
• Négociation de la fréquence d'échantillonnage. La fréquence par défaut dépend du système d'exploitation et du matériel. Un système dont la valeur par défaut est 44100 Hz produit une sortie de compresseur différente de celle d'un système à 48000 Hz, même avec des nœuds et des paramètres identiques.
• Disposition des canaux. Le nombre de canaux de sortie et la façon dont ils sont mixés peuvent modifier le tampon relu par la routine.

Le résultat est que le tampon rendu peut contenir des différences numériques liées à l'implémentation et aux paramètres de rendu déclarés. Une somme d'échantillons n'est pas un score et ne signifie rien par elle-même. Un résultat répété constitue une observation pour les conditions testées, et ne prouve pas une cause universelle propre à un appareil, un système d'exploitation ou un pilote.

Un modèle mental utile consiste à voir le résultat audio comme une mesure de toute la pile de lecture, effectuée à l'insu de l'utilisateur. Lire AudioContext.sampleRate indique à la page quelle fréquence la pile a négociée. Rendre un tampon lui indique comment cette pile traite l'arithmétique. Lire la sortie d'un analyseur lui indique comment se comportent les nœuds d'analyse sur la même entrée. Chacune de ces lectures est peu coûteuse, aucune ne demande de permission, et ensemble elles décrivent l'hôte bien plus précisément qu'une valeur isolée.

Pourquoi les VPN, les extensions de bruit et la randomisation laissent des incohérences

Plusieurs mesures courantes sont parfois présentées comme des réponses à l'empreinte audio. Chacune a une limite qu'il vaut mieux comprendre avant de s'y fier.

Les VPN changent votre adresse IP mais n'ont aucun effet sur le rendu audio. L'API Web Audio s'exécute entièrement dans le navigateur et n'a aucune composante réseau. Le résultat audio est le même que vous passiez par un VPN, un proxy ou une connexion directe.

Les extensions de navigateur qui proposent une protection audio interceptent généralement les appels JavaScript et ajoutent un bruit aléatoire aux valeurs renvoyées. Cette approche a trois limites que vous pouvez vérifier dans vos propres tests. D'abord, un appareil authentique répète son propre résultat, donc une routine qui renvoie une valeur différente à chaque exécution dans votre test montre que la sortie n'est pas stable. Ensuite, une extension peut ne couvrir que certaines méthodes, par exemple la lecture du tampon, et laisser intactes des méthodes voisines comme AnalyserNode.getFloatFrequencyData, donc comparez les valeurs liées entre elles pour confirmer qu'elles concordent. Enfin, une extension agit au niveau de la page et ne change pas la manière dont l'audio a été rendu au départ.

La randomisation des paramètres audio, comme la fréquence d'échantillonnage ou le nombre de canaux, casse souvent les applications qui dépendent d'une lecture audio précise. Les outils de production musicale, les appels vidéo et les jeux reposent tous sur un comportement audio stable. Une valeur randomisée doit en outre concorder avec ce qui a réellement été rendu. Une fréquence d'échantillonnage déclarée qui ne correspond pas à la sortie rendue est une combinaison qu'aucun appareil réel ne produit.

Bloquer AudioContext purement et simplement est l'option la plus brutale. Elle empêche le signal, mais aussi l'audio légitime, et l'absence d'interface audio est en soi inhabituelle pour un navigateur moderne.

Uniformiser la sortie pour tous les utilisateurs réduit l'information du signal, mais crée une valeur partagée qui est distinctive pour le groupe qui l'utilise. Cela peut être un compromis raisonnable dans un cadre contrôlé, et c'est différent de garder l'audio cohérent avec un profil d'appareil donné.

Le fil conducteur est la cohérence. Une approche efficace doit garder alignés trois éléments : les valeurs lues par la page, les échantillons réellement rendus et le reste de l'identité déclarée par le navigateur. Un changement appliqué à un seul d'entre eux laisse une incohérence plus difficile à expliquer que la différence d'origine.

Comportement audio de BotBrowser et options de lancement

D'après la documentation audio de BotBrowser, BotBrowser peut appliquer un bruit déterministe à la sortie Web Audio avec un profil valide et les conditions de niveau et de déploiement documentées. Vérifiez chaque résultat avec le build, le profil, les options et le contexte exacts utilisés.

Bruit piloté par le profil, activé par défaut. Le bruit d'AudioContext est activé par défaut. L'option --bot-noise-audio-context le contrôle explicitement, avec true par défaut et false pour le désactiver.

Reproductibilité avec une graine de bruit. L'option --bot-noise-seed vise une sortie reproductible entre sessions comparables et requiert ENT Tier2. Réutiliser la même graine peut rendre les sessions corrélables ; cela ne garantit pas une sortie identique entre tous les builds, hôtes, déploiements ou contextes. Sans graine fixe, le bruit varie d'une session à l'autre par conception.

Cohérence entre contextes d'exécution. La documentation décrit une cohérence entre le thread principal, les Web Workers et les Service Workers dans une session. Traitez-la comme une capacité à vérifier pour le build et le contexte exacts, pas comme une garantie universelle.

Un outil d'enregistrement pour votre propre revue. BotBrowser fournit AudioLab, un outil qui enregistre les appels à l'API Web Audio effectués par une page pendant une session. Il est documenté comme un moyen d'étudier la façon dont les signaux audio sont collectés et de vérifier votre propre configuration.

Il y a aussi des limites. La sortie de BotBrowser ne suit le profil que lorsqu'un profil valide est chargé. La reproductibilité à graine fixe dépend du niveau ENT Tier2. Certaines configurations headless peuvent ne pas initialiser l'audio du tout, alors vérifiez que votre mode de déploiement prend en charge l'audio avant de vous fier à un résultat. L'audio est un signal parmi d'autres, et un résultat audio cohérent ne garantit pas la façon dont un site donné traitera une session. Ces limites sont rappelées dans les points à retenir à la fin de cet article.

Chargement de profil de base

La configuration la plus simple charge un profil qui inclut des paramètres audio :

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

Cette seule option configure le comportement audio pour qu'il suive le profil chargé.

Audio reproductible avec une graine de bruit

Pour des résultats audio reproductibles d'une session à l'autre :

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

La même combinaison de profil et de graine donne la même sortie audio. Changez la graine pour obtenir un résultat différent mais tout aussi stable. La graine accepte des entiers de 1 jusqu'au plus grand entier non signé sur 32 bits, et la valeur 0 conserve les valeurs par défaut du profil sans graine déterministe. Cette option requiert ENT Tier2.

Intégration 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 accepte les mêmes arguments via son option args. Ce sont des arguments de navigateur ordinaires : le même profil et la même graine fonctionnent donc avec l'une ou l'autre bibliothèque.

Voir la sortie de base du profil

Si vous voulez la sortie audio de base du profil sans bruit appliqué :

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

C'est une étape de comparaison, pas une valeur par défaut recommandée. Elle montre ce que le profil apporte avant l'ajout du bruit.

Vérifier la cohérence audio dans votre propre configuration

Pour confirmer que la sortie audio suit le profil chargé, comparez les résultats entre vos propres sessions. Utilisez une page de test que vous maîtrisez ou une page publique de test d'empreinte, et notez les valeurs audio affichées à chaque lancement.

Contrôle de reproductibilité. Lancez deux sessions distinctes avec le même profil et le même --bot-noise-seed, exécutez la même routine audio dans chacune et comparez la sortie. Les deux résultats doivent correspondre. Lancez une troisième session avec une autre graine et vérifiez que son résultat est différent mais stable lorsque vous le répétez. La graine fixe requiert ENT Tier2.

Contrôle entre machines. Exécutez le même profil et la même graine sur deux machines physiques différentes et comparez la sortie. Notez le build, le déploiement, les paramètres audio et les conditions de l'hôte ; une concordance est une preuve pour cette configuration, pas une garantie pour toutes les machines.

Contrôle des contextes. Exécutez la même routine dans la page principale et dans un Web Worker au sein d'une même session. La documentation indique que les résultats restent cohérents entre ces contextes : une différence entre eux invite donc à revoir le profil et les options.

Contrôle des valeurs liées. Comparez la fréquence d'échantillonnage déclarée par votre configuration, le tampon produit par un rendu hors ligne et les données de fréquence d'un nœud analyseur. Elles doivent toutes sembler provenir du même appareil. Une valeur déclarée qui ne concorde pas avec la sortie rendue signifie que votre configuration mérite un nouvel examen.

Enregistrement des appels. Pour une revue plus approfondie, AudioLab peut enregistrer les appels Web Audio effectués par une page pendant une session, ce qui permet de voir quelles fonctions audio la page utilise réellement avant de décider quoi comparer.

Ces contrôles s'exécutent sur vos propres machines. Ils ne demandent pas de permission de microphone et ne dépendent pas de votre réseau, c'est pourquoi les vérifications utiles se font à l'intérieur du navigateur.

Lire vos propres résultats audio

Les nombres audio sont faciles à mal interpréter parce qu'ils paraissent arbitraires. Ces trois questions aident à examiner la sortie de votre propre configuration.

Premièrement, la configuration déclarée concorde-t-elle avec la sortie rendue ? Vous pouvez lire directement la fréquence d'échantillonnage et le nombre de canaux, rendre un court tampon hors ligne et comparer le résultat avec ce que cette configuration devrait produire. Lorsque les deux proviennent de sources différentes, par exemple une fréquence modifiée au-dessus d'un rendu non modifié, la combinaison n'est pas celle d'un appareil réel. La concordance entre valeurs déclarées et échantillons rendus compte plus que n'importe quel nombre isolé.

Deuxièmement, le résultat audio concorde-t-il avec le reste du profil ? Un profil qui présente un système d'exploitation ne devrait pas renvoyer le comportement audio d'un autre. L'audio seul ne prouve rien, et c'est pourquoi un profil doit être considéré dans son ensemble, avec le canvas, WebGL, les polices et les propriétés de navigator.

Troisièmement, le résultat est-il stable quand il doit l'être ? Un appareil authentique renvoie la même valeur chaque fois qu'il exécute la même routine. Si votre propre test renvoie une valeur différente à chaque appel, votre configuration n'est pas reproductible et il faut revoir le profil et les options. Avec BotBrowser, lancer deux sessions avec le même profil et le même --bot-noise-seed et comparer la sortie est le moyen le plus simple de confirmer que votre configuration est reproductible. Une graine différente avec le même profil doit donner un résultat différent mais toujours cohérent avec lui-même.

L'option --bot-noise-audio-context=false a un objectif précis. Elle expose la sortie de base du profil sans bruit, ce qui est utile pour comprendre ce que le profil apporte lui-même. Considérez-la comme une étape de comparaison et non comme une valeur par défaut, car le bruit est activé par défaut et la plupart des configurations devraient le laisser ainsi.

Changer d'adresse IP, effacer les cookies ou ouvrir une fenêtre privée ne modifie pas nécessairement une mesure audio. Vérifiez toujours les conditions de rendu déclarées au lieu d'en déduire une persistance absolue.

Gardez des attentes réalistes. Un résultat audio cohérent est une pièce d'une identité de navigateur cohérente. Il ne dit pas si un site donné acceptera ou contestera une session, et il doit être examiné avec les autres surfaces plutôt que de façon isolée.

Habitudes de configuration qui gardent l'audio cohérent

• Chargez toujours un profil. Lancer BotBrowser sans --bot-profile signifie que la sortie audio provient de votre matériel natif. Le profil est ce qui fait suivre à la sortie audio une plateforme déclarée.
• Adaptez le profil à votre cas d'usage. Un profil Windows produit une sortie audio typique de Windows. Choisissez un profil qui correspond à la plateforme que vous testez.
• Laissez le bruit audio activé sauf pour comparer. L'option --bot-noise-audio-context=false supprime une couche de variation. Utilisez-la pour une comparaison avec le profil de base, puis réactivez le bruit.
• Mesurez la sortie avant de comparer. En headless, créez un AudioContext et consignez s'il renvoie des échantillons ; une sortie absente est un résultat du mode, pas une variation du réseau.
• Figez les versions pendant la comparaison. Si la version du navigateur ou le profil change entre deux sessions, une différence de sortie audio peut venir de ce changement et non de vos options.

FAQ : Questions sur l'empreinte audio

Q : L'empreinte audio nécessite-t-elle l'accès au microphone ? R : Non. Elle utilise les fonctions de synthèse et de traitement de l'API Web Audio. Aucun microphone, aucune permission et aucun son audible ne sont impliqués, et toute la routine s'exécute par logiciel.

Q : Puis-je savoir si un site web utilise un traitement audio ? R : En principe, vous pouvez observer la création d'AudioContext et d'OfflineAudioContext dans les outils de développement du navigateur, et AudioLab peut enregistrer les appels Web Audio effectués par une page pendant une session. Les scripts sont souvent obfusqués : l'absence d'appel évident ne prouve donc pas qu'il ne se passe rien.

Q : La graine de bruit affecte-t-elle la qualité de lecture audio ? R : La graine de bruit contrôle la petite variation numérique des valeurs audio utilisées comme signal d'appareil. La documentation audio de BotBrowser la décrit comme un bruit appliqué à la sortie Web Audio, et il convient de tester le flux audio précis dont vous dépendez dans votre propre déploiement.

Q : Quelle est la stabilité de la sortie audio avec une graine de bruit fixe ? R : D'après la documentation, le même profil et la même graine donnent la même sortie audio d'une session à l'autre. Considérez cela comme le comportement documenté pour un profil valide au niveau ENT Tier2, et confirmez-le avec le contrôle à deux sessions décrit plus haut.

Q : Que se passe-t-il si j'utilise des graines de bruit différentes avec le même profil ? R : Chaque graine donne un résultat audio différent mais stable. C'est utile lorsque des sessions distinctes ont besoin de valeurs audio distinctes et répétables.

Q : Pourquoi mon résultat diffère-t-il entre exécutions headless et avec fenêtre ? R : Vérifiez d'abord que votre mode de déploiement crée un AudioContext et que la routine de test renvoie des échantillons. Si la création échoue en headless, consignez cette limite du mode plutôt qu'un changement de réseau.

Q : Un VPN ou un proxy modifie-t-il le résultat audio ? R : Non. Le résultat audio provient du rendu à l'intérieur du navigateur, et un changement de route réseau ne l'altère donc pas.

Q : La cohérence audio suffit-elle à elle seule ? R : Non. Vérifiez aussi canvas, WebGL, les polices et les propriétés de navigator ; une concordance audio décrit seulement la routine et le profil mesurés.

À retenir

L'empreinte audio utilise la variation naturelle de la façon dont différents appareils traitent les signaux audio via l'API Web Audio. Parce qu'elle ne nécessite aucune permission et ne produit aucun effet visible, c'est l'une des méthodes de pistage les plus difficiles à remarquer ou à prévenir pour les utilisateurs. BotBrowser fournit un bruit déterministe piloté par le profil à la sortie d'AudioContext et de Web Audio, dans le rendu audio du navigateur lui-même, activé par défaut : le résultat audio suit le profil chargé plutôt que le matériel de votre machine. Avec un --bot-noise-seed fixe, qui requiert le niveau ENT Tier2, la sortie est reproductible d'une session à l'autre, et vous pouvez le vérifier en lançant deux sessions avec le même profil et la même graine, puis en comparant la sortie audio. Les limites sont claires : BotBrowser ne peut pas garantir qu'un site ne détectera ni ne bloquera l'automatisation, il ne remplace pas les autres surfaces d'empreinte (canvas, WebGL, polices, navigator) qu'un profil complet doit aussi couvrir, et il ne modifie pas la surface de l'API Web Audio ni le comportement des appels que voient les sites ; seules les valeurs de sortie suivent le profil. Les résultats audio dépendent toujours d'un profil valide, de votre niveau et d'une graine fixe. Consultez l'ensemble des protections sur la page des fonctionnalités ou vérifiez vous-même la cohérence audio dans le Centre de preuves.

Pour des sujets connexes, consultez Qu'est-ce que l'empreinte de navigateur et Protection de l'empreinte WebGL. Les contrôles canvas et du mode déterministe restent des surfaces de régression distinctes.

Sources

Références publiques utilisées pour les affirmations sur Web Audio et BotBrowser dans cet article :

• Spécification W3C Web Audio API
• MDN : Web Audio API
• MDN : OfflineAudioContext
• Documentation audio de BotBrowser
• Englehardt et Narayanan, Online Tracking: A 1-million-site Measurement and Analysis