Nachrichtenprivatsphäre
Kann Collogue meine privaten Nachrichten lesen?
Worauf der aktuelle Browser-Code beim Verschlüsseln einer Collogue-Nachricht zugreifen kann und worauf nicht.
Veröffentlicht: 14. Januar 2026
Grenzen der aktuellen Implementierung
Aktuelle Collogue-Links enthalten die verschlüsselte Nutzlast in der URL. Der Browser verwendet die Web Crypto API: PBKDF2-SHA-256 mit 310.000 Iterationen leitet aus dem separat eingegebenen Passwort einen 256-Bit-AES-GCM-Schlüssel ab, mit einem zufälligen 16-Byte-Salt und einem 12-Byte-IV. Der aktuelle Client sendet keine Anwendungs-API-Anfrage zum Erstellen, Abrufen oder Speichern von Nachrichten.
Das Passwort ist nicht im Link kodiert. Die Implementierung bietet keine einmalige Ansicht, keine serverseitige Löschung und keinen Ablauf-Timer. Behandeln Sie den vollständigen Link als sensibel und teilen Sie das Passwort über einen separaten Kanal.
Weiterer Kontext
„Kann der Dienst meine Nachricht lesen?“ klingt wie eine Ja-oder-Nein-Frage. Technisch sind es mehrere Fragen, die sich als eine einzige verkleiden.
Eine hilfreiche Antwort trennt diese Fragen, statt sie hinter einem einzigen Adjektiv zu verbergen.
Die lesbare Nachricht heißt Klartext. Das verschlüsselte Ergebnis heißt Chiffretext. Gute Verschlüsselung sollte den Chiffretext ohne den erforderlichen Schlüssel unbrauchbar machen.
Die nächste Frage ist, woher der Schlüssel kommt und wer ihn erhalten kann.
Wenn Collogue einen anderen Mechanismus verwendet, muss die öffentliche Erklärung diesen Mechanismus beschreiben, statt die Geschichte mit dem URL-Fragment von einem anderen Produkt zu übernehmen.
Angenommen, eine Website verschlüsselt Nachrichten im Browser. Heute prüfen Sie die Netzwerkanfrage und bestätigen, dass kein Klartext gesendet wird. Gut.
Das macht Browser-Verschlüsselung nicht nutzlos. Es zeigt, was dieser Schutz tatsächlich bedeutet.
Ein öffentlich einsehbares Repository kann die Transparenz verbessern. Es beweist nicht, dass der bereitgestellte Build exakt dem Repository entspricht, solange es keinen überprüfbaren Release-Prozess gibt. Ein unabhängiges Audit kann das Vertrauen erhöhen. Es macht eine sich ändernde Webanwendung jedoch nicht zu einem mathematischen Lehrsatz.
Sicherheit bleibt eine technische Aussage, die durch Belege gestützt wird.
Diese Schutzmaßnahmen sind gerade deshalb sinnvoll, weil sie begrenzt sind.
- das Gerät des Absenders ist kompromittiert;
- das Gerät des Empfängers ist kompromittiert;
- eine bösartige Browser-Erweiterung liest die Seite;
- der Absender gibt den Link an die falsche Person weiter;
- jemand leitet den vollständigen Link weiter, bevor er geöffnet wird;
- der Empfänger kopiert oder nimmt die Nachricht auf;
- die an den Browser gelieferte Webanwendung ist bösartig;
- das Geheimnis selbst ist schwach, wiederverwendet oder übermäßig privilegiert.
Verschlüsselung kontrolliert den Zugriff auf Informationen unter den genannten Annahmen. Sie hebt menschliches Verhalten nicht auf.
Verwenden Sie diesen Begriff nur, wenn Architektur, Schlüsselverwaltung, ausgelieferter Code und Betriebsmodell die Aussage rechtfertigen. Eine browserverschlüsselte Nutzlast allein reicht nicht aus, um jede Auslegung von „Zero Knowledge“ zu klären.
Die Antwort hängt davon ab, ob Datensätze Klartext, Chiffretext, Schlüssel oder genügend Daten zur Schlüsselableitung enthalten. Veröffentlichen Sie das überprüfte Schema und den Schlüsselpfad statt eines Slogans.
Ja. Ein Empfänger muss den Klartext schließlich rekonstruieren, um ihn zu sehen. In diesem Moment werden die Browserumgebung und das Gerät Teil des Vertrauensmodells.
Erstellen Sie einen privaten Collogue-Link, wenn Sie ein Passwort, Token, einen Wiederherstellungscode oder einen anderen kurzen sensiblen Wert senden müssen.