الشفافية
Transparenzbericht
Bestätigt vom Betreiber am 2026-11-14 · nächste Aktualisierung spätestens am 2027-02-14
Diese Seite hält öffentlich jede Anfrage nach Nutzerdaten fest, die dieser Dienst erhalten hat — und legt sich im Voraus auf das Datum ihrer nächsten Aktualisierung fest. Ein Transparenzbericht, der nach seinem versprochenen Datum verstummt, ist selbst ein Signal; genau deshalb wird das Datum versprochen.
Erhaltene Anfragen, seit Beginn
| Anfragen von Behörden oder Strafverfolgung nach Nutzerdaten | 0 |
| Gerichtsbeschlüsse, die zur Herausgabe verpflichten | 0 |
| Schweigeanordnungen, die einschränken, was diese Seite sagen darf | 0 |
| National Security Letters oder Vergleichbares | 0 |
| Von alledem betroffene Konten | 0 |
| Anfragen, bei denen irgendeine Post im Klartext hätte herausgegeben werden können | 0 — auf dem Server gibt es keine, die sich herausgeben liesse |
Canary
Mit Stand vom 2026-11-14 erklärt der Betreiber dieses Dienstes:
- Wir haben nie einen Durchsuchungsbeschluss, eine Vorladung oder irgendeine rechtliche Forderung nach Nutzerdaten erhalten.
- Wir standen nie unter einer Schweigeanordnung irgendeiner Art.
- Wir wurden nie aufgefordert, eine Möglichkeit einzubauen, das Siegel der Nutzerpost abzufangen, zu schwächen oder zu umgehen, und haben nie eine eingebaut.
- Wir haben nie Nutzerdaten an irgendjemanden herausgegeben.
Hört eine der Aussagen oben auf, wahr zu sein, ist es unsere Pflicht, sie bis zur nächsten planmässigen Aktualisierung zu entfernen — niemals, sie weiter zu veröffentlichen. Lies ihr Fehlen entsprechend.
Was eine Anfrage überhaupt erbringen könnte
Der ehrliche Kern dieser Seite ist strukturell, nicht statistisch. Nachrichtentexte, Betreffzeilen, Absender, Anhänge und ihre Dateinamen, Entwürfe und Kontakte sind mit Schlüsseln versiegelt, die nur im entsperrten Browser des Nutzers existieren, und der Suchindex liegt gar nicht auf dem Server — die stärkste Abfrage, die der Betreiber gegen den Postspeicher richten kann, trifft auf Chiffretext. Eine erzwungene Herausgabe könnte daher liefern: Daten der Kontohülle (Kennung, Zeitstempel), die Routing-Metadaten, die der Server braucht, um ein Mailserver zu sein, Sicherheitsprotokolle innerhalb ihrer Aufbewahrungsfrist und Chiffretext. Diese Grenze setzt das Design des Siegels mit seiner Testsuite durch, nicht eine Richtlinie — siehe das Bedrohungsmodell und die Verfassung, deren Artikel VI („Keine Hintertür, um keinen Preis“) die Antwort auf die Anfrage festlegt, die niemand veröffentlicht.
Der Code, den diese Instanz nach eigener Angabe ausliefert
…
So prüfst du es: Die Browser-Erweiterung (extension/) lädt dieses Manifest und bildet in deinem Browser den Hash jeder Datei, die ein offener RocMail-Tab von dieser Instanz geladen hat, des Service Workers dieses Tabs und jeder hier aufgeführten Datei. Eine geladene Datei, die nicht aufgeführt ist, oder eine, die abweicht, lässt die Prüfung scheitern.
Was das nicht beweist. Dieses Manifest ist die eigene Aussage des Servers über sich selbst. Die Erweiterung lädt die Dateien erneut, und ein Server kann diese Anfragen von denen der Seite unterscheiden und anders beantworten; eine Übereinstimmung beweist also nicht, dass der Tab genau diese Bytes ausgeführt hat. Das HTML jeder Seite und sein eingebetteter Startcode werden bei jeder Anfrage neu erzeugt und sind nicht abgedeckt. Jeder kann den Commit auschecken und den Produktions-Build ausführen. Zwei Builds desselben Commits auf einem Rechner ergeben dieselben Dateien und dieselbe Prüfsumme; dass ein Build auf einem anderen Rechner das ebenfalls tut, ist noch nicht gezeigt, ein Neubau anderswo ergibt deshalb noch nicht verlässlich dieselbe Prüfsumme.
Das Schlüsselprotokoll
Jeder Schlüssel, den diese Instanz für den Namen eines Mitglieds herausgibt, wird zuerst an ein Protokoll angehängt, das nur wächst — ein Merkle-Baum, wie ihn Certificate Transparency führt —, unter einer Kennung, die nur diese Instanz berechnen kann. So zeigt das Protokoll, dass es Schlüssel gibt und dass sie sich ändern, nie aber, wem sie gehören. Die Browser der Mitglieder prüfen jeden Schlüssel, für den sie versiegeln, daran, und die App jedes Mitglieds prüft bei offenem Tresor, dass das Protokoll für seine Namen keinen Schlüssel enthält, der nicht seiner ist. Meldet das Programm eines Mitglieds, der Schlüssel des Protokolls habe sich geändert, ist dieser Fingerabdruck das, womit es vergleicht.
…
Was es nicht kann: Das Protokoll hat noch keine Zeugen von aussen. Ein Server, der verschiedenen Mitgliedern verschiedene Protokolle zeigt, fällt erst auf, wenn sie die Köpfe vergleichen — dafür ist diese Seite da, und am meisten bedeutet sie, wenn der Fingerabdruck hier mit dem übereinstimmt, den das eigene Programm eines Mitglieds gespeichert hat, denn diese Seite kommt von dem Server, den sie beschreibt.
Methode
Aktualisierungen erscheinen nach einem festen vierteljährlichen Plan, ob sich etwas geändert hat oder nicht, und zuerst im öffentlichen Quellcode-Repository — so hat jede Änderung dieser Seite eine öffentliche, mit Zeitstempeln versehene Geschichte, die der Betreiber nicht still umschreiben kann.