Jitsi - Fragen & Antworten (Update)

(Aktualisiert: 26.7.2020)

Was ist Jitsi Meet?

Jitsi Meet ist eine Videokonferenzlösung, die aus freien quelloffenen (Open Source) Komponenten besteht und mit einem Browser oder mobilen Apps benutzt werden kann. Neben Audio- und Video kann auch der Bildschirm oder einzelne Anwendungsfenster geteilt, mit allen Teilnehmenden gechattet oder mit Etherpad gemeinsam an Dokumenten gearbeitet werden. Bei Bedarf kann Jitsi auf einem eigenen Server betrieben werden.

Wie nutze ich Jitsi Meet?

Hier empfehle ich die hervorragende Anleitung von Mike Kuketz, die auch andere Fragen zu Jitsi Meet beantwortet.

Grundsätzlich reicht ein moderner Browser, empfohlen wird Ungoogled Chromium, Chromium, Chrome oder Firefox. Letzterer hat noch ein paar Probleme, allerdings gehen die Arbeiten voran und mit Firefox 76 soll es bereits besser sein, das dazugehörige Ticket bei Jitsi-Meet ist schon geschlossen.

Weitere Möglichkeiten Jitsi zu nutzen

Es gibt wohl auch eine Electron App, wobei ich persönlich Bedenken gegenüber Electron Apps habe:

  • Electron ist ein Framework für Web-Apps auf dem Desktop, letztlich bündelt es eine Web-App, NodeJS und die Chromium Rendering Engine sowie die von beiden benutze JavaScript-Engine V8.
  • Recht ressourcenhungrig, Jitsi selbst braucht bereits einige Ressourcen, da muss es m.E. nicht noch ein zusätzlicher Browser sein, der neben dem normalen mitläuft.
  • Jede Menge Bloat pro App, bei je nach Anwendung geringem Funktionsumfang.
  • Browser als Unterbau macht es Web-Entwicklern zwar einfacher, die Anwenderin hat damit aber auf ihrem Rechner zu leben, die Hardware-Industrie freut sich (mehr RAM, mehr CPU, mehr Speicherplatz - und letztlich höherer Stromverbrauch).
  • Viele andere Web-Apps, darunter populäre wie VS Code, Slack, Skype, WhatsApp, nutzen ebenfalls Electron, somit laufen im schlimmsten Fall einige Browser-Instanzen parallel.
  • Ich habe bislang keine Gründe gefunden, wieso ich neben einem Browser weitere brauche, in denen Web-Apps laufen.

Was sind die Vorteile gegenüber Zoom und Co.?

Häufig geht es um die Fragen

  • ob eine Software offen und frei oder proprietär ist,
  • wo der Anspruch und die Grenze von Kontrolle und Freiheit verläuft,
  • ob es möglich ist, jemanden zu finden, der eine Anwendung betreiben und Support leisten kann und letztlich auch,
  • wer bei Missbrauch oder Schäden haftet.

Bei Zoom und etlichen anderen Diensten (Microsoft Teams, Skype, Google Hangout, Slack, Facebook Messenger usw.) handelt es sich

  • um amerikanische Unternehmen, die an amerikanische Gesetze gebunden sind.
  • Die Produkte sind proprietär,
  • man kann den Quellcode nicht überprüfen und
  • man muss den Anbietern vertrauen.
  • Die Datenhaltung erfolgt in deren Infrastruktur/Cloud.
  • Der Anbieter übt die volle Kontrolle über die Nutzung und die erhobenen Daten aus,
  • Alle Anbieter verwenden diverses Tracking, also die Überwachung der installierten und verwendeten Software bis auf die individuelle Benutzerebene, was sich nur begrenzt deaktivieren lässt.
  • Die Geschäftsbedingungen und Datenschutzerklärungen sind größtenteils gruselig,
  • Anbieter geben Daten an Dritte weiter, z.B. Facebook und Tracking-Firmen.
  • Konten können bei vermutetem Missbrauch schnell gesperrt werden. Da meist mehr an einem Konto hängt, z.B. bei Microsoft oder Google, findet man sich plötzlich ausgesperrt vor und kann weder auf Dokumente noch auf E-Mails zugreifen, insofern sie nur in der Cloud lagen.
  • Schwierig, die DSGVO durchzusetzen, das Privacy Shield ist problematisch. Wer eine Checkliste braucht ...
  • Nicht gerade preiswert.

Verglichen dazu Jitsi:

  • Alle Komponenten von Jitsi sind frei und quelloffen.
  • Fehler können von Interessierten gefunden und korrigiert werden.
  • Jeder kann und darf einen Server selbst betreiben,
  • das ganze ist datenschutzfreundlich möglich.
  • Die Weiterentwicklung wird neben der Community und den vielen Beitragenden auch durch einige größere Partner ermöglicht.
  • Viele betreiben Server, die kostenfrei genutzt werden können.
  • Es gibt Dienstleister, die bei dem Betrieb von Jitsi-Instanzen unterstützen bzw. gleich den Betrieb übernehmen.

Vorteile freier und quelloffener Software (Open Source)

  • Selbst betriebene Software fördert Dezentralität, zentrale Ansätze haben einen gemeinsamen Dreh- und Angelpunkt, der in mehrerer Hinsicht ein Problem darstellen kann.
  • Freie Software kann langfristig betrieben und entwickelt werden, während eine Firma das Produkt bzw. den Service einstellt - auch große Firmen und Plattformen gehen pleite. Häufig stirbt damit die Software, selten wird sie unter einer offenen Lizenz freigegeben.
  • Freie Software kann geforkt werden, siehe z.B. die historische Entwicklung von Nextcloud oder LibreOffice. Beide Versionen werden weiterentwickelt, solange sich Unterstützer finden, häufig in Forma von Organisationen aber auch Firmen.
  • Offene Schnittstellen bzw. Protokolle und entsprechende Lizenzen ermöglichen die Integration in fremde oder gar eigene entwickelte Anwendungen.
  • Neue Dienste/Anwendungen können dadurch entstehen, aufbauend auf Open Source Software.

Wie steht es um den Datenschutz und die Sicherheit bei Jitsi?

Die wichtigsten Punkte, teilweise übernommen von Jitsi Meet Security & Privacy, manche beziehen sich auf die Standard-Instanz auf https://meet.jit.si:

  • Jitsi lässt sich datenschutzkonform selbst betreiben.
  • Für Jitsi benötigt man standardmäßig kein Benutzerkonto. Dateneingaben, wie Benutzername oder Mail-Adresse sind optional und werden nur mit Teilnehmenden geteilt.
  • Passwortschutz wird bei Erstellung einer neuen Konferenz angeboten.
  • Authentifizierung ist möglich, z.B. über lokal einzurichtende Benutzer, nicht-authentifizierte Gäste müssen warten, bis die Gastgeberin sich eingeloggt hat. (🛈 Ich habe bislang noch keine praktische Erfahrung mit der Authentifizierung von Jitsi gesammelt, dies sind nur erste Rechercherergebnisse)
  • Chats und Sprecherstatistiken werden nach Ende einer Konferenz gelöscht.
  • Falls Aufzeichnungen durchgeführt wurden, verbleiben diese erst einmal auf dem Server. Der Server-Betreibende muss sich um eine Bereinigung kümmern.
  • Jitsi-Instanzen haben standardmäßig kein Tracking, auf dem Server muss man z.B. Google Analytics erst aktivieren (kann ich nur von abraten). https://meet.jit.si verwendet Tracking. Siehe zu deren Instanz bitte auch Angaben zu Privacy und Terms of Service.
  • Die Jitsi-Meet Apps für iOS und Android verwenden Third-Party-Tracking (siehe Privacy), ein Ticket dazu mit Verweis auf die DSGVO/GDPR wurde nach etwas hitziger Debatte geschlossen. Empfehlung: Auch auf mobilen Geräten bei Bedenken lieber den Browser verwenden ("Desktop-Version" von Jitsi auswählen).
  • Die Kommunikation zwischen dem Browser und Jitsi-Server erfolgt in der Regel über eine verschlüsselte Verbindung (HTTPS, HTTP/2, Websockets über TLS, oder QUIC). Der Grad der Transportverschlüsselung hängt vom jeweiligen Server-Betreiber ab.
  • Video- und Audio werden von WebRTC über SRTP und Daten über DTLS verschlüsselt übertragen, der Schlüsselaustausch erfolgt über DTLS-SRTP.
  • Bei zwei Teilnehmenden erfolgt die WebRTC-Kommmunikation Ende-zu-Ende verschlüsselt von Browser zu Browser (Peer to Peer).
  • Bei mehr als zwei Teilnehmenden übernimmt die Videobridge die Durchleitung von Video und Audio, die Verschlüsselung endet derzeit auf der Videobridge. Es ist ratsam, einen eigenen Server zu betreiben, falls man den Server-Betreibenden nicht vertraut.
  • Ende-zu-Ende-Verschlüsselung zwischen mehr als zwei Teilnehmenden ist in Arbeit, eine Demo samt Video sowie eine Design-/Konzeptbeschreibung existieren bereits (Stand: April 2020).
  • Unabhängig von Jitsi: WebRTC kann die privaten IP-Adresses von Teilnehmenden offenbaren, selbst wenn diese ein VPN einsetzen, was u.a. zum Fingerprinting, d.h. zur eindeutigen Identifizierung von Geräten über Website-Grenzen hinweg missbraucht wird. In Chromium wurde dies mittlerweile wohl mittels Ersetzung von privaten IP-Adressen mit mDNS-Hostnamen adressiert, Firefox scheint noch nicht so weit zu sein.
  • Die verwendeten STUN-Server waren bislang auf Server von Google vorkonfiguriert, mittlerweile setzen sie auf meet-jit-si-turnrelay.jitsi.net, siehe z.B. in der Docker-Variante. Selbst betriebene STUN-Server sind natürlich ebenfalls möglich.
  • Bei Eingabe einer Mail-Adresse schaut Jitsi standardmäßig bei Gravatar vorbei. Auf dem Server können jedoch Third-Party-Requests und damit Gravatar per Konfiguration abgeschaltet werden.
  • Reine Telekommunikationsanbieter müssen ab einer gewissen Größe Überwachungsschnittstellen bereithalten und unterliegen strengeren Auflagen beim Datenschutz. Ob Dienste wie Gmail darunter fallen, hatte im letzten Jahr der EUGH in einem Grundsatzurteil geklärt: Nein, Gmail ist kein Telekommunikationsdienst im Sinne des EU-Rechts. Inwiefern eine große Jitsi-Instanz mit tausenden von Nutzern als einer betrachtet wird und welche Pflichten damit einhergehen ist mir unklar, vielleicht kann eine Leserin mit Erfahrung im Medienrecht hier etwas Klarheit bringen.
  • Darüber hinaus greifen sicherlich Auskunftspflichten ggü. Strafverfolgungsbehörden. Auch hier: Ich bin kein Anwalt, andere mit entsprechendem Hintergrund mögen sich gerne melden.

Wie sieht es mit Datenschutz und Sicherheit bei proprietären Alternativen aus?

  • Nicht öffentlicher Quellcode kann nicht unabhängig geprüft werden, man muss dem Anbieter vertrauen.
  • Anbieter sind verpflichtet mit Strafverfolgungsbehören gemäß der rechtlichen Rahmenbedingungen zu kooperieren, allerdings sind gerade Anbieter proprietärer Software dabei nicht immer transparent und sind manchmal nur zu schnell bereit, Daten ihrer Nutzerinnen weiterzugeben.
  • Auch hier gelten die oben gemachten Anmerkungen hinsichtlich Einstufungen als Telekommunikationsdienste und Auskunfstpflichten.
  • Neben den Strafverfolgungsbehörden gibt es noch viel weniger transparente Entitäten: Die Enthüllungen 2013 durch Edward Snowden haben gezeigt, wie umfangreich Firmen mit Geheimdiensten kooperiert haben, bekannt geworden beispielsweise durch PRISM.
    • Skype war eine Weile relativ dezentral und eher Peer to Peer, nach der Übernahme durch Microsoft wurden zentrale "Superknoten" eingeführt und dank Snowden kam raus, dass Microsoft Geheimdiensten breiten Zugriff auf diese Knoten und Kommunikationsinhalte gewährt hat (Stichwort Prism).
    • Als Gegeninitiative wurde u.a. die Website PRISM-Break aus der Taufe gehoben.
  • Eine zu installierende Anwendung sorgt für eine größere Angriffsfläche auf einem System.
  • Ein Browser muss robust und sicher sein, dafür sorgen ein paar wenige Hersteller, die viele Ressourcen in deren Entwicklung stecken.
  • Gerade Nicht-EU-Anbieter nehmen den Datenschutz häufig wenig ernst und tracken, was das Zeug hält.
  • Einige implementieren eigene Sicherheitsalgorithmen und verstoßen damit gegen die Grundregel, genau dies nicht zu tun, sondern auf etablierte Algorithmen und Lösungen zu setzen. Oder sie setzen darauf, aber implementieren sie falsch.
  • Microsoft, Apple, Amazon, Google lassen bzw. ließen Menschen zur Verbesserung von maschinellen Übersetzungen und "Sprachassistenten" Konversationen mithören.
  • Zoom machte seit einiger Zeit mit etlichen Sicherheits- und Datenschutzproblemen auf sich aufmerksam und zeigte, was passiert, wenn Datensicherheit vernachlässigt wird, sodass vom Zoom-CEO die Notbremse gezogen und Besserung gelobt wurde, hier ein paar Vorfälle:
    • Zoom rühmte sich bis Anfang April 2020 damit, die Aufmerksamkeit von Teilnehmenden zu tracken. Nach Protesten haben sie diese Funktion erstmal deaktiviert.
    • Die iOS App sendete bis Ende März Daten an Facebook.
    • "Zoombombing" wurde eine Art Sport, wo Trolle Zoom-Konferenzen anhand deren IDs herausfanden, diese betraten und auf diverse Weise störten. Die IDs waren entweder direkt ersichtlich oder konnten über automatisierte Routinen berechnet werden. Ein Passwortschutz war standardmäßig nicht gegeben.
      • Hier sei angemerkt, dass Jitsi Meet in der Standardkonfiguration auch keinen Passwortschutz erzwingt, allerdings wird beim Öffnen einer neuen Konferenz die Nutzung eines Passworts angeboten.
    • Zoom gab an, die Videokonferenzen wären Ende-zu-Ende verschlüsselt, während letztlich nur Transportverschlüsselung (TLS) zum Einsatz kam. Mittlerweile erfolgte eine Klarstellung seitens Zoom.
    • Eigene Videolösungen zu entwickeln, statt auf Standards wie WebRTC zu setzen, ist hart und endet oft in Hacks. Auf dem Mac öffnete sich Zoom nach einem Klick auf einen Link automatisch und aktivierte Kamera und Mikrofon. Zudem ließ sich die App nicht deinstallieren, da der gleiche Link die App wieder installierte, denn es wurde ein Webserver bei Deinstallation auf dem System gelassen, der auf diverse Kommandos lauscht, u.a. zur erneuten Installation von Zoom. Mehr dazu.
    • Die Windows App wartete mit etlichen Sicherheitslücken auf, ein Sicherheitsforscher benötigte dazu nur ein paar Stunden Zeit und etwas statische Code-Analyse.

Technik: Woraus besteht Jitsi?

Einfach betrachtet handelt es sich bei Jitsi Meet um einen Server, der eine Web-Oberfläche für die Teilnehmenden bereitstellt sowie weiteren Komponenten, die Videokonferenzen mit mehr als zwei Teilnehmenden koordinieren bzw. vermitteln:

Was ist WebRTC?

WebRTC ermöglicht die Echtzeit-Kommunikation zwischen Browsern und Geräten, meist Video und Audio, aber auch andere Daten sind möglich. WebRTC ist kostenlos und wird von modernen Browsern unterstützt. Software-Entwicklende können eigene WebRTC-Anwendungen umsetzen bzw. ihre Anwendungen um WebRTC erweitern, wobei die Anwendungen im Browser laufen können oder in Form von nativen Apps auf mobilen Geräten wie Google Android oder Apple iOS.

Mit WebRTC kann eine (Web-)Anwendung auf Kamera und Mikrofon des Geräts zugreifen oder dessen Bildschirm teilen. Dies erfolgt grundsätzlich nur mit Einverständnis der Anwenderin.

Wie fließen die Video- und Audioströme bei WebRTC?

Drei Topologien stehen zur Auswahl:

  • Mesh
    Alle Teilnehmer senden und empfangen zwischen allen Teilnehmern.
    • Vorteil: Prinzipiell kein Server benötigt.
    • Nachteil: Sehr CPU- und bandbreitenintensiv (gleichermaßen Downstream und Upstream) bei den beteiligten Geräten.
  • Mixed (Multi-party Conferencing Unit, MCU)
    Teilnehmende senden an einen Server, dieser kombiniert alle Video- und Audioströme und sendet sie an die Teilnehmer.
    • Vorteil: Wenig Last bei den Geräten der Teilnehmer, geringste Bandbreite von allen genannten Topologien, geringste Anzahl an Verbindungen zwischen Server und Teilnehmenden.
    • Nachteil: Alle Video- und Audioströme zu kombininieren ist sehr ressourcenintensiv für den Server.
  • Routing (Selective Forwarding Unit, SFU)
    Teilnehmende senden an einen Server, dieser reicht jeden Video- und Audiostrom an alle Teilnehmer durch.
    • Vorteil: Teilnehmende benötigen wenig Upload-Bandbreite, der Server braucht relativ wenig CPU, da er nur durchreicht.
    • Nachteil: Teilnehmende benötigen mehr Downstream-Bandbreite, der Server die höchste Upstream-Bandbreite aller genannten Topologien, höchste Anzahl an Verbindungen zwischen Server und Teilnehmenden. Bei dem in Europa verbreiteten asymmetrischen DSL, mit deutlich mehr Downstream als Upstream, ist diese Variante praktikabler als Mesh.

Die Illustrationen entsprechen denen im Video, das die Topologien anschaulich erläutert.

Welche WebRTC-Topologie verwendet Jitsi Meet?

Bei zwei Teilnehmenden kommunizieren die Browser per WebRTC direkt miteinander.

Bei mehr als zwei Teilnehmenden laufen die Video- und Audioströme über die Videobridge, die sie an alle Teilnehmer durchleitet. Jitsi setzt auf die Routing-Topologie Selective Forwarding Unit (SFU, siehe oben).

Last: Wie viele Teilnehmende kann ein Jitsi Meet Server verkraften?

Zur Performance hat das Jitsi-Team einen ausführlichen Test durchgeführt und den Bericht veröffentlicht, hier zusammengefasst:

  • Server: Quad-core Intel Xeon E5-1620 v2 @ 3.70GHz CPU
  • Komponenten: Jitsi Meet, Nginx Web-Server, Prosody XMPP-Server und Jitsi Videobridge
  • Sie haben die Anzahl an Konferenzen, lastgenerierenden Endpunkte, CPU-Verbrauch sowie ein- und ausgehenden Netzwerkverkehr gemessen und daraus Bitrate und Anzahl der Video-/Audioströme berechnet, die von der Videobridge gesendet wurden.
  • Es wurden pro Endpunkt voraufgezeichnete Audio- und Videodaten mit durchschnittlich 512 Kbps gesendet, in einer Chrome-Instanz lief die Jitsi-Meet Web-Anwendung.

Das Ergebnis gerundet: 1000 Videostreams mit 550 Megabit pro Sekunde bei 20% CPU.

Konkret: 1056 Video- und Audioströme wurden von der Videobridge versandt, was in etwa Bitraten von

  • 528 Konferenzen mit zwei Personen,
  • 176 Konferenzen mit drei Personen oder
  • 53 Konferenzen mit 5 Personen entspricht.

Sie weisen darauf hin, dass im normalen Betrieb bei großen Konferenzen nie alle Teilnehmenden als Video sichtbar wären, sondern automatisch nur die letzten N Sprechenden als Video übertragen würden, alle anderen Videoströme sind deaktiviert, bis jemand spricht. Dies lässt sich pro Jitsi-Instanz konfigurieren, standardmäßig ist die dazugehörige Konfigurationsoption channelLastN mit -1 belegt, d.h. alle Teilnehmer sind sichtbar.

Die Videobridge läuft mit Java und war auf 3 GB Arbeitsspeicher limitiert, der zugewiesene Speicher (Resident Set Size) überschritt nicht 1,5 GB.

Genereller Tipp: Wenn besonders viele Teilnehmer in einer Konferenz sind oder auf dem Server, kann die Videoqualität reduziert werden. Steht der Server generell unter Last, kann die (maximale) Videoauflösung per Konfiguration reduziert werden, z.B. von 720p auf 480p.

Load-Balancing: Wie skaliert man Jitsi?

Das Jitsi-Team stellt eine Anleitung zur Skalierung von Jitsi bereit.

Das Setup besteht grob aus einem Server mit allen Jitsi-Komponenten außer der Videobridge und beliebig viele Videobridge-Server.

Die Videobridge hat die meiste Arbeit zu leisten. Sie sollte entsprechend gut ausgestattet sein, mit 4 oder 8 CPU-Kernen und 8 GB RAM pro Server. Hier möchte ich ergänzen: 4 Kerne erscheinen mir arg wenig, wenn die Videobridge belastbar sein soll. Am besten soviele CPUs/Kerne wie möglich.

Der Server mit der Web-Applikation, Prosody usw. ist genügsamer, solange nicht allzu viele Konferenzen gleichzeitig laufen. Hier reichen 4 CPU-Kerne und 8 GB Ram.

Die aktuelle Anleitung ersetzt veraltete Tutorials zum Load-Balancing für Cloud und Server-Farm, die ich an sich ganz anschaulich fand. Ich würde ergänzen wollen, dass die Bandbreite der Videobridge der kritische Punkt ist und der begrenzende Faktor für die Größe einer einzelnen Konferenz. Man sollte mindestens 1 Gbps pro Server an Bandbreite vorsehen.

Eine Konferenz kann m.W. nur auf einer Videobridge laufen, es können jedoch mehrere Konferenzen über mehrere Videobridges verteilt werden.

Überarbeitungen/Updates

Nach oben

  • 26.07.2020:
    • Zwischenzeitlich verweisten Link zur Skalierung von Jitsi korrigiert. Vielen Dank für den Hinweis, M.!
  • 02.05.2020:
    • Rechtschreibfehler korrigiert
  • 01.05.2020:

Nach oben

Jan Beilicke

About the author

Long-time IT professional and full-time nerd. Open source enthusiast, advocating security and privacy. Sees the cloud as other people's computers. Find me on Mastodon or Twitter.