Cómo desactivar la telemetría y el registro de datos en Jitsi Meet

Si alojas Jitsi Meet, puedes desactivar los controladores de análisis de la aplicación y bloquear sus solicitudes opcionales de terceros en config.js. Esto reduce la telemetría del lado del cliente, pero no desactiva los registros del servidor web, Docker, Prosody, Jicofo o Videobridge. Estas son rutas de datos independientes, administradas por el operador del servidor. Si te unes a una reunión en meet.jit.siu otro servicio alojado, no puedes cambiar la configuración del servidor por tu cuenta.

A fecha de 6 de octubre de 2026, la documentación de referencia de configuración de Jitsi sigue mostrando los analytics.disabledcontroles disableThirdPartyRequests. Ningún cambio reciente en el producto requiere un procedimiento diferente. Los pasos que se describen a continuación se aplican a una implementación web autohospedada; los SDK móviles, las integraciones integradas y los paneles de alojamiento de terceros pueden mostrar controles diferentes.

Qué significan “telemetría” y “registro” en Jitsi Meet

El cliente web de Jitsi puede cargar controladores de análisis o conectarse a servicios de estadísticas externos configurados. La configuración incluye una opción para deshabilitar el análisis en general y opciones para servicios como rtcstats. Una configuración de privacidad independiente disableThirdPartyRequestsbloquea las solicitudes de terceros y hace que los avatares se generen localmente; Jitsi indica que las integraciones de estadísticas externas no funcionarán cuando esta opción esté habilitada.

WebRTC aún necesita intercambiar tráfico de señalización y multimedia para que una reunión funcione. Deshabilitar el análisis no oculta la dirección de red de un usuario a la infraestructura de la reunión, no elimina a un participante de la sala, no impide que el anfitrión grabe ni borra los datos ya recopilados. Los registros de acceso al servidor y los registros de diagnóstico también son independientes del análisis del navegador. La guía del analizador de registros de Jitsi describe una pila independiente que puede recopilar registros de componentes a través de OpenTelemetry y Loki, lo que ilustra por qué una sola configuración del cliente no puede deshabilitar todos los registros.

1. Confirma quién controla el despliegue.

Para un servidor Jitsi que administre, localice el archivo de configuración web. En instalaciones comunes de paquetes Debian o Ubuntu, suele ser /etc/jitsi/meet/<your-domain>-config.js. Con Docker, el archivo host se monta normalmente en el contenedor web como su config.js; utilice la ruta y la asignación de volumen en su configuración de Compose. Realice una copia de seguridad antes de editar y conserve la estructura existente del archivo.

Si solo utiliza reuniones públicas o gestionadas por un proveedor, es posible que el cliente tenga la opción de limitar su información, pero el anfitrión decide sobre el registro, la retención y el análisis del servidor. Consulte con el proveedor sus políticas de privacidad y retención vigentes cuando estas configuraciones sean importantes.

2. Deshabilitar el análisis de clientes y las solicitudes externas.

En el objeto de nivel superior existente config, combine estas entradas en los lugares correspondientes. No pegue una segunda copia de una clave existente ni reemplace todo el archivo de configuración.

disableThirdPartyRequests: true,
enableDisplayNameInStats: false,
enableEmailInStats: false,
gatherStats: false,
analytics: {
  disabled: true,
  rtcstatsEnabled: false,
  rtcstatsStoreLogs: false,
  scriptURLs: []
},

Las opciones de análisis están anidadas en analytics; las otras cuatro entradas pertenecen al nivel superior. Si su archivo ya contiene un analyticsobjeto, edite ese objeto en lugar de agregar otro. Elimine cualquier URL de script de análisis personalizado y puntos finales de servicio que haya configurado intencionalmente, o deje la matriz vacía como se muestra. Los valores explícitos de rtcstats dejan claro el estado previsto, mientras que analytics.disabledes el interruptor principal para los manejadores de análisis.

La guía de usuario avanzada de Jitsi también lo documenta disableThirdPartyRequests: truecomo una opción de configuración. Puede afectar a funciones que dependen de servicios externos, como avatares alojados externamente o integraciones de estadísticas. Pruebe las funciones de reunión que utiliza su organización antes de implementar el cambio de forma generalizada.

3. Aplique el cambio y verifique la configuración resultante.

Guarda el archivo y sigue el procedimiento habitual de la implementación para recargar o reiniciar el componente web. En Docker, esto suele implicar recrear o reiniciar el servicio web tras confirmar que la configuración montada en el host es el archivo que editaste; las implementaciones basadas en paquetes pueden servir el archivo directamente. La instalación de Jitsi varía según el paquete, la versión y las modificaciones locales, así que no reinicies todos los componentes por costumbre.

Abra la página de la reunión en una ventana de incógnito o borre la caché del sitio y, a continuación, revise la configuración que se muestra en el navegador. En las herramientas para desarrolladores, cargue la configuración https://your-domain/config.jsy confirme que contiene los valores que estableció. Si aparecen los valores antiguos, compruebe el nombre de archivo específico del dominio, el montaje del volumen del contenedor, la caché del proxy inverso y si el navegador se conecta al servidor previsto.

4. Revise los registros del servidor por separado.

Ahora, haga un inventario de los registros que aún existen. Las ubicaciones típicas incluyen los registros de acceso y error del proxy inverso, la salida del contenedor de Docker y los registros de Prosody, Jicofo y Jitsi Videobridge. Si instaló el paquete opcional de análisis de registros, inspeccione también su OpenTelemetry Collector y la configuración de Loki. La documentación del analizador de registros de Jitsi describe esta ruta de recopilación y almacenamiento por separado del análisis del cliente.

En lugar de asumir que todos los registros se pueden deshabilitar de forma segura, elija una política operativa. Puede reducir la verbosidad, restringir el acceso a los registros, acortar el período de retención o desactivar una canalización de envío de registros opcional. Conserve suficiente información de diagnóstico para investigar interrupciones y abusos, y evite recopilar nombres de salas, direcciones de correo electrónico, direcciones IP o datos de señalización completos, a menos que exista una necesidad definida. Aplique la retención en la capa de almacenamiento real (como el proxy, el entorno de ejecución del contenedor o el backend de registros), ya que el cliente config.jsno establece esos períodos de retención.

5. Verifique el comportamiento sin considerar un panel de red silencioso como prueba.

Únase a una sala de prueba desde una sesión nueva del navegador y confirme que el audio, el video, el chat y la función de compartir pantalla siguen funcionando. En el panel de Red del navegador, revise las solicitudes a los servidores de análisis o estadísticas de terceros mientras la reunión se inicia y se desarrolla. Algunas solicitudes son necesarias para la reunión en sí, y bloquear todos los nombres de host desconocidos puede interrumpir la señalización, la configuración multimedia, los avatares u otras integraciones. Compare los destinos con su propia configuración y diseño de implementación; la ausencia de una solicitud visible en una prueba no demuestra que no se estén escribiendo registros del servidor.

Si el tráfico no deseado persiste, busque otra fuente: un script de análisis personalizado, una etiqueta inyectada por un proxy inverso, una página principal con un iframe, una extensión del navegador o la propia instrumentación del proveedor de alojamiento. Si el problema reside en los registros del servidor y no en el análisis del cliente, revise la configuración del servicio y del almacenamiento correspondiente.

Lo que este cambio puede y no puede garantizar

Estas configuraciones son útiles para detener el análisis de clientes configurado en Jitsi Meet y las solicitudes opcionales de terceros en un servidor que usted controla. No proporcionan anonimato, no deshabilitan todas las conexiones de red ni eliminan automáticamente los datos históricos. Tampoco controlan la telemetría agregada por una compilación modificada, un sitio web integrado o el proveedor de alojamiento. Revise la configuración para la versión exacta de Jitsi que implementa y vuelva a comprobarla después de las actualizaciones, ya que los nombres de configuración y las integraciones pueden cambiar.

Para referencias principales, consulte la guía de configuración de Jitsi Meet , la guía de usuario avanzada , el ejemplo de config.js de origen y la guía del analizador de registros autohospedado de Jitsi .