FSFE-Matrix-Server

[Roland Hummel]

Lieber Stefan,

On 10/8/19 10:25 AM, Stefan Kropp wrote:
> Meiner Meinung nach ist dies nicht korrekt. E-Mail haben sicherlich
> viele eingerichtet, da jeder E-Mail braucht. Es funktioniert auch eigentlich
> sehr gut. Threads, Subject und Quote sind wichtig für eine
> strukturierte Kommunikation und meiner Meinung nach nicht nur auf
> Mailinglisten.

ja, würde ich auch so sehen. Bei Instant Messaging geht das dann in die
Richtung, ob man in "vernünftigen" Blöcken antwortet
oder
aber so
wie einem die Enter-Taste gerade
so passt
.

> Ich kenne mich jetzt nicht so gut mit Messenger aus, versuche mich
> aber in XMPP einzuarbeiten. Matrix kenne ich gar nicht. Jedoch finde
> ich die Unterschiede der Protokolle sehr interessant. Ich halte Matrix
> für eine Alternative als ein Protokoll für Soziale Netzwerke, aber
> *nicht* als Instant Messaging Protokoll.

Uh, dann besser erstmal ausprobieren. Verwechselt Du hier *Ma*trix
eventuell mit *Ma*stodon? ;)
Ich will nicht ausschließen, dass der Einsatzzweck von Matrix in der
Roadmap der Entwickler langfristig mehr sein soll als ein Instant
Messaging-Protokoll, aber aktuell ist es in der primären Verwendung klar
ein Instant Messaging-Protokoll.

> Wenn ein Protokoll die "E-Mail" ersetzen soll (was bei mir im
> Bekanntenkreis schon lange der Fall ist), dann muss es ein seriöses
> Protokoll sein, wie auch immer es heißt (Whatsapp, XMPP, Matrix).

Was genau ist für Dich "seriös"?

> Um welche Schlüssel geht es? Soweit ich es verstanden habe, gibt es ja
> mehrere Schlüssel für unterschiedliche Verwendungszwecke, oder? Ist
> jedoch ein Schlüssel für eine Gruppenkommunikation auf dem Server in
> der Gruppe hinterlegt, dann ist es keine E2E Verschlüsselung sonder
> eine P2P Verschlüsselung, oder sehe ich das falsch? Ich hab den Link
> nicht mehr, aber soweit ich es in Erinnerung habe, wird die Nachricht
> mit einem Gruppenschlüssel verschlüsselt und nicht mit dem einer
> Person. Wie das alles im Browser funktioniert habe ich auch noch nicht
> verstanden und halte es deswegen erst mal als fragwürdig.

Ohne mich in der Tiefe damit auseinandergesetzt zu haben (bin eher ein
"Praktiker"): Es geht bei Matrix bzw. Riot tatsächlich um e2e-Schlüssel
für eine echte e2e-Verschlüsslung. Allein schon aufgrund der Tatsache,
dass der Matrix-Referenzclient "Riot" beim Ausloggen explizit dazu
auffordert, die privaten Schlüssel zu exportieren, spricht dafür. Der
Umstand, dass bei mehreren Usern in einem Raum (ganz wichtig: Matrix
unterscheidet technisch nicht zwischen 2er- und Gruppen-Chats - alles
findet in Räumen statt, egal ob da niemand, nur ein User oder mehrere
anwesend sind) bei aktivierter e2e auch bei jedem neu angemeldeten
Device eines Users (und ein Device kann eben auch eine Browser-Anmeldung
sein) eine entsprechende Warnung aufploppt, spricht gegen Deine Vermutung.
Das Speichern von Keys auf dem jeweiligen Matrix-Server betrifft meines
Wissens nach die Backup-Funktion der eigenen privaten Keys und ohne es
expizit nachgeprüft zu haben, ist dieses Backup verschlüsselt (denn beim
Aktivieren dieser Funktion muss man ein Passwort festlegen und es wird
explizit dazu aufgefordert, dass dies möglichst ein anderes sein soll
als das für die Matrix-ID).

> "We store and distribute the messages and files you share using the
> Service (and across the wider Matrix ecosystem via federation) as
> described by the Matrix protocol and according to the access rules
> configured within the system. Storing and sharing this content is the
> reason the Service exists."
> 
> Somit hat meiner Meinung nach die Sache bei Matrix eine ganz anderes
> Ausmaß als bei XMPP.

Korrekt - und das macht Matrix um Vergleich zu XMPP auch so fantastisch
ausfallsicher. Bei XMPP hängt die Funktionalität eines MUCs davon ab, ob
der hostende Server verfügbar ist. Bei Matrix hingegen ist ein Raum so
lange erreichbar und benutzbar wie min. ein Server eines im Raum
anwesenden Users erreichbar ist. Ich habe bspw. eine deutschsprachige
"Matrix-Admingruppe" gegründet: #synapse_de:matrix.org - diese
Raum-Adresse ist lediglich ein Alias auf eine eine, die in etwa
"#synapse_de:my.ddns.net" heißt und die ich hier nicht angebe, weil ich
nicht sicher bin, ob ich diese DynDNS-Adresse langfristig behalte, ist
aber wie gesagt auch egal, denn der Raum hat viele User, die eigene
Matrix-Server betreiben und die allesamt entsprechende Alias-Adressen
zur Hauptadresse hinzugefügt haben, sodass der Raum über eine Vielzahl
von Adressen erreichbar ist - und (und das ist der entscheidende
Unterschied zu XMPP) dies auch dann ist, wenn mein kleiner Heim-Server
down ist (Stromausfall, wöchentliches Wartungsfenster), denn Matrix, und
darauf spielt die von Dir zitierte AGB(?)-Stelle an, spiegelt Inhalte
über alle beteiligten Server. Das mag für manche Einsatzzwecke ein
Nachteil sein, ich sehe darin eine immense Stärke des Protokolls, denn
es macht Gruppenkommunikation unabhängig von der Erreichbarkeit
zentraler Instanzen und damit  föderaler.

> Bei XMPP suche ich den Betreiber aus oder lass einen eigenen Server
> laufen.

Dasselbe gilt für Matrix.

> Die Upload erfolgt nur aus dem eigenen Server und der Link
> wird dann den Kommunikationspartner zugeschickt. Dies kann auch per
> OMEMO erfolgen, bei dem die Verschlüsselung pro Device ist.

Dasselbe gilt ebenfalls für Matrix und in Bezug auf den Link, wenn beide
User ihre Matrix-ID auf dem selben Server haben. Haben sie ihre
Matrix-ID auf unterschiedlichen Servern, wird der Inhalt des Raumes (und
jeder Beitrag bekommt eine verlinkbare ID) auf beide Server gespiegelt.

> Ich habe
> da irgendwie einfach ein besseres Gefühl als bei der "cross the wider
> Matrix ecosystem via federation".

Kann man durchaus haben, wenn man sich mit den Nachteilen dieses
Ansatzes arrangieren will. Ich möchte es nicht, bspw. was die
Möglichkeit betrifft, spielend einfach Accounts zu wechseln und die
Inhalte des alten Accounts auf einen anderen Account zu übetragen: Ich
lade den neuen Account in einen bestehenden Matrix-Raum ein und der neue
Account zieht die Inhalte auf seinen Server. Umzug erledigt, ohne "bitte
adde mich neu unter dieser und jender Adresse"-Generve oder
Bckup/Import-Abende.

> Das ist genau der Punkt. Für ein soziales Netzwerk alles gut, jedoch
> nicht für ein Instant Messaging Protokoll. Es geht hier um den Schutz
> der Privatsphäre und nicht um "Features für den
> Ottonormalverbraucher". Ich würde dies gerne versuchen zu trennen.

Tut mir leid, aber mir scheint Deine Meinung noch sehr auf "Hörensagen"
zu basieren. Matrix bietet mir Riot eine e2e-Verschlüsslung, die auf dem
gleichen Verfahren basiert wie OMEMO und ist damit genauso gut oder
schlecht für den schutz der Privatsphäre geeignet wie dessen Einsatz in
XMPP. Ich sage "schlecht", weil mir der Ruf nach "sicheren Messengern",
seit WhatsApp das e2e-Verfahren von Signal übernommen hat, für das, was
eigentlich unser Anliegen sein sollte (nämlich *freie* Kommunikation zu
verbreiten), in eine argumentative Sackgasse zu führen scheint: "WA
verschlüsselt doch jetzt, wozu brauch ich denn dann noch deine
Messenger-Alternative, die eh niemand verwendet?" - > "sicher" bedeutet
eben nicht "frei" und eine echte Privatsphäre kann es nur auf Grundlage
freier Protokolle geben, nicht dadurch, dass erstmal eine sichere Krypto
bereitsteht. XMPP hatte hier über Jahre eine Vorreiterposition, die
(leider leider) nicht so ausgebaut wurde, dass sie die "Features für den
Otonormalverbraucher" (ob sie gerechtfertigt sind oder nicht) bieten
kann, Matrix hingegen schon (zumindest mit dem Client "Riot").

> Denn der Ottonormalverbraucher nutzt leider Whatsapp und ist
> glücklich. Leider ist dies wohl so und meiner Meinung nach nichts
> akzeptabel.

"Er/sie/User" ist glücklich, weil es einfach einzurichten ist und auf
jeder gängigen Plattform funktioniert. Das ist der Punkt, den XMPP in
seiner Entwicklung schlicht verpennt hat. Es gibt tolle Clients, aber
dann nur für eine bestimmte Plattform. Matrix hat hier mit "Riot" meiner
Erfahrung nach genau das richtige getan und einen Referenz-Client
bereitgestellt, der die Funktionalität des Matrix-Konzepts
plattformübergreifend unter Beweis stellt (ich hatte mehrere Monate
einen XMPP-Server im Betrieb, dessen praktischer Einsatz am Ende durch
die mangelhafte Client-Situation vor allem unter iOS scheiterte).

> Nebenbei bestehen wohl noch ganz andere Probleme:
> 
> "This means that your username will continue to be publicly associated
> with rooms in which you have participated, even after we have
> processed your request to be forgotten. We are actively working on a
> solution to work around this restriction and allow you to be fully
> forgotten while maintaining a high quality experience for other users.
> If this is not acceptable to you, please do not use the Service."
> 
> Gute Idee, dann lassen wir es besser erst einmal! :-)

Dann verrate mir doch mal, warum Du es eine gute Idee hälst, E-Mails zu
schreiben (denn ich nehme an, Du schreibst auch an Adressen/Listen,
deren Server außerhalb Deiner administrativen und auch juristischen
Reichweite liegen)?
Ich verstehe nicht, warum dieser Umstand bei Matrix ein Problem
darstellt, im E-Mail-Verkehr jedoch nicht.

> Aus meiner Sicht hat die Verwendung von Verschlüsselungen mit "Perfect
> Forward Secrecy" auch noch ein paar Nachteile. Weshalb ich immer noch
> für OpenPGP bin.

Ich bin kein Krypto-Experte, aber bietet OMEMO nicht auch "Perfect
Forward Secrecy"?

> Allerdings, wie oben schon angesprochen, kenne ich mich mit den Details
> auch nicht gut genug aus. Ich würde es aber auch mehr kritisch sehen
> und nicht jeden einfach Matrix empfehlen.

Ebenso solltest Du aus dem Grund, den Du faireweise selbst zugegeben
hast, aber auch nicht davon abraten, Matrix zu nutzen. ;)

> Die Community von XMPP ist wieder aktiver geworden. Neben
> Conversations und Gajim kommen neue Clients wie dino und Kaidan. Das
> Protokoll wird besprochen und versucht zu verbessern. iOS ist leider
> noch ein Problemkind. Aber sichere Kommunikation uns das Backup in der
> Cloud vom Hersteller passt für mich auch nicht so zusammen. 

Das ist schön (wirklich, denn eine faire (weil freie) Konkurrenz ist
immer gut). Wenn man XMPP (hoffentlich) irgendwann mit seinen
"Problemkindern" (denn es sind mehrere, nicht nur "iOS") zurechtkommt,
freue ich mich darauf, es wieder aktiver nutzen und empfehlen zu können.
Gruß
Roland
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : 0xBE135DCD5A22CEFB.asc
Dateityp    : application/pgp-keys
Dateigröße  : 7640 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20191008/9cde70bf/attachment-0001.key>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20191008/9cde70bf/attachment-0001.sig>