Gedanken

- Lesezeit: 38 Minuten -

Meinung/Kritik zu „Matrix“

Vorwort

Diese Gedanken beschäftigen sich nicht mit der in der Tat großartigen Funktionsvielfalt von Matrix-Clients oder anderen Vorteilen - sondern sollen vielmehr dazu anregen, sich mit mit verschiedenen Themen auseinanderzusetzen und vorgebrachte Argumente bewusster wahrzunehmen und auch mal zu hinterfragen. Sie spiegeln meinen persönlichen Eindruck zum „Matrix-Hype“ und meine private Meinung dazu.

Allerdings habe ich keine in Stein gemeißelte Meinung sondern sehe das als Entwicklungsprozess. Deshalb auch hier nochmals die ausdrückliche Bitte um kurze Information, wenn jemand veraltete Informationen oder Fehler findet!

Das Matrix-Protokoll wird oft als die Lösung im Mittelpunkt des Chat-Universums gesehen und als solche verkauft, mit deren Hilfe Interoperabilität erreicht werden könnte. Das sehe ich nicht so.

Matrix ist kein Heilsbringer für Interoperabilität sondern Teil des Interoperabilitäts-Problems selbst. Aber Matrix-Installationen können die dringend notwendige Interoperabilität unterstützen, wenn die vorhandene Schnittstelle zum internationalen Standard im Bereich Chat auch tatsächlich in der Praxis freigeschaltet wird und genutzt werden kann.

Die Erfahrung aus vielen Gesprächen zeigt, daß oft etwas aufgeschnappt wird und so (oder so ähnlich) einfach in einem anderen Kontext weitergegeben wird - ohne davor die Äußerungen zu hinterfragen. Dadurch entsteht dann ein falsch positiver Eindruck oder es gibt Mißverständnisse.

Vor allem sind die nachfolgenden Punkte der Grund für meine Antwort auf die oft an mich gestellte Frage, wie ich zu Matrix stehe - denn: Ich bin zwiegespalten!

Kritikpunkte

Die Presse- und Lobbyarbeit im Matrix-Umfeld ist beneidenswert gut und clever - und vielleicht war es exakt das, was mich dazu gebracht, genauer hinschauen:

… sind die Punkte, da mir aufgefallen sind. Ob und wie man diese für sich als relevant bewertet, bleibt jedem selbst überlassen.

Neutralität

Matrix.org ist sehr eng mit der Firma (den Firmen) New Vector verbunden. >> mehr << Seitens der Matrix.org Foundation wird hier auch offen darauf hingewiesen: https://matrix.org/foundation (extern)

Die Matrix.org Foundation wurde genau mit dem Zweck der Unabhängigkeit - auch von New Vector Ltd. - gegründet, um eine unabhängige Instanz die Spezifikationen des Matrix-Protokolls zu haben. Diese Unabhängigkeit is so groß/wichtig, dass New Vector Inc. sogar in den offiziellen Regeln der Foundation explizit genannt wird:

to ensure there is continuity, but also neutrality, between the Foundation and New Vector Ltd.

Heißt das dann im Umkehrschluß, daß die Firma New Vector derart einflussreich ist, daß sie es namentlich in die „Rules“ schafft, um keinen besonderen Einfluss haben zu sollen? ‎ In den offiziellen Matrix-Foundation-Regeln ist festgelegt, daß die vorhandenen Personen (also zu Beginn die beiden Gründer) über Neubesetzungen entscheiden - und dabei auf Neutralität achten sollten was jedoch nicht nähers konkretisiert ist. Im Vergleich dazu sind die Regeln der IETF(XSF) bezüglich der Neutralität sehr deutlich: Es ist klar definiert, daß …

  • die Aktuere ihre Arbeitgeber/Interessen benennen müssen,
  • der Anteil eines Arbeitgebers nicht größer als x sein darf und
  • das Council/Board ansonsten von den Mitgliedern frei gewählt wird.

Die Art und Weise der Neutralität kann und sollte prinzipiell auch ein Kriterium für sowohl kommerzielle als auch staatliche Entscheider sein. Auch wenn diese Dinge aktuell völlig im Matrix-Hype untergehen und keine Beachtung finden.

Finanzierung/Lizensierung

Ist Matrix gefährdet?

Eng mit der Neutralität verbunden ist die Ende 2022 in einem Blog-Artikel bei Matrix.org (extern) veröffentlichte Aufforderung, sich an der teuren Entwicklung (von was konkret?) zu beteiligen.

Allerdings ist nach dem Lesen des Artikels nicht ganz klar, ob das Protokoll „Matrix“ (es gibt keinen Krypto-Messenger „Matrix“!) an sich gefährdet ist, oder ob „lediglich“ die Softwareschmiede/der Dienstleister „Element” (New Vector) in Finanznot ist. Da wird einiges miteinander vermischt.

Im Originalblog von matrix.org steht (maschinell übersetzt):

… Wir haben sogar das Gegenteil erlebt: Kommerzielle Anbieter fälschen das Protokoll und versuchen, das Kernteam aufzulösen. Matrix-Ausschreibungen gingen an “bevorzugte” Anbieter verloren, die absolut nichts über Matrix wissen. Anbieter, die Matrix-Hosting oder -Dienste verkaufen, ohne überhaupt etwas zum Projekt beizutragen. Organisationen mit riesigen Geldbeträgen (Regierungen, $$B-Massivunternehmen) haben mit Begeisterung proprietäre Matrix-Lösungen auf den Weg gebracht, indem sie auf den frei lizenzierten Apache-Referenz-Matrix-Implementierungen aufbauen - und nichts zum Projekt beitragen. …

Hoppla! Harte Worte.
Erst als Matrix.org ein freies Protokoll anpreisen - und sich dann bei/für Element über die selbst gewählte Lizenzierungsart beschweren?

Daß es bei kommerziellen Implementierungen evtl. keine Spenden und keine Zusammenarbeit gibt, ist bei der gewählten Lizensierung logisch. Man muß damit rechnen und sollte weder jammern noch mit Forderungen auftreten. Es scheint, daß die deutliche Aufforderung zur finanziellen Beteiligung tendenziell als Finanzspritze für die Entwicklerschmiede verstanden werden soll. Eine Klarheit, für welche Zwecke Gelder gefordert/verwendet werden, wäre schön.

… Element sei jetzt buchstäblich nicht mehr in der Lage, “die gesamte Matrix Foundation im Namen aller anderen zu unterhalten” …
… noch durch indirekte Unterstützung in Form von Zusammenarbeit mit dem Ableger Element, über den aktuell Matrix maßgeblich vorangetrieben werde. …

Das ist zu hinterfragen, denn die im Artikel zu Ausdruck gekommene Vermengung von Matrix (Protokoll) und Element (Software & Dienstleistungen) bzw. diese „Querfinanzierung” durch Element ist nicht unproblematisch: Wo bleibt die gewollte Unabhängigkeit?

Wurde nicht gerade deshalb die Stiftung gegründet, die sich doch unabhängig um die Fortentwicklung des Matrix-Protokolls kümmern soll?

Größere Summen von Risikokapital wurden sowohl in Matrix.org als auch Element gesteckt. Insofern scheint es, daß sowohl die 5 Millionen Risikokapital als auch weitere zig Millionen Dollar Investment von Element („Element has put tens of millions of dollars into Matrix”) aufgebraucht sind …

Zum Glück sind internationale Standards wie IMAP oder XMPP nicht genauso von einzelnen Geldgebern und Risikokapital abhängig.

Fazit: Egal ob matrix.org oder element.im (New Vector): Man sollte nicht unter Apache lizensieren und sich hinterher beklagen!

Übersetzung

Ein für mich sehr wichtiger Punkt, denn deutsche Informationen zu Matrix sind rar und fast alles liegt nur auf Englisch vor:

  • Weder die Seite von Matrix.org (extern)
  • noch die Seite von Element (extern) ist deutschsprachig.

Eine wichtige Frage hierzu ist: Sind englischsprachige AGB im deutschsprachigen Raum (D/A/CH) ausreichend bzw. wo sind deutsche AGB (=Allgemeine Geschäftsbedingungen) der beteiligten Firmen/Organisationen (New Vector Limited, New vector SARL, ELEMENT SOFTWARE INC. und The Matrix.org Foundation) zu finden?

Auch zur Lizensierung findet sich auf der Seite von matrix.org (extern) sehr wenig und noch weniger auf Deutsch:

The Matrix protocol is licensed by the Matrix Foundation which makes it available to third parties who set up their own homeserver.

Datenschutz/Privatsphäre

Matrix wurde nicht mit dem Fokus auf Datenschutz entwickelt (vermutlich ist das auch der Grund für die vielen Insellösungen und die Nicht-Nutzung der Schnittstelle zu standardisiertem Chat (XMPP). Es wird auch nicht damit geworben, daß Nutzer die volle Kontrolle über ihre Kommunikation behalten - statt dessen ist der Vorteil lt. Matrix:

There is no single point of control or failure in a Matrix conversation which spans multiple servers: the act of communication with someone elsewhere in Matrix shares ownership of the conversation equally with them.

Quelle: Privacyhandbuch (extern)

Merkwürdigerweise wird genau der Punkt Datenschutz als Argument aufgeführt, um geschlossene Matrix-Instanzen zu rechtfertigen und um keine Schnittstelle nach außen (=Interoperabilität) haben zu müssen. Aus einer E-Mail auf Landesebene:

…, was von uns aus datenschutzrechtlichen Gründen ausdrücklich nicht gewünscht ist.

Auf die Frage nach einer Konkretisierung der angeblichen Datenschutzbedenken bekommt man jedoch trotz gezielter Nachfragen von keiner Firma und keiner Behörde eine Auskunft. Es kann nicht begründet werden.

Querverweis: öffentliche Vorbildfunktion.

Das Grundkonzept von Matrix ist die Replizierung von Chaträumen (auch 1:1-Chats) auf alle am jeweiligen Chat beteiligten Server. Und genau das führt nicht nur zu höherem Ressourcenverbrauch (s.u.), sondern ist auch bei öffentlicher Föderation datenschutztechnisch problematisch. Vermutlich müsste der Auftrag zur Datenverarbeitung jeweils erweitert werden, was praktisch kaum möglich ist. Eine Lösung hier ist nur, bei der Kommunikation mit anderen Systemen auf standardisierte Schnittstellen zurückzugreifen, die keine Replizierung von Datenbanken erfordern.

Datensparsamkeit

Die allgemein gebotene Datensparsamkeit ist in Bezug auf unnötig gespeicherte Benutzernamen und Profilbildern in Anbetracht von teils riesigen Chaträumen schwer zu erreichen.

Identitätsserver

Eigentlich, so erklärt uns Matrix-Mitbegründer Matthew Hodgson im Gespräch, sollten die Matrix-IDs nach außen gar nicht mehr sichtbar sein. Stattdessen sollen Nutzer neue Kontakte über bekannte Merkmale wie etwa die E-Mail-Adresse finden können. Bereits jetzt ist es möglich, die eigene Matrix-ID freiwillig mit einer E-Mail-Adresse zu verknüpfen. Später sollen auch Telefonnummern oder andere bekannte Merkmale wie Skype- oder Facebook-Namen hinzukommen.

Allerdings ist das Zusammenführen solch sensibler Informationen in einem föderierten Netz wie Matrix eine (datenschutz-)technische Herausforderung. Aktuell speichert Matrix die mit den Matrix-Konten verknüpften Informationen auf einem zentralen Identity-Server. “Das ist ein Desaster”, sagt Hodgson. In einem föderierten Netz “solltest du nicht dazu gezwungen werden, einem zentralen ID-Server zu vertrauen”.

Hodgson und sein Team seien auf der Suche: “Wir müssen das in diesem Jahr lösen”. Angedacht ist demnach ein hierarchischer Ansatz, ähnlich der Funktionsweise des Domain Name Systems (DNS). Eine schnelle Lösung des Problems scheint aber eher unwahrscheinlich, denn das Matrix-Team ist mit drängenderen Arbeiten beschäftigt: Aktuell werden die Identitätsinformationen des zentralen Servers noch nicht einmal gehasht.

Quelle: golem.de (extern)

Amdocs

Die Firma Amdocs ist Matrix’ Vater/Mutter: „The initial project was created inside Amdocs …“ (extern; Wikipedia)

In 2016,[20] a subsidiary of Amdocs was created, named “Vector Creations Limited”, which employed the team working on the Matrix protocol and software.[21] Funding by Amdocs was announced to be cut in July 2017, leading to the Matrix core team creating their own UK-based company, “New Vector Limited”.

Quelle: https://en.wikipedia.org/wiki/Matrix_(protocol) (extern; englisch - auf der deutschen Wikipedia-Seite ist die Verbindung zu Matrix nicht ersichtlich und viele Informationen fehlen dort)

Amdocs hat über 26.000 Mitarbeiter und erstellt in ca. 85 Ländern und für mehr als die Hälfte der Weltbevölkerung die Mobilfunkabrechungen. Das heißt, sie wissen seit den 80er-Jahren wer mit wem Kontakt hat, wie oft, wie lange und zu welcher Uhrzeit … das sind Metadaten.

Auch nach 2017 gab es Kontakte zu Amdocs. So war Matthew Hodgeson im August 2020 zu Gast bei Avishai Sharlin (Division President of Amdocs Technology) und es gab einen Podcast

Weitere Infos: - Informationsblatt von Amdocs zu Amdocs (extern; englisch; PDF)

Gesammelte Kommentare

Unendliche Speicherung < (hier klicken zum Öffnen des Abschnitts)

Hinweis: Es ist so, daß Datenbanken zumindest vom jeweiligen Server-Administrator aufgeräumt werden können.

Eine Meinung zu privaten bzw. teilprivaten IRC-Räumen

If the irc channel is intended to be private then I’m sure it’s best not to bridge to matrix. Heads up if you have a semi-private IRC channel with bridged #Matrix users in it. Once the channel logs arrive at the Matrix server hosting the bridge, every Matrix user can join this channel and the Matrix sever will happily provide the complete channel logs without anyone on the IRC side ever noticing. (tested with matrix.org & freenode) This is a HUGE privacy concern and I don’t understand why anyone would consider using Matrix.

Hier würde mich interessieren, ob das tatsächlich so ist >> Kontakt <<.

Blinde Empfehlungen

Das Kommunikationssystem „Matrix“ mit dem Referenzclient Element wird vermehrt bei großen Einheiten (Organisationen, Verwaltungen, Firmen) als Alternative zu proprietären (geschlossenen, firmeneigenen) Systemen eingesetzt oder es bestehen Überlegungen hierzu. Das ist an sich nichts besonderes, denn der Trend geht hin zu quelloffenen Systemen für Arbeitsgruppen, die unbestritten Vorteile haben.

Oft wird der Umstand „Sogar Organisation XY nutzt Matrix“ als (blinde) Empfehlung verstanden, ohne die Hintergründe oder Zusammenhänge zu kennen. Aber außer matrix(.org) sind fast alle wirklich großen Instanzen wie …

  • „BW-Messenger“ (Bundeswehr)
  • „Tchap“ (Französische Regierung/Verwaltung)
  • „TI-Messenger“ (gematik) oder auch
  • viele (nicht alle!) Instanzen im Bildungsbereich

… für eine rein interne Kommunikation und so konfiguriert, daß keine öffentliche Föderation erlaubt ist. Ganz zu schweigen von einer echten Interoperabilität, denn theoretisch mögliche Brücken zu anderen Systemen wie beispielsweise dem Standardprotokoll „XMPP“ sind/werden in der Praxis oft nicht aktiviert.

Interoperabilität ist so nicht möglich. Und von blindem Vertrauen bei solchen Empfehlungen ist abzuraten - es ist Eigenverantwortung gefragt.

Kein Internetstandard

Das Matrix-Protokoll selbst gehört der Matrix.org-Foundation (extern) und ist lediglich eine offengelegte Schnittstellenbeschreibung. Matrix ist kein durch die IETF (extern) geprüftes, legitimiertes oder standardisiertes Protokoll. Die Matrix.org-Foundation lizensiert das Protokoll an andere:

The Matrix protocol is licensed by the Matrix Foundation which makes it available to third parties who set up their own homeserver.

Quelle: Matrix.org Homeserver Privacy Notice (nur englisch)

Ob/wann der Standardisierungsprozess angestoßen wird, ist aktuell nicht bekannt. Es gibt jedoch eine in der Zwischenzeit relativ gut funktionierende Schnittstelle zum Chat-Standard „XMPP“, was als Brücke bezeichnet wird.

Etwas seltsam dazu ist folgende Selbsteinschätzung von Matrix.org:

„… abschließendes positives Fazit: matrix.org/foundation ist eine ziemlich solide Stiftung (hah) in Bezug auf die Führungsstruktur - wir schützen das Protokoll so weit wie möglich vor Sabotage durch unser zukünftiges Ich (oder irgendjemand anderen).“

Quelle: https://twitter.com/matrixdotorg/status/1197297411300958208 (extern; maschinell aus dem Englischen übersetzt)

Die Kritik seitens Matrix am IETF-Standardisierungsprozess von XMPP wird nicht sachlich begründet. Es gibt ein paar IETF-RFCs, die den Kern des XMPP-Protokolls spezifizieren (und auch schon eine komplette Überarbeitung in 2011 hinter sich haben) - mit allen Garantien/Sicherheiten die das mit sich bringt. Plus dank der Modularität des Protokolls die XEPs, die das Protokoll beliebig dynamisch weiterentwickeln können und von der XSF, die nicht nur formal völlig unabhängig ist kontrolliert werden. Strukturell also die besten Voraussetzungen. Wenn vorhanden ist ein Internetstandard einer individuellen “REST-API” vorzuziehen. Darüber hinaus könnte die Matrix-Schnittstelle auch durch die IETF standardisiert werden … wenn man das wollte.

Monolithisches Protokoll

Matrix will alle für einen modernen Chat erforderlichen Funktionen in einem Protokoll vereinen. Es ist monolithisch. Technisch verzichtet Matrix auf Modularität (also auf das ‘X’ in XMPP). Damit soll eine Fragmentierung vermieden werden. Eigenes Zitat dazu von 2018:

Das Problem ist, dass heute ‘nötige Funktionen’ nicht denen der Zukunft entsprechen müssen - die Entwicklung geht weiter. Künftige Anwendungsfälle brauchen andere Funktionen und keiner weiß, wie in 5 Jahren der Bereich Sofortnachrichten aussieht. Dem Protokoll fehlen die Mechanismen, um es entsprechend anpassen zu können. Also wird es irgendwann aktualisiert und in der Folge wird es mit alten Servern Schwierigkeiten geben oder überhaupt nicht mehr funktionieren. Damit soll eine Fragmentierung vermieden werden. Das ist umstritten („illusorisch“). Im Gegenteil - es wird so viel schwieriger, die Fragmentierung in den Griff zu bekommen. Das Problem ist, dass heute ‘nötige Funktionen’ nicht denen der Zukunft entsprechen müssen; die Entwicklung geht weiter. Künftige Anwendungsfälle brauchen andere Funktionen und keiner weiß, wie in 5 Jahren der Bereich Sofortnachrichten aussieht.Dem Protokoll fehlen die Mechanismen, um es entsprechend anpassen zu können. Also wird es irgendwann aktualisiert und in der Folge wird es mit alten Servern Schwierigkeiten geben oder überhaupt nicht mehr funktionieren.

Der Ansatz, auf Modularität zu verzichten um keine Fragmentierung zu bekommen funktionierte zu Beginn wunderbar. Allerdings ist Stand heute (2022) schon eine gewisse Fragmentierung festzustellen:

  • Es sind Matrix-Server mit unterschiedlichsten Versionen (extern) sowie verschiedenste Clients im Einsatz.
  • Auch ein Beispiel dafür sind die sich immer wieder veränderten Spezifikationen für Räume, für die derzeit 9 verschiedene Versionen (extern), da sich Raumspezifikationen (wie erwartet) fortentwickeln.

Der angebliche Vorteil gegenüber dem Chatstandard XMPP von damals hat sich in Luft aufgelöst.

Flexibilität des Protokolls

Für moderne IM-Anforderungen ist das Matrix-Protokoll geeignet (es wäre ja auch schlimm, wenn nicht) - für andere Dinge jedoch wie das Internet der Dinge (IoT) oder neue Entwicklungen nicht wirklich. Also braucht es dafür separate Lösungen, was schade ist.

Föderation & Interoperabilität

Beim Matrix-Protokoll können verschiedene Matrix-Server miteinander föderieren, was gegenüber anderen quelloffenen Teammessengern ein großer Vorteil ist. Deshalb auch meine Empfehlung im Systemvergleich.

Durch die Föderation von Matrix-Servern wird eine Ausfallsicherheit bei Chaträumen erreicht. Wird bei Matrix von Föderation gesprochen, so können hierunter verschiedene Dinge gemeint sein:

  • Bei einer internen Föderation gibt es organisationsintern mehrere Server, die zwar verbunden sind, aber die nicht nach/von außen kommunizieren können.
  • Bei einer öffentlichen Föderation ist eine Kommunikation auch mit (von/zu) anderen Matrix-Anbietern möglich.

Es ist also immer wichtig zu hinterfragen, ob eine tatsächliche Kommunikation mit beliebigen Matrix-Instanzen (Föderation) möglich ist oder nicht!

Denn es ist festzustellen, daß in Werbeversprechen immer wieder auf Föderation (welche?) hingewiesen wird und angebliche Interoperabilität versprochen und fleißig damit geworben wird. Aber: Föderation ist nicht mit Interoperabilität zu verwechseln!

Dadurch hat man nicht nur eine große Matrix-Welt, sondern auch viele einzelne Matrix-Inseln, die für sich genommen eine tolle Lösung sind - aber eben nicht föderieren und somit nicht interoperabel sind. Das ist so, wie wenn man E-Mails nur betriebsintern versenden/empfangen könnte!

Interessant wird diese Konstellation, falls politisch eine zwangsweise Interoperabilität zur Pflicht gemacht würde (-> Sektoruntersuchung des Bundeskartellamts). Wie sieht es dann mit der öffentlichen Vorbildfunktion aus?

„Aber es nutzen doch so viele Matrix.“

Ja, unbestritten - aber nochmals: „Matrix ist nicht gleich Matrix“ und vor allem nicht von vornherein mit öffentlicher Föderation oder gar Interoperabilität gleichzusetzen. Geschlossene Matrixinstanzen tun der offenen Föderation anderer Installationen keinen Abbruch - genauso, wie es zum Teil auch extrem große, geschlossene Instanzen anderer Systeme gibt.

Vielmehr geht es hier um die Sensibilisierung, ob mit Matrix eine öffentliche Interoperabilität erreicht werden kann oder nicht. Denn das ist gerade für die Frage des Einsatzes bei öffentlichen Einrichtungen und in der Bürgerkommunikation ein wesentlicher Punkt.

Trägt die Matrix-Brücke zu standardisiertem Chat („Bifröst“) zu einer Interoperabilität bei Messengern bei oder nicht?

  • Theoretisch ja, denn so können Nachrichten übergreifend ausgetauscht werden.
  • In der Praxis werden jedoch sehr viele Matrix-Instanzen für eine rein interne Kommunikation und so konfiguriert, daß keine öffentliche Föderation erlaubt ist. Ganz zu schweigen von einer echten Interoperabilität. Theoretisch mögliche Brücken zu anderen Systemen wie insbesondere dem Standardprotokoll „XMPP“ sind/werden in der Praxis oft nicht aktiviert. Aus Ängsten, die nicht sachlich und konkret zu begründen sind?

Eine interne Matrix-Föderation bringt jedoch keine in der Politik geforderte Interoperabilität von Messengersystemen und hilft auch nicht beim Erreichen dieses Ziels.

Wenn beispielsweise Frankreich auch Nicht-Regierungsmitarbeitern anbieten würde, mit diesen zu kommunizieren (also mit Nutzern anderer Matrix-Server=Föderation), dann müssten die Matrix-Chatadressen konsequenterweise irgendwo kommuniziert und veröffentlicht werden: Auf einer Internetseite, auf Visitenkarten, in E-Mails, in Gesprächen, …
Da das nicht gemacht wird, hat das auch in der Praxis rein gar nichts mit öffentlicher Interoperabilität zu tun.

Theorie (das technisch Machbare sowie Marketingversprechungen) und Praxis (tatsächliche Servereinstellungen) laufen somit oft auseinander.

Freie Anbieterwahl

Eine freie Wahl des Anbieters ist seitens des Protokolls zwar ohne Probleme möglich - wird jedoch in der Praxis etwas eingeschränkt, da kleine Anbieter durch den erhöhten Ressourcenbedarf an Hauptspeicher, CPU und „Platten-“Speicher deutlich schneller an ihre Kapazitätsgrenzen kommen. Das Eigenhosting (das Betreiben eines eigenen Matrix-Servers) für Privatpersonen wird dadurch erschwert. Natürlich kann man eine private Matrix-Instanz auch auf einem Raspberry PI laufen lassen - aber gewisse Unterschiede gibt es doch …

Ressourcenbedarf

Ein Beispiel mit konkreten Zahlen (extern): Es ist ein Unterschied, ob für ca. 20 Nutzer 140 GB Datenbank und 4,5 GB Hauptspeicher benötigt werden (Matrix) oder für ca. 450 Nutzer nur 6 GB Datenbank und weniger als 400 MB Hauptspeicher (XMPP).

Weitere Beispiele mit konkreten Zahlen sind im Systemvergleich XMPP-Matrix zu finden.

Die einfachste Lösung für das Ressourcenproblem, das seitens Matrix derzeit mit „conduit“ (Beta-Status) (extern) versucht wird zu verbessern, ist die Einschränkung bei der Föderation. Um im Rahmen der vorhandenen technischen Möglichkeiten zu bleiben, werden deshalb manche Matrix-Instanzen nicht öffentlich betrieben.

Die realtiv hohen Anforderungen an die Hardware fördern die (öffentliche) Interoperabilität nicht.

Verschlüsselung

Auch bei Matrix ist es nicht so, daß das Protokoll eine Verschlüsselung vorschreibt (das wäre auch nicht sinnvoll). Statt dessen ist das eine Sache der Clients (extern):

This guide is intended for authors of Matrix clients who wish to add support for end-to-end encryption.

Trotzdem wird immer behauptet, bei Matrix wäre automatisch alles verschlüsselt. Das stimmt nicht.

Ein weiterer Punkt ist die fehlende Flexibilität bei den zur Verfügung stehenden Verschlüsselungsarten. Es gibt ausschließlich das gerätebezogene OLM/MEGOLM - benutzerbezogene Verschlüsselungsarten wie PGP sind als Alternative gar nicht möglich.

Anmerkung zu „gerätebezogen“: Matrix spricht von „device keys“ (extern) - was jedoch eigentlich client-keys sind (auf einem Gerät können mehrere Clients mit dem selben Chatkonto arbeiten).

Nutzerzahlen

Wie auch bei Telegram werden die Nutzerzahlen durch das Zählen ehemaliger und irgendwann einmal in Chaträumen vorhandener Nutzer immer größer. Sie sollten nicht mit Nutzern verwechselt werden, die aktuell gerade online sind. Die für Matrix-Chaträume angegebenen und teils riesigen Nutzerzahlen sind also mit Vorsicht zu genießen und zu hinterfragen, denn …

  1. Nutzer anderer Systeme zu denen gebrückt wird, werden einverleibt und finden sich in der „Nutzerstatistik“ von Matrix wieder (z.B. werden verbundene IRC-Nutzer als Teil des Matrix-Netzwerks gesehen)
  2. Auch vergißt ein Matrix-Server die ehemaligen Nutzer eines Chats nicht so einfach, sondern läßt diese weiter im Chatraum „vorhanden sein“ - obwohl diese gar nicht mehr online sind. Bei den Chaträumen werden also alle bisherigen Mitglieder (egal ob noch aktuell oder nicht) weiter mit aufgeführt - natürlich auch die unter Punkt 1 genannten Nutzer (die von über Brücken „angezapften“ Chaträumen anderer Systeme mal online waren). Das kann unter dem Gesichtpunkt von unnötig gespeicherten Benutzernamen und Profilbildern auch ein Datenschutzthema (Datensparsamkeit) sein.

Es werden also teilweise deutlich mehr Nutzer angezeigt als tatsächlich „vorhanden“ - und diese werden in der Folge dann auch oft als aktive Matrix-Nutzer interpretiert und als solche in Gesprächen „verkauft“.

„Anzahl der Nutzer“ ist nicht mit „Anzahl der aktuell angemeldeten Nutzer“ oder gar „Anzahl der Nutzer mit einem Konto bei Matrix“ gleichzusetzen!

„Bei Matrix sind öffentliche Chaträume viele größer!“

Oft wird gefragt „Gibt es in System X/Y denn keine Chaträume, die so groß sind wie bei Matrix?“ - Doch - aber dort werden einfach nur die Nutzer angezeigt, die aktuell im Chat anwesend sind. Trotzdem meinen manche, es wäre ein Qualitätsmerkmal, wenn Chaträume tausende schreibberechtigte Mitglieder hätten.

Electron

Es gibt keinen nativen Element-Desktopclient für Windows oder Linux.

Zur Erklärung: Wenn eine Anwendung „nativ“ läuft, wurde sie direkt für die Betriebssystemumgebung erstellt (Fachausdruck: kompiliert) und kann somit auch direkt vom Betriebssystem ausgeführt und interpretiert werden. Läuft eine Anwendung „nicht nativ“, kann sie nur in einem emulierten Modus (oder eben innerhalb einer Browserumgebung) ausgeführt werden.

Der Referenzclient Element für Desktop ist eine Electron-Anwendung und deshalb für manche ein (Un-)Sicherheitsfaktor. Die Anwendung ist in einen eigenen Browser eingebettet und müsste auch bei jedem Sicherheitsupdate des Browsers mit aktualisiert werden. Zudem benötigen Electron-Anwendungen mehr Speicherressourcen als native Programme/Apps. Das ist jedoch kein spezifisches Matrix-Phänomen sondern ist bei allen Electron-Anwedungen so.

Externe Dienste

Element.io bietet mit „Element Matrix Services“ die weltweit größte Hostingplattform für Matrix (Infrastruktur zum Hosten von Matrix-Instanzen) an. Für diesen Hosting-Service werden auch die externen Dienste Cloudflare und „AWS“ (Amazon Server) genutzt, die seitens Datenschützern in der Kritik stehen. Im Falle von matrix.org werden also AWS-Server genutzt, deren Domains hinter Cloudflare liegen. Auch bei jedem Dateiupload (auch von anderen Instanzen, sofern der Admin da die Voreinstellung nicht geändert hat), geht alles über element.io, wiederum auf AWS und hinter Cloudflare.

Kritiker meinen: Cloudflare ist die Pest des Internets. Keiner braucht es, aber alle verwenden es, weil sie glauben, dass sie es brauchen. (Aus einem Kommentar)

In der Tat kann man einen Widespruch darin finden, wenn ein auf Dezentralisierung angelegtes System wie Matrix im Hintergrund zentralisierte Systeme nutzt, die für Überwachungszwecke mißbraucht werden können und nicht dem EU-Recht unterliegen.

Privacy policy von Element: https://element.io/privacy (extern) unter „2.10 Who Else Has Access to My Data?“:

We host the Element Matrix Services on Amazon Web Services (AWS), specifically: Our admin server is hosted in an AWS data centre in Amsterdam; Our deployment server is hosted in an AWS data centre in Stockholm; Customer deployments have the option to select the geographical location which is the most convenient for them; We also host the Gitter.im app on AWS, in a datacenter based in the East of the US. Amazon employees may have access to this data. Here’s Amazon’s privacy policy. Amazon controls physical access to their locations.

We use Cloudflare to mitigate the risk of DDoS attacks. Here’s CloudFlare’s privacy policy.

Zu Cloudflare steht in der Dokumentation Integration Manager Privacy Notice (extern) unter „3.9 Who Else Has Access to My Data?“:

We host the majority of the Service in UpCloud data centres. Here’s UpCloud’s privacy policy. UpCloud controls physical access to their locations. We use Cloudflare to mitigate the risk of DDoS attacks. …

Anfragen auf Github zum Beenden der externen Dienstenutzung wurden mit dem Hinweis zur Verhinderung von DDoS-Attacken erledigt:

In der Dokumentation der Element Matrix Services EMS Server With Custom Domain (extern) wird die Nutzung des Verweises auf Cloudflare - der „report-uri“ - beschrieben.

Informationen dazu: https://www.kuketz-blog.de/the-great-cloudwall-weshalb-cloudflare-ein-krebsgeschwuer-ist/ (extern)
Viele gesammelte Infos: https://mypdns.org/dCF/deCloudflare/-/blob/master/readme/de.md (extern)

„VS-NfD“

Auch eine vermeintlich offizielle Einstufung des Matrix-Protokolls als sicheres Kommunikationsmittel ist ein Mißverständniss, das immer wieder auftaucht. Es geht dabei um „Verschlußsache - Nur für den Dienstgebrauch (VS-NfD)“. Im Privacyhandbuch wird versucht, hierüber aufzuklären:

Es kursiert das Gerücht, [matrix] wäre aufgrund sicherer Krypto vom BSI für klassifizierte Kommunikation der Einstufung VS-NfD in der Bundeswehr zugelassen. Das ist eine Legende bzw. irreführende Werbung, also Fake News. Für die Nutzung des bwmessenger gelten in der Bundeswehr die gleichen Regeln, wie für unverschlüsselte E-Mails.

Daraus abzuleiten, das Protokoll selbst wäre für “VS NfD” konzipiert/freigegeben oder besonders sicher ist falsch - auch wenn der Gedankengang nahe liegt. Wenn das so wäre, könnten die meisten (alle?) Inselsysteme als “sicher” eingestuft werden.

Quellen:
- Privacyhandbuch (extern)
- Pressemitteilung der Bundeswehr (extern)
- Information des BWI (IT-Dinstleister der Bundeswehr) vom 16.11.2021 (extern)

Brücken

Ganz allgemein gilt:
Werden zwei strukturell unterschiedliche Systeme durch Hilfskonstrukte wie Brücken verbunden, so summieren sich die Nachteile der beteiligten Messenger und die jeweils einzigartigen Vorteile werden in der gemeinschaftlichen Kommunikation verworfen.

Grundsätzliches

  1. Die Matrix-Bifröst-Brücke ist bisher noch nicht Über den Experimentalstatus (extern; 01.02.2023) hinaus gekommen („This bridge is in very active development currently and intended mainly for experimentation and evaluation purposes.“) - offensichtlich wird in anderen Brücken mehr Wertschöfpungspotential gesehen.
  2. Austausch nur über Matrix
    Matrix-Brücken sind lediglich Brücken von/zu Matrix - ein direkter Austausch zwischen anderen Systemen ist damit nicht möglich. Folglich sind Brücken also Teil des Interoperabilitätsproblems und nicht der Problemlöser (das Selbe gilt auch für Brücken (“Transporte”), die es bei XMPP gibt!).

Matrix-Grafik mit Matrix als zenraler Stelle, um für übergreifende Kommunikaition (=/= Interoperabilität) zu sorgen - worauf auch in entsprechenden Pressetexten (z. B. bei t3n.de (extern)) eingegangen wird.
Allerdings kann das Schaubild suggerieren, daß zwischen den Systemen und systemübergreifend ohne Probleme und in vollem Funktionsumfang kommuniziert werden kann (was falsch wäre).
Bildquelle: t3n.de (extern)

Rechtmäßigkeit und Zukunftssicherheit

Matrix wirbt damit, viele Brücken zu geschlossenen Messengerdiensten wie beispielsweise Discord, Facebook Messenger, Instagram, Signal, Threema, WeChat und auch WhatsApp zu haben: https://matrix.org/bridges (extern)

Dabei ist jedoch nicht klar, ob es mit den jeweiligen Eigentümern von zentralen Diensten (z.B. Facebook, Microsoft, Apple oder Google - um mal die großen zu nennen) überhaupt Verträge diesbezüglich gibt oder nicht. Denn andere Clients als den eigenen zu nutzen ist nicht erwünscht. Vielleicht lohnt sich hier ein Blick in die Allgemeinen Geschäftsbedingungen der jeweiligen Anbieter …!?

Wenn also Brücken zu zentralen Diensten als funktionierend angeboten werden, sollte das auch durch einsehbare und transparente Verträge des eigenen Dienstleister mit dem jeweiligen Zielsystem sichergestellt werden. Alles andere ist heiße Luft und nicht wirklich zukunftssicher.

In der Vergangenheit war es zumindest so, daß alle Brücken anderer Systeme, die beispielsweise zu WhatsApp oder zu Signal erstellt wurden, lediglich eine gewisse Zeit geduldet waren. Wenn die Nutzung zu intensiv wird und die Geschäftsinteressen zu sehr berühren, sind dafür angelegte Chatkonten schnell vom Anbieter gesperrt/gelöscht.

Bezüglich des Einsatzes von Brücken zwischen verschiedenen Messengersystemen gibt es kritische Stimmen wie die von Mike Kuketz (extern). Hier ist es jedoch vermutlich sinnvoll, kein pauschales Urteil abzugebenn, sondern zu hinterfragen, welche Art von Chat (Einzelchat, Gruppe oder öffentlich Chaträume) wie (per Föderation oder per Brücke) verbunden werden soll und ob sich in diesen jeweils unterschiedlichen Fällen tatsächlich datenschutzrechtliche Fragen/Probleme ergeben oder nicht.

Datenintegrität

Seit März 2022 verändert die die Matrix-Brücke (Bifröst) Inhalte und übersetzt neuerdings XMPP URIs (Adressen). Für mich ein absolutes “no-go”, denn das was beim Empfänger ankommt, entspricht nicht dem, was der Absender der Nachricht tatsächlich geschrieben hat. Inhalte von Nachrichten werden auf Matrix-Seite geändert angezeigt und in der Folge auch Zitate verfälscht. Ich finde das nicht gut - auch wenn das für Matrix-Nutzer “praktisch” erscheinen mag.

Ganz abgesehen davon, daß Nachrichten von einer Brücke nicht inhaltlich geändert werden sollten: Warum erfolgt die Änderung der Links in Nachrichten ausschließlich in Richtung der Matrix-Syntax und in der anderen Richtung wird keine Matrix-Adresse „übersetzt“ - warum?

Hier werden Aufgaben, die ein Client übernehmen sollte (optionale Anpassung in der Anzeige von Inhalten) von der Brücke übernommen. Verknüpfungen (Links) beinhalten bewußt das zu berücksichtigende Protokoll, was viele Gründe haben kann - unter anderem Sicherheit. Der Kontext von Nachrichten kann sonst inhaltlich total verfälscht werden.
Beispiele:

  • “Die Adressen xmpp-adresse und matrix-adresse betreffen unterschiedliche Systeme!” wird auf Matrix-Seite zu:
    “Die Adressen matrix-adresse und matrix-adresse betreffen unterschiedliche Systeme!”
  • “Wer administriert den Chatraum xmpp-chatraum?” wird auf Matrix-Seite zu:
    “Wer administriert den Chatraum matrix-chatraum?”
  • Beispiel:
    • Die Einladung auf Matrix-Seite #matrixistsuper:matrix.org wird von der Bridge in Richtung XMPP nicht verändert (so wie es auch richtig ist). Aber …
    • Aus der Einladung xmpp:testchatraum@conference.irgendeinserver.tls?join wird auf Matrix-Seite: https://matrix.to/#/#_bifrost_testchatraum_conference.irgendeinserver.tls:aria-net.org

Ein Entwickler der Bifröst-Bridge merkt dazu treffenderweise an, daß das lediglich meine Meinung ist:

Ich nehme an, das ist Ihre Meinung im Gegensatz zu anderen, die vielleicht tatsächlich XMPP benutzen und dafür entwickeln, z.B. https://github.com/matrix-org/matrix-bifrost/issues/308 (extern)

… und steht voll und ganz zu dieser „Funktionalität“: “Und dem stimme ich voll und ganz zu, daher die Änderung.”

Praktische Mängel

Insbesondere bei der Verbindung und dem Brücken von öffentlichen Chaträumen kommt es immer wieder zu Mißverständnissen und Problemen durch „im anderen Chatraum nicht angezeigte Nachrichten“. Grund dafür ist die fehlende Synchronisation der Berechtigungen. So werden weder die Rollen der Teilnehmer (Eigentümer, Moderatoren, Mitglieder, Teilnehmer) sowie auch blockierte und somt eigentlich ausgesperrte Chatadressen nicht automatisch gebrückt. Das ist schlecht.

Auch ist nicht ersichtlich, daß man sich quasi „als Gast“ im anderen System ist. Dadurch besteht ständig Verwechslungsgefahr, was mit „hier/dort im Chatraum“ gemein ist.

Unklare Positionierung

Auf der einen Seite wird mit Brücken zwischen den Protokollen Matrix und XMPP geworben - auf der anderen Seite wird XMPP überhaupt nicht bei den Matrix-Brücken (extern) aufgeführt bzw. mit keinem Wort erwähnt. Zumindest nicht auf dieser wichtigen Seite.

Um „XMPP“ zu finden, muß man unter „libpurple“ schauen, wo widerum auf „matrix-bifrost“ verwisen und der Hinweis “General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purposes.” gegeben wird. Erst auf der dort verlinkten Github-Seite steht bzw. findet man dann „XMPP“.

Es wird also teilweise mit Brücken zu XMPP geworben - aber Interoperabilität auf der Basis von internationalen Protokollen wird nicht aktiv verfolgt. Dieser vermeintliche Widerspruch resultiert vermutlich aus dem Geschäftsmodell.

Es erschließt generell auch nicht so einfach, warum unterschiedliche Brücken beworben werden oder im Einsatz sind - oder auch nicht.

Bei Matrix.org (extern) wird eine Brücke (trotz experimentellem Status) zu standardisiertem Chat betrieben - Stand April 2022 werden aufgeführt: IRC (6x), Slack, Gitter und XMPP
In den Informationen zu den verfügbaren Brücken findet man auf Matrix.org (extern) jedoch kein Wort zum Standard XMPP, kein Logo und keinen Hinweis darauf.
Quellen:
https://element.io/element-matrix-store#bridges (extern) oder
https://element.io/enterprise/matrix-bridging-services (extern) oder
https://element.io/matrix-services/hosted-bridges
(extern)
Wird die Hosting-Dienstleistung von element.io (extern) als weltweit größtem Matrix-Hoster in Anspruch genommen, werden Stand April 2022 dagegen folgende 8 unterschiedliche Brücken aufgeführt: WhatsApp, Slack, MS Teams, Signal, Gitter, Discord, Telegram und IRC. Auf der offiziellen Internetseite von Element.io fehlt somit die Brücke zum internationalen Standard XMPP, was auch in der dortigen Matrix-Grafik zum Ausdruck kommt.

Hier sind darüber hinaus auch noch Verbindungen zwischen dein einzelnen ‘Zielsystemen’ eingezeichnet (nebenstehend farblich deutlicher als im Original hervorgehoben), woraus man eine direkte Kommunikation zwischen diesen (und ohne Matrix in der Mitte) ableiten könnte (was falsch wäre).
Interoperabilität kann unterschiedlich gesehen werden.

Markdown

Markdown ist eine einfache Art, um Texte formatiert anzuzeigen und hervorzuheben - unter anderem auch zum Anzeigen von Verknüpfungen (Links). Im Chatstandard XMPP ist es nicht möglich, gefälschte Links zu erstellen, da es keine Möglichkeit gibt, explizit einen Formatierungscode aufzurufen, um einen Link zu beginnen und zu beenden. In Matrix dagegen hat man die Möglichkeit, gefälschte Links zu erstellen und man überlässt es der Client-Software zu entscheiden, was zu tun ist.

Beispiel:
Man stelle sich vor, man hätte ein Konto bei der Bank ‘XY’ und auch ein Matrix-Chatkonto. Eines Tages erhält man die Nachricht: „Unerwartetet Geldeingang auf Konto bei Bank XY - bitte prüfen: https://bankXY.tld” (gerne mal testen!)

Formatierte Texte per Markdown sind gut für Textdaten in einem Kontext, in dem man Zeit zum Lesen hat und etwas Zeit erübrigen kann, um auch den Link zu untersuchen. Aber für ein Kommunikationsmittel, das sich durch „sofort“ als Haupteigenschaft auszeichnet, ist es auf Protokollebene problematisch.

Gründe für Matrix

Die Entscheidung zu einem neuen Protokoll und der Entstehung von Matrix wurde 2012 durch verschiedene Argumente begründet. Diese Punkte hätten lt. Verfechtern von XMPP direkt auch am kritisierten Protokoll (XMPP) verbessert/ergänzt werden können, statt ein neues Protokoll zu kreieren:

… es ist besser, Bestehendes zu verbessern anstatt das Rad neu zu erfinden …

Investoren erwarten jedoch i.d.R. nach einer gewissen Zeit einen ROI (return of investment). Die Investitionen sollen sich natürlich lohnen und das ist bei der Verbesserung eines öffentlichen Standards nicht möglich.

Trotzdem haben sich viele Punkte beim damals (zu Recht) bemängelten Standard XMPP verbessert und „erledigt“ - obwohl keine Millionengelder geflossen sind:

  • Mehrere Geräte,
  • nutzbar auf mobilen Geräten,
  • mehrere Geräte sind möglich,
  • Verlaufsynchronisierung,
  • es gibt Brücken zu anderen Systemen

Und: Die damals bemängelte Fragmentierung findet nun auch schon bei Matrix statt, so wie das beidezentralen Systemen ganz natürlich ist.

Zusammenfassung / Fazit

Matrix ist eine sehr gute Lösung für verteilte Arbeit in Organisationen, Unternehmen oder Behörden! Im Gegensatz zu manch anderer Groupware wie z.B. Slack ist der komplette Quellcode offen und somit überprüfbar.

Das Standardprotokoll, das WhatsApp tatsächlich mittelfristig in der Breite ersetzen kann, ist aus heutiger Sicht und mit diesem Hintergrundwissen nicht das Protokoll Matrix sondern anbieterunabhängier Chat (auf der Basis des Standards XMPP).

Daß es eine Schnittstelle (Brücke) zu standardisiertem Chat gibt, ist jedoch ein großer Vorteil von Matrix, der nicht zu unterschätzen ist. Diese Schnittstelle sollte jedoch:

  • deutlicher kommuniziert,
  • unbedingt auch aktiviert,
  • an manchen Stellen noch verbessert,
  • ohne inhaltliche Änderungen an Nachrichten umgesetzt und
  • in der Praxis genutzt werden

… aus Sicht einer generellen Interoperabilität ist diese Brücke sogar wichtiger als die matrixinterne Föderation. Nicht durch eine öffentliche Föderation von Matrix-Servern sondern durch Aktivierung und Nutzung der wichtigen Brücke zu standarsisiertem Chat - also durch das Einhalten von internationalen Standards - wird tatsächliche Interoperabilität unterstützt und ermöglicht.


Weitere Meinungen


Ergänzende Informationen:

Datum: 01.02.2023
Rechte: CC BY-SA



Alle Artikel/Gedanken rund um das Thema Messenger: