Durch die Corona-Krise haben viele Videochat-Services einen steilen Anstieg bei Kunden- und Nutzerzahlen zu verzeichnen. Jitsi hat dabei unter den bekannteren Videochat-Programmen das Alleinstellungsmerkmal, dass es Open-Software ist und selbst gehostet werden kann. Nun kommt auch noch die End-to-End-Verschlüsselung für Gruppen hinzu. Die Datenschutzkontroverse um Zoom rührt u.a. auch daher, dass das Unternehmen fälschlicherweise die Angabe machte, dass es End-to-End-Verschlüsselung anwendet. Gemeint war aber eine einfache Verschlüsselung, die Außenstehenden den Zugriff zu den Daten verweigert. Ich berichtete darüber Anfang des Monats.
Im Bereich der Video-Chat-Software gibt es bereits End-to-End-Verschlüsselung, die bei Jitsi und vielen anderen Videochat-Programmen bei 1:1-Sitzungen auch angewendet wird. Für Gruppenchats gestaltet sich der Sicherheitsstandard aber komplizierter. Denn bei mehreren Parteien verursacht die Verschlüsselung eine Multiplikation der Beanspruchung von Bandbreite und Rechenleistung.
Bei 1:1-Gesprächen bekommt der jeweilige Partner die verschlüsselte Version des anderen zugespielt. Bei drei Parteien wären das schon sechs verschlüsselte Videodateien, bei vier schon 12, usw. Ein zentraler Server entschlüsselt die Videodateien dagegen einmal vor Ort und gibt allen Parteien Zugang zu derselben Videodatei. Technisch also um einiges einfacher.
Bei Jitsis Verschlüsselung von Gruppenchats handelt es sich um ein absolutes Novum, das die Open-Source-Software in Sachen Sicherheit von Zoom, Google Hangouts oder Skype vollkommen abhängt. Da Jitsi Open-Source ist, kann das Feature schon jetzt getestet werden. Jitsi bittet dabei um Mithilfe und Kommentare bei der Entwicklung des Codes, den ihr auf github begutachten könnt.
Bei der Vorstellung des neuen Features bei jitsi.org könnt ihr sehen, dass das Feature bei drei Personen bereits zu funktionieren scheint. Bei vier oder mehr Personen scheint es aber noch zu Problemen zu kommen. Hier wird auch verraten, wie die Verschlüsselung (theoretisch) funktioniert. Nämlich über einen Second-Layer namens „Insertable Streams“. Google hat diese API entwickelt zur Verschlüsselung von Video- und Audiodateien im Streaming.
