Identidad de red y privacidad en WebRTC

BotBrowser permite ajustes controlados de identidad de red WebRTC; no garantiza conexiones anónimas ni privacidad fuera del contexto configurado.

Resumen

WebRTC reúne direcciones que el proxy de páginas nunca ve. Elige una postura por contexto (profile, real o disabled) y regístrala. Revisa los candidatos ICE y getStats() de la conexión WebRTC, y consulta la dirección pública por separado con un servicio externo autorizado; son observaciones distintas.

Contenido

• Por qué WebRTC forma parte de la política de privacidad
• Qué puede revelar el navegador
• Las tres posturas
• Cómo interpretar candidatos y estadísticas
• Un modelo sencillo de gobierno
• Preguntas habituales
• Conclusión práctica

Por qué WebRTC forma parte de la política de privacidad

WebRTC permite llamadas, reuniones, soporte en directo y medios entre pares desde el navegador. También crea una superficie de identidad de red separada. Una página puede recibir información sobre las direcciones consideradas para una conexión y ver datos estadísticos durante la sesión. Esa información sigue siendo sensible aunque las solicitudes normales de la página usen un proxy. BotBrowser puede coordinar la información de red de WebRTC con un perfil configurado en un contexto controlado; no puede hacer anónimas las conexiones entre pares ni garantizar la privacidad fuera de ese contexto.

La pregunta no es si WebRTC debe existir. Muchas personas lo necesitan para comunicarse. La pregunta es qué información de direcciones exponen las API de WebRTC bajo la política del contexto. Una política clara debe elegir la postura, explicar el intercambio y revisar las observaciones cuando cambie la ruta.

BotBrowser ofrece tres posturas: profile, real y disabled. Representan el uso de la política del perfil configurado, la red del anfitrión y la indisponibilidad de WebRTC. En profile, los controles configurados de SDP e ICE buscan alinear la información de WebRTC con la identidad declarada del perfil; comprueba las condiciones del proxy y UDP aplicables, sin tratar esa intención como una medición de la salida pública. La elección depende del propósito del contexto y del límite de privacidad aceptado por la organización.

La política prioriza la privacidad, la minimización de datos y la interpretación cuidadosa de candidatos y estadísticas. Para contexto relacionado, consulta prevención de fugas de WebRTC y la página de funciones de red.

Qué puede revelar el navegador

Al preparar una sesión WebRTC, el navegador reúne rutas posibles para los medios. Un candidato lleva un tipo candidate: host para una interfaz local, srflx para una asignación reflexiva de servidor y relay para una dirección TURN, además de la dirección en sí (RFC 8445). Durante la sesión, RTCPeerConnection.getStats() informa los registros local-candidate, remote-candidate y candidate-pair; el par seleccionado identifica la ruta que transporta los medios en ese momento (estadísticas WebRTC). Estos registros ayudan a comparar la ruta WebRTC observada con la política del contexto, pero no miden de forma independiente la salida pública de las solicitudes de página.

Una dirección puede relacionar una sesión con una red, una zona, una organización o un hogar. Una dirección privada puede mostrar la forma de la red local. Una dirección pública puede identificar la salida del equipo. Una dirección de retransmisión puede señalar un servicio o una región. La combinación de datos que parecen pequeños por separado puede crear un vínculo persistente. Para ver cómo los candidatos de host mDNS cambian lo que una página puede saber de la red local, consulta Candidatos mDNS de WebRTC y privacidad de la red local, que trata los candidatos mDNS y los objetivos de privacidad de RFC 8828.

Las solicitudes normales y la comunicación WebRTC están relacionadas, pero no usan necesariamente la misma ruta. Un proxy puede dar una identidad pública a las solicitudes de la página mientras WebRTC sigue otra ruta. Por eso revisar solo el tráfico de la página deja una parte de la política sin definir. Para ver cómo mantener alineados el enrutamiento por proxy, el DNS y WebRTC en un flujo de trabajo, consulta Coherencia de proxy, DNS y WebRTC en una identidad de navegador, que trata la coherencia entre proxy, DNS, zona horaria y WebRTC.

La disponibilidad también importa. Bloquear toda comunicación reduce una superficie, pero puede impedir reuniones, soporte y colaboración. Conviene empezar por el propósito del contexto, elegir la postura y explicar la exposición que queda.

Las tres posturas

Profile: revisar la política de identidad

profile sirve para un contexto con una política de red declarada que puede compararse con los registros de candidatos y estadísticas. Si el proxy SOCKS5 admite UDP ASSOCIATE y BotBrowser establece la asociación, STUN puede usar ese proxy y los candidatos ICE pueden reflejar su dirección. El par seleccionado describe la ruta multimedia de WebRTC; no mide por separado la salida pública de las solicitudes de página. La organización debe documentar la ruta asignada a cada contexto y contrastar ambas observaciones con ella.

Puede encajar en un flujo que necesita llamadas y una frontera de privacidad documentada. Mantiene WebRTC disponible y aplica la política configurada; el resultado sigue dependiendo del proxy y la red. No sustituye la revisión del proveedor, la región ni las reglas de conservación. Para ver cómo el tráfico UDP de QUIC y WebRTC puede seguir el mismo plan de proxy, consulta UDP sobre SOCKS5: rutas privadas para QUIC y WebRTC, que trata la política de proxy TCP y UDP por contexto.

Si cambia el proxy, el perfil o la ruta, registra una nueva decisión. Revisa los candidatos y las estadísticas frente a la política del contexto, sin inferir que las solicitudes de página siguieron la misma ruta.

Real: usar la red del anfitrión

real elige de forma explícita la identidad de red proporcionada por el equipo anfitrión. Puede ser apropiado para desarrollo local, verificación interna o una comunicación que debe utilizar esa red. No es una protección de privacidad por sí misma. La red del anfitrión puede ser visible para el otro extremo o para un servicio que reciba información de WebRTC.

Nombrar esta postura es mejor que dejar la decisión implícita. El equipo puede tener varias interfaces, una ruta pública cambiante o reglas corporativas propias. La organización debe saber quién es responsable de esa red y si sus direcciones son adecuadas para el contexto.

También puede utilizarse en una sesión de diagnóstico autorizada. Esa sesión necesita una persona responsable, un alcance limitado y un registro de que la identidad del anfitrión se usó de forma intencionada.

Disabled: retirar una capacidad innecesaria

disabled es apropiado cuando el flujo no usa comunicación en tiempo real. Reduce la información que una página puede recibir, pero elimina llamadas, uso compartido de medios y otras funciones que dependen de WebRTC.

Debe ser una decisión explícita y no el resultado accidental de un entorno roto. La persona usuaria debe entender por qué una reunión no puede comenzar. Si el flujo vuelve a necesitar comunicación, conviene cambiar a un contexto documentado con profile o real.

Hay un coste de usabilidad. Algunas páginas ofrecen una experiencia diferente cuando falta la comunicación en tiempo real. Es un intercambio válido cuando la privacidad pesa más, siempre que el equipo pueda distinguir la política de una avería.

Cómo interpretar candidatos y estadísticas

Dos vistas pueden parecer válidas y contar historias distintas. Los candidatos pueden mostrar una ruta y las estadísticas otra. Las solicitudes pueden usar un proxy mientras el canal de comunicación muestra la red del anfitrión. Una configuración de perfil puede indicar una región y la dirección observada pertenecer a otra.

Por eso la comparación es una revisión de política, no una promesa de que dos vistas de la API coincidan. Con profile, inspecciona los candidatos y el par seleccionado y compara lo que muestran con la ruta asignada al contexto. Con real, interpreta las direcciones expuestas como información de la red del anfitrión. Con disabled, comprueba que la capacidad WebRTC no esté disponible. El resultado aporta evidencia para una revisión, no demuestra una dirección o ruta garantizada.

Una migración de red, un cambio de proxy o un cambio de perfil puede modificar la ruta durante una sesión. Hay que revisar la decisión del contexto cuando ocurra. Varios contextos en un mismo equipo pueden tener políticas distintas si cada uno tiene propósito y responsable claros.

Postura	Tipos de candidato ICE	Vista de getStats()	Úsala cuando
profile	Siguen el perfil cargado	Revisar candidatos y pares seleccionados	Las llamadas deben funcionar con una identidad declarada
real	Direcciones de interfaz local (host, srflx)	Revisar candidatos y pares del anfitrión	La ruta del anfitrión es la identidad buscada
disabled	No hay candidatos WebRTC	Transporte WebRTC no disponible	El flujo nunca necesita medios en tiempo real

Un modelo sencillo de gobierno

Asigna a cada flujo un propósito: comunicación, desarrollo local, verificación interna o navegación sensible. Registra si necesita WebRTC. Elige profile, real o disabled y anota quién administra la ruta elegida.

Decide qué registros de candidatos y estadísticas necesita revisar el equipo. Compara esas observaciones con la política del contexto sin asumir que coincidirán ni que identificarán la salida pública. Conserva solo los detalles de dirección necesarios para una tarea aprobada. El acceso a los registros debe seguir las mismas reglas de minimización que las cookies, las cuentas y el estado de sesión.

Durante el mantenimiento, los cambios de proxy, perfil, interfaces o requisitos de comunicación son cambios de política. La persona que inicia una llamada debe saber si usa la ruta del perfil, la del anfitrión o un contexto sin WebRTC. Una explicación clara evita que alguien busque una alternativa no gestionada.

Preguntas habituales

¿Un proxy protege WebRTC automáticamente?

No. Puede controlar las solicitudes normales mientras WebRTC usa una ruta separada. Revisa por separado los candidatos ICE y las estadísticas del par seleccionado, e interprétalos según la política del contexto; ninguna de esas vistas mide por sí sola la salida pública.

¿Todos los contextos deben usar profile?

No. profile encaja cuando WebRTC es necesario y la identidad de red está definida. real puede corresponder a un flujo propiedad del anfitrión, y disabled a un flujo sin comunicación. La postura debe seguir al propósito.

¿disabled es siempre la opción más privada?

Reduce una superficie, pero también elimina una capacidad legítima. Si se necesita una llamada, puede ser más responsable usar un contexto profile documentado que empujar a la persona a una solución no gestionada.

¿Por qué comparar candidatos y estadísticas?

Son vistas distintas del transporte WebRTC. Compáralas con la política del contexto para identificar diferencias que requieran investigación, sin tratarlas como una medición independiente de la salida de las solicitudes de página. La revisión debe minimizar los datos y permanecer dentro del proceso autorizado.

¿Qué ocurre si cambia la red?

La interfaz o la ruta pueden cambiar. El cambio debe activar una revisión de la política del contexto para no unir observaciones que pertenecen a redes distintas.

¿Qué conviene conservar para la revisión de privacidad?

Conserva la postura elegida, el propósito del contexto, quién administra la ruta y la decisión de revisión. Los detalles de dirección solo deben guardarse cuando exista una necesidad operativa aprobada, con el mismo control de acceso que el estado de sesión.

Fuentes

• RFC 8445: Interactive Connectivity Establishment
• RFC 8828: requisitos de tratamiento de direcciones IP en WebRTC
• Estadísticas WebRTC del W3C
• W3C WebRTC 1.0

Conclusión práctica

La privacidad de WebRTC es una decisión de identidad de red. profile, real y disabled ofrecen tres posturas comprensibles. Elige de forma consciente, inspecciona los registros de candidatos y estadísticas e interprétalos según la política del contexto, sin asumir que coinciden ni que revelan la salida pública. Revisa prevención de fugas de WebRTC y las funciones de red junto con la documentación de cada flujo.

Registra una postura por contexto. Revisa los candidatos ICE y los registros de getStats() en la página de prueba autorizada; después, consulta la dirección pública con un servicio externo autorizado. Trata un contexto real como una decisión deliberada sobre la red del anfitrión, no como un descuido, y un contexto disabled como un flujo donde las API de WebRTC no están disponibles. Repite ambas comprobaciones tras cambiar de red, rotar el proxy o actualizar el navegador de versión mayor.