Fingerprinting de codecs WebRTC: cuando las capacidades multimedia revelan tu plataforma

Introducción

WebRTC permite la comunicación de video y audio en tiempo real en el navegador. Antes de que cualquier medio fluya entre pares, los navegadores enumeran sus codecs compatibles y los exponen a través de APIs de capacidades y ofertas SDP (Session Description Protocol). Esta negociación es esencial para las videollamadas funcionales, pero también crea un inventario detallado de las capacidades multimedia de tu sistema que cualquier sitio web puede consultar sin permisos especiales.

Las capacidades de codecs WebRTC difieren entre plataformas y pueden usarse como señal de rastreo. Diferentes sistemas operativos proporcionan diferentes niveles de soporte de aceleración por hardware, lo que determina directamente qué codecs aparecen en las listas de capacidades del navegador. Un sitio web puede consultar estas listas y compararlas con perfiles de plataforma conocidos para inferir tu sistema operativo real, incluso cuando tu cadena de user agent afirma algo diferente.

BotBrowser aborda esto construyendo las listas de capacidades de codecs WebRTC completamente desde el perfil de fingerprint, asegurando que lo que JavaScript ve coincida con la plataforma objetivo del perfil en lugar del hardware real del sistema anfitrión.

La solución de BotBrowser

BotBrowser resuelve el fingerprinting de codecs WebRTC a nivel del motor del navegador, donde las capacidades de codecs se determinan realmente. En lugar de parchear APIs de JavaScript o post-procesar cadenas SDP, BotBrowser construye las listas de capacidades de codecs a partir de los datos del perfil de fingerprint. Esto asegura que cada API que expone información de codecs devuelva resultados consistentes y precisos según el perfil.

Construcción de codecs impulsada por perfil

Cuando se carga un perfil de BotBrowser, las capacidades de codecs WebRTC se construyen a partir de los datos de codecs registrados en el perfil en lugar de las capacidades de hardware reales del sistema anfitrión. El perfil contiene la configuración completa de codecs capturada de un dispositivo real que coincide con la plataforma objetivo:

• La lista completa de codecs de video y audio compatibles
• Parámetros de codecs incluyendo profiles, levels y opciones específicas de formato
• El ordenamiento correcto de codecs en las listas de capacidades
• Asignaciones de payload type para la generación de SDP

Esto significa que un perfil dirigido a una plataforma, cargado en un sistema operativo anfitrión completamente diferente, seguirá reportando los codecs WebRTC correctos para el objetivo del perfil. Las capacidades reales del sistema anfitrión son irrelevantes para lo que JavaScript ve.

Consistencia del SDP

BotBrowser asegura que el SDP generado por createOffer() sea consistente con las capacidades de codecs reportadas por getCapabilities(). Ambos se derivan de los mismos datos del perfil, por lo que no hay brecha entre lo que reportan las APIs de capacidades y lo que aparece en el SDP.

Las líneas m=video y m=audio en el SDP contienen exactamente los payload types que corresponden al conjunto de codecs del perfil. Los atributos a=rtpmap y a=fmtp coinciden con los parámetros de los objetos de capacidades. Cualquier script que consulte ambas APIs y las compare encontrará perfecta consistencia.

Compatibilidad funcional

Uno de los desafíos en el control de codecs WebRTC es mantener la funcionalidad real de los medios. Si el perfil especifica un codec que el sistema anfitrión realmente no puede decodificar, el navegador necesita manejar esto con elegancia.

BotBrowser aborda esto mediante un diseño de doble capa: JavaScript ve la lista de codecs del perfil, mientras que internamente el navegador registra solo los codecs que el sistema anfitrión puede procesar realmente. Esta separación significa:

• Los scripts de fingerprinting ven la lista de codecs precisa del perfil.
• Las llamadas WebRTC reales negocian usando codecs que tanto los pares como el sistema local pueden manejar.
• No hay crash ni error cuando un perfil lista un codec que el anfitrión no puede decodificar.

Esta es una distinción crítica. Simplemente inyectar entradas de codecs en la lista de capacidades causaría fallos cuando el navegador intente usar realmente esos codecs. La integración a nivel de motor de BotBrowser maneja correctamente el límite entre la presentación del fingerprint y el procesamiento funcional de medios.

Alineación entre APIs

BotBrowser asegura la consistencia no solo dentro de las APIs WebRTC, sino a través del conjunto completo de interfaces de capacidades multimedia:

• RTCRtpSender.getCapabilities() y RTCRtpReceiver.getCapabilities() devuelven codecs consistentes con el perfil.
• Las ofertas SDP de createOffer() contienen payload types coincidentes.
• Las APIs de medios generales como canPlayType() y MediaCapabilities.decodingInfo() devuelven resultados consistentes con el perfil de codecs WebRTC.
• El fingerprint multimedia general cuenta una historia única y coherente sobre la plataforma.

Esta alineación entre APIs es lo que hace efectiva la protección de BotBrowser. Todas las rutas de reporte de codecs están gobernadas por una única fuente de datos consistente: el perfil cargado.

Configuración y uso

Uso básico por CLI

La protección de codecs WebRTC es automática cuando se carga un perfil. No se necesitan flags adicionales:

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

La configuración de codecs WebRTC del perfil se aplica al inicio. Todas las consultas de capacidades WebRTC y la generación de SDP posteriores reflejarán el conjunto de codecs del perfil.

Integración con 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();
})();

Integración con 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();
})();

Combinación con proxy y configuración de plataforma

Para una consistencia completa de plataforma, combina la protección de codecs con la configuración de proxy y plataforma:

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)"

Esto asegura que no solo las capacidades de codecs sean consistentes con la plataforma del perfil, sino que la identidad de red, zona horaria, configuración regional y todas las demás señales también estén alineadas.

Verificación

Después de configurar BotBrowser con un perfil, verifica que la protección de codecs WebRTC esté funcionando:

1. Verificación del conteo de codecs: Llama a RTCRtpSender.getCapabilities('video') y confirma que el número de codecs coincide con lo que esperas para la plataforma objetivo del perfil.

2. Verificación de estabilidad: Recarga la página y repite. El conteo y tipos de codecs deben ser idénticos entre cargas de página. Reinicia el navegador con el mismo perfil y verifica de nuevo.

3. Sitios de prueba de fingerprint: Visita servicios de prueba de fingerprint de navegador y revisa la sección WebRTC. Los codecs reportados no deben marcar ninguna anomalía.

Mejores prácticas

1. Siempre usa un perfil completo. Las capacidades de codecs WebRTC deben alinearse con el sistema operativo, la versión del navegador y la configuración de GPU del perfil. Los perfiles de BotBrowser se capturan de dispositivos reales, asegurando que todas estas dimensiones sean internamente consistentes. No mezcles componentes de perfiles.

2. Haz coincidir las expectativas de codecs con tu caso de uso. Si trabajas con sitios web que usan activamente WebRTC para videollamadas o streaming, asegúrate de que el conjunto de codecs de tu perfil soporte los formatos que esos sitios esperan. Un perfil que excluya codecs comúnmente usados puede causar fallos de negociación durante sesiones WebRTC reales.

3. Combina con protección de IP WebRTC. El fingerprinting de codecs y la filtración de IP son preocupaciones de privacidad WebRTC separadas, pero ambas necesitan abordarse. Usa la integración de proxy de BotBrowser con --proxy-server y --bot-webrtc-ice para asegurar que tus direcciones IP WebRTC también estén controladas. Consulta la guía de prevención de fugas WebRTC para más detalles.

4. No modifiques la configuración de codecs manualmente. Deja que el perfil maneje la configuración de codecs completamente. Agregar o eliminar codecs manualmente a través de flags de Chrome o sobrescrituras de configuración puede crear inconsistencias que socaven la consistencia del perfil.

5. Mantén los perfiles actualizados. El soporte de codecs cambia con las versiones del navegador. Se agregan nuevos codecs y los parámetros de codecs existentes pueden cambiar. Usar perfiles que coincidan con la versión del navegador declarada asegura que tus capacidades de codecs correspondan a lo que un navegador real de esa versión reportaría.

6. Verifica la consistencia multiplataforma. Si usas el mismo perfil en diferentes sistemas operativos anfitriones (por ejemplo, ejecutando un perfil de Windows tanto en un host macOS como en un host Linux), verifica que las capacidades de codecs WebRTC sean idénticas en ambos hosts. El enfoque impulsado por perfil de BotBrowser debería producir la misma salida independientemente del anfitrión, pero la verificación te da confianza.

7. Monitorea errores WebRTC relacionados con codecs. Si encuentras problemas de conectividad WebRTC, revisa la consola del navegador para errores de negociación de codecs. BotBrowser maneja con elegancia la brecha entre los codecs del perfil y los codecs disponibles localmente, pero ciertos casos extremos con configuraciones de pares inusuales pueden requerir atención.

Preguntas frecuentes

¿Qué es el fingerprinting de codecs WebRTC?

El fingerprinting de codecs WebRTC es una técnica donde los sitios web consultan las capacidades multimedia WebRTC de tu navegador para conocer qué codecs de video y audio soporta tu sistema. Debido a que el soporte de codecs varía por sistema operativo y hardware, esta información puede usarse como señal de rastreo para inferir detalles sobre tu plataforma.

¿En qué se diferencia del fingerprinting general de codecs multimedia?

El fingerprinting general de codecs multimedia usa APIs como canPlayType() y MediaCapabilities. El fingerprinting de codecs WebRTC usa APIs específicas de WebRTC: RTCRtpSender.getCapabilities(), RTCRtpReceiver.getCapabilities() y ofertas SDP de createOffer(). El conjunto de codecs WebRTC no es idéntico al conjunto general de codecs multimedia, porque WebRTC tiene su propia lista de codecs compatibles que refleja los requisitos de comunicación en tiempo real. El enfoque impulsado por perfil de BotBrowser cubre ambas superficies de manera consistente. Para la protección general de codecs multimedia, consulta el artículo sobre fingerprinting de tipos MIME y codecs.

¿Puede un sitio web consultar codecs WebRTC sin hacer una llamada?

Sí. No se necesita ninguna conexión WebRTC real. RTCRtpSender.getCapabilities('video') es un método estático que devuelve información de codecs inmediatamente. De manera similar, createOffer() genera un documento SDP sin conectarse a ningún par remoto. Ambas operaciones son rápidas, silenciosas y no requieren interacción del usuario ni permisos.

¿BotBrowser deshabilita algún codec?

No. BotBrowser no elimina ni deshabilita la funcionalidad de codecs. En su lugar, controla qué información de codecs se reporta a JavaScript. La lista de codecs visible para JavaScript coincide con el perfil cargado. Internamente, el navegador sigue usando los codecs disponibles en el sistema anfitrión para el procesamiento real de medios. Esto significa que tu fingerprint está controlado sin sacrificar la funcionalidad WebRTC.

¿Qué sucede si el perfil lista un codec que mi sistema no soporta?

BotBrowser maneja esto con elegancia. Las APIs visibles para JavaScript reportan la lista de codecs del perfil, manteniendo el fingerprint correcto. Cuando ocurre la negociación real de medios WebRTC, el navegador usa internamente solo los codecs que el sistema anfitrión puede procesar. Si un codec del perfil no está disponible localmente, se excluye del procesamiento interno sin afectar la presentación del fingerprint. Esto previene crashes y asegura que las llamadas sigan funcionando.

¿Esto protege los codecs de audio también?

Sí. La construcción de codecs impulsada por perfil de BotBrowser se aplica tanto a las capacidades de video como de audio. La lista de codecs de audio de getCapabilities('audio') y los payload types de audio en las ofertas SDP también se derivan de los datos del perfil.

¿Cómo maneja BotBrowser el ordenamiento de codecs?

El ordenamiento de codecs en las listas de capacidades y ofertas SDP puede contener información específica de la plataforma. BotBrowser preserva el ordenamiento exacto de codecs del perfil, que refleja el ordenamiento natural en la plataforma objetivo. Este detalle importa porque el orden en que aparecen los codecs es en sí mismo una señal que debe coincidir con el objetivo del perfil.

¿Funciona esto en modo headless?

Sí. Las capacidades de codecs WebRTC están disponibles en modo headless, y la construcción de codecs impulsada por perfil de BotBrowser funciona de manera idéntica ya sea que el navegador se ejecute en modo headless o con una ventana visible.

¿Puedo verificar la protección sin hacer una llamada WebRTC real?

Sí. Puedes verificar llamando a RTCRtpSender.getCapabilities('video') y createOffer() en la consola JavaScript de una página o mediante automatización con Playwright/Puppeteer. No se necesita conexión entre pares ni servidor remoto. Los ejemplos de código en la sección de Configuración y uso demuestran esto.

Resumen

La enumeración de codecs WebRTC a través de getCapabilities() y ofertas SDP expone capacidades multimedia que difieren entre sistemas operativos, haciendo que la lista de codecs sea una señal de rastreo potencial. BotBrowser resuelve esto a nivel del motor construyendo las capacidades de codecs WebRTC completamente desde el perfil de fingerprint cargado. Cada API que expone información de codecs, desde getCapabilities() hasta la generación de SDP con createOffer(), devuelve resultados consistentes con el perfil. La separación de doble capa entre la lista de codecs visible para JavaScript y los decodificadores registrados internamente asegura que tu fingerprint coincida con la plataforma objetivo mientras la funcionalidad real de WebRTC continúa funcionando.

Combinado con la prevención de fugas de IP WebRTC, la protección de tipos MIME y codecs, los perfiles de navegador multiplataforma y la verificación completa de fingerprint, BotBrowser proporciona un control exhaustivo sobre cada señal WebRTC que podría revelar la identidad de tu plataforma.