Jak wyłączyć telemetrię i rejestrowanie danych w Jitsi Meet

Jeśli hostujesz Jitsi Meet, możesz wyłączyć obsługę analityki w aplikacji i zablokować opcjonalne żądania stron trzecich w config.js. Zmniejsza to dane telemetryczne po stronie klienta, ale nie wyłącza logów serwera WWW, Dockera, Prosody, Jicofo ani Videobridge. Są to oddzielne ścieżki danych, zarządzane przez operatora serwera. Jeśli dołączasz do spotkania w meet.jit.siinnej usłudze hostowanej, nie możesz samodzielnie zmienić jej ustawień po stronie serwera.

Na dzień 6 października 2026 r. aktualne odniesienia do konfiguracji Jitsi nadal dokumentują kontrolki analytics.disabledi disableThirdPartyRequests. Żadna z ostatnich zmian w produkcie nie wymagała innej procedury. Poniższe kroki dotyczą wdrożenia w witrynie hostowanej samodzielnie; mobilne zestawy SDK, wbudowane integracje i panele hostingowe innych firm mogą udostępniać inne kontrolki.

Co oznaczają „telemetria” i „rejestrowanie” w Jitsi Meet

Klient internetowy Jitsi może ładować moduły obsługi statystyk lub łączyć się ze skonfigurowanymi zewnętrznymi usługami statystycznymi. Konfiguracja obejmuje flagę wyłączania dla całej analityki oraz opcje dla usług takich jak rtcstats. Osobne ustawienie prywatności, disableThirdPartyRequests, blokuje żądania stron trzecich i powoduje lokalne generowanie awatarów; Jitsi zaznacza, że ​​integracja ze statystykami zewnętrznymi nie będzie działać po włączeniu tej opcji.

WebRTC nadal wymaga wymiany sygnałów i ruchu multimedialnego, aby spotkanie działało. Wyłączenie analityki nie ukrywa adresu sieciowego użytkownika w infrastrukturze spotkania, nie usuwa uczestnika z pokoju, nie uniemożliwia hostowi nagrywania ani nie usuwa zebranych danych. Dzienniki dostępu do serwera i dzienniki diagnostyczne są również niezależne od analityki przeglądarki. Przewodnik po analizatorze logów Jitsi opisuje oddzielny stos, który może zbierać logi komponentów za pośrednictwem OpenTelemetry i Loki, co ilustruje, dlaczego jedno ustawienie klienta nie może wyłączyć wszystkich logów.

1. Potwierdź, kto kontroluje wdrożenie

W przypadku serwera Jitsi, którym administrujesz, zlokalizuj plik konfiguracji webowej. W typowych instalacjach pakietów Debian lub Ubuntu jest to zazwyczaj /etc/jitsi/meet/<your-domain>-config.js. W przypadku Dockera plik hosta jest zazwyczaj montowany w kontenerze webowym jako jego config.js; użyj mapowania ścieżki i woluminu we własnej konfiguracji Compose. Przed edycją utwórz kopię zapasową i zachowaj istniejącą strukturę pliku.

Jeśli korzystasz wyłącznie ze spotkań publicznych lub organizowanych przez dostawcę, klient może mieć możliwość ograniczenia własnych danych, ale to organizator decyduje o logowaniu, przechowywaniu i analizie danych na serwerze. Zapytaj dostawcę o aktualne informacje dotyczące prywatności i przechowywania danych, jeśli te ustawienia mają znaczenie.

2. Wyłącz analizę klienta i żądania zewnętrzne

W istniejącym configobiekcie najwyższego poziomu scal te wpisy w odpowiednich miejscach. Nie wklejaj drugiej kopii istniejącego klucza ani nie zastępuj całego pliku konfiguracyjnego:

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

Opcje analityczne są zagnieżdżone w analytics; pozostałe cztery wpisy znajdują się na najwyższym poziomie. Jeśli plik zawiera już analyticsobiekt, edytuj go zamiast dodawać kolejny. Usuń wszelkie niestandardowe adresy URL skryptów analitycznych i punkty końcowe usług, które celowo skonfigurowałeś, lub pozostaw tablicę pustą, jak pokazano. Jawne wartości rtcstats jasno określają zamierzony stan, a klauzula while analytics.disabledjest głównym przełącznikiem dla procedur obsługi analiz.

Zaawansowany podręcznik użytkownika Jitsi zawiera również dokumenty disableThirdPartyRequests: truedotyczące opcji konfiguracji. Może to wpłynąć na funkcje zależne od usług zewnętrznych, w tym na awatary hostowane zewnętrznie lub integrację statystyk. Przed szerokim wdrożeniem zmiany przetestuj funkcje spotkań używane w Twojej organizacji.

3. Zastosuj zmianę i sprawdź dostarczoną konfigurację

Zapisz plik i postępuj zgodnie ze standardową procedurą wdrożenia, aby przeładować lub ponownie uruchomić komponent sieciowy. W przypadku Dockera często oznacza to ponowne utworzenie lub ponowne uruchomienie usługi sieciowej po potwierdzeniu, że konfiguracja zamontowana na hoście to edytowany plik; wdrożenia oparte na pakietach mogą udostępniać plik bezpośrednio. Instalacja Jitsi różni się w zależności od pakietu, wersji i lokalnych modyfikacji, dlatego nie restartuj każdego komponentu z przyzwyczajenia.

Otwórz stronę spotkania w prywatnym oknie przeglądarki lub wyczyść pamięć podręczną witryny, a następnie sprawdź konfigurację faktycznie dostarczoną do przeglądarki. W narzędziach programistycznych załaduj ją https://your-domain/config.jsi upewnij się, że zawiera ustawione przez Ciebie wartości. Jeśli pojawią się stare wartości, sprawdź nazwę pliku specyficzną dla domeny, montowanie woluminu kontenera, pamięć podręczną odwrotnego proxy oraz czy przeglądarka łączy się z docelowym serwerem.

4. Przejrzyj osobno rejestrowanie po stronie serwera

Teraz zinwentaryzuj logi, które nadal istnieją. Typowe lokalizacje to logi dostępu i błędów odwrotnego proxy, dane wyjściowe kontenera Dockera oraz logi z Prosody, Jicofo i Jitsi Videobridge. Jeśli zainstalowano opcjonalny stos analizatora logów, należy również sprawdzić jego konfigurację OpenTelemetry Collector i Loki. Dokumentacja analizatora logów Jitsi opisuje tę ścieżkę kolektora i przechowywania danych oddzielnie od analityki klienta.

Wybierz politykę operacyjną zamiast zakładać, że wszystkie logi można bezpiecznie wyłączyć. Możesz zmniejszyć szczegółowość, ograniczyć dostęp do logów, skrócić czas przechowywania lub wyłączyć opcjonalny proces przesyłania logów. Zachowaj wystarczającą ilość informacji diagnostycznych, aby zbadać awarie i nadużycia, i unikaj gromadzenia nazw pokoi, adresów e-mail, adresów IP lub pełnych danych sygnalizacyjnych, chyba że zajdzie taka potrzeba. Zastosuj przechowywanie na poziomie rzeczywistej warstwy pamięci masowej — takiej jak serwer proxy, środowisko wykonawcze kontenera lub zaplecze logów — ponieważ klient config.jsnie ustawia tych okresów przechowywania.

5. Zweryfikuj zachowanie, nie traktując cichego panelu sieciowego jako dowodu

Dołącz do pokoju testowego z nowej sesji przeglądarki i sprawdź, czy dźwięk, wideo, czat i udostępnianie ekranu nadal działają. W panelu Sieć przeglądarki przejrzyj żądania do zewnętrznych hostów analitycznych lub statystycznych podczas rozpoczynania i trwania spotkania. Niektóre żądania są niezbędne do samego spotkania, a zablokowanie każdej nieznanej nazwy hosta może zakłócić sygnalizację, konfigurację multimediów, awatary lub inne integracje. Porównaj miejsca docelowe z własną konfiguracją i projektem wdrożenia; brak widocznego żądania w jednym teście nie dowodzi, że nie są zapisywane żadne logi serwera.

Jeśli niepożądany ruch nadal występuje, sprawdź inne źródło: niestandardowy skrypt analityczny, wstrzyknięty tag z odwrotnym proxy, stronę nadrzędną iframe, rozszerzenie przeglądarki lub własne narzędzia dostawcy hostingu. Jeśli problem dotyczy logów serwera, a nie analityki klienta, sprawdź odpowiednią konfigurację usługi i pamięci masowej.

Co ta zmiana może, a czego nie może zagwarantować

Te ustawienia są przydatne do zatrzymania skonfigurowanych analiz klienta Jitsi Meet i opcjonalnych żądań stron trzecich na kontrolowanym przez Ciebie serwerze. Nie zapewniają one anonimowości, nie wyłączają każdego połączenia sieciowego ani nie usuwają automatycznie danych historycznych. Nie kontrolują również danych telemetrycznych dodawanych przez zmodyfikowaną kompilację, witrynę osadzoną ani dostawcę hostingu. Sprawdź konfigurację pod kątem konkretnej wersji Jitsi, którą wdrażasz, i sprawdź ją ponownie po aktualizacjach, ponieważ nazwy konfiguracji i integracje mogą ulec zmianie.

Podstawowe odniesienia można znaleźć w podręczniku konfiguracji Jitsi Meet , podręczniku użytkownika zaawansowanego , przykładzie config.js oraz podręczniku analizatora dzienników hostowanego samodzielnie w Jitsi .