نموذج التهديد

Das Sicherheitsmodell

Ein Satz trägt das ganze Design: Ein Angreifer, der den gesamten Server übernimmt — Datenbank, Geheimnisse, Quellcode, laufenden Arbeitsspeicher —, kann die dort gespeicherte Post nicht lesen. Alles Weitere ist dieser Satz, genau betrachtet.

Was versiegelt ist

Texte, Absender, Empfänger, Betreffzeilen, Vorschauen, die Bytes der Anhänge und ihre Dateinamen, Entwürfe, deine Kontakte, die Passwörter, die du neben deinen Namen aufbewahrst, samt den Dateien dazu und ihren früheren Fassungen zum Rückgängigmachen, und die Liste der Absender, die du blockierst. All das ist mit Mashrabiya versiegelt — einer Verbindung aus einem Post-Quanten- und einem klassischen Verfahren —, und zwar für eine Tresor-Identität, deren geheime Hälfte nur in deinem entsperrten Browser-Tab existiert. Der Eingangs-Worker, der deine Post empfängt, hält die öffentliche Hälfte: Er kann Nachrichten an dich versiegeln und nie eine öffnen.

Gegen wen wir uns verteidigen

Wogegen wir uns nicht verteidigen

Ehrlichkeit über Grenzen ist der Unterschied zwischen einem Bedrohungsmodell und einer Werbung:

• ✦Dein entsperrtes Gerät. Ein offener Tresor ist ein offenes Postfach — genau das bedeutet „entsperrt“. Die Sperre bei Inaktivität und das konsequente Löschen der Schlüssel verkleinern das Zeitfenster; schliessen können sie es nicht.
• ✦Eingeschleuste Skripte bei entsperrtem Tresor. Ein erfolgreicher XSS-Angriff liest, was du lesen kannst. Eine CSP mit Nonces, abgeschottete Darstellung des Absender-HTML und doppelte Bereinigung machen es schwer; unmöglich macht es nichts.
• ✦Verkehrsanalyse. Der Server sieht, dass Post für dich ankam, wann und ungefähr wie gross. Das Siegel verbirgt den Inhalt, nicht die Existenz. Wir fügen keinen Tarnverkehr hinzu und sagen das.
• ✦Suche, Gerät für Gerät. Gesucht wird auf jedem Gerät, in einem Index, den es baut, indem es deine Post öffnet: Wir erfahren nie, wonach du suchst oder was die Suche findet. Was wir sehen, ist gewöhnlich: dass jedes Gerät jeden Brief einmal herunterlädt, um ihn zu lesen, und die Verschiebung in den Spam, wenn ein Gerät eine Blockierung anwendet. Ein Gerät, das einen Brief noch nicht gelesen hat, findet ihn nicht, und ein geschlossener Tresor durchsucht nichts.
• ✦Ein bösartiges Client-Update. Der Code, den dein Browser ausführt, kommt von uns. Ein feindlicher Build könnte den Tresor beim Entsperren verraten. Der Quellcode ist einsehbar, und diese Grenze teilt jedes über den Browser ausgelieferte E2E-Produkt — wir benennen sie, statt sie zu beschönigen.
• ✦Ein veränderter Eingang. Post kommt über SMTP im Klartext an, wie alle Post, und wird im Moment der Ankunft versiegelt. Ein Betreiber, der den Eingangscode änderte, könnte neue Post beim Eintreffen lesen — nie das, was schon gespeichert ist. Geprüft wird das am veröffentlichten Quellcode und am Build-Manifest auf der Transparenzseite.
• ✦Post an Adressen ausserhalb. Gewöhnliche E-Mail muss Gmail oder Outlook in einer Form erreichen, die deren Server lesen können; deshalb liest dieser Server einen Brief an eine Adresse ausserhalb, während er ihn überträgt, und die Kopie in deinem Ordner „Gesendet“ ist versiegelt. Zwischen RocMail-Mitgliedern versiegelt dein Browser den Brief, bevor er hinausgeht, und der Server reicht nur Chiffretext weiter — versiegelt mit einem Schlüssel, den dein Browser beim Server erfragt hat, und erst, wenn dieser Schlüssel der Prüfung am Schlüsselprotokoll der Instanz standhält, das deine eigene App auf jeden Schlüssel absucht, der nicht deiner ist. Das Protokoll hat noch keine Zeugen von aussen: Ein Server, der verschiedenen Menschen verschiedene Protokolle zeigt, fällt erst auf, wenn sie seinen Kopf auf der Transparenzseite vergleichen. Und Post an ein Mitglied ohne Tresor versiegelt der Server bei der Ankunft; die Desktop-Bridge versiegelt wie dein Browser, am selben Protokoll geprüft.
• ✦Deine Namen, nebeneinander. Damit Mitglieder einander Briefe versiegeln können, gibt das Verzeichnis einem angemeldeten Mitglied den Schlüssel, mit dem für einen Namen versiegelt wird. Jeder deiner Namen hat einen eigenen Schlüssel, in deinem Browser aus deinem Postfachschlüssel erzeugt; zwei deiner Namen antworten also mit zwei voneinander unabhängigen Schlüsseln, und ein Mitglied, das beide kennt, kann an ihnen nicht erkennen, dass sie einer Person gehören. Zwei Grenzen bleiben: Antworten, die vor dem 25. Oktober 2026 aufgezeichnet wurden, als alle Namen eines Kontos einen Schlüssel teilten, verknüpfen diese Namen weiterhin; und ein ausserhalb der App angelegter Name antwortet mit dem Schlüssel deines Kontos, bis du das nächste Mal entsperrst. Der Server selbst weiss immer, welche Namen deine sind.
• ✦Ein unverschlüsselter Export deiner Passwörter. Deine Passwörter können dich in zwei Formen verlassen. Die verschlüsselte Sicherung wird auf deinem Gerät unter einer Passphrase versiegelt, die du für genau diese Datei wählst (Argon2id, XChaCha20-Poly1305), und übersteht ein Zurücksetzen des Tresors; vergisst du diese Passphrase, öffnet nichts die Datei, weder für uns noch für dich. Der unverschlüsselte Export, gedacht für den Umzug zu einem anderen Passwort-Manager, ist überhaupt nicht verschlüsselt: Wer die Datei bekommt — aus einem synchronisierten Ordner, einem Backup-Dienst, von einem geliehenen Computer —, liest jedes Passwort, jedes Einmalcode-Geheimnis und jede Notiz darin. Die App warnt zweimal, bevor sie einen schreibt; danach liegt es bei dir, die Datei zu hüten und zu löschen.
• ✦Ein per Link geteiltes Passwort. Ein Teilen-Link trägt eine versiegelte Kopie der Teile eines Eintrags, die du auswählst, und den Schlüssel dazu nach dem `#`, den Browser nie an einen Server senden: Wir speichern einen Chiffretext, den wir nicht öffnen können, die verbleibenden Ansichten und den Ablauf, und löschen ihn bei seiner letzten Ansicht oder seinem Ablauf. **Wer den Link hat, kann ihn öffnen**, solange er gilt — wem er weitergeleitet wird, wer den Chat liest, in den er eingefügt wurde, ein synchronisierter Browserverlauf. Eine Ansicht, die Voreinstellung, schliesst ihn, sobald die Person, für die er bestimmt ist, ihn öffnet; das Öffnen der Seite verbraucht nichts, sodass die Linkvorschau einer Chat-App ihn nicht aufbrauchen kann — nur „Anzeigen“ tut das. Meldet ein Link mit einer Ansicht schon beim ersten Öffnen, er sei aufgebraucht, hat ihn jemand anderes zuerst geöffnet: Betrachte, was er enthielt, als offengelegt. Wer ein Einmalcode-Geheimnis teilt, gibt auch den zweiten Faktor weiter.
• ✦Eine beschlagnahmte Maschine. Wer den Server nimmt, nimmt, was er im Klartext hat: die Routing-Metadaten unten, die Sicherheitsprotokolle innerhalb ihrer Aufbewahrungsfrist und das kurzlebige Zustellprotokoll des Hosts. Der Inhalt bleibt versiegelt; die Gestalt deiner Korrespondenz nicht.

Die Metadaten, die der Server behält

Jede Zeile existiert, weil der Server auf ihrer Grundlage HANDELN muss, während dein Tresor geschlossen ist, und nichts davon ist Inhalt. Weiterleitungsadressen, 2FA-Geheimnisse, DKIM-Signaturschlüssel und die Warteschlange für zeitversetztes Senden sind zusätzlich mit einem Einstellungsschlüssel des Servers verschlüsselt; der Rest sind gewöhnliche Datenbankspalten, unverschlüsselt auf der Festplatte dieses Servers.

Was endgültig schiefgehen kann

Verlierst du deine Tresor-Passphrase und deine Wiederherstellungsphrase aus 24 Wörtern, ist deine Post weg — kein Zurücksetzen, keine Hinterlegung, kein Eingriff. Das steht bei der Registrierung, beim Anlegen des Tresors und hier, weil es dieselbe Tatsache ist wie unser Kernversprechen, von der anderen Seite gesehen. Ein Wiederherstellungsschalter ist ein Schlüssel, den jemand anderes hält.

Fragen, die diese Seite nicht beantwortet? Das technische Bedrohungsmodell liegt dem Quellcode bei — der gesamte Dienst ist öffentlich. Oder beginne bei der Ethikseite — dasselbe Design, aus Prinzipien begründet statt aus Primitiven.