Startseite
» NETZWERK-ADMIN
»
Wie man Telemetrie und Datenprotokollierung in Jitsi Meet deaktiviert
Wie man Telemetrie und Datenprotokollierung in Jitsi Meet deaktiviert
Wenn Sie Jitsi Meet hosten, können Sie die Analysefunktionen der App deaktivieren und optionale Drittanbieteranfragen blockieren config.js. Dadurch wird die clientseitige Telemetrie reduziert, jedoch werden die Protokolle von Webserver, Docker, Prosody, Jicofo und Videobridge nicht deaktiviert. Diese Datenpfade sind separat und werden vom Serverbetreiber verwaltet. Wenn Sie an einem Meeting über Jitsi Meet meet.jit.sioder einen anderen gehosteten Dienst teilnehmen, können Sie die serverseitigen Einstellungen nicht selbst ändern.
Die aktuelle Jitsi-Konfigurationsreferenz vom 6. Oktober 2026 dokumentiert weiterhin die Steuerelemente. Aufgrund analytics.disabledaktueller disableThirdPartyRequestsProduktänderungen ist kein anderes Vorgehen erforderlich. Die folgenden Schritte gelten für selbstgehostete Web-Bereitstellungen; mobile SDKs, eingebettete Integrationen und Hosting-Panels von Drittanbietern können andere Steuerelemente bereitstellen.
Die Meeting-Lobby ist der für den Benutzer sichtbare Client; ihre Analyseoptionen werden durch die vom Host bereitgestellte Konfiguration gesteuert.
Was bedeuten „Telemetrie“ und „Protokollierung“ in Jitsi Meet?
Der Webclient von Jitsi kann Analyse-Handler laden oder sich mit konfigurierten externen Statistikdiensten verbinden. Die Konfiguration umfasst eine Option zum Deaktivieren der Analysefunktionen sowie Optionen für Dienste wie rtcstats. Eine separate Datenschutzeinstellung disableThirdPartyRequestsverhindert Anfragen von Drittanbietern und bewirkt, dass Avatare lokal generiert werden. Jitsi weist darauf hin, dass externe Statistikintegrationen nicht funktionieren, wenn diese Einstellung aktiviert ist.
WebRTC benötigt weiterhin Signalisierungs- und Mediendaten, damit ein Meeting funktioniert. Das Deaktivieren der Analysefunktionen verbirgt weder die Netzwerkadresse eines Nutzers vor der Meeting-Infrastruktur, noch entfernt es einen Teilnehmer aus dem Raum, verhindert die Aufzeichnung durch den Host oder löscht bereits erfasste Daten. Serverzugriffs- und Diagnoseprotokolle sind ebenfalls unabhängig von Browseranalysen. Die Jitsi-Anleitung zum Log-Analysator beschreibt einen separaten Stack, der Komponentenprotokolle über OpenTelemetry und Loki erfassen kann. Dies verdeutlicht, warum eine einzelne Client-Einstellung nicht alle Protokolle deaktivieren kann.
1. Bestätigen, wer die Bereitstellung kontrolliert.
Suchen Sie für einen von Ihnen verwalteten Jitsi-Server die Webkonfigurationsdatei. Bei gängigen Debian- oder Ubuntu-Installationen befindet sie sich üblicherweise /etc/jitsi/meet/<your-domain>-config.jsunter `/etc/jitsi/`. Bei Docker wird die Host-Datei in der Regel als `/etc/jitsi/` in den Webcontainer eingebunden config.js; verwenden Sie den Pfad und die Volume-Zuordnung in Ihrer Compose-Konfiguration. Erstellen Sie vor der Bearbeitung eine Sicherungskopie und achten Sie darauf, die bestehende Struktur der Datei beizubehalten.
Bei der Nutzung öffentlicher oder von Anbietern gehosteter Meetings besteht möglicherweise eine Client-Option zur Einschränkung der eigenen Daten. Serverprotokollierung, Datenspeicherung und Analyse werden jedoch vom Host festgelegt. Erkundigen Sie sich beim Anbieter nach den aktuellen Datenschutz- und Aufbewahrungsrichtlinien, wenn diese Einstellungen relevant sind.
2. Client-Analysen und externe Anfragen deaktivieren
Fügen Sie diese Einträge im bestehenden configObjekt der obersten Ebene an den entsprechenden Stellen ein. Fügen Sie keine zweite Kopie eines vorhandenen Schlüssels ein und ersetzen Sie nicht die gesamte Konfigurationsdatei.
Die Analyseoptionen sind unter `<analytics>` verschachtelt analytics; die anderen vier Einträge gehören auf die oberste Ebene. Falls Ihre Datei bereits ein analyticsObjekt enthält, bearbeiten Sie dieses, anstatt ein weiteres hinzuzufügen. Entfernen Sie alle benutzerdefinierten Analyseskript-URLs und Dienstendpunkte, die Sie absichtlich konfiguriert haben, oder lassen Sie das Array wie gezeigt leer. Die expliziten `rtcstats`-Werte verdeutlichen den gewünschten Zustand, während ` analytics.disabled<analytics>` der Hauptschalter für Analyse-Handler ist.
Die erweiterte Benutzeranleitung von Jitsi beschreibt dies ebenfalls disableThirdPartyRequests: trueals Konfigurationsoption. Sie kann Funktionen beeinflussen, die von externen Diensten abhängen, wie z. B. extern gehostete Avatare oder Statistikintegrationen. Testen Sie die Meeting-Funktionen, die Ihr Unternehmen nutzt, bevor Sie die Änderung flächendeckend einführen.
Die relevanten Einstellungen gehören in das bestehende config.js-Objekt; die Code-Editor-Ansicht dient nur der Veranschaulichung und ist kein Screenshot einer bestimmten Installation.
3. Wenden Sie die Änderung an und überprüfen Sie die bereitgestellte Konfiguration.
Speichern Sie die Datei und befolgen Sie die übliche Vorgehensweise des Bereitstellungsanbieters zum Neuladen oder Neustarten der Webkomponente. Bei Docker bedeutet dies häufig, den Webdienst neu zu erstellen oder neu zu starten, nachdem Sie überprüft haben, ob die auf dem Host eingebundene Konfigurationsdatei der bearbeiteten Datei entspricht. Paketbasierte Bereitstellungen können die Datei direkt bereitstellen. Die Jitsi-Installation variiert je nach Paket, Version und lokalen Änderungen. Starten Sie daher nicht routinemäßig jede Komponente neu.
Öffnen Sie die Besprechungsseite in einem privaten Browserfenster oder leeren Sie den Website-Cache und überprüfen Sie anschließend die an den Browser übermittelte Konfiguration. Laden Sie diese in den Entwicklertools https://your-domain/config.jsund vergewissern Sie sich, dass sie die von Ihnen festgelegten Werte enthält. Falls die alten Werte angezeigt werden, überprüfen Sie den domänenspezifischen Dateinamen, die Container-Volume-Einbindung, den Reverse-Proxy-Cache und ob der Browser den gewünschten Server erreicht.
4. Serverseitige Protokollierung separat prüfen
Erstellen Sie nun eine Bestandsaufnahme der noch vorhandenen Protokolldateien. Typische Speicherorte sind Zugriffs- und Fehlerprotokolle des Reverse-Proxys, die Ausgabe von Docker-Containern sowie Protokolle von Prosody, Jicofo und Jitsi Videobridge. Falls Sie den optionalen Log-Analyser-Stack installiert haben, überprüfen Sie auch dessen OpenTelemetry Collector- und Loki-Konfiguration. Die Dokumentation des Jitsi-Log-Analysers beschreibt diesen Collector- und Speicherpfad separat von der Client-Analyse.
Wählen Sie eine operative Richtlinie, anstatt anzunehmen, dass alle Protokolle gefahrlos deaktiviert werden können. Sie könnten die Ausführlichkeit reduzieren, den Zugriff auf Protokolle einschränken, die Aufbewahrungsdauer verkürzen oder eine optionale Protokollversandpipeline deaktivieren. Bewahren Sie ausreichend Diagnoseinformationen auf, um Ausfälle und Missbrauch zu untersuchen, und vermeiden Sie die Erfassung von Raumnamen, E-Mail-Adressen, IP-Adressen oder vollständigen Signalisierungsdaten, sofern kein definierter Bedarf besteht. Wenden Sie die Aufbewahrung auf der tatsächlichen Speicherebene an – z. B. beim Proxy, der Container-Laufzeitumgebung oder dem Protokoll-Backend –, da der Client config.jsdiese Aufbewahrungsfristen nicht festlegt.
Die Protokolle von Containern und Webservern stellen auch nach der Deaktivierung der Browseranalyse ein separates administratives Problem dar.
5. Überprüfen Sie das Verhalten, ohne ein unauffälliges Netzwerkpanel als Beweis zu werten.
Treten Sie einem Testraum in einer neuen Browsersitzung bei und prüfen Sie, ob Audio, Video, Chat und Bildschirmfreigabe weiterhin funktionieren. Überprüfen Sie im Netzwerk-Panel des Browsers die Anfragen an externe Analyse- oder Statistikdienste, während das Meeting startet und läuft. Einige Anfragen sind für das Meeting selbst notwendig. Das Blockieren aller unbekannten Hostnamen kann die Signalisierung, die Medieneinstellungen, Avatare oder andere Integrationen beeinträchtigen. Vergleichen Sie die Zieladressen mit Ihrer eigenen Konfiguration und Ihrem Bereitstellungsdesign. Das Fehlen einer sichtbaren Anfrage in einem Test beweist nicht, dass keine Serverprotokolle geschrieben werden.
Im Netzwerk-Panel können Sie nach konfigurierten externen Analyseanfragen suchen, während die für den Anruf erforderlichen Verbindungen erhalten bleiben.
Sollte der unerwünschte Datenverkehr weiterhin bestehen, prüfen Sie die Quelle: ein benutzerdefiniertes Analyse-Skript, ein per Reverse-Proxy eingeschleustes Tag, eine übergeordnete Seite eines iFrames, eine Browsererweiterung oder die Instrumentierung Ihres Hosting-Anbieters. Falls das Problem Serverprotokolle und nicht Client-Analysen betrifft, überprüfen Sie stattdessen die entsprechende Dienst- und Speicherkonfiguration.
Was diese Änderung garantieren kann und was nicht.
Diese Einstellungen sind nützlich, um die konfigurierten Client-Analysen von Jitsi Meet und optionale Drittanbieteranfragen auf einem von Ihnen kontrollierten Server zu unterbinden. Sie bieten keine Anonymität, deaktivieren nicht jede Netzwerkverbindung und löschen keine historischen Daten automatisch. Auch Telemetriedaten, die durch eine modifizierte Version, eine eingebettete Website oder den Hosting-Anbieter hinzugefügt werden, werden dadurch nicht gesteuert. Überprüfen Sie die Konfiguration für die von Ihnen eingesetzte Jitsi-Version und überprüfen Sie sie nach Aktualisierungen erneut, da sich Konfigurationsnamen und Integrationen ändern können.