Informe WebRTC de CreepJS: rastrear los campos

El panel WebRTC de CreepJS es un informe compuesto, no una captura de paquetes ni una lista de todo lo que puede hacer el navegador. El recolector fijado en el commit 10aa6724cd33a1015db1574211890518cd04f0cc combina la enumeración de tipos de dispositivos, seis consultas de decodificación multimedia, el SDP de una oferta y datos seleccionados de eventos ICE. BotBrowser documenta controles de candidatos, proxy y servidores ICE para flujos autorizados; esos controles no garantizan la exactitud de un informe de CreepJS ni identifican una interfaz física o persona.

TL;DR

• El recolector convierte las filas de enumerateDevices() en tipos de dispositivo y las ordena; ese helper no lee las etiquetas.
• Consulta decodingInfo() con seis configuraciones fijas de audio y vídeo, conserva las filas compatibles y reduce cada una a etiquetas de fluidez y eficiencia energética.
• Se eliminan los ID numéricos de las extensiones SDP antes de deduplicar y ordenar las cadenas restantes. La lista mostrada no es el SDP original.
• La primera cadena de evento no vacía aporta iceCandidate y foundation; otro evento puede completar el resultado más tarde.
• Si no existe RTCPeerConnection, el resultado inmediato es null. Un temporizador independiente de tres segundos puede devolver campos parciales; null, salida parcial y campo omitido no son veredictos equivalentes.

Contents

• Límites del recolector y revisión fijada
• Mapa de procedencia de los campos
• Qué omiten los campos derivados del SDP
• Campos de candidato y resultados parciales
• Qué representa el hash del informe
• Un registro de lectura acotado
• Conclusión práctica

Límites del recolector y revisión fijada

Los enlaces de código fijan una revisión pública concreta de CreepJS. Las afirmaciones describen esa revisión, no una ejecución del sitio actual de CreepJS, BotBrowser ni Chrome estándar. El alcance es más acotado que una guía de configuración de WebRTC: relaciona los valores visibles con las operaciones que los generan y señala dónde la implementación descarta, resume o interrumpe datos por tiempo.

La distinción importa porque la comparación de códecs WebRTC trata APIs de códecs y compatibilidad, mientras que la agrupación de candidatos ICE y la privacidad temporal examina la precarga y el tiempo de los eventos. La prevención de fugas WebRTC cubre la configuración de proxy e ICE. Esta página sigue la construcción del informe de un recolector; no sustituye esas guías operativas.

Mapa de procedencia de los campos

Valor o grupo del informe	Operación del código fijado	Transformación o estado ausente	Qué permite sostener
mediaDevices	navigator.mediaDevices.enumerateDevices()	Convierte cada fila en kind y luego ordena; la API no disponible devuelve null	Qué tipos de dispositivo recibió este helper, no etiquetas, dispositivos físicos ni identidad del usuario
codecsSdp	SDP de createOffer() e ID de formato multimedia	Resume tipo MIME, frecuencias, canales, parámetros de formato y feedback	Una vista analizada de capacidades seleccionadas de la oferta, no cada línea SDP ni el éxito de reproducción
extensions	Líneas SDP a=extmap	Elimina el ID numérico, deduplica y ordena	Las cadenas de extensión restantes según este analizador, no su orden o ID originales
iceCandidate y foundation	Primer evento icecandidate no vacío	Extrae foundation una vez; la rama de dirección asigna etiquetas conocidas y el timeout conserva el valor bruto	La primera cadena del evento y un valor mostrado que depende de la rama, no un inventario de interfaces
address	connection.localDescription.sdp	Analiza primero una línea de conexión; después busca una subcadena con forma de candidato; excluye 0.0.0.0	Una dirección devuelta por este analizador, no prueba que no exista otra
foundationProp y stunConnection	Evento que alcanza la rama de dirección válida	Se devuelve junto a la dirección analizada; puede ser posterior al evento que guardó iceCandidate	Campos del evento que completó esta rama, no necesariamente del evento detrás de iceCandidate
Hash mostrado	codecsSdp, extensions, foundation, foundationProp, address y mediaDevices	Resume un subconjunto; iceCandidate y stunConnection no están en ese objeto	Igualdad de esas entradas seleccionadas según esta implementación, no del informe completo

La tabla es un mapa del código fuente, no una medición. La API RTCPeerConnection y la especificación WebRTC del W3C definen la interfaz del navegador, pero los nombres y operaciones anteriores pertenecen a este recolector fijado. Un campo con un nombre de API conocido todavía puede ser una proyección con pérdida de sus datos originales.

Qué omiten los campos derivados del SDP

El helper de extensiones extrae las líneas extmap, elimina el ID numérico de la extensión y después deduplica con Set y ordena lexicográficamente. Dos ofertas SDP cuyos ID o cuyo orden original difieran pueden producir la misma lista visible si las cadenas restantes coinciden. No es posible reconstruir las líneas originales a partir de esa lista.

La lista facilita responder «¿qué nombres de extensión sobrevivieron al análisis?», pero ya no permite responder «¿qué ID numérico tenían?» ni «¿en qué orden aparecían en la oferta?». Quien consuma el informe no debe inferir ninguno de esos valores descartados a partir de las cadenas ordenadas.

La salida de códecs también se resume. El recolector lee los ID de formato multimedia de audio y vídeo, busca líneas rtpmap, fmtp y rtcp-fb coincidentes y combina entradas por tipo MIME. El resultado conserva campos seleccionados como frecuencias, canales, parámetros de formato y feedback. Sirve para leer lo que el panel decidió mostrar, pero no es un archivo SDP sin modificar ni una prueba de que un par remoto aceptó cada códec.

El orden del analizador importa. Primero busca los ID de formato de cada sección multimedia y después busca en todo el SDP de la oferta las líneas que contienen cada ID. Una línea rtpmap proporciona el tipo MIME y la frecuencia; para audio, un tercer componente separado por barras se usa como número de canales, con un valor predeterminado de uno si falta o se evalúa como cero. Una línea rtcp-fb se agrega al feedback. Otras líneas coincidentes pueden aportar parámetros de formato, separados por punto y coma. Son campos de presentación ensamblados a partir de líneas coincidentes, no un validador de estándares.

El recolector también limita los detalles de códecs repetidos. Trata las entradas RTX de forma especial y un contador impide agregar una segunda descripción RTX por la misma ruta. Las entradas con el mismo tipo MIME se combinan: las frecuencias se unen como valores únicos y los parámetros de formato o el feedback se combinan cuando existen. Si una sección multimedia no tiene ID de formato o no hay líneas coincidentes, la lista de descripciones puede quedar vacía. Eso indica qué encontró este analizador en la oferta; no prueba que el navegador carezca de decodificador ni que falle la reproducción.

Esta distinción sirve cuando el panel parece más breve que el SDP. Una fila más corta puede deberse a agrupación, eliminación de duplicados, una lista de campos seleccionada o la ausencia de una línea coincidente. No demuestra por sí sola que se quitara un códec de la oferta. Para responder una pregunta sobre la oferta, inspecciona una captura SDP aparte, autorizada y redactada; no la reconstruyas desde la tabla del informe.

El helper independiente decodingInfo() construye seis configuraciones fijas: cuatro tipos de audio y dos de vídeo, con dimensiones, tasa de bits, frecuencia de fotogramas, canales y frecuencia de muestreo fijos. Las entradas de audio son Ogg Vorbis, Ogg FLAC, MP4/AAC y audio MPEG; las de vídeo son Ogg/Theora y MP4/AVC. El objeto de vídeo usa 1920 por 1080, 120000 bits por segundo y 60 fotogramas por segundo. El objeto de audio usa dos canales, 300000 bits por segundo y una frecuencia de muestreo de 5200. El código pasa solo el objeto de audio a las entradas de audio y solo el objeto de vídeo a las entradas de vídeo.

Conserva únicamente filas cuya respuesta tenga supported: true; después emite las etiquetas smooth y efficient cuando los booleanos correspondientes son verdaderos. Una fila compatible puede no mostrar ninguna etiqueta si ambos booleanos son falsos. Una fila ausente puede significar que el reductor omitió una respuesta con supported falso; una promesa rechazada sigue una ruta de registro y no produce una fila compatible para reducir. Ninguno de esos estados explica por sí solo por qué un formato no está disponible en otra aplicación. Las entradas son consultas concretas, no todos los canales, frecuencias de muestreo, resoluciones, perfiles de códec o frecuencias de fotogramas posibles.

Esto difiere de preguntar qué formatos multimedia admite la plataforma en general. La especificación Media Capabilities describe los campos de compatibilidad, fluidez y eficiencia energética; el recolector fijado decide qué seis entradas consulta y qué respuestas conserva. La referencia de decodingInfo() explica el contrato del método, no la política de visualización del recolector. Si una aplicación usa 30 fotogramas por segundo mientras el informe consulta 60, son consultas distintas. El resultado de una no se debe trasladar a la otra. La misma limitación afecta a la frecuencia de muestreo y los canales de audio: una consulta de dos canales con el valor fijado no enumera todas las configuraciones de audio posibles.

Campos de candidato y resultados parciales

El callback guarda la primera cadena de candidato no vacía y analiza su foundation, pero sigue escuchando hasta que getIPAddress() puede analizar una dirección del SDP de la descripción local. En esa rama válida, knownInterface transforma 842163049 en public interface y 2268587630 en WireGuard; el timeout de tres segundos devuelve en cambio el valor bruto analizado. El valor mostrado depende de la rama de salida y no demuestra un inventario de interfaces. foundationProp y stunConnection proceden del evento que alcanzó la rama de dirección y pueden no tener el mismo evento de origen que iceCandidate.

Hay dos condiciones de salida distintas. Si falta window.RTCPeerConnection, el recolector resuelve null antes de crear una conexión. De lo contrario, crea una conexión con tamaño de grupo uno y dos URL de STUN de Google, crea un canal de datos y solicita una oferta con opciones de recepción de audio y vídeo. Llama a setLocalDescription() y lee inmediatamente el SDP del objeto de oferta para resumir extensiones y códecs. En esta primera lectura no espera a que termine setLocalDescription().

Después inicia un temporizador de tres segundos mientras escucha eventos icecandidate. Si vence con un SDP de oferta disponible, el resultado puede incluir campos de códec, extensión, foundation y candidato sin los campos posteriores que dependen de una dirección; sin SDP, resuelve null. El vencimiento quita el listener y cierra la conexión. Esta ventana temporal está definida por el código; no prueba que terminara la recolección ICE ni que el conjunto final esté completo. El código no asigna un motivo universal a todos estos casos.

getIPAddress() prueba primero una línea de conexión SDP y luego recurre a una subcadena con forma de candidato. Excluye el literal 0.0.0.0, pero si el analizador devuelve undefined solo se sabe que ese código no produjo una dirección. No demuestra que el navegador careciera de interfaz, que no existiera ningún candidato ni que un servicio remoto aceptara o rechazara la sesión. El analizador no es un inventario de red: devuelve una coincidencia según su regla de priorizar la línea de conexión. La guía independiente sobre privacidad de direcciones mDNS explica lo que la forma de una dirección puede revelar y lo que no.

Hay un límite sutil en la asociación de campos devueltos. iceCandidate y foundation solo se asignan mientras la cadena guardada está vacía, así que conservan la primera cadena de evento no vacía. El análisis de dirección lee en cambio el texto actual de connection.localDescription.sdp. Cuando un evento llega a un SDP con una dirección analizable, el callback devuelve foundationProp y stunConnection del evento actual. Quien agrupe todas las propiedades devueltas bajo «el primer candidato» estaría mezclando dos reglas de selección distintas.

Por eso el objeto puede tener procedencia mixta: la cadena guardada y foundation de un evento temprano, junto con una dirección encontrada en la descripción local actual y campos específicos del evento que completó la rama. «Mixta» describe qué rama de código aportó cada propiedad; no demuestra una carrera, incoherencia ni defecto de red. Quien consuma el informe debería conservar la diferencia entre fuentes en vez de afirmar que todas las propiedades describen un único paquete o interfaz.

El callback también ignora eventos sin objeto de candidato y retorna antes si el texto actual de la descripción local no proporciona una dirección. No finaliza la recolección con cada evento. El temporizador es la otra ruta de finalización y su resultado parcial contiene menos propiedades que la ruta donde se obtuvo una dirección. Al comparar dos informes, comprueba primero si ambos alcanzaron la misma rama; en caso contrario, la diferencia de forma del objeto puede deberse al tiempo o a la disponibilidad, no a un valor cambiado en un campo común.

Qué representa el hash del informe

El código de visualización construye la entrada del hash con codecsSdp, extensions, foundation, foundationProp, address y mediaDevices. No incluye todos los valores devueltos: iceCandidate y stunConnection no forman parte de esa entrada. Por tanto, una cadena de candidato sin cambios en los campos seleccionados podría no aparecer en la comparación del hash; a la inversa, un campo seleccionado puede cambiar el resumen sin indicar por qué cambió.

La igualdad del hash es una ayuda de comparación específica de esta implementación. No demuestra que dos navegadores sean el mismo dispositivo, que coincidan los informes completos o que un sitio externo asigne el mismo resultado. Si los digestos difieren, el código solo indica que al menos una entrada seleccionada difiere según la implementación del hash; el propio digesto no identifica cuál. Si coinciden, aún pueden diferir campos omitidos porque no se incluyeron. El resumen es una señal compacta para inspeccionar los campos seleccionados, no un sustituto de ellos.

El productor también calcula mediaDevices independientemente del resultado de la conexión entre pares. El código HTML mapea esa lista a etiquetas breves, y la entrada del hash incluye la lista junto a los valores derivados del SDP. Una enumeración no disponible o filtrada por permisos puede cambiar esa parte del hash aunque los campos de la oferta no cambien. A la inversa, una diferencia en la oferta puede cambiar un campo SDP seleccionado mientras la lista de tipos permanece igual. El digesto combina categorías que proceden de APIs y rutas de recolección distintas.

Para comparar con cuidado, separa tres niveles: la operación fuente, su valor devuelto y la proyección visible. Por ejemplo, enumerateDevices() devuelve registros de dispositivos; este helper conserva solo los tipos; la interfaz transforma esos tipos en etiquetas. La lista original, la salida del helper y la etiqueta visible no son intercambiables. Del mismo modo, decodingInfo() devuelve un objeto de compatibilidad; el reductor conserva un subconjunto y el panel presenta sus campos supervivientes. La ruta del código, no solo el texto final, define qué permite sostener el informe.

El mantenimiento de este mapa debe seguir los cambios de entradas fijas, propiedades conservadas, temporizador o campos del hash en revisiones posteriores de CreepJS. Comparar solo la etiqueta mostrada ocultaría qué etapa cambió. Fija la revisión, compara las funciones productoras y consumidoras y actualiza únicamente la fila pertinente del mapa de procedencia. Ese procedimiento describe el mantenimiento de código público y no equivale a probar una compilación del navegador. Para límites entre páginas, red y producto, consulta la cobertura de suites detectoras públicas.

Un registro de lectura acotado

Al conservar una interpretación del código, registra la revisión y solo las distinciones entre campos necesarias para la pregunta. No conserves direcciones sin redactar, etiquetas de dispositivos, SDP completo o cadenas de candidato si basta con un estado anonimizado. Un buen registro indica si el valor procede de una llamada API, una descripción de oferta, un callback de evento o una proyección de interfaz. También indica si la propiedad estaba ausente, se filtró o apareció por la ruta de vencimiento. Esas etiquetas permiten comparar dos informes sin copiar su contenido sensible.

{
  "sourceCommit": "10aa6724cd33a1015db1574211890518cd04f0cc",
  "field": "extensions",
  "sourceOperation": "getExtensions(sdp)",
  "steps": ["remove numeric extmap id", "deduplicate", "sort"],
  "state": "parsed",
  "interpretationLimit": "not original SDP order or extension IDs"
}

El ejemplo registra una ruta de código, no una observación del navegador. Si una investigación de soporte necesita evidencia de ejecución por separado, recógela bajo un plan de prueba autorizado y redacta los valores antes de compartirlos; el código público no contiene un registro de esa ejecución. Evita guardar un SDP completo o una dirección sin redactar solo para probar que un analizador devolvió un campo. Un estado booleano como addressPresent, el nombre de una rama y la revisión de código pueden responder la pregunta con menos datos retenidos. El registro no debe presentarse como evidencia de identidad ni de una decisión remota.

FAQ

¿Un hash WebRTC de CreepJS identifica un navegador?

No. El código fijado calcula el hash de entradas seleccionadas del informe. No incluye cada valor devuelto ni demuestra un dispositivo físico, una persona o una decisión de un servicio externo.

¿Una dirección ausente demuestra que WebRTC está desactivado?

No. El analizador puede no devolver una dirección aunque el recolector tenga otros datos, y el temporizador puede producir una salida parcial. El código tiene una rama null inmediata distinta cuando RTCPeerConnection no está disponible.

¿La lista de extensiones es el SDP original?

No. Se eliminan los ID numéricos, se quitan duplicados y se ordenan los valores. La lista no permite reconstruir el orden ni los identificadores originales.

¿decodingInfo() muestra todos los formatos multimedia compatibles?

No. Este recolector consulta seis configuraciones fijas y conserva solo respuestas compatibles con algunas etiquetas. Otra configuración, versión de navegador o contexto de dispositivo puede dar un resultado distinto.

Sources

• Recolector WebRTC de CreepJS fijado
• WebRTC del W3C
• RFC 8866: SDP
• Media Capabilities del W3C
• MDN: RTCPeerConnection
• MDN: MediaCapabilities.decodingInfo()
• Prevención de fugas WebRTC de BotBrowser

Conclusión práctica

Lee el panel WebRTC de CreepJS como un conjunto de campos con productores y transformaciones distintos. Conserva la revisión de código, distingue una API ausente del vencimiento y de una salida filtrada, y evita convertir un informe parcial o un hash de campos seleccionados en una afirmación sobre dispositivo, identidad o veredicto.