|
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!
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. Danach dann:
Matrix.org (die Foundation) 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 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.
Was viele nicht wissen: Die Matrix.org Foundation ist nicht ausschließlich für das Protokoll zuständig, sondern darüber hinaus insbesondere auch für Softwareprojekte, Infrastruktur und ihr gehören Copyright-Rechte (https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite) (extern):
Ihre Hauptaufgabe ist die Pflege der Matrix-Spezifikation, aber sie tut noch viel mehr als das.
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!
Ein für mich sehr wichtiger Punkt, denn deutsche Informationen zu Matrix sind rar und fast alles liegt nur auf Englisch vor:
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.
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.
Die allgemein gebotene Datensparsamkeit ist in Bezug auf unnötig gespeicherte Benutzernamen und Profilbildern in Anbetracht von teils riesigen Chaträumen schwer zu erreichen.
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)
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) - Einem Counterpunch-Artikel (extern; englisch) zufolge hat Amdocs beispielsweise Software für Abhörmaßnahmen und die Verfolgung von Telefonaufzeichnungen geliefert
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 <<.
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 …
… 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.
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.
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/war schon nach ein paar Jahren eine gewisse Fragmentierung festzustellen:
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.
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:
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?
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?
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.
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 …
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.
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).
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 …
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.
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.
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)
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)
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.
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) |
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.
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:
#matrixistsuper:matrix.org
wird von der Bridge in Richtung XMPP nicht verändert (so wie es auch richtig ist). Aber …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.”
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.
Auf der einen Seite wird mit Brücken zwischen den Protokollen Matrix und XMPP geworben - auf der anderen Seite wurde XMPP überhaupt nicht bei den Matrix-Brücken (extern) aufgeführt bzw. mit keinem Wort erwähnt. Zumindest nicht auf dieser wichtigen Seite. Der Kritikpunkt scheint jedoch angekommen zu sein: Bei einem weiteren Besuch der Seite im April 2024 habe ich festgestellt, daß nun auch das XMPP-Logo mit Link zur Beschreibung (extern) aufgeführt wird.
Um „XMPP“ zu finden, musste man vorher 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 wwurde. Erst auf der dort verlinkten Github-Seite stand bzw. fand man dann „XMPP“.
Es wird/wurde 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 wurden aufgeführt: IRC (6x), Slack, Gitter und XMPP In den Informationen zu den verfügbaren Brücken fand man auf Matrix.org (extern) jedoch kein Wort zum Standard XMPP, kein Logo und keinen Hinweis darauf (die Brücke war hinter “libpurple” unter “matrix bifrost” versteckt). Der Kritikpunkt scheint jedoch angekommen zu sein, denn Stand April 2024 ist das nicht mehr so. 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, wurden 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 fehlte somit die Brücke zum internationalen Standard XMPP, was auch in der dortigen Matrix-Grafik zum Ausdruck kam. (Stand April 2024 sind auf den Seiten von element.io überhaupt keine Brücken mehr zu finden.) Dort waren 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 konnte (was falsch wäre). Interoperabilität kann unterschiedlich gesehen werden. |
Von Libera.Chat wurden bezüglich der Matrix-Brücke verschiedene Punkte festgestellt, die sicherheitsrelevant bzw. datenschutzproblematisch waren. Hier die Zusammenfassung von Libera.Chat vom 10.08.2023:
Wir haben darum gebeten, das Portalling zu deaktivieren, da wir Bedenken bezüglich der Arbeitsbelastung durch Missbrauch, verschiedener Datenschutz- und Sicherheitsprobleme sowie der allgemeinen Stabilität hatten. Wir haben die vorübergehende Abschaltung aufgrund eines wiederkehrenden Datenschutzproblems veranlasst, bei dem Matrix-Nutzer, die nicht mit Libera.Chat verbunden sind, Kanalinhalte sehen konnten. Das Problem konnte nicht schnell behoben oder auf Opt-in-Kanäle beschränkt werden. Brücken von Drittanbietern sind nach wie vor willkommen und werden individuell beurteilt, wenn Bedenken auftreten.
Chronik zu Matrix’ Fehlverhalten gegenüber libera.chat und die dadurch verursachten Probleme im Jahr 2023:
07.06.2023 / Libera.Chat: Aktualisierungen auf der Matrix<>IRC-Brücke (extern)
”… Wir sind uns bewusst, dass die Libera.Chat Matrix<>IRC-Brücke (betrieben von Element Matrix Services, ‘EMS’) in letzter Zeit eine Reihe von Problemen hatte, darunter das stille Verwerfen von Nachrichten, das Abbrechen von Verbindungen und das Durchsickern von Informationen über die Existenz von +s (geheimen) Kanälen an Benutzer, die nicht in diesen Kanälen sind. …”
03.07.2023 / Libera.Chat: Abschaltung der Matrix-Portalisierung (extern)
”… Libera.Chat wird EMS auffordern, die portierten Kanäle zu deaktivieren, und zwar bis zum 31. Juli 2023, jedoch nicht vor dem 25. Juli 2023. Wenn die Deaktivierung der portierten Kanäle nicht möglich ist, wird Libera.Chat EMS auffordern, die gesamte Matrix-Brücke im gleichen Zeitrahmen zu deaktivieren.”
28.07.2023 / Libera.Chat: Verzögerungen bei der Matrix-Entportalisierung (extern)
”… In Anbetracht der Art der Probleme haben wir zugestimmt, die Frist bis zum 11. August 2023 zu verlängern, was zusätzliche zwei Wochen zur Verfügung stellt, um diese Probleme mit hoher Priorität zu beheben und die Situation zu verbessern. …”
28.07.2023 / Matrix.org: Verschiebung der Matrix-Entportalisierung von Libera.Chat (extern)
”… zum jetzigen Zeitpunkt kann der Plumbed-Modus jedoch noch nicht als ausreichend stabil angesehen werden. Außerdem wurden wir im Rahmen des Projekts auf mehrere neue Sicherheitsprobleme der Brücke aufmerksam gemacht. Diese Probleme müssen vor den Stabilitätsarbeiten an den angedockten (plumped) Chaträumen behoben werden, wodurch sich der Gesamtumfang des Projekts erhöht. Die begrenzten Ressourcen der Matrix.org Foundation erlaubten es uns nicht, den Termin rechtzeitig einzuhalten.”
(Hier sei die Frage erlaubt, warum Matrix.org als für das Protokoll zuständige, neutrale Organisation, Programmierarbeiten macht?)
05.08.2023 / Libera.Chat: Vorübergehende Deaktivierung der Matrix-Brücke (extern)
”… Um unsere Benutzer und unsere IRC-First-Communities vor zunehmenden Stabilitäts-, Sicherheits- und Datenschutzproblemen zu schützen, haben wir EMS gebeten, die Matrix-Brücke von Libera.Chat zu entfernen, bis diese schwerwiegende Regression behoben ist und alle anderen offenen Probleme ebenfalls gelöst sind. EMS hat zugestimmt, die Brücke bis Samstag, den 5. August, 1400UTC abzuschalten. …”
10.08.2023 / Libera.Chat: Matrix Bridge Temporary Shutdown, a Retrospective (extern)
”… Einige haben um Transparenz darüber gebeten, wie Libera zu dem Schluss gekommen ist, dass wir die drastische Maßnahme ergreifen müssen, Element Matrix Services (EMS) aufzufordern, die Türsteher-ähnliche Funktion der Matrix-Brücke zu deaktivieren und sie auf ausdrücklich zugelassene Räume zu beschränken, und dann zu einer ernsteren Maßnahme überzugehen, indem wir die vollständige Deaktivierung der Brücke fordern. …”
28.11.2023 / Matrix.org: Shutting down the Matrix bridge to Libera Chat (extern)
”… Leider müssen wir Ihnen heute mitteilen, dass wir nicht in der Lage sind, die Libera Chat-Brücke wieder online zu stellen. …”
”… Wer eine Bridge für seine Community benötigt, kann seine eigene betreiben: Die Software matrix-appservice-irc wird weiterhin gepflegt. Nur die Libera-Chat-Instanz, die so konfiguriert war, dass Verbindungen über Neustarts hinweg bestehen bleiben, wird abgeschaltet. …”
Ergänzende Informationen: https://libera.chat/guides/matrix (extern)
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.
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:
Und: Die damals bemängelte Fragmentierung findet nun auch schon bei Matrix statt, so wie das beidezentralen Systemen ganz natürlich ist.
Matrix ist eine sehr gute Lösung für verteilte Arbeit IN (aber nicht zwischen!) Organisationen, Unternehmen oder Behörden! Im Gegensatz zu manch anderer Groupware wie z.B. Slack ist der komplette Quellcode offen und somit überprüfbar. Interoperabilität ist meiner Meinung nach bei Matrix nicht durch offene Föderation mit anderen Matrix-Instanzen möglich, sondern lediglich durch die Verwendung der Schnittstelle zu Chatstandard XMPP.
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:
… 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.
Auch wenn evtl. manche Punkte in den folgenden (kritischen) Artikeln in der Zwischenzeit behoben sind, dürfen diese dennoch nicht als Ganzes verteufelt werden:
koehntopp.info: The Matrix Trashfire (extern)
Der Co-Founder von Matrix ist auf den Artikel bei lobste.rs (extern) eingegangen.
telegra.ph: Why not matrix? / 2023 (extern)
Zu deren Punkt 11 und 12: Diese müssten sich mittlerweise lt. Matrix-Spezifikationen (ab Raum-Version 6) erledigt haben, wurde in einem Forum berichtet. Hier würden mich konkretere Informationen interessieren. Bei Sachkenntnis gerne melden: >> Kontakt <<
Zu deren Punkt 17: Ein Ausschalten des Servers reicht tatsächlich nicht; das ist lt. Spezifikation aber so gewollt. Ein Raum kann jedoch in einer Föderation durch den Admin des Raumes (oder dessen Serveradmin) geschlossen werden - entweder durch das Kicken aller Personen im Raum oder dem Entziehen der Berechtigungen. Alle wohlgesonnenen Server, die föderieren, werden das respektieren.
cr-online.de: Fehler in der Matrix / 2022 (extern)
nuegia.net: Why I don’t use Matrix / 2020? (extern)
hackea.org: Matrix? No, thanks / 2020 (extern)
Auf die Frage, ob es inhaltliche Rückmeldungen auf den Artikel gab, kam per E-Mail (31.03.2024⁄02.04.2024) folgende Antwort:
„Wir haben einige wenige Nachrichten dazu erhalten, die im Wesentlichen besagten, dass ihnen der Artikel nicht gefiel, aber keiner konnte beweisen, dass etwas falsch oder ungenau war.“ und
„Dem Bericht zufolge mussten Sie keine Unterhaltung oder einen Chatroom mit einem Benutzer von matrix.org zu haben, damit Ihre selbst gehostete Instanz all diese Mengen an Metadaten an matrix.org und vector.im zu senden, Ihre selbst gehostete Instanz hat sie ohnehin gesendet. Wir schreiben in der Vergangenheitsform, weil wir das wissen, vielleicht passiert es noch vielleicht passiert das auch heute noch, wir wissen es nicht.“
(maschinell aus dem Englischen übersetzt)
Gerne werden hier weitere korrigierende Hinweise mit aufgenommen! >> Kontakt <<
Datum: 14.06.2024
Rechte: CC BY-SA
Alle Artikel/Gedanken rund um das Thema Messenger: