Benutzer-Werkzeuge

Webseiten-Werkzeuge


diskussion_matrix

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
diskussion_matrix [29.10.2017 15:40]
PhilippRuess
diskussion_matrix [25.11.2017 10:56] (aktuell)
Johbra
Zeile 26: Zeile 26:
       *         Ich bin kein Rechtsfachmann und das ist keine verbindliche Rechtsauslegung,​ aber für mich als Laien sieht das so aus, als würden sie praktisch alles speichern und es bei Bedarf auch jeder staatlichen Stelle in den UK herausgeben (müssen).       *         Ich bin kein Rechtsfachmann und das ist keine verbindliche Rechtsauslegung,​ aber für mich als Laien sieht das so aus, als würden sie praktisch alles speichern und es bei Bedarf auch jeder staatlichen Stelle in den UK herausgeben (müssen).
       *         Bei Bedarf würden Sie die Firma und die Daten auch gerne verkaufen. Nettes Geschäftsmodell.       *         Bei Bedarf würden Sie die Firma und die Daten auch gerne verkaufen. Nettes Geschäftsmodell.
-      * **Anmerkung:​ Die Datenschutzerklärung ​beziehen ​sich auf die Nutzung von Riot.im als Home Server und gelten ​nicht für selbst gehostet Server**+      * **Anmerkung:​ Die Datenschutzerklärung ​bezieht ​sich auf die Nutzung von Riot.im als Home Server und gilt nicht für selbst gehostet Server. Sie gilt aber für den Identitätsserver (der die datenschutzrechtlich wesentlichen ​ Daten bekommt) und für die Apps aus dem AppStore. Hier müsste ein anderer Identitätsserver voreingestellt sein, um dieses Problem zu umgehen.**
  
   *     Die Verschlüsselung in der Web-App wird als "​beta"​ eingestuft. Das halte ich für eine grobe Beschönigung. Ein per HTTP/Server ausgelieferter kryptographischer Javascript-Code kann nicht sicher sein, weil es derzeit keine Möglichkeit gibt, die Code-Integrität von Javascript-Code browserseitig zu überprüfen (korrigiert mich, wenn ich falsch liege). Das bedeutet, dass man jede verschlüsselte Nachricht, die von der WebApp versendet wird, prinzipiell als unsicher einstufen muss, weil der Server jederzeit fehlerhaften kryptographischen Code ausliefern kann (beabsichtigt oder unbeabsichtigt durch Code Intrusion).   *     Die Verschlüsselung in der Web-App wird als "​beta"​ eingestuft. Das halte ich für eine grobe Beschönigung. Ein per HTTP/Server ausgelieferter kryptographischer Javascript-Code kann nicht sicher sein, weil es derzeit keine Möglichkeit gibt, die Code-Integrität von Javascript-Code browserseitig zu überprüfen (korrigiert mich, wenn ich falsch liege). Das bedeutet, dass man jede verschlüsselte Nachricht, die von der WebApp versendet wird, prinzipiell als unsicher einstufen muss, weil der Server jederzeit fehlerhaften kryptographischen Code ausliefern kann (beabsichtigt oder unbeabsichtigt durch Code Intrusion).
-  * **Anmerkung**:​ Die Verschlüsselung bezieht sich auf die Verschlüsselung von Räumen durch eine End-zu-End Verschlüsselung. Solange man den Server selber kontrolliert,​ ist eine Verschlüsselung nicht zwingend erforderlich. Die Transportverschlüsselung selber geschieht immer über SSL/HTTPS - ist also von diesem Problem nicht betroffen. Im Wesentlich kein großer Unterschied zu Mattermost, Rocketchat, Slack und Co.+  * **Anmerkung**:​ Die Verschlüsselung bezieht sich auf die Verschlüsselung von Räumen durch eine End-zu-End Verschlüsselung. Solange man den Server selber kontrolliert,​ ist eine Verschlüsselung nicht zwingend erforderlich. Die Transportverschlüsselung selber geschieht immer über SSL/HTTPS - ist also von diesem Problem nicht betroffen. Im Wesentlich kein großer Unterschied zu Mattermost, Rocketchat, Slack und Co. Für den Anwender wäre hier wichtig darauf hinzuweisen,​ dass bei Nutzung der Weboberfläche keine Ende-zu-Ende-Verschlüsselung besteht.
  
 Vorteile: Vorteile:
-  * +
   * Einfach aufzusetzender Server   * Einfach aufzusetzender Server
 +  * Push-Nachrichten funktionieren ohne dass die App im Hintergrund laufen muss (dafür aber Sammlung von Meta-Daten beim Push-Server).
   * Funktionierende Referenzclienten für iOS, MacOS, Linux, Windows, Android. Ein Sailfish/​Mer Client ist in Arbeit   * Funktionierende Referenzclienten für iOS, MacOS, Linux, Windows, Android. Ein Sailfish/​Mer Client ist in Arbeit
-  * Integrierte VoIP und Videotelefnielösung +  * Integrierte VoIP und Videotelefonielösung 
-  * Offenes Design - das "​bridgen"​ zu anderen Platformen ist nicht nur möglich, sondern vorgesehen. Es exitsieren ​Brücken zu IRC, XMPP-MUCs, Slack, Telegram uvm.. Das heißt man kann an Matrixdiskussionen auch mit einem völlig anonymen, über TOR getunnelten,​ IRC Clienten teilnehmen. +  * Offenes Design - das "​bridgen"​ zu anderen Platformen ist nicht nur möglich, sondern vorgesehen. Es existieren ​Brücken zu IRC, XMPP-MUCs, Slack, Telegram uvm.. Das heißt man kann an Matrixdiskussionen auch mit einem völlig anonymen, über TOR getunnelten,​ IRC Clienten teilnehmen. 
-  * Der Identitässever **kann** benutzt werden. Damit verläuft das Suchen nach Kontakten analog zu den bekannten Mechanismen bei WhatsApp und Co.+  * Der Identitässever **kann** benutzt werden. Damit verläuft das Suchen nach Kontakten analog zu den bekannten Mechanismen bei WhatsApp und Co. Ergänzung: Er sollte aber nicht benutzt werden. Hier ist der kritische Punkt.
  
  
 Meine Bewertung; TL;DR: Meine Bewertung; TL;DR:
  
-  *     Spannende Open-Source-Idee, ​mit dem zentralen Identitätsserver, der Datenschutzerklärung ​in den UK und der WebApp aber ein Datenschutz- ​und Sicherheitsfail+    ​Spannende Open-Source-Idee, ​die viele technische Probleme anderer Messenger löst. Mit dem zentralen Identitätsserver in den UK und der WebApp ​kann "out of the box" ​aber nicht sicher ​und datenschutzkonform gearbeitet werden
-      ​Für seriöse kirchliche (seelsorgerliche oder amtliche) oder betriebliche Kommunikation daher nicht verwendbar. ​(Anmerkung: Was ist "​seriöse kirchliche Kommunikation"​ - Anspruch der Platform ist ja nicht ein Angebot für betriebliche Kommunikation zu sein, sondern eine Alternative für die öffentliche Diskussionen wie WhatsApp und CO. ) +    * Für seriöse kirchliche (seelsorgerliche oder amtliche) oder betriebliche Kommunikation ​ist das Produkt bei dem aktuellen Stand (Dez. 2017) daher nicht verwendbar. 
-      Ausnahme: Man schließt ​WebApp-Nutzer aus, betreibt einen eigenen, in Deutschland lokalisierten Identitätsserver und liefert eine App aus, die nur diesen ​Server nutzt. ​Wäre aber viel Aufwand und auch eine ungünstige Insellösung:​ Die Identitätsserver sollten auch dezentral sein und bei Bedarf untereinander kommunizieren können(Frage: Auch ein dezentraler Identitässever wäre nicht geeignet - i.A. ist ja die Idee eines Identitätsservers Adressdaten öffentlich zugänglich zu machen, vergleichbar mit einem Telefonbuch - ich verstehe hier die Kritik nicht so richtig) +    Das könnte geändert werden: Man weist bei der WebApp ​deutlich auf den fehlende Ende-zu-Ende-Verschlüsselung hin (und deaktiviert die existierende Funktion), betreibt einen eigenen, in Deutschland lokalisierten Identitätsserver ​und Push-Server ​und liefert eine App aus, die nur diese Server nutzt. ​Das wäre aber relativ ​viel ArbeitAber vielleicht lohnende?
-  *     ​Insgesamt gibt es also noch deutliches Entwicklungspotential. :-)+
diskussion_matrix.1509288044.txt.gz · Zuletzt geändert: 29.10.2017 15:40 von PhilippRuess