Identidad de red y privacidad en WebRTC

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.

La pregunta no es si WebRTC debe existir. Muchas personas lo necesitan para comunicarse. La pregunta es si la información que muestra WebRTC coincide con la identidad de red elegida para el contexto. Una política clara debe elegir la postura, explicar el intercambio y mantener el resultado comprensible durante toda la sesión.

BotBrowser ofrece tres posturas: profile, real y disabled. profile coordina la información de red de WebRTC con el perfil cargado. real mantiene la identidad de red del equipo anfitrión. disabled elimina la capacidad de WebRTC cuando el flujo no necesita comunicación en tiempo real. 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 coherencia entre 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 registro de candidato puede contener una dirección de una interfaz local, una ruta pública asignada o una dirección de retransmisión. Las estadísticas pueden ofrecer otra vista de las direcciones que participan en la sesión. Son vistas distintas de un mismo límite de privacidad.

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.

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.

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: coordinar la identidad elegida

profile sirve para un contexto con una identidad de red definida. WebRTC sigue disponible y la información de sus direcciones se coordina con esa identidad. Los candidatos y las estadísticas deben corresponder a la misma ruta seleccionada.

Es una opción adecuada cuando un flujo necesita llamadas y también una frontera de privacidad predecible. La postura mantiene la comunicación, pero no sustituye la revisión del proveedor de red, la región ni las reglas de conservación de datos. La calidad de la política depende de que la ruta elegida se mantenga clara.

El valor principal es la coherencia. Las solicitudes, los candidatos y las estadísticas representan una identidad de red común. Un cambio de proxy, perfil o ruta debe tratarse como una nueva decisión de privacidad, sobre todo en contextos de larga duración.

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.

La importancia de la coherencia entre 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 coherencia es una propiedad de la política. Con profile, ambas vistas deben ser compatibles con la ruta del perfil. Con real, ambas deben entenderse como información de la red del anfitrión. Con disabled, no existe una capacidad WebRTC que produzca esas vistas. El objetivo no es fijar una dirección concreta, sino mantener una relación clara entre postura e información expuesta.

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.

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.

Define también la relación esperada entre candidatos y estadísticas con una frase de alto nivel: ambas vistas deben ser compatibles con la misma identidad. 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. Hay que revisar si la postura elegida mantiene las direcciones de candidatos y estadísticas compatibles con la identidad prevista.

¿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 de la comunicación. Compararlas ayuda a saber si el contexto expresa una identidad de red coherente o mezcla rutas. 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.

Cierre

La privacidad de WebRTC es una decisión de identidad de red. profile, real y disabled ofrecen tres posturas comprensibles. La práctica importante es elegir de forma consciente y mantener las direcciones de candidatos y estadísticas compatibles con la misma postura. Revisa prevención de fugas de WebRTC y las funciones de red junto con la documentación de cada flujo.