Das Sicherheits- modell.
Was eine Notiz schützt, was der Server sehen kann und was nicht, und wo die Grenzen liegen, klar gesagt — denn Sicherheit, die du nicht verstehen kannst, ist keine Sicherheit.
Kryptografie
- Verschlüsselung: Jede Notiz wird auf deinem Handy mit AES-256-GCM (einem 12-Byte-Nonce und einem 16-Byte-Authentifizierungs-Tag) versiegelt, bevor irgendetwas hochgeladen wird. Manipulierter Chiffretext scheitert an der Authentifizierung, statt zu Müll zu entschlüsseln.
- Schlüsselableitung: Der Schlüssel stammt aus HKDF-SHA256 über 32 frische Zufallsbytes — den Fragment-Schlüssel — plus ein zufälliges 16-Byte-Salt. Diese 32 Bytes gehen in das #Fragment des Links und in nichts anderes.
- Passphrase (optional): Wenn du eine festlegst, wird sie mit PBKDF2-HMAC-SHA256 über 600.000 Iterationen gestreckt und in die Ableitung gemischt, sodass der Link allein nicht mehr genügt. Falsche Versuche scheitern lokal im Browser des Empfängers und verbrauchen nie Aufrufe.
- Doppelt verifiziert: die Swift- und Kotlin-Implementierungen in den Apps und die WebCrypto-Implementierung im Viewer werden mit unabhängig erzeugten Testvektoren gegeneinander geprüft, sodass eine von einem versiegelte Notiz immer im anderen öffnet.
Der Fragment-Schlüssel-Link
Ein Notiz-Link sieht aus wie burnpony.app/n/<id>#<key>. Alles nach dem # ist ein URL-Fragment, und Browser senden Fragmente nicht in HTTP-Anfragen — weder an diesen Server noch an einen anderen. Der Server erfährt die zufällige Notiz-ID; der Schlüssel existiert nur im Link selbst und im Browser des Empfängers während des Lesens. Deshalb ist „der Server kann deine Notiz nicht lesen“ eine Eigenschaft der Funktionsweise des Webs, kein Versprechen.
Was der Server speichert — und nicht lesen kann
Solange eine Notiz lebt, hält der Server: die zufällige Notiz-ID, den versiegelten Chiffretext-Blob, Erstellungs- und Ablaufzeitstempel, das Aufruf-Kontingent und den Zähler, ob eine Lesebestätigung angefordert wurde, und einen Hash des Verwaltungs-Tokens, mit dem deine App die Notiz vorzeitig verbrennen kann. Sind Bestätigungen aktiv, werden Öffnungszeitstempel aufgezeichnet. Das ist das Inventar. Er hat nie den Schlüssel, den Notiztext oder auch nur die Auto-Ausblenden-Einstellung — die reist verschlüsselt in der Notiz. Die Erstellungs-Ratenbegrenzung verwendet IP-Hashes mit einem Server-Geheimnis, die nach etwa zwei Stunden ablaufen, keine rohen Adressprotokolle.
Verbrennen und was bleibt
Wenn der letzte erlaubte Aufruf abgerufen wird, wird der Chiffretext in derselben Datenbank-Transaktion gelöscht, die ihn ausgeliefert hat. Abgelaufene Notizen werden von einem Durchlauf entfernt, der alle fünf Minuten läuft. Und entscheidend: Eine verbrannte Notiz, eine abgelaufene Notiz und eine nie existierte Notiz liefern alle exakt dieselbe Antwort — der Server kann nicht als Orakel dienen, um zu bestätigen, dass ein Link je echt war.
Der Viewer
Empfänger öffnen eine einzige, in sich geschlossene Seite: keine Frameworks, keine Cookies, keine Analytik, keine Anfragen an irgendwohin außer an diesen Server für die versiegelte Notiz selbst. Sie trägt eine strikte Content-Security-Policy (default-src 'none'), eine noindex-Direktive und eine No-Referrer-Policy, damit der Link nie über Referrer-Header durchsickert. Die Entschlüsselung geschieht im eingebauten WebCrypto des Browsers. Die Seite ist kurz genug, um sie mit Quelltext anzeigen zu prüfen — das ist ein Designziel, kein Zufall.
Lesebestätigungen, ehrlich
Bestätigungen sind pro Notiz optional. Der Empfänger sieht „Der Absender wird benachrichtigt, wenn diese Notiz geöffnet wird“ bevor er sie enthüllt. Die Push-Nachricht, die du erhältst, ist bewusst allgemein — „Eine Notiz wurde geöffnet.“ mit nur der angehängten Notiz-ID — sodass nichts vom Inhalt der Notiz die Server des Push-Anbieters durchläuft.
Bedrohungsmodell
BurnPony schützt Vertraulichkeit und Integrität einer Notiz gegen den Server, Netzwerkbeobachter und jeden, der die URL später ohne ihr Fragment findet — und begrenzt, wie lange und wie oft eine Notiz überhaupt lesbar ist. Es setzt voraus, dass sich dein Handy und der Browser des Empfängers wie dokumentiert verhalten. Es verteidigt nicht gegen Malware auf einem der Endpunkte oder gegen einen Empfänger, der die Notiz kopiert, per Screenshot festhält oder abfotografiert, solange sie sichtbar ist — kein Burn-after-Reading-Werkzeug kann das. Selbstzerstörung begrenzt künftigen Zugriff; sie kann den Moment des Lesens nicht überwachen.
Ehrliche Grenzen
- Der Link ist der Schlüssel. Wer den vollständigen Link (und die Passphrase, falls gesetzt) erhält, bevor er verbrennt, kann die Notiz lesen. Sende ihn über einen Kanal, dem du das Geheimnis selbst anvertrauen würdest, oder füge eine Passphrase hinzu und teile sie separat.
- Bildschirme können erfasst werden. Der Auto-Ausblenden-Countdown verringert die Zeit für Shoulder-Surfing; er ist kein Screenshot-Schutz.
- Handy verloren, Verwaltung verloren. Notizen, die du gesendet hast, verbrennen und laufen weiterhin nach ihrem eigenen Zeitplan ab, aber ohne den Gesendet-Tab der App verlierst du die Möglichkeit, sie vorzeitig zu verbrennen oder den Status zu prüfen.
- Metadaten auf Netzwerkebene existieren. Wie jeder Webserver sieht auch dieser beim Bedienen von Anfragen die verbindenden IP-Adressen auf Netzwerkebene. Der Webserver vor dem Relay ist mit deaktiviertem Zugriffs-Logging konfiguriert, und die Anwendung behält nur die oben beschriebenen kurzlebigen gesalzenen IP-Hashes.
Die exakte Spezifikation
Jede Behauptung auf dieser Seite ist präzise dargelegt, Konstante für Konstante, auf der v1-Protokollseite, geschrieben gegen den eingefrorenen Code in dem öffentlichen Repository und gegen die gemeinsamen Testvektoren überprüfbar.
Offen zur Prüfung
Der Viewer ist heute auf jedem Notiz-Link überprüfbar, und der Krypto-Kern, der Viewer und der Relay-Server sind zur Veröffentlichung geplant — siehe die Open-Source-Seite zum aktuellen Stand.
Eine Schwachstelle melden
Etwas gefunden? Schreib NorseHorse@norsehor.se — verschlüsselt mit den PGP-Schlüssel, wenn du magst. Meldungen gehen direkt an den Entwickler, und Fixes erscheinen schnell, weil kein Gremium im Weg steht.