DokuWiki

Dies ist eine alte Version des Dokuments!

Verschiedene LUKis testen gerade verschiedene Messenger, die angetreten sind, um die zentrale Marktherrschaft eines bestimmten zentralisierten, closed-sourced Messengers in Frage zu stellen.

Hier kommt meine Einschätzung des Matrix Protokolls bzw. seiner aktuellen Implementierung in Form von riot.im:

Matrix/riot.im:

• ist angetreten, das XMPP-Protokoll zu beerben und dessen Schwächen zu beheben
• will dezentral und mit dem Web und mobilen Geräten gut nutzbar sein
• bietet vielfältige Funktionen, inkl. Telefonie und AV-Konferenz
• bietet mit riot.im viele funktionsfähige Implementierungen auf unterschiedlichen Plattformen

Klingt also spannend.

Probleme:

• Ein dezentraler Server ist schnell aufgesetzt (gut!), aber die Entwicklerfirma hinter Matrix/Riot.im betreibt einen zentralisierten Identitätsserver. Ohne diesen Identitätsserver sind die Anwendungen imho nur einem eingeschränkten Nutzerkreis zugänglich (so wie IRC/XMPP), weil man die Nutzerkennung auf drittem Wege austauschen muss.

• Die Datenschutzerklärung sieht für meine Augen ganz übel aus:
  • „Information we collect about you: […] other information about your user activity to aid communication on the service: details of the rooms you participate in (name, topic, address, participant list, access permissions, and any other extensible data associated with that room), whether your user account is discoverable using which identifiers, optional public directory listing of your user identifiers and user trust/reputation data associated with your account;“
  • „We may also receive information about you made available to us through your client, including (where supplied by your client) user presence information (whether your client is currently active/idle/offline or other extensible presence data), user profile information (display name, avatar, encryption public key data, other extensible profile data), ‘typing notifications’ (whether you are typing a message in a given room or not), ‘read notifications’ (whether you have read a message in a given room or not), ‘push notification rules’ (which messages should trigger notifications, and how to notify you), ‘search history’ (which terms you have searched for). You may be able to limit the information about you that your client provides to us via the account settings in your client application.“
  • „We will store information for as long as it is necessary to provide the Service to you or as is required to meet any legal obligations.“
  • „We will generally only disclose your personal information with your consent, but in certain circumstances, we may need to, or believe it is appropriate to, disclose your personal information. More information on these limited circumstances are below:
  • · To comply with our legal obligations or to protect the interests of our users. […]
  • · With our third party suppliers. […]
  • · If VECTOR CREATIONS LIMITED is sold. […]“
  • Ich bin kein Rechtsfachmann und das ist keine verbindliche Rechtsauslegung, aber für mich als Laien sieht das so aus, als würden sie praktisch alles speichern und es bei Bedarf auch jeder staatlichen Stelle in den UK herausgeben (müssen).
  • Bei Bedarf würden Sie die Firma und die Daten auch gerne verkaufen. Nettes Geschäftsmodell.
  • Anmerkung: Die Datenschutzerklärung beziehen sich auf die Nutzung von Riot.im als Home Server und gelten nicht für selbst gehostet Server

• Die Verschlüsselung in der Web-App wird als „beta“ eingestuft. Das halte ich für eine grobe Beschönigung. Ein per HTTP/Server ausgelieferter kryptographischer Javascript-Code kann nicht sicher sein, weil es derzeit keine Möglichkeit gibt, die Code-Integrität von Javascript-Code browserseitig zu überprüfen (korrigiert mich, wenn ich falsch liege). Das bedeutet, dass man jede verschlüsselte Nachricht, die von der WebApp versendet wird, prinzipiell als unsicher einstufen muss, weil der Server jederzeit fehlerhaften kryptographischen Code ausliefern kann (beabsichtigt oder unbeabsichtigt durch Code Intrusion).
• Anmerkung: Die Verschlüsselung bezieht sich auf die Verschlüsselung von Räumen durch eine End-zu-End Verschlüsselung. Solange man den Server selber kontrolliert, ist eine Verschlüsselung nicht zwingend erforderlich. Die Transportverschlüsselung selber geschieht immer über SSL/HTTPS - ist also von diesem Problem nicht betroffen. Im Wesentlich kein großer Unterschied zu Mattermost, Rocketchat, Slack und Co.

Meine Bewertung; TL;DR:

• Spannende Open-Source-Idee, mit dem zentralen Identitätsserver, der Datenschutzerklärung in den UK und der WebApp aber ein Datenschutz- und Sicherheitsfail.
• Für seriöse kirchliche (seelsorgerliche oder amtliche) oder betriebliche Kommunikation daher nicht verwendbar.
• Ausnahme: Man schließt WebApp-Nutzer aus, betreibt einen eigenen, in Deutschland lokalisierten Identitätsserver und liefert eine App aus, die nur diesen Server nutzt. Wäre aber viel Aufwand und auch eine ungünstige Insellösung: Die Identitätsserver sollten auch dezentral sein und bei Bedarf untereinander kommunizieren können.
• Insgesamt gibt es also noch deutliches Entwicklungspotential.