Fingerprinting des codecs WebRTC : quand les capacites multimedia revelent votre plateforme

Introduction

WebRTC permet la communication video et audio en temps reel dans le navigateur. Avant que tout media ne circule entre les pairs, les navigateurs enumerent leurs codecs pris en charge et les exposent via des API de capacites et des offres SDP (Session Description Protocol). Cette negociation est essentielle pour les appels video fonctionnels, mais elle cree egalement un inventaire detaille des capacites multimedia de votre systeme que tout site web peut interroger sans permissions speciales.

Les capacites de codecs WebRTC different selon les plateformes et peuvent etre utilisees comme signal de suivi. Differents systemes d'exploitation fournissent differents niveaux de support d'acceleration materielle, ce qui determine directement quels codecs apparaissent dans les listes de capacites du navigateur. Un site web peut interroger ces listes et les comparer a des profils de plateforme connus pour deduire votre veritable systeme d'exploitation, meme lorsque votre chaine user agent pretend autre chose.

BotBrowser resout ce probleme en construisant les listes de capacites de codecs WebRTC entierement a partir du profil de fingerprint, assurant que ce que JavaScript voit correspond a la plateforme cible du profil plutot qu'au materiel reel du systeme hote.

La solution de BotBrowser

BotBrowser resout le fingerprinting des codecs WebRTC au niveau du moteur du navigateur, la ou les capacites de codecs sont reellement determinees. Plutot que de patcher les API JavaScript ou de post-traiter les chaines SDP, BotBrowser construit les listes de capacites de codecs a partir des donnees du profil de fingerprint. Cela garantit que chaque API qui expose des informations de codecs retourne des resultats coherents et precis selon le profil.

Construction de codecs pilotee par le profil

Lorsqu'un profil BotBrowser est charge, les capacites de codecs WebRTC sont construites a partir des donnees de codecs enregistrees dans le profil plutot qu'a partir des capacites materielles reelles du systeme hote. Le profil contient la configuration complete de codecs capturee a partir d'un appareil reel correspondant a la plateforme cible :

• La liste complete des codecs video et audio pris en charge
• Les parametres de codecs incluant les profiles, niveaux et options specifiques au format
• L'ordonnancement correct des codecs dans les listes de capacites
• Les attributions de payload type pour la generation SDP

Cela signifie qu'un profil ciblant une plateforme, charge sur un systeme d'exploitation hote completement different, rapportera toujours les codecs WebRTC corrects pour la cible du profil. Les capacites reelles du systeme hote sont sans rapport avec ce que JavaScript voit.

Coherence du SDP

BotBrowser s'assure que le SDP genere par createOffer() est coherent avec les capacites de codecs rapportees par getCapabilities(). Les deux sont derives des memes donnees du profil, il n'y a donc aucun ecart entre ce que rapportent les API de capacites et ce qui apparait dans le SDP.

Les lignes m=video et m=audio dans le SDP contiennent exactement les payload types qui correspondent a l'ensemble de codecs du profil. Les attributs a=rtpmap et a=fmtp correspondent aux parametres des objets de capacites. Tout script qui interroge les deux API et les compare trouvera une coherence parfaite.

Compatibilite fonctionnelle

L'un des defis du controle des codecs WebRTC est le maintien de la fonctionnalite multimedia reelle. Si le profil specifie un codec que le systeme hote ne peut reellement pas decoder, le navigateur doit gerer cela de maniere elegante.

BotBrowser resout cela par une conception a double couche : JavaScript voit la liste de codecs du profil, tandis qu'en interne le navigateur n'enregistre que les codecs que le systeme hote peut reellement traiter. Cette separation signifie :

• Les scripts de fingerprinting voient la liste de codecs precise du profil.
• Les appels WebRTC reels negocient en utilisant des codecs que les deux pairs et le systeme local peuvent gerer.
• Il n'y a pas de crash ni d'erreur lorsqu'un profil liste un codec que l'hote ne peut pas decoder.

C'est une distinction critique. Injecter simplement des entrees de codecs dans la liste de capacites provoquerait des echecs lorsque le navigateur tente d'utiliser reellement ces codecs. L'integration au niveau du moteur de BotBrowser gere correctement la frontiere entre la presentation du fingerprint et le traitement multimedia fonctionnel.

Alignement inter-API

BotBrowser assure la coherence non seulement au sein des API WebRTC, mais a travers l'ensemble complet des interfaces de capacites multimedia :

• RTCRtpSender.getCapabilities() et RTCRtpReceiver.getCapabilities() retournent des codecs coherents avec le profil.
• Les offres SDP de createOffer() contiennent des payload types correspondants.
• Les API multimedia generales comme canPlayType() et MediaCapabilities.decodingInfo() retournent des resultats coherents avec le profil de codecs WebRTC.
• L'empreinte multimedia globale raconte une histoire unique et coherente sur la plateforme.

Cet alignement inter-API est ce qui rend la protection de BotBrowser efficace. Tous les chemins de rapport de codecs sont gouvernes par une source de donnees unique et coherente : le profil charge.

Configuration et utilisation

Utilisation CLI basique

La protection des codecs WebRTC est automatique lorsqu'un profil est charge. Aucun flag supplementaire n'est necessaire :

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

La configuration des codecs WebRTC du profil est appliquee au demarrage. Toutes les requetes de capacites WebRTC et la generation SDP subsequentes refleteront l'ensemble de codecs du profil.

Integration Playwright

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

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

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  await page.goto('about:blank');

  // Verify WebRTC codec capabilities from the loaded profile
  const codecInfo = await page.evaluate(() => {
    const videoCaps = RTCRtpSender.getCapabilities('video');
    const audioCaps = RTCRtpSender.getCapabilities('audio');
    return {
      videoCodecCount: videoCaps?.codecs.length || 0,
      audioCodecCount: audioCaps?.codecs.length || 0,
    };
  });

  console.log('Video codecs:', codecInfo.videoCodecCount);
  console.log('Audio codecs:', codecInfo.audioCodecCount);

  await browser.close();
})();

Integration Puppeteer

const puppeteer = require('puppeteer-core');

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

  const page = await browser.newPage();
  await page.goto('about:blank');

  // Verify WebRTC codec capabilities from the loaded profile
  const codecs = await page.evaluate(() => {
    const videoCaps = RTCRtpSender.getCapabilities('video');
    const audioCaps = RTCRtpSender.getCapabilities('audio');
    return {
      videoCount: videoCaps?.codecs.length || 0,
      audioCount: audioCaps?.codecs.length || 0,
    };
  });

  console.log(`Video codecs: ${codecs.videoCount}`);
  console.log(`Audio codecs: ${codecs.audioCount}`);

  await browser.close();
})();

Combinaison avec proxy et parametres de plateforme

Pour une coherence complete de la plateforme, combinez la protection des codecs avec la configuration du proxy et de la plateforme :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy.example.com:1080" \
       --bot-config-timezone="America/New_York" \
       --bot-config-locale="en-US" \
       --user-data-dir="$(mktemp -d)"

Cela garantit que non seulement les capacites de codecs sont coherentes avec la plateforme du profil, mais que l'identite reseau, le fuseau horaire, les parametres regionaux et tous les autres signaux sont egalement alignes.

Verification

Apres avoir configure BotBrowser avec un profil, verifiez que la protection des codecs WebRTC fonctionne :

1. Verification du nombre de codecs : Appelez RTCRtpSender.getCapabilities('video') et confirmez que le nombre de codecs correspond a ce que vous attendez pour la plateforme cible du profil.

2. Verification de stabilite : Rechargez la page et repetez. Le nombre et les types de codecs doivent etre identiques entre les chargements de page. Redemarrez le navigateur avec le meme profil et verifiez a nouveau.

3. Sites de test de fingerprint : Visitez des services de test de fingerprint de navigateur et verifiez la section WebRTC. Les codecs rapportes ne doivent signaler aucune anomalie.

Meilleures pratiques

1. Toujours utiliser un profil complet. Les capacites de codecs WebRTC doivent etre alignees avec le systeme d'exploitation, la version du navigateur et la configuration GPU du profil. Les profils BotBrowser sont captures a partir d'appareils reels, assurant que toutes ces dimensions sont internement coherentes. Ne melangez pas les composants de profils.

2. Faites correspondre les attentes de codecs a votre cas d'utilisation. Si vous travaillez avec des sites web qui utilisent activement WebRTC pour des appels video ou du streaming, assurez-vous que l'ensemble de codecs de votre profil supporte les formats que ces sites attendent. Un profil qui exclut des codecs couramment utilises peut causer des echecs de negociation lors de sessions WebRTC reelles.

3. Combinez avec la protection d'IP WebRTC. Le fingerprinting de codecs et la fuite d'IP sont des preoccupations de confidentialite WebRTC separees, mais les deux doivent etre traitees. Utilisez l'integration proxy de BotBrowser avec --proxy-server et --bot-webrtc-ice pour vous assurer que vos adresses IP WebRTC sont egalement controlees. Consultez le guide de prevention des fuites WebRTC pour plus de details.

4. Ne modifiez pas les parametres de codecs manuellement. Laissez le profil gerer entierement la configuration des codecs. Ajouter ou supprimer manuellement des codecs via des flags Chrome ou des surcharges de configuration peut creer des incoherences qui sapent la coherence du profil.

5. Gardez les profils a jour. Le support des codecs change avec les versions du navigateur. De nouveaux codecs sont ajoutes et les parametres de codecs existants peuvent changer. Utiliser des profils qui correspondent a la version du navigateur declaree garantit que vos capacites de codecs correspondent a ce qu'un vrai navigateur de cette version rapporterait.

6. Verifiez la coherence multiplateforme. Si vous utilisez le meme profil sur differents systemes d'exploitation hotes (par exemple, en executant un profil Windows sur un hote macOS et un hote Linux), verifiez que les capacites de codecs WebRTC sont identiques sur les deux hotes. L'approche pilotee par profil de BotBrowser devrait produire la meme sortie quel que soit l'hote, mais la verification vous donne confiance.

7. Surveillez les erreurs WebRTC liees aux codecs. Si vous rencontrez des problemes de connectivite WebRTC, verifiez la console du navigateur pour les erreurs de negociation de codecs. BotBrowser gere avec elegance l'ecart entre les codecs du profil et les codecs disponibles localement, mais certains cas limites avec des configurations de pairs inhabituelles peuvent necessiter une attention particuliere.

Questions frequentes

Qu'est-ce que le fingerprinting des codecs WebRTC ?

Le fingerprinting des codecs WebRTC est une technique ou les sites web interrogent les capacites multimedia WebRTC de votre navigateur pour connaitre les codecs video et audio que votre systeme prend en charge. Parce que le support des codecs varie selon le systeme d'exploitation et le materiel, ces informations peuvent etre utilisees comme signal de suivi pour deduire des details sur votre plateforme.

En quoi est-ce different du fingerprinting general des codecs multimedia ?

Le fingerprinting general des codecs multimedia utilise des API comme canPlayType() et MediaCapabilities. Le fingerprinting des codecs WebRTC utilise des API specifiques a WebRTC : RTCRtpSender.getCapabilities(), RTCRtpReceiver.getCapabilities() et les offres SDP de createOffer(). L'ensemble de codecs WebRTC n'est pas identique a l'ensemble general de codecs multimedia, car WebRTC a sa propre liste de codecs pris en charge qui reflete les exigences de communication en temps reel. L'approche pilotee par profil de BotBrowser couvre les deux surfaces de maniere coherente. Pour la protection generale des codecs multimedia, consultez l'article sur le fingerprinting des types MIME et codecs.

Un site web peut-il interroger les codecs WebRTC sans passer d'appel ?

Oui. Aucune connexion WebRTC reelle n'est necessaire. RTCRtpSender.getCapabilities('video') est une methode statique qui retourne immediatement les informations de codecs. De meme, createOffer() genere un document SDP sans se connecter a aucun pair distant. Les deux operations sont rapides, silencieuses et ne necessitent aucune interaction utilisateur ni permission.

BotBrowser desactive-t-il des codecs ?

Non. BotBrowser ne supprime ni ne desactive la fonctionnalite des codecs. Au lieu de cela, il controle quelles informations de codecs sont rapportees a JavaScript. La liste de codecs visible par JavaScript correspond au profil charge. En interne, le navigateur utilise toujours les codecs disponibles sur le systeme hote pour le traitement multimedia reel. Cela signifie que votre empreinte est controlee sans sacrifier la fonctionnalite WebRTC.

Que se passe-t-il si le profil liste un codec que mon systeme ne prend pas en charge ?

BotBrowser gere cela avec elegance. Les API visibles par JavaScript rapportent la liste de codecs du profil, maintenant l'empreinte correcte. Lorsque la negociation reelle des medias WebRTC se produit, le navigateur utilise en interne uniquement les codecs que le systeme hote peut traiter. Si un codec du profil n'est pas disponible localement, il est exclu du traitement interne sans affecter la presentation de l'empreinte. Cela previent les crashs et garantit que les appels continuent de fonctionner.

Cela protege-t-il aussi les codecs audio ?

Oui. La construction de codecs pilotee par profil de BotBrowser s'applique aux capacites video et audio. La liste de codecs audio de getCapabilities('audio') et les payload types audio dans les offres SDP sont egalement derives des donnees du profil.

Comment BotBrowser gere-t-il l'ordonnancement des codecs ?

L'ordonnancement des codecs dans les listes de capacites et les offres SDP peut contenir des informations specifiques a la plateforme. BotBrowser preserve l'ordonnancement exact des codecs du profil, qui reflete l'ordonnancement naturel sur la plateforme cible. Ce detail compte car l'ordre dans lequel les codecs apparaissent est en soi un signal qui doit correspondre a la cible du profil.

Cela fonctionne-t-il en mode headless ?

Oui. Les capacites de codecs WebRTC sont disponibles en mode headless, et la construction de codecs pilotee par profil de BotBrowser fonctionne de maniere identique que le navigateur s'execute en mode headless ou avec une fenetre visible.

Puis-je verifier la protection sans passer un vrai appel WebRTC ?

Oui. Vous pouvez verifier en appelant RTCRtpSender.getCapabilities('video') et createOffer() dans la console JavaScript d'une page ou via l'automatisation Playwright/Puppeteer. Aucune connexion entre pairs ni serveur distant n'est necessaire. Les exemples de code dans la section Configuration et utilisation le demontrent.

Resume

L'enumeration des codecs WebRTC via getCapabilities() et les offres SDP expose des capacites multimedia qui different selon les systemes d'exploitation, faisant de la liste de codecs un signal de suivi potentiel. BotBrowser resout cela au niveau du moteur en construisant les capacites de codecs WebRTC entierement a partir du profil de fingerprint charge. Chaque API qui expose des informations de codecs, de getCapabilities() a la generation SDP de createOffer(), retourne des resultats coherents avec le profil. La separation a double couche entre la liste de codecs visible par JavaScript et les decodeurs enregistres en interne garantit que votre empreinte correspond a la plateforme cible tandis que la fonctionnalite WebRTC reelle continue de fonctionner.

Combine avec la prevention des fuites d'IP WebRTC, la protection des types MIME et codecs, les profils de navigateur multiplateformes et la verification complete de fingerprint, BotBrowser fournit un controle complet sur chaque signal WebRTC qui pourrait reveler l'identite de votre plateforme.