Signal & Matrix
Immer wenn ich die Experten für cialtroprivacy herausfordere und sage, ich solle mich von Signal und Matrix fernhalten, denken die Leute, dass ich aus irgendeinem persönlichen Grund besonders wütend auf diese beiden Plattformen bin. Nun, nein. Ich habe es mit diesen beiden Plattformen aus bestimmten Gründen, nämlich dass sie sich als Alternativen bewerben, wenn sie authentisch gegenüber jenen Gafams sind, denen sie mit Worten entgegentreten wollen.
Signal als Alternative zu GAFAM zu verderben ist so einfach, dass ich mich nicht einmal darauf einlassen sollte, aber anscheinend können die Leute nicht auf die Website einer Plattform gehen und sich eine Idee machen (aber sie sind Experten für Online-Privatsphäre und "Alternativen-Ethik". "ist klar):
Dies ist also die Blockarchitektur des Systems, die Sie vor GAFAMs schützen und ihnen keine Daten geben soll:
Anscheinend würde es ausreichen, sich die beteiligten Akteure anzusehen, um zu verstehen, dass diese Plattform Sie vor allen außer der GAFAM verteidigen kann. Aber das ist nicht wirklich das Problem. Das Problem liegt nicht bei den Schauspielern oben ((Twilio, Apple, Google, Amazon S3), sondern bei dem, was ich unten sehe.
"Postgres, Redis". Okay. Schritte für Redis, die Daten nach einiger Zeit automatisch entfernen können. Ich mag es nicht, aber ich toleriere es. Aber Postgres?
Sie werden sagen: und warum ärgern Sie sich über Postgres? Auch ohne ein veraltetes Produkt, das in den 70er Jahren von einem ehemaligen IBM-Programmierer auf Acid entwickelt worden zu sein scheint, in Ungnade fallen zu wollen, ist das Problem einfach: „Was macht eine persistente Datenbank in einem Instant-Messaging-Produkt?“?
Ich weiß, dass Sie, wenn Sie kein Systemarchitekt sind, nicht erkennen, dass Architekturen über die Verwendung der Plattform "sprechen" und "sprechen", deshalb gebe ich ein Beispiel.
Stellen Sie sich vor, Sie nehmen Ihr Handy in die Hand und möchten Ihre Großmutter anrufen. Gehen Sie dann zum Telefonbuch, klicken Sie auf "Großmutter" und das Mobiltelefon sagt Ihnen "rufen Sie an, bitte starten Sie die Aufnahme der Stimme".
Und Sie sagen: „Nein, ich möchte das Telefonat nicht aufzeichnen, ganz im Gegenteil. Ich möchte nur mit meiner Großmutter reden“. Und das Handy: "Anruf nicht möglich, wenn der Anruf nicht aufgezeichnet wird".
Jetzt dauert es nicht lange, bis Sie erkennen, dass ein Mobiltelefon, das den Anruf und das Gespräch aufzeichnen muss, Sie ausspioniert – Sie brauchen zwei Dinge, um mit jemandem zu sprechen. Sie, jemand und eine Audioleitung. Es ist keine Aufzeichnung des Anrufs erforderlich, und ein Mobiltelefon, das dies anfordert oder erzwingt, ist DEUTLICH gemacht, um Sie auszuspionieren.
Kommen wir nun zu einem Signalserver. Ein Chat-System, oder IM, wie man heute sagt, ist nichts anderes als ein Multiplexer. Sie können den Anruf an eine Person oder an eine Gruppe weiterleiten, aber hier und jetzt arbeiten. Vielleicht ist es akzeptabel, dass er sich einige Zeit anstellt, aber mehr nicht.
Aber es gibt eine ganze Datenbank mit Persistenz dort. Was Daten speichert. Was ist das. Ding? Keine Ahnung, denn der Signal-Server ist seit etwa einem Jahr gesperrt:
und dann wieder online stellen:
Manuel Vonau 
Auch als Opensource fehlt es also an Transparenz.
Gehen wir zur Matrix. Um festzustellen, was mit der Matrix nicht stimmt, müssen wir ungefähr dasselbe tun: gehen und nachsehen, ob es eine Datenbank gibt. Denn wenn es eine Datenbank gibt, haben wir DEUTLICH einen Server erstellt, um Gespräche auszuspionieren.
Ist die Datenbank da? Es kann SQLite oder Postgres sein, und wenn Sie für einen Moment wissen möchten, was es tut, können Sie diese Suche durchführen:
Warum Warum muss etwas Multiplexing Zustände speichern? Schritte zur Authentifizierung von Benutzern, aber alles andere? Selbst wenn wir wollen, dass ein verdammter IM-Server eine temporäre Persistenz hat oder für einige Zeit Warteschlangen hält, ist ein Memcached oder eine Redis mehr als genug.
Aber hier umgehen wir die REALE Frage: Warum müssen wir ein IM-System von Grund auf neu entwickeln? Es gibt bereits alles, was Sie brauchen, um eine zu erstellen, indem Sie Schnittstellen zu jedem Warteschlangensystem entwerfen: RabbitMQ, NATS / GNATS, Kafka, Pulsar, Macrometa. MQTT…. es gibt viele davon. Sie müssen keine Warteschlangen- und Dispatching-Systeme schreiben. Alles, was Sie tun müssen, ist, die Schnittstellen zu schreiben und die Clients ihre Arbeit machen zu lassen.
Denn wenn wir über E2E-Verschlüsselung sprechen, erledigt der Client den Job. Okay, möchten Sie die Identität bestätigen? Sie benötigen einen Keyserver, aber es wäre besser, wenn der Client ein Adressbuch hätte. Auf jeden Fall braucht man im schlimmsten Fall einen NATS und einen Keyserver und ein paar tausend SLOCs. Der Kunde muss die Nachricht nicht mit dem öffentlichen Schlüssel des Empfängers verschlüsseln und dann die Nachricht mit seinem eigenen privaten Schlüssel signieren,
Möchten Sie Räume mit E2E? Sie haben zwei Möglichkeiten:
- Wenn jemand den Raum betreten kann, ist E2E lächerlich. Der Angreifer wird einfach beitreten und alles aufzeichnen. Wenn Sie überprüft haben, dass die Sockets SSL sind, ist die Verschlüsselung mehr als ausreichend: Jeder kann reinkommen und zuhören. Der Rest ist cialtrocryptarian Mist.
- Wenn der Raum nur für wenige zugänglich ist, wird der Zugang von einem Administrator verwaltet, egal ob Mensch oder nicht. Der Client muss lediglich mit dem öffentlichen Schlüssel des Administrators verschlüsseln und mit seinem eigenen Schlüssel signieren. Der Admin-Bot tut nichts anderes, als die Signatur zu überprüfen, zu entschlüsseln und die Nachricht an alle weiterzugeben, nachdem er sie mit IHREM öffentlichen Schlüssel verschlüsselt und mit ihrem privaten Schlüssel signiert hat.
Die Implementierungen, die ich im Raum sehe, sind andererseits einfach Hintertüren und oft schlecht getarnt.
Die Geschichte "aber wir müssen nicht telefonieren und keine Videokonferenzen machen" ist lächerlich. Beides ist unnötig: Du hast ein Telefon in der Hand, erinnerst du dich? Er macht bereits die Telefonate und sogar die Videoanrufe. Es ist bereits Teil des LTE-Protokolls. Und Sie können sie bereits verschlüsseln. Die Infrastruktur ist bereits vorhanden.
Die Wahrheit ist, dass nach der Geburt von Systemen wie RabbitMQ, NATS / GNATS, Kafka, Pulsar, Macrometa. MQTT müssen wir keine anderen "IM-Server" schreiben. Wir müssen höchstens die Bots schreiben, die die Strophen halten, und dann einen Keyserver für die öffentlichen Schlüssel verwenden und gute Clients schreiben. Punkt. Wenn wir möchten, dass sie sich zusammenschließen, müssen wir einen Roboter (und eine Warteschlange) schreiben, der sich um das Senden von Nachrichten für einen anderen Server und eine TCP / SSL-Schnittstelle kümmert.
Mehr brauchen wir eigentlich nicht. Das Rad muss nicht neu erfunden werden. Queue-Systeme (clusterfähig, skalierbar, Pub/Sub oder nicht) existieren bereits. Und sie sind SICHER, weil sie GETESTET sind. Und sie alle ermöglichen es Ihnen, Plugins vor Schnittstellen zu schreiben. Wir brauchen nur Clients und höchstens einen Keyserver.
Die bloße Tatsache, dass sich jemand einen neuen IM-Server schreibt, ist verdächtig, da wir auch im Sicherheitsprofil bereits ausgereifte und GETESTETE Message-Queue- Systeme haben. Legen sie dann eine persistente Datenbank hinein, bestätigt sich der Verdacht: Spyware.
Natürlich werden Sie mir sagen, dass Ihr kostbares Geschöpf mit E2E-Verschlüsselung keine Nachrichten speichern kann, sondern nur die Metadaten. Ich könnte Ihnen von dieser Frau erzählen, die beim Lesen der Metadaten herausfand, dass ihr Mann ihr Ex jedes Mal anrief, wenn sie zum Fußball ging, aber da Sie uns nicht hören können, zeichne ich Ihnen eine Skizze:
Hier ist, was ich von Signal, der Matrix und all denen halte:
- nach der Geburt von Systemen wie RabbitMQ, NATS / GNATS, Kafka, Pulsar, Macrometa. MQTT und andere, Ihr eigenes oder proprietäres IM-System zu schreiben, ist an sich schon eine verdächtige Handlung.
- Die E2E-Verschlüsselung kann nur vom Client durchgeführt werden. Es darf und darf keine Implementierungskomplexität vom Server verlangen
- Es besteht keine Notwendigkeit, Benutzeranmeldeinformationen zurückzuhalten, wenn ein öffentlicher Schlüssel ausreicht, um Signaturen zu überprüfen.
- Wenn es dann eine persistente Datenbank gibt, sind wir DEFINITIV mit Spyware konfrontiert.
Und das ist der Punkt.
Sie sind alle Spyware, in die Sie mit dem falschen Sicherheitsgefühl eintauchen, das von den "Datenschutzexperten" kommt, die sie empfehlen.