WietransparentsindAnbietervonVideochat-Software?
Letzter Stand: 03.04.2020

Die Corona-Pandemie ist dabei, quasi über Nacht unserer Gesellschaft sehr große Veränderungen aufzuerlegen. Auch bislang selbstverständliche und gewohnte Kommunikationsformen sind von diesen Veränderungen betroffen. Schulen, Universitäten sowie Unternehmen, Verbände und Vereine müssen sich in kürzester Zeit neue Wege der Kommunikation erschließen.

Mittlerweile haben sich viele Stellen zu verschiedenen Aspekten von Videochatsoftware geäußert. Gleichwohl bleibt die Zahl der an unsere Behörde gerichteten Anfragen hoch. Daher veröffentlicht der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit (HmbBfDI) die vorliegenden Betrachtungen des Prüflabors der Behörde zu verschiedenen Videokommunikationsdiensten.

In den meisten Fällen muss man sich als Softwarenutzer*in auf Herstellerangaben und –versprechen verlassen. Software kommt häufig fertig paketiert auf unsere Geräte und Nutzer*innen können sich über ihre genaue Funktionsweise kein Bild machen.  Eine Ausnahme bildet freie open-source Software, die man grundsätzlich aus dem Quellcode selbst bauen kann. Für alle anderen Distributionsformen gilt, dass man für die Funktionsweise auf Herstellerangaben angewiesen ist.

Insbesondere bei Software, die personenbezogene Daten verarbeitet, ist daher maximale Transparenz über ihre Funktionsweise eines der wichtigsten Auswahlkriterien. Je präziser ein Hersteller die Funktionsweise seiner Software beschreibt, desto besser können sich Nutzer*innen ein Bild machen. Transparenz erhöht das Vertrauen in Software und Hersteller und dokumentiert darüber hinaus, ob sich Hersteller zu wichtigen Fragen Gedanken machen. 

​​​​​​​In der vorliegenden Serie betrachten wir die von Videochatbetreibern öffentlich zur Verfügung gestellten Informationen und Angebotsbeschreibungen. Wir legen der Betrachtung der einzelnen Dienste einen tagesgenauen Zeitstempel zugrunde und nehmen uns jeweils einen festen Zeitrahmen von einer Stunde, um zu vergleichbaren Ergebnissen zu gelangen.

Anhand der zusammengetragenen Informationen beantworten wir in unseren Untersuchungen Fragen aus den folgenden Kategorien, um Verantwortlichen die datenschutzrechtliche Einordnung der Dienste zu erleichtern:

  • Architektur des Dienstes
  • Maximale Teilnehmeranzahl in Videokonferenzen
  • Datenhoheit über die erzeugten Videoströme und Metadaten
  • Notwendigkeit der Registrierung eines Nutzerkontos
  • Kommunikationsverschlüsselung
  • Einsatz von Tracking und Analytics
  • Kommerzialisierung des Dienstes

Es handelt sich hierbei um eine im Wesentlichen technische Betrachtung der Dienste, nicht hingegen um eine datenschutzrechtliche Prüfung und Bewertung. Eine solche kann nur bezogen auf den konkreten Verwendungskontext und nicht abstrakt erfolgen. Insbesondere ist die datenschutzrechtliche Rollenverteilung zwischen Diensteanbietern und -nutzer*innen (Stichwort: wer ist Verantwortlicher, Auftragsverarbeiter, gemeinsam für Verarbeitung verantwortlich, Betroffener, Dritter, etc.) von dem jeweiligen Nutzungsverhältnis und den rechtlichen Beziehungen der Beteiligten abhängig und muss einzelfallbezogen geklärt werden.

Die sich hieraus ergebenden datenschutzrechtlichen Pflichten und Haftungsrisiken sind dementsprechend nicht Gegenstand der folgenden Betrachtung.

Die betrachteten Werkzeuge bilden einen Ausschnitt der verfügbaren Tools zur Videokommunikation und rücken meist insbesondere durch externe Anfragen, große Popularität und hervorzuhebende Transparenz über ihre Funktionsweise in unseren Fokus. Die hier vorgestellte Liste wächst stetig im Sinne eines Living Documents weiter, wobei wir uns zunächst auf Werkzeuge konzentrieren, die Videokonferenzen mit mindestens 10 Teilnehmern unterstützen.

 

Wire

URL: https://wire.com/
Datum:  26.03.2020
   

Unser erster Prüfgegenstand ist die Messenger- und Videochatsoftware Wire. Auf der Website erwartet uns zunächst eine Landing-Page mit Screenshots und Marketingslogans. Direkt hier findet sich auch ein Link auf einen Security-Bereich, auf dem ein Security Whitepaper (PDF) zu finden ist.

Aus dem Security Whitepaper lernen wir z.B., wie der Registrierungsprozess funktioniert. Registrierung ist per E-Mail Adresse oder Telefonnummer möglich. Diese Daten werden aber nur für Contact Discovery verwendet, dienen jedoch nicht der Indentifikation von Nuter*innen. Dafür nutzt Wire eine interne ID, die an einen Benutzernamen gekoppelt ist. Weiter gibt es Informationen zu Nutzer*innenprofilen und anfallenden Metadaten sowie zur Passwortspeicherung und zur Registrierung weiterer Geräte in einem Account.

Contact Discovery

Die automatische Erkennung von Freunden und Bekannten innerhalb von Kommunikationsanwendungen nennt man Contact Discovery. Ein gängiges Verfahren ist die Speicherung von Telefonnummern und/oder E-Mail Adressen aller Nutzer*innen auf einem Server. Neue Nutzer*innen können dann ihr Adressbuch an den Betreiber hochladen und die enthaltenen Telefonummern und E-Mail Adressen werden mit denen auf dem Server abgeglichen. Bei Übereinstimmung kriegen beide Parteien eine Rückmeldung, dass die jeweils andere Nutzer*in als Kontakt verfügbar ist.

Idealerweise werden diese Daten beim Betreiber nicht im Klartext abgelegt, sondern in pseudonymisierter (z.B. gehashter) Form. In diesen Fällen kann auch das Adressbuch vor Upload in derselbe Weise pseudonymisiert werden. Dieses Vorgehen hat allerdings die Schwäche, dass es insbesondere bei Telefonnummern nicht viele Möglichkeiten gibt und Tabellen für die Hashes aller möglichen Telefonnummern mit relativ geringem Aufwand erzeugt werden können. Dennoch ist ein Hashverfahren der Speicherung im Klartext deutlich vorzuziehen.

Das Whitepaper enthält darüber hinaus eine umfangreiche Protokollbeschreibung für Messaging und Videotelefonie. Für Messaging setzt Wire auf das hauseigene Proteus-Protokoll, das auf dem Double Ratchet-Protokoll des Messengers Signal basiert.

Das Signal Protokoll

Viele aktuelle Messenger setzen auf das Signal-Protokoll, bestehend aus dem Extended Triple Diffie-Hellman (X3DH) Schlüsselaustauschprotokoll, dem Double Ratchet Schlüsselmanagement-Protokoll und einem Nachrichtenaustauschverfahren. Es wurde von den Machern des gleichnamigen Messengers für diesen entwickelt und gilt als sehr modernes und gut erforschtes Messaging-Protokoll, das dank seiner offenen Spezifikation von anderen Messengeranbietern genutzt werden kann und von vielen Messengern eingesetzt wird.

Wir finden heraus, dass Wire Multi-Device Unterstützung für bis zu sieben permanent registrierte Geräte bietet und dass Nachrichten während einer Kommunikation von allen Teilnehmer*innen individuell pro Gerät anderer Teilnehmer*innen verschlüsselt werden. Für Videocalls setzt Wire auf etablierte Standards wie ICE und SRTP.

Interactive Connectivity Establishmeht (ICE)

Das Interactive Connectivity Establishmeht (ICE) Verfahren kombiniert mehrere Protokolle zum Überwinden eines NAT-Routers. Viele Netzwerke nutzen sog. Network Address Translation (NAT) um mehreren Geräten in einem privaten Netz die Nutzung einer gemeinsamen öffentlichen IP Adresse zu ermöglichen. NAT erschwert es einzelnen Computern, frei aus dem Internet Pakete zu empfangen. ICE dient dazu, diese limitierung aufzuheben und – je nach Situation – entweder eine Direktverbindung zwischen zwei Geräten durch ein NAT aufzubauen oder alternativ über einen gemeinsamen Server zu kommunizieren.

In Gruppencalls bauen alle Teilnehmer*innen je eine SRTP-verschlüsselte Verbindung zu allen anderen Teilnehmer*innen auf. Ob es sich hierbei um peer-to-peer Direktverbindungen handelt, oder Verbindungen durch ein Wire Relay bleibt unklar. Jedoch sind diese Verbindungen laut Whitepaper Ende-zu-Ende verschlüsselt. Perfect Forward Secrecy gilt auch für den Austausch von Medien und für Audio- und Videokonferenzen.

Perfect Forward Secrecy und Post-Compromise Security

Perfect Forward Secrecy ist eine Eigenschaft kryptografischer Protokolle, die nach kompromittierung eines Schlüssels garantiert, dass bisher ausgetauschte Nachrichten nicht entschlüsselt werden können. Umgesetzt wird dies meistens durch regelmäßig erneuerte Sitzungsschlüssel, die so von einem Langzeitschlüssel abgeleitet werden, dass weder die Kompromittierung eines Sitzungsschlüssels, noch die des Langzeitschlüssels dazu führt, dass Nachrichten entschlüsselt werden können, die nicht mit exakt diesem Schlüssel verschlüsselt wurden.

Post-Compromise Security ist die analoge Eigenschaft, die garantiert, dass nach kompromittierung eines Schlüssels zukünftig versendete Nachrichten geheim bleiben.

Das Security Whitepaper macht darüber hinaus Angaben zu verschiedenen Aspekten der Kommunikation (Auszug):

  • Medien wie Bilder und Videos werden symmetrisch verschlüsselt auf einen Server geladen und der Schlüssel in einer Nachricht übermittelt. Die Empfängerseite lädt die verschlüsselte Datei herunter und entschlüsselt sie zur Anzeige. Die verschlüsselten Dateien verbleiben ohne Zeitbeschränkung auf dem Server.
  • Backups unter iOS werden verschlüsselt
  • Auf Android und iOS werden lokale Daten verschlüsselt abgelegt. Die Desktop-App legt unverschlüsselt ab.
  • HTTP Verbindungen zu Wire-Servern werden grundsätzlich mit TLS verschlüsselt und die älteste unterstützte Protokollversion ist TLSv1.2
  • Anrufe sind nach Möglichkeit Direktverbindungen zwischen zwei Teilnehmer*innen. Unter bestimmten Umständen kann die Nutzung eines TURN-Servers notwendig sein. Hierbei werden generische Log-In Informationen verwendet, die keine Rückschlüsse auf Nutzer*innen zulassen sollen.

Ebenfalls verlinkt ist ein Privacy Whitepaper (PDF) mit Angaben über die Erhebung und Verarbeitung personenbezogener Daten. Dieses Papier beschreibt die erhobenen Daten, macht Angaben zur Nutzung von Adressbüchern und beschreibt u.a. das Verfahren für Contact Discovery, die Speicherung von Zahlungsdaten, die Policy für serverseitige Logs und Hinweise auf die Erhebung von Nutzungsdaten, die per Opt-out deaktiviert werden kann.

Wire verlinkt außerdem auf das eigene Github-Profil, das zum Zeitpunkt der Untersuchung über 200 Repositories enthält, die auf den ersten Blick den Quellcode aller Komponenten des Dienstes enthalten; darunter sowohl Code für die Android und iOS Apps, den Desktop-Client, aber auch den Servercode selbst.

Weiter finden sich auf der Webseite Hinweise zu Security Audits zu verschiedenen Komponenten und die Prüfberichte dazu zum Download. Geprüft wurden die Clients für Web, Android und iOS. Ein Audit zur Implementierung des Protokolls fand ebenso statt. Auf der Seite zum Thema Transparenz wird Wire als Unternehmen mit Sitz in der Schweiz angegeben. Die Entwicklung findet in Deutschland statt. Die Standorte der Wire-Server befinden sich in der EU. Es wird betont, dass die Vorgaben der DSGVO eingehalten werden.

Schließlich finden wir auf der Support-Seite eine FAQ sowie Angaben zur maximalen Anzahl von 10 Teilnehmern bei Videokonferenzen. Es ist möglich, mit einem Gastaccount an Konferenzen teilzunehmen, so dass eine Nutzerregistrierung nicht für alle Teilnehmer*innen zwingend ist. Die Wire-Desktop-Anwendung unterstützt laut Herstellerseite auch eine Screen-Sharing Funktion. Wire kann als Messenger und Videokonferenztool kostenlos genutzt werden. Durch die Verwendung einer Client-Software oder des Webclients kann ein Nutzerkonto erstellt und genutzt werden. In diesem Fall wird die von Wire zur Verfügung gestellte Infrastruktur genutzt. Alternativ stehen verschiedene Nutzungsmodelle zur Verfügung, die unter anderem ein eigenständiges Hosting des Backends seitens der IT zahlender Nutzer*innen zulassen. Eine Anbindung an zentrale Nutzerver*innenwaltungsdienste wie LDAP und Active Directory werden unterstützt. Auf den Internetseiten von Wire wird eine Limitierung der kostenlosen Variante nicht dargestellt. Eine Abgrenzung von verschiedenen Leistungsstufen bei Wire Pro und Enterprise ist nicht ersichtlich.

Die Wire Client-Anwendungen für Android und den Linux Desktop lassen sich nach der Registration mit einem Nutzernamen und Passwort verwenden. Die Anwendung auf dem Smartphone lässt sich durch ein zusätzliches Passwort sichern.

Fazit

Wire überzeugt mit hohem Detailgrad an Informationen über den eigenen Service. Wichtige Ressourcen sind leicht zu finden und in verständlicher Sprache geschrieben. Informationen über die grundsätzliche Funktionsweise sind nachvollziehbar dargelegt und dennoch wird nicht mit Informationen über kryptografische Parameter gespart.

Die Kombination aus Security- und Privacy-Whitepaper sowie FAQ ist gut geeignet, einen Überblick über die verschiedenen Apps und ihre Funktionsweisen zu gewinnen. Dass nebenbei der Quellcode für alle Komponenten aus Wires Netzwerk (inklusive einer Übersicht über die Komponenten) öffentlich verfügbar ist, unterstreicht diesen Ansatz. Wire geht dabei sogar den selten gesehenen Schritt, den Code der Serverkomponenten zu veröffentlichen. Auch wenn natürlich von Nutzer*innenseite nicht nachvollzogen werden kann, ob auf ihren Geräten oder dem Server exakt der öffentlich verfügbare Code läuft, ist dieser Ansatz der transparenteste, den wir bisher gefunden haben.


Zoom

URL: https://www.zoom.us/
Datum:  27.03.2020
   

Aufgrund mehrerer Beschwerden und der wachsenden Popularität der Videokommunikationssoftware Zoom haben wir uns entschieden, als nächstes den Dienst des gleichnamigen Unternehmens anzuschauen. Wir besuchen die Webseite und schauen, welche Informationen der Hersteller preisgibt. Anschließend probieren wir das kostenfreie Basic-Angebot Zoom aus und wollen daraus weitere Informationen gewinnen.

Zoom wirbt mit Vielseitigkeit und macht mit Funktionen zum Durchführen von Videokonferenzen und Präsentationen auf sich aufmerksam. Vor allem durch die Möglichkeit der Aufzeichnung von Konferenzen und der sog. Aufmerksamkeitsüberwachung (Attention Tracking) versucht Zoom, sich von anderen Anbietern abzuheben. Auf der Startseite finden wir eine Reihe von Learn More-Links zu verschiedenen Features, über die wir die ersten Dinge lernen:

Die Aufzeichnungen können vom Organisator (Host) einer Konferenz lokal auf dem eigenen Gerät gespeichert werden. Die Enterpise Version von Zoom erlaubt die Speicherung in der Zoom-Cloud. Optional kann dann aus dieser Aufzeichnung eine Transkription​​​​​​​angefertigt werden. Der Dienst speichert nach eigenen Angaben alle Chat-Konversationen für 10 Jahre und stellt sie für eine Suche seitens der Nutzer*innen zur Verfügung.

Zoom kann über den Webbrowser, Mobile- und Desktop-Clients verwendet werden. Die beiden Letztgenannten benötigen eine Installation auf dem Gerät des Nutzers. Viele Betriebssysteme wie Android, iOS, Linux, MacOS und Windows werden unterstützt.

Über die deutschsprachige Seite zu den rechtlichen Bestimmungen können die Zoom Datenschutzrichtlinien aufgerufen werden. Die Einhaltung des EU-US Privacy Shield Abkommens wird deklariert. Über einen weiteren Link kann ein als GDPR Hinweis bezeichnetes Official Statement: EU GDPR Compliance​​​​​​​ aufgerufen werden.

Die Datenschutzrichtlinien enthalten eine Auflistung der personenbezogenen Daten, die von Nutzer*innen erhoben werden, wenn diese Zoom-Produkte verwenden oder anderweitig mit diesen Produkten interagieren. Die Angaben zu den gesammelten Daten werden tabellarisch aufgelistet.

In der Basic-Version unterstützt Zoom maximal 100 Teilnehmer in einer Konferenz und gleichzeitig 49 Nutzer auf einem Bildschirm. Wir können Hinweise auf eine optionale Ende-zu-Ende Verschlüsselung für Chat-Nachrichten finden, deren Funktionsweise aber mit Angabe von AES256 und public/secret key-Erwähnung vage bleiben. Ob und inwieweit sich die einzelnen Versionen an diesem Punkt unterscheiden wird uns nicht deutlich. In den Support-Seiten im Zoom Help Center finden wir Angaben zur TLS 1.2 Transportverschlüsselung.

Zoom lässt sich an Nutzerkontodienste wie Active Directory anbinden. Es werden Nutzerrollen und Rechte unterstützt. Die Nutzerin, die die Konferenz eröffnet, wird als “Host” bezeichnet und entscheidet über den Einsatz optionaler Funktionen, wie das Anfertigen von Aufzeichnungen, die Aufmerksamkeitsüberwachung und den Einsatz von Ende-zu-Ende Verschlüsselung. Ein Host benötigt ein registriertes Nutzerkonto, um die Sitzung zu starten und um weitere Teilnehmer*innen einzuladen. Die Einladung wird als eine URL mit der Identifikationsnummer für die Sitzung und einem Sitzungspasswort generiert. Teilnehmer*innen kommen als Gast ohne eine Registrierung aus.

Schließlich finden wir einen Verweis auf ein Whitepaper, welches detailliertere Beschreibungen zu den einzelnen Zoom-Funktionen enthält.

Die Kommunikation wird auch bei nur zwei Teilnehmer*innen immer über die Server von Zoom geleitet. Obwohl der Dienst Zoom Cloud-basiert ist, können sich Kunden der kommerziellen Business- und Enterprise-Stufen entscheiden, bestimmte Komponenten lokal in ihrem eigenen Netzwerk und auf ihrer eigenen Infrastruktur zu betreiben. Bei der Nutzung dieser On-Premise Lösung wird bei Verbindungsproblemen mit den lokalen Servern automatisch auf die Zoom-Cloud zurückgegriffen. Es wird die Möglichkeit benannt, Zoom mit anderen Messaging Tools zu verbinden. Ein API steht für die Anbindung an eigene Werkzeuge zur Verfügung.

Zurzeit wird auf die Verwendung von WebRTC verzichtet. Nach kurzer Recherche finden wir Hinweise auf eine geplante, zukünftige Nutzung dieser Web-Technologie.

Wir haben die kostenfreie Basic-Version des Zoom Dienstes in mehreren Sitzungen mit zwei oder mehreren Teilnehmern durchgeführt und die beworbenen Funktionen ausprobiert. Wir konnten den Web-Client aufrufen, nachdem der Host ihn aktiviert hatte und uns die Einladungs-URL zusandte. Beim Beitritt einer Zoom-Konferenz baut der Client eine Verbindung zu Servern in den USA auf. Dies ist auch bei zwei Teilnehmern der Fall. Eine peer-to-peer Verbindung zwischen den Teilnehmern konnten wir nicht feststellen.

Fazit

Die Informationen auf der Zoom-Webseite zum Funktionsumfang der Software konnten wir nachvollziehen. Die Beschreibung der Architektur von Zoom, des eingesetzten Kommunikationsprotokolls und der verwendeten Verschlüsselungstechniken bleiben an der Oberfläche und enthalten keine Erklärung beispielsweise wie und was verschlüsselt wird. Für Nutzer*innen kann anhand der Informationen auf der Zoom Webseite keine Aussage über eine mögliche vertrauliche Kommunikation gegenüber dem Anbieter und Dritten bei der Verwendung von Zoom getroffen werden. Hervorzuheben ist außerdem, dass die vom Host aktivierte Aufzeichnung einer Konferenz für die Teilnehmer beim Desktop-Client nur durch einen Hinweis am oberen Rand in kleiner Schrift erkennbar ist.

Der HmbBfDI zu Zoom

Auf die derzeit sehr kritische Medienberichterstattung zu Zoom – insbesondere im Zusammenhang mit Ermittlungen der New Yorker Generalstaatsanwaltschaft zu Verstößen gegen Datenschutz und Datensicherheit – gehen wir an dieser Stelle nicht ein, da dies den Rahmen unserer Betrachtungen sprengen würde.


Skype

URL: https://www.skype.com/
Datum:  31.03.2020
   

Als drittes Werkzeug zur Videokommunikation betrachten wir Skype. Die Website von Skype​​​​​​​ ist in die von Eignerin Microsoft eingebunden. Ein Whitepaper, dass Fragen zu technischen Details beantwortet, konnten wir zunächst nicht finden.

​​​​​​​Antworten zu einigen unserer Fragen finden wir erst auf der Skype Support Seite, die ein FAQ enthält, das jedoch technisch oberflächlich bleibt und hautpsächlich Fragen zur UI beantwortet.  Hier lernen wir, dass Skype bis zu 50 Teilnehmer in einer Konferenz unterstützt. Dafür stehen Clients verschiedener Betriebssysteme wie Android, iOS, Windows, MacOS und ein Web Client zur Verfügung. Der Dienst funktioniert nur mit Hilfe der Skype Cloud, die von Microsoft betrieben wird. Wir können keine Angaben zu individuellen On-Premise Lösungen oder zu Serverstandorten der Skype Cloud auf den Webseiten des Dienstes finden.

Zur Nutzung von Skype wird ein Microsoft Nutzerkonto, bestehend aus E-mail Adresse und Passwort benötigt. Gastzugänge sind möglich und können für die jeweilige Konferenz erzeugt werden. Für Gäste ist sowohl Audio- als auch Videoteilnahme möglich. Für registrierte Nutzer kann Contact Discovery nach E-Mail Adresse oder hinterlegter Telefonnummer erfolgen.

Die automatische Erkennung von Freunden und Bekannten innerhalb von Kommunikationsanwendungen nennt man Contact Discovery. Ein gängiges Verfahren ist die Speicherung von Telefonnummern und/oder E-Mail Adressen aller Nutzer*innen auf einem Server. Neue Nutzer*innen können dann ihr Adressbuch an den Betreiber hochladen und die enthaltenen Telefonummern und E-Mail Adressen werden mit denen auf dem Server abgeglichen. Bei Übereinstimmung kriegen beide Parteien eine Rückmeldung, dass die jeweils andere Nutzer*in als Kontakt verfügbar ist.

Idealerweise werden diese Daten beim Betreiber nicht im Klartext abgelegt, sondern in pseudonymisierter (z.B. gehashter) Form. In diesen Fällen kann auch das Adressbuch vor Upload in derselbe Weise pseudonymisiert werden. Dieses Vorgehen hat allerdings die Schwäche, dass es insbesondere bei Telefonnummern nicht viele Möglichkeiten gibt und Tabellen für die Hashes aller möglichen Telefonnummern mit relativ geringem Aufwand erzeugt werden können. Dennoch ist ein Hashverfahren der Speicherung im Klartext deutlich vorzuziehen.

Bei der Kommunikation zwischen zwei Teilnehmern sind Text-Nachrichten im Regelfall via TLS transportverschlüsselt. Später finden wir auf einer FAQ-Unterseite ein Whitepaper von Microsoft (PDF), das Details zur Ende-zu-Ende verschlüsselten Kommunikation enthält. Demnach unterstützt Skype sog. Private Conversations, die zwischen exakt zwei Nutzer*innen aufgebaut werden können. Hierfür kommt das Signal Protokoll zum Einsatz.

Das Signal Protokoll

Viele aktuelle Messenger setzen auf das Signal-Protokoll, bestehend aus dem Extended Triple Diffie-Hellman (X3DH) Schlüsselaustauschprotokoll, dem Double Ratchet Schlüsselmanagement-Protokoll und einem Nachrichtenaustauschverfahren. Es wurde von den Machern des gleichnamigen Messengers für diesen entwickelt und gilt als sehr modernes und gut erforschtes Messaging-Protokoll, das dank seiner offenen Spezifikation von anderen Messengeranbietern genutzt werden kann und von vielen Messengern eingesetzt wird.

Telefonate mit Ende-zu-Ende Verschlüsselung sind ausschließlich aus diesen Private Conversations initiierbar und nutzen SRTP. Die Dokumentation im Skype Help Center gibt aber eine zukünftige Priorisierung des Nachrichtenverkehrs mit Transportverschlüsselung über die Microsoft Cloud an, so dass die Perspektive einer Nutzung von Ende-zu-Ende Verschlüsselung langfristig verschwindet.

Skype schaltet Werbung in den Client-Anwendungen. Dafür werden personenbezogene Daten erhoben und verwendet, um zielgerichtete Werbung für die Teilnehmer zu schalten.

Gespräche können in Echtzeit als Untertitel erzeugt und angezeigt werden. Hierbei steht auch die Simultanübersetzung des gesprochenen Wortes zur Verfügung. Diese Funktionalität steht in Private Conversations nicht zur verfügung. 

Die Aufnahmen der Gespräche werden intern von Microsoft zur Produktverbesserung genutzt. Es kann sowohl eine automatisierte als auch eine manuelle Verarbeitung dieser Aufnahmen stattfinden. Die Einstellungen zu den Aufnahmen sind gerätespezifisch, d.h. auf jedem Gerät muss die Einstellung erneut getroffen werden. Allerdings ist die Standardeinstellung für Gesprächsaufnahmen ausgeschaltet. Wir konnten auf den verschiedenen Skype-Seiten keine Angaben zur Speicherdauer von Aufnahmen ausfindig machen.

Spezifische Datenschutz-Bestimmungen für Skype als isolierten Dienst waren für uns nicht auffindbar. Entsprechende Links auf der Skype Website führten uns jeweils auf die Microsoft Nutzerkonto Bestimmungen

Fazit

Das Whitepaper über Private Conversations enthält grundlegende Aussagen zur technischen Funktionsweise. Für alle anderen Funktionen fehlt eine solche technische Beschreibung bisher. Ein tieferes Verständnis für die internen Vorgänge und die Verarbeitung personenbezogener Daten kann so nur schwer erlangt werden. Die enge Verknüpfung mit einem Microsoft-Konto erschwert die Differenzierung der Datenschutzbestimmungen von Skype zu anderen Diensten im Sortiment des Herstellers. Microsoft bietet mit Skype for Business und Microsoft Teams zwei weitere kommerzielle Chat- und Konferenzwerkzeuge an, die sich vornehmlich an Geschäftskunden und größere Gruppen richten.


Jitsi Meet

URL: https://jitsi.org/jitsi-meet/
Datum:  01.04.2020
   

Auf der Startseite stellt sich Jitsi als freies open-source Projekt für Web-Konferenzen vor. Das untergeordnete Tool für Videokonferenzen heisst Jitsi-Meet und wird auf seiner eigenen Unterseite als eine verschlüsselte Videokonferenzlösung präsentiert und wir lernen, dass es ohne Registrierung eines Kontos benutzbar ist. Die Projektwebseite ruft Besucher auf, eine eigene Jitsi Meet Instanz zu hosten. Es stehen Client-Anwendungen für Android und iOS, sowie für Web und Desktop zur Verfügung. Wir finden Hinweise auf Quellcode-Module, mit deren Hilfe Softwareentwickler Jitsi als Dienst in eigene Webseiten oder Werkzeuge integrieren können. Zusätzlich bietet der Projektbetreiber selbst einen öffentlichen Videokonferenzdienst auf basis der eigenen Technologie an. In der FAQ werden uns unter anderem die verschiedenen Jitsi Projekte vorstellt. Darunter finden wir “Jitsi Meet” als Anwendung für Nutzer*innen, sowie einige Serverkomponenten und Zusatzwerkzeuge, wie Browser Addons zur Unterstützung von Screen Sharing. Jitsi ist als ein Baukasten zu verstehen, mit dem Betreiber*innen nach eigenen Wünschen viele Funktionen durch den Einsatz einzelner Komponenten aktivieren und damit den Nutzern zur Verfügung stellen können. Dazu gehört auch beispielsweise die Möglichkeit direkt zu YouTube zu streamen.

Finanziert wird das Jitsi Projekt von 8x8, einem Telefonsystemanbieter.

Neben Installationsanleitungen für Client- und Server-Software erhalten wir keine tiefer reichenden Informationen zur unterliegenden Technologie auf jitsi.org. Da Jitsi jedoch ein freies open-source Projekt ist, werden wir in den Quellcode-Repositories auf github.com fündig. In der readme des jitsi-meet Repositories findet sich direkt ein security-Abschnitt, der darauf hinweist, dass WebRTC als Unterbau von Jitsi keine Ende-zu-Ende verschlüsselten Gruppenkonversationen erlaubt. Stattdessen kommt eine Transportverschlüsselung zum Einsatz. Auf dem genutzten Server werden die Videostreams jedoch für die Weiterleitung kurz ent- und dann wieder verschlüsselt. Bei einer 1:1 Kommunikation kommt die Einschränkung zum Tragen, dass Nutzer*innen ihre Schlüssel selbst abgleichen müssten und somit zwar grundsätzlich eine Ende-zu-Ende Verschlüsselung möglich ist, jedoch ohne Authentizitätsgarantien.

Eine Angabe über eine maximale Teilnehmeranzahl in Jitsi-Meet konnten wir zunächst nicht finden. Mittlerweile wissen wir, dass sich die maximale Teilnehmeranzahl aus den verfügbaren Hardware-Ressourcen ergibt. Schöpft eine durchgeführte Videokonferenz diese Ressourcen gänzlich aus, leidet die übertragene Audio- und Videoqualität für Teilnehmer.

WebRTC

Der WebRTC Standard definiert eine Reihe von Kommunikationsprotokollen und Schnittstellen zur peer-to-peer-Kommunikation. Es ist heute teil moderner Browser, und kann so von Websites für Kommunikationsdienste wie Videochat eingesetzt werden. WebRTC wird daher von vielen Videochatanbietern eingesetzt.

WebRTC definiert nur einen verschlüsselten Übertragungsmodus. Ob dieser für eine Ende-zu-Ende Verschlüsselung von einer Kommunikationspartei zur anderen eingesetzt wird, oder nur als Transportverschlüsselung zwischen einem Browser oder einer App und einem Back-End Webserver, hängt von der implementierung ab.

Im Github Repository ist ebenfalls eine Anleitung zur manuellen Installation verlinkt, die einen Eindruck von den eingesetzten Komponenten und ihrer jeweiligen Rolle vermittelt. Kern von Jitsis Videokonferenzsystem ist demnach die Jitsi Videobridge, eine Softwarekomponente, die für das korrekte Weiterleiten von Audio- und Videostreams zur korrekten Empfängerin zuständig ist. Dies ist laut Jitsi die Ursache für das fehlen von Ende-zu-Ende Verschlüsselung.

Bei der Verwendung einer Jitsi Meet Instanz, welche durch einen dritten Betreiber zur Verfügung gestellt wird, ist auf dessen Datenschutzregelungen zu achten. Durch die Konfiguration der Instanz könnten kompromitierende Einstellungen vorgenommen werden. Des weiteren ist es dem Betreiber möglich, auf den selbst gehosteten Jitsi-Webseiten Tracking wie z.B. Google Analytics einzubauen. Es ist nicht vorgesehen, einen direkten Dateiaustausch zwischen Teilnehmern durchzuführen. Jitsi versteht sich diesbezüglich als reines Videochatwerkzeug und sieht keinen Bedarf für diese Funktion.

Fazit

Es war uns möglich, innerhalb einer Stunde einen guten Überblick über Jitsi und seine Funktionsweise zu gewinnen. Mehr als bei vielen anderen Anbietern, haben wir auch die serverseitige Infrastruktur verstehen können. Leider finden sich wenige dieser Informationen auf der Startseite. Wie bei vielen Open-Source Projekten, wird Jitsi durch seine Quellcode Repositories dokumentiert. Diese sind allerdings mit umfangreichen Readme und Wiki-Einträgen versehen, die es technisch vorgebildeten Nutzer*innen ermöglicht, die Funktionsweise von Jitsi schnell zu verstehen.

Jitsi kommuniziert offen auch die Schwächen des eigenen Ansatzes, insbesondere die fehlende Ende-zu-Ende-Verschlüsselung und grenzt einzelne Anwendungsfälle (z.B. 1:1- und Gruppencalls) voneinander ab. Jedoch mussten wir uns, ähnlich wie bei anderen Anbietern, viele Informationen erst zusammentragen. Auf den Projektseiten konnten wir z.B. keine Angaben zur maximal unterstützten Teilnehmeranzahl im Untersuchungszeitraum finden. Jedoch konnten wir dank der hervorragenden Dokumentation der Repositories sehr einfach und schnell eine eigene Test-Jitsi-Instanz aufsetzen und einen Einblick z.B. in das Logverhalten und den Ressourcenverbrauch erhalten.

Durch ein Selbstverständnis als Anbieter einer freien Open-Source Softwarelösung für den individuellen Einsatz und nicht als Dienstanbieter, hebt sich Jitsi von allen anderen bisher betrachteten Werkzeugen ab.​​​​​​ Trotzdem ist die Software gut genug dokumentiert, dass alle wichtigen Informationen zu finden waren.​​​​​​​ Betrachtet man Jitsi-Meet, wird der klare Fokus des Projektes auf Videokonferenzfunktionen deutlich, so dass Aspekte anderer Dienste, wie beispielsweise Nutzer*innenverwaltung, Dateitransfer oder Kalenderintegration nicht vorhanden sind oder über zusätzliche Module eingerichtet werden müssen.