Campos del informe WebRTC de BrowserLeaks

La prueba WebRTC de BrowserLeaks muestra varias observaciones separadas: compatibilidad de interfaces, candidatos ICE recopilados, una descripción de sesión y el estado de los dispositivos multimedia. BotBrowser documenta controles de ICE y dispositivos, pero no puede validar las conclusiones de esta página. Ninguna fila demuestra identidad, anonimato ni una fuga universal. La lectura útil consiste en relacionar cada fila con la operación que la produjo y mantener separados los datos de cada ruta.

Resumen

La página pública de BrowserLeaks presenta comprobaciones de interfaz, un resultado de recopilación ICE, un registro SDP e información de dispositivos multimedia. Su script, con versión visible en la URL de la página, crea una RTCPeerConnection, solicita una oferta, escucha eventos de candidatos y consulta dispositivos y permisos por separado. Una dirección de candidato, una marca de compatibilidad, un estado de permiso o una fila de dispositivo describe esa operación en ese contexto; no ofrece una explicación completa de una ruta de red ni identifica a una persona.

Índice

• El informe contiene varias rutas, no una puntuación
• La compatibilidad y la recopilación de candidatos responden preguntas distintas
• Las etiquetas de candidatos proyectan los datos recopilados
• El registro SDP no es una captura de paquetes
• Dispositivos multimedia, permisos y captura son pasos separados
• Tabla de campos y operaciones
• Qué no puede demostrar el informe
• Preguntas frecuentes
• Fuentes
• Conclusión práctica

El informe contiene varias rutas, no una puntuación

La página WebRTC de BrowserLeaks presenta secciones distintas, no una puntuación numérica única. Los encabezados visibles incluyen la compatibilidad de WebRTC, etiquetas de dirección IP local y pública, una descripción de sesión y dispositivos multimedia. La página también incluye botones separados para solicitar permiso de captura de audio o vídeo. La distribución importa: cada sección se completa mediante una operación distinta expuesta por el navegador, y un valor en una sección no hace que las demás operaciones tengan éxito.

La página carga un script público cuyo URL lleva actualmente el identificador de versión 86970852. Ese script permite describir el comportamiento de la página, pero no es una norma de WebRTC ni un repositorio de código auditado. Una versión posterior podría cambiar los campos, los límites de espera o las reglas de análisis. El HTML visible y el script responden a una pregunta acotada: qué solicita esta versión recuperada de la página al navegador y dónde coloca los valores resultantes. No demuestran cómo se comportan todos los navegadores, redes, extensiones o versiones futuras de BrowserLeaks.

Este enfoque difiere de la documentación de prevención de fugas WebRTC de BotBrowser, que explica controles de ICE y SDP, y de la documentación de dispositivos multimedia, que describe la enumeración respaldada por perfil. Aquí el objeto es el informe de BrowserLeaks. El análisis separado de los campos WebRTC de CreepJS sigue las transformaciones de otro colector; sus nombres de campo y ramas no deben trasladarse a BrowserLeaks.

Mantener un alcance estrecho evita un error de interpretación habitual. Un informe puede mostrar a la vez RTCPeerConnection: True y un área de direcciones vacía, o mostrar una lista de dispositivos mientras una solicitud de captura sigue pendiente o se deniega. Esos estados no se contradicen. La compatibilidad indica que se encontró una interfaz; la recopilación de candidatos y las acciones de permiso son operaciones posteriores con resultados propios.

La compatibilidad y la recopilación de candidatos responden preguntas distintas

La página pública muestra dos filas de compatibilidad: RTCPeerConnection y RTCDataChannel. En el script versionado, la función constructora prueba nombres de constructor estándar y prefijados en el contexto de la página y en un iframe aislado. Después comprueba si el objeto obtenido expone createDataChannel. Son comprobaciones de disponibilidad de una interfaz. No crean una ruta de red, no establecen que ICE haya terminado y no muestran que un par remoto haya recibido datos.

La recopilación de candidatos es otra ruta. El script crea una peer connection con el servidor STUN público de Google stun:stun.l.google.com:19302, crea un canal de datos cuando ese método existe y solicita una oferta. La oferta pide recibir audio y vídeo; si esa forma falla, el script prueba una oferta más sencilla. Cuando el navegador acepta localmente la oferta, el script la establece como descripción local y procesa eventos de candidatos. Estas llamadas explican por qué la página puede mostrar datos relacionados con candidatos sin que una aplicación inicie una llamada, pero no prueban todas las aplicaciones, configuraciones TURN ni sesiones entre pares.

El script recopila valores del evento icecandidate y de líneas con forma de candidato en localDescription.sdp. Deduplica cadenas de direcciones analizadas, espera a que termine la ruta de recopilación o llegue a su rama de tiempo límite, escribe el SDP en el registro visible y cierra la peer connection. El flujo de eventos y la representación SDP son vistas relacionadas de una negociación, no dos análisis de red independientes. Si un valor aparece en ambas, no debe contarse como dos interfaces ni como dos fugas distintas.

La API del navegador define qué representan una RTCPeerConnection y su intercambio ICE; la página decide qué llamadas hacer y qué valores mostrar. La especificación W3C WebRTC y la referencia RTCPeerConnection de MDN describen el contrato de la interfaz. Las decisiones de esta prueba, como el servidor STUN, la oferta alternativa, el límite de recopilación y el texto mostrado, proceden del script de BrowserLeaks. Que una norma describa un evento de candidato no certifica la clasificación ni la conclusión del informe.

Las etiquetas de candidatos proyectan los datos recopilados

La página muestra áreas de dirección local y pública. El script del cliente recoge valores de eventos icecandidate y de localDescription.sdp, extrae texto con forma de dirección, lo compara con una lista de rangos locales y coloca valores únicos en uno de dos grupos. El análisis del agrupamiento de candidatos ICE explica por qué importa cuándo aparecen. Es una proyección propia del informe, no el objeto ICE completo, una captura de paquetes ni un inventario de todas las direcciones a las que puede llegar el sistema operativo.

Esta distinción importa cuando el resultado visible está vacío. Puede que el script no reciba un candidato que coincida con su analizador, que el navegador aplique una medida de privacidad, que la ruta elegida no produzca una dirección con la forma prevista o que el informe salga por una rama de tiempo límite o error. Un área vacía significa que esta versión no representó un valor analizado en ese campo durante esa ejecución. No demuestra que el equipo carezca de dirección local, que no exista una ruta de red ni que todos los observadores remotos vean lo mismo.

Del mismo modo, un valor en el grupo local no identifica automáticamente una interfaz física. La comprobación de rangos solo responde si el texto analizado coincide con las reglas locales del script. No establece qué adaptador produjo la dirección, quién controla ese adaptador ni si un par separado podría usarlo. Los valores del grupo público son etiquetas del informe para direcciones que no coinciden con esas reglas locales; no representan un mapa completo de accesibilidad pública ni prueban que se haya evitado un proxy.

El análisis también pierde información. El analizador busca subcadenas con forma de IPv4 o IPv6, en lugar de conservar un registro tipado de candidato con todos sus campos relacionados. El colector no muestra junto a cada dirección un objeto de procedencia que permita reconstruir su foundation, transporte, componente, dirección relacionada o selección de par de candidatos. Una lista de cadenas únicas no responde a esas preguntas omitidas. Cuando una aplicación necesita diagnosticar ICE, el par de candidatos seleccionado y las estadísticas de conexión de esa aplicación son evidencias distintas, con otro alcance y permisos.

La página de BrowserLeaks resulta útil como superficie pública de observación porque muestra lo que recopila su prueba actual. No es un veredicto general de detector. En una revisión de privacidad conviene separar la fuente de datos (evento o SDP), el analizador (extracción de direcciones), la regla de agrupación (coincidencia con rangos locales) y el campo visible. Colapsar esos pasos en «el navegador filtró» elimina información sobre lo que la página observó realmente.

El registro SDP no es una captura de paquetes

La sección Session Description incluye un registro SDP tomado de localDescription.sdp. SDP es una descripción textual que se usa durante la negociación. Puede incluir secciones de medios, atributos de códecs, parámetros ICE y líneas de candidatos; los campos concretos dependen de lo que genere el navegador y de lo que se haya recopilado cuando el informe los lee. No es un registro de paquetes enviados por la red ni demuestra que un extremo remoto recibiera, aceptara o utilizara cada línea.

El script normaliza la línea inicial de versión SDP cuando hace falta y después representa la descripción local en un área de texto. Ese texto pertenece al estado de negociación local del navegador. Es distinto de las listas de direcciones derivadas del informe: el mismo texto de candidato puede aparecer en el registro SDP y ser analizado en un grupo local o público. Tratar el registro bruto y la lista agrupada como confirmaciones independientes duplicaría una sola fuente.

El registro tampoco muestra todas las propiedades de una llamada real de una aplicación. Esta página crea su propia peer connection, su propia oferta y su propia configuración ICE. Una aplicación de videoconferencia puede usar otra oferta SDP, otros servidores ICE, una política de retransmisión, otro ciclo de llamada o un contexto distinto de origen y permisos. El resultado de BrowserLeaks no se generaliza a esas condiciones sin evidencia de esa ruta de la aplicación.

Una forma acotada de leer el registro consiste en preguntar tres cosas. ¿Qué texto estaba presente en la descripción local? ¿Qué líneas analizó este script como cadenas con forma de dirección? ¿Qué valores analizados colocó su comprobación de rangos en un grupo visible? La pregunta de si un par recibió un paquete no se responde solo con esta área de texto. Para eso hace falta evidencia de transporte o aplicación que este campo no presenta.

Dispositivos multimedia, permisos y captura son pasos separados

La sección Media Devices es una rama distinta de la recopilación de candidatos ICE. El script del cliente comprueba si existe navigator.mediaDevices.enumerateDevices() y la llama cuando está disponible. Para cada MediaDeviceInfo devuelta, formatea kind, label, deviceId y groupId. También registra por separado si las filas de entrada de audio y vídeo tienen etiquetas no vacías. El navegador puede exponer cantidades y etiquetas distintas según el contexto, el permiso, la política y la implementación; esas filas no son un inventario del hardware.

La página también consulta el estado de los permisos de micrófono y cámara mediante navigator.permissions.query() cuando esa API y el nombre del permiso son compatibles. Estos valores aparecen separados de las filas de dispositivos. La consulta de permiso puede variar entre navegadores, y una consulta rechazada o no compatible no equivale a un permiso denegado. El estado prompt no es una concesión de captura. Una etiqueta vacía no demuestra que el dispositivo no exista; puede reflejar reglas de divulgación o el permiso actual.

La captura de audio y vídeo son acciones explícitas distintas. Los botones de la página llaman a getUserMedia() con una solicitud solo de audio o solo de vídeo. El script actualiza el área correspondiente según se resuelva o falle esa promesa. La enumeración no abre automáticamente el micrófono o la cámara, y un estado de permiso no demuestra que se pueda obtener una transmisión utilizable. A la inversa, una solicitud de captura correcta de un tipo no significa que el otro esté concedido o disponible.

La separación coincide con el modelo de API del navegador. La referencia de MDN a enumerateDevices describe una lista filtrada por permisos y políticas; la referencia de getUserMedia describe una solicitud que puede mostrar una petición, rechazarse o devolver una transmisión. El informe presenta ambas superficies porque responden preguntas relacionadas, pero distintas. Su interfaz no convierte una fila de dispositivo en un resultado de captura.

La guía de dispositivos multimedia de BotBrowser describe cómo la enumeración respaldada por perfil difiere de los dispositivos reales del sistema. Ese control no crea una cámara física, no concede permisos del sistema operativo ni garantiza una etiqueta concreta en BrowserLeaks. La guía de configuración WebRTC también describe el comportamiento de red, no la captura multimedia. Mantener separados estos controles evita confundir una opción de perfil con un permiso del usuario o una entrada utilizable.

Tabla de campos y operaciones

La tabla resume los campos visibles del informe y la operación que los proporciona. Es una ayuda para leer esta versión de la página, no una instrucción para reproducir un análisis de red ni una afirmación de que cada fila sea una característica de un detector.

Campo visible	Operación de la página	Qué respalda	Qué no demuestra
RTCPeerConnection	Búsqueda del constructor en la página y en un iframe aislado	Si se encontró un constructor compatible en ese contexto	Que la recopilación termine o que la conexión alcance otro host
RTCDataChannel	Comprobación de createDataChannel en el objeto construido	Si el objeto expone ese método	Que se haya abierto un canal de datos con un par remoto
Local IP Address / Public IP Address	Análisis de candidatos y SDP, deduplicación y agrupación por rangos locales	Qué cadenas analizadas colocó el informe en cada grupo	Un inventario completo de interfaces, ruta, identidad física o veredicto universal de fuga
SDP Log	Lectura de localDescription.sdp tras la ruta de oferta	El texto presente en la descripción local de esta página	Una captura de paquetes, una respuesta remota o un intercambio de medios correcto
API Support en Media Devices	Comprobación de enumerateDevices()	Si el método está presente antes de enumerar	Si existe un dispositivo o puede abrirse
Filas de dispositivos	Formateo del resultado de enumerateDevices()	Los valores devueltos de kind, label, deviceId y groupId	Todo el hardware conectado o una identidad de dispositivo permanente
Permiso de audio/vídeo	permissions.query() para el nombre correspondiente	El estado de permiso que devuelve la consulta	Una transmisión concedida, compatibilidad uniforme o un dispositivo utilizable
Captura de audio/vídeo	Solicitud iniciada por el usuario con getUserMedia()	Si esa solicitud se resolvió o rechazó en el contexto actual	El otro tipo multimedia, permisos futuros o calidad de una llamada remota

Las filas deben seguir independientes al resumir un resultado. Por ejemplo, RTCPeerConnection: True, ninguna dirección visible y enumerateDevices(): True pueden coexistir porque describen presencia de interfaz, una ruta de análisis que no mostró un valor y otra API multimedia. Una nota que convierta todo en un único «aprobado» o «fallido» borra qué operación produjo cada observación.

Qué no puede demostrar el informe

El informe WebRTC no identifica a una persona. Las direcciones de candidatos pueden compartirse, reasignarse, traducirse, retransmitirse, ocultarse o no estar disponibles para una página. Los identificadores y las etiquetas de dispositivos multimedia son valores contextuales del navegador, no pruebas de quién posee un dispositivo físico. Un informe visible en el navegador no autentica una cuenta, no identifica una aplicación que incrusta un WebView ni determina qué conservó un servidor después de una solicitud.

El informe no demuestra anonimato. Un campo de dirección es solo una superficie observable; la página no mide todas las rutas de red ni todas las señales del navegador. Un campo vacío no demuestra una ruta limpia, y un valor público no es por sí mismo evidencia de que se evitó un proxy. Antes de sostener una afirmación de privacidad de red hay que definir un observador y un contexto de prueba acotado.

Tampoco demuestra que un navegador «supere» un detector de bots. BrowserLeaks es una página pública de diagnóstico, no un estándar universal de decisiones sobre tráfico automatizado. Un campo puede recopilarse para depuración o transparencia sin que ningún servicio anti-bots lo utilice. El informe no determina decisiones de proveedores, resultados de desafíos ni tasas de aceptación.

Por último, el informe depende del tiempo y el contexto. La versión del navegador, los permisos de origen, la ruta de red, la disponibilidad de STUN, las políticas, las extensiones y los cambios del script pueden modificar el resultado visible. El identificador de versión del script señala el recurso recuperado cuando se inspeccionó; no garantiza que todas las visitas futuras reciban el mismo código. Conviene citar la página pública con la fecha de consulta y la sección leída, no tratarla como una especificación inmutable.

Preguntas frecuentes

¿La prueba WebRTC de BrowserLeaks siempre muestra una dirección pública?

No. La página muestra una dirección analizada cuando su operación recibe texto de candidatos o SDP que reconoce el analizador y la prueba alcanza la ruta de representación. Un resultado vacío puede tener varias causas y no demuestra que no exista otra dirección o ruta.

¿RTCPeerConnection: True demuestra que una llamada WebRTC funciona?

No. Es una comprobación de compatibilidad. La recopilación de candidatos, la conectividad ICE, la negociación remota y la transferencia de medios son etapas posteriores. La fila de compatibilidad no representa una llamada terminada con otro extremo.

¿La lista de dispositivos significa que el micrófono está activo?

No. enumerateDevices() devuelve una lista filtrada por el navegador. Los botones de captura de la página envían solicitudes independientes con getUserMedia(), que pueden resolverse o fallar por separado. Una fila no demuestra que la captura haya comenzado.

¿La página BrowserLeaks es un detector de código abierto?

La página y su script pueden recuperarse públicamente, lo que permite inspeccionar el comportamiento que muestran. Eso no demuestra que exista una licencia de código abierto o un repositorio con licencia. Aquí se describe como una página pública con un script público, no como un proyecto con licencia de código fuente.

¿El resultado dice si un navegador es detectable?

No. Muestra observaciones seleccionadas de WebRTC y dispositivos multimedia. Otras páginas y servicios pueden utilizar APIs, políticas o señales del servidor distintas; este informe no comunica sus decisiones.

Fuentes

• BrowserLeaks WebRTC Leak Test y su script del cliente con versión de la página.
• W3C WebRTC 1.0 y RTCPeerConnection de MDN.
• MediaDevices.enumerateDevices() de MDN y MediaDevices.getUserMedia().
• Prevención de fugas WebRTC de BotBrowser y Privacidad de dispositivos multimedia.

Conclusión práctica

Lee la página WebRTC de BrowserLeaks como un conjunto de resultados independientes. Relaciona las marcas de compatibilidad con las comprobaciones de constructores, los grupos de direcciones con el análisis de candidatos y SDP, el registro de sesión con la descripción local, las filas de dispositivos con la enumeración, las etiquetas de permiso con sus consultas y los resultados de captura con solicitudes explícitas de getUserMedia(). El informe ofrece una vista útil de esas operaciones dentro del contexto de su página. No las convierte en identidad personal, garantía de anonimato, veredicto universal de fuga ni predicción de una decisión anti-bots.