Candidatos mDNS de WebRTC y privacidad de la red local

WebRTC reúne candidatos ICE para encontrar una ruta entre pares. Un candidato de host puede revelar una interfaz local; por eso el navegador puede usar un nombre mDNS en lugar de una dirección privada. RFC 8828 describe este objetivo de privacidad, pero no promete anonimato. BotBrowser puede repetir un escenario autorizado y observar candidatos y estados visibles; no puede controlar al par remoto ni demostrar la retención del servicio.

Resumen

Trata el nombre mDNS como un nombre que protege parcialmente al host, no como prueba de que no existe información local. Registra por separado versión del navegador, política ICE, tipo de candidato, origen final y resultado visible. Usa medios sintéticos, rutas propias y tiempos limitados. No publiques direcciones, credenciales ICE ni grabaciones.

BotBrowser puede repetir una prueba WebRTC autorizada en un contexto declarado y observar categorías de candidatos redactadas y el estado visible. No puede controlar al par remoto, proporcionar una cámara, inspeccionar la retención del servicio ni garantizar el comportamiento de todos los navegadores. Esa limitación debe acompañar cualquier resultado usado para una decisión de versión.

Contenido

• Qué cambia mDNS
• Separar la evidencia
• Ejecutar una prueba limitada
• Tipos de candidato en contexto
• Diseñar la comparación
• Interpretar los resultados
• Conservar evidencia útil
• Clasificar fallos y limpiar
• Lista de comprobación
• Conclusión práctica

Qué cambia mDNS

El candidato de host describe una interfaz local útil para el par. Con mDNS contiene un nombre con alcance local en vez de la dirección. Los candidatos reflexivos pueden mostrar una asignación pública y un relay puede mostrar que se eligió un relay. La lista de candidatos es una observación, no un informe completo de privacidad.

Separar la evidencia

Observación	Registrar	No demuestra
Señalización	origen final y estado HTTP	que el par sea confiable
ICE	tipo, protocolo y nombre mDNS redactado	anonimato o ausencia de registros
Conectividad	par seleccionado y transición	calidad o estabilidad
Aplicación	marcador propio y límite de tiempo	un registro remoto

No conviertas un nombre mDNS en un inventario. Redacta SDP, contraseñas y credenciales. Un cambio del navegador o de TURN puede cambiar los tipos sin cambiar tu aplicación.

Ejecutar una prueba limitada

Mantén dos páginas propias: control y candidata. Usa pistas generadas, señalización con límite y una aserción explícita de icegatheringstate. Clasifica por separado DNS, certificados, permisos, señalización y conexión. Un tiempo agotado significa que falta evidencia.

const state = await page.evaluate(async () => {
  const pc = new RTCPeerConnection({ iceServers: [] });
  const values = [];
  pc.onicecandidate = e => {
    const candidate = e.candidate;
    if (!candidate) return;
    const isMdnsHost = candidate.type === 'host' && /\\.local(?:\\s|$)/.test(candidate.candidate);
    values.push(isMdnsHost ? 'mdns-host' : candidate.type || 'unknown');
  };
  await pc.setLocalDescription(await pc.createOffer({ offerToReceiveAudio: true }));
  await new Promise(resolve => setTimeout(resolve, 1500));
  pc.close();
  return { gathering: pc.iceGatheringState, values };
});

Detalles para revisar candidatos

Tipos de candidato en contexto

Los candidatos host, reflexivo y relay responden a preguntas distintas de conectividad. El host describe una interfaz local; el reflexivo muestra un mapeo observado mediante STUN; el relay usa TURN. No son una escala de privacidad: quién puede verlos depende de la señalización, del par, del relay y del navegador. mDNS sustituye la dirección local por un nombre para la representación del candidato; no es un identificador estable ni debe convertirse en un inventario.

Diseñar la comparación

Escribe primero una pregunta estrecha: «¿Esta versión expone un candidato host con formato mDNS a mi página propia bajo la misma configuración?». Compara una página control y una candidata que difieran en una sola configuración declarada. Conserva el mismo origen, ruta, navegador, servidores ICE, medios generados y permisos; registra solo categorías redactadas, estado y versión, nunca un identificador persistente.

Campo	Control y candidata	Motivo
Origen y ruta	misma ruta HTTPS propia	mismo contexto de seguridad
ICE y medios	configuración sintética fija	evita cambios de STUN/TURN o dispositivos reales
Observación	categoría de candidato redactada	evita direcciones y credenciales
Resultado	estado y categoría del par	separa recolección de conectividad

Interpretar los resultados

Si aparece un nombre .local, registra únicamente mdns-host; no guardes el nombre completo. La recolección completada no implica que exista un par conectado, y una conexión no revela qué retuvo el servicio o el par. No infieras permisos de cámara desde ICE. Un fallo puede ser DNS, firewall, relay, descripción inválida o una aserción de la aplicación.

Conservar evidencia útil

Un recibo pequeño incluye pregunta, versión del fixture, navegador, ruta, configuración ICE, categorías, estado final, categoría del par si existe y hora. Declara también lo que no prueba: observación del par, retención de señalización, consentimiento real o comportamiento universal. No pongas direcciones, SDP, contraseñas, cookies ni grabaciones en informes comunes; los datos crudos requieren almacenamiento restringido y fecha de eliminación.

Clasificar fallos y limpiar

Asigna cada fallo a su dueño: navegación/origen, servicio de señalización, recolección ICE, alcance del par, relay/firewall o aserción de aplicación. Cada etapa debe tener un tiempo límite y conservar la etapa donde se detuvo la evidencia. En éxito y error cierra el RTCPeerConnection, detén pistas sintéticas y cierra el contexto para no contaminar la siguiente ejecución.

Lista de comprobación

• ¿La página y la señalización son propias o están autorizadas?
• ¿La pregunta separa representación, conectividad, medios y servicio?
• ¿Se declararon navegador, origen, ICE y entradas sintéticas?
• ¿Se excluyeron nombres, direcciones, credenciales, SDP y medios de los registros?
• ¿Cada tiempo límite identifica su etapa y el resultado queda limitado al fixture?
• ¿Se cerraron conexiones y pistas en éxito y error?

Conclusión práctica

Revisa origen, permiso, política ICE, redacción de candidatos, ruta elegida y resultado de la aplicación como una cadena. BotBrowser repite el viaje autorizado en un contexto declarado; no proporciona dispositivos, controla registros de pares ni garantiza cumplimiento universal.

Para continuar, consulta la guía de prevención de fugas WebRTC y la guía de UDP sobre SOCKS5. Una prueba solo describe su versión, ruta y configuración declaradas.

Fuentes

• RFC 8828
• W3C WebRTC
• MDN RTCPeerConnection
• MDN conectividad WebRTC
• BotBrowser prevención de fugas WebRTC

BotBrowser Team