Zuerst die enge Aussage: Nach erreichter Lesezahl oder Ablauf liegt der Chiffretext nicht mehr auf dem Server; ein erneuter Abruf über dieselbe Kennung liefert die Originalbytes nicht. Daraus folgt nicht „die Gegenseite hat keinen Screenshot gemacht“, „im Kanal hat niemand Drittes geöffnet“ oder „in Chat-Sicherungen steckt kein vollständiger Link“. Die Prüfung sind zwei Öffnungen plus Network – nicht „Wurde verbrannt“ als Audit des anderen Geräts.
Die Suchintention in einem Satz beantworten
Ein selbstzerstörender Einmal-Link trägt eine Aussage: der Host hält den Chiffretext nicht mehr. Er trägt nicht die Aussage, Bildschirm, Zwischenablage oder Chatverlauf der Empfangsseite seien geleert. Nach dem ersten erfolgreichen Abruf zeigt dasselbe Öffnen „Wurde verbrannt“ oder „Abgelaufen“. Unter HTTP 410 Gone ist die Zielressource am Ursprung nicht mehr verfügbar, und dieser Zustand ist in der Regel dauerhaft. Das beantwortet: „Gibt der Server ihn noch heraus?“ Es beantwortet nicht: „Hat jemand eine Kopie behalten?“
Diese Notiz richtet sich an Entwicklung, Betrieb und alle, die vor dem Versand eines Einmalpassworts, eines API-Schlüssels oder eines Wiederherstellungscodes zwei Sätze trennen wollen: „der Link ist tot“ und „die Gegenseite hat nichts behalten“. Sie ersetzt nicht die Bedienung von Burn-Link und wiederholt nicht, wie Sie eine URL erzeugen. Mitnehmen sollten Sie: Welche Schicht verbrannt ist, was ein gescheiterter Refresh beweisen kann, warum Screenshots außerhalb dieser Schicht liegen, und wie Sie Host-Seite mit zwei Öffnungen plus Network auf diesem Gerät prüfen.
„Wurde verbrannt“ ist nicht dasselbe wie „die Gegenseite hat keine Kopie“
Alltagssprache knetet drei verschiedene Tatsachen in den Satz „diese Nachricht ist nach dem Lesen weg“. Erstens: Der Server speichert keinen Chiffretext mehr. Der Datensatz zu dieser Kennung ist gelöscht, eine spätere Anfrage liefert nur „Wurde verbrannt“ oder „Abgelaufen“. Zweitens: Dieser Tab zeigt keinen Klartext mehr. Seite schließen, „Von dieser Seite leeren“ oder ein Skript, das das Feld beim Verlassen leert, können das tun. Drittens: Auf dem Gerät der Empfangsseite liegt keine Kopie – kein Screenshot, kein Einfügen, kein Weiterleiten des vollständigen Links, kein Klartext zurück in den Chat.
Burn-after-Read kann die erste Tatsache erzwingen. Für die zweite kann es höchstens die Anzeige in diesem Tab leeren. Über die dritte hat es keine Gewalt. Die Leseseite darf schreiben, dass sie Kopieren und Bildschirmfotos nicht sperrt. Das ist eine Grenze, kein fehlendes Kästchen: Eine Webseite kann ein zweites Handy nicht am Fotografieren des Bildschirms hindern, und sie greift nach „Klartext kopieren“ weder in die System-Zwischenablage noch in den lokalen Speicher einer Chat-App.
„Ich habe neu geladen, es öffnet nicht mehr“ trägt deshalb nur eine enge Folgerung: Dieser Abruf über die Kennung hat keinen Chiffretext zurückgegeben. Es trägt nicht „nur jene Kollegin hat ihn gesehen“, „niemand hat einen Screenshot gemacht“ oder „diese Zeichenkette taucht in keiner Ticketsuche mehr auf“. Die späteren Sätze brauchen eine andere Beobachtung: Ob Klartext oder die vollständige URL diesen Tab verlassen hat – nicht, ob Ihr zweites Öffnen scheiterte.
Welche Schicht der Server tatsächlich verbrennt
Ein Zero-Knowledge-Burn-Link trennt Ort und Entschlüsselung. Die Form lautet s.html?id={id}#{key}: Die Query trägt nur die Kennung, der Schlüssel sitzt hinter der Raute. RFC 9110 schließt das Fragment aus der Ziel-URI der Anfrage aus. Holt der Browser das Dokument, streicht er # und alles danach. Nach Entwurf sieht der Server die Kennung, nicht den Schlüssel und nicht den Klartext.
Beim Erstellen nutzt dieser Tab Web Crypto für AES-256-GCM: ein zufälliger 32-Byte-Schlüssel, ein 12-Byte-IV, Klartext auf diesem Gerät zu Chiffretext verdichtet, danach POST /secrets. Nach außen gehen Chiffretext, Ablauf und Lesezahl. Der Schlüssel erscheint erst in der danach gebauten Teilen-URL. Ein Eintrag ist auf 32 KB begrenzt. Ablauf kann 1 Stunde, 24 Stunden, 7 Tage oder nur nach dem Lesen sein. Die Lesezahl liegt bei 1–10, Standard 1. Erstellen und Lesen sind sofort nutzbar. Es gibt kein Konto und keine Login-Identität für „wer hat geöffnet“.
Beim Lesen löscht der Server den Chiffretext, nachdem er ihn herausgegeben hat und die gesetzte Zahl erreicht ist. Öffnen Sie denselben Link erneut, steht dort „Wurde verbrannt“ oder „Abgelaufen“. Das beweist: Der Host hält diese Chiffretext-Bytes nicht mehr. Es beweist nicht, dass der Schlüssel nie im Chatverlauf stand, dass Klartext nie den anderen Bildschirm getroffen hat, oder dass niemand Drittes auf derselben vollständigen URL „Öffnen und anzeigen“ geklickt hat.
Wer die vollständige URL hat, hält den Schlüssel. https://…/s.html?id=…#… in einen Kanal zu kleben, übergibt Kennung und Schlüssel zugleich. Auch nachdem der Server den Chiffretext verbrannt hat, kann diese Löschung niemanden zurückdrehen, der bereits geöffnet und den Klartext behalten hat. Bleiben Lesungen übrig, kann ein späterer Klick den Chiffretext weiter holen. Das Verbrennen des Chiffretexts betrifft die langfristige Speicherung beim Host. Es betrifft nicht „alle, die die ganze Zeichenkette gesehen haben“.
Was ein gescheiterter Refresh beweisen kann – und was nicht
Ein zweites Öffnen, das scheitert, ist kein einzelner Status. Trennen Sie drei Hinweise. „Wurde verbrannt“: Der Chiffretext ist weg, weil die Lesezahl verbraucht oder die Kennung nie gültig war. „Abgelaufen“: Die beim Erstellen gesetzte TTL ist um, der Server hat den Datensatz auch ohne Lesung gelöscht. „Fragment-Schlüssel fehlt“: Die Kennung kann noch existieren, dieses Gerät kann aber nicht entschlüsseln. Slack, Teams, WhatsApp und manche Mailprogramme schneiden alles nach # ab. Die Empfangsseite sieht dann „Fragment-Schlüssel fehlt“ – das ist nicht dasselbe Ereignis wie „jemand anderes hat bereits gelesen“.
410 Gone heißt: Die Zielressource ist am Ursprung nicht mehr verfügbar, und dieser Zustand ist wahrscheinlich dauerhaft. Die Leseseite teilt 410 in „verbrannt“ und „abgelaufen“: Markiert die Antwort expired, ist es TTL; sonst gilt sie als verbrannt. Ein 404 erscheint ebenfalls als „Wurde verbrannt“, weil das Ergebnis für Empfänger dasselbe ist – Chiffretext lässt sich nicht erneut holen. Ein Netzfehler ist kein Verbrennen: Passiert der Abbruch nach „Öffnen und anzeigen“ und war nur eine Lesung erlaubt, kann der Chiffretext bereits abgeholt sein, obwohl dieser Tab ihn nie entschlüsselt hat.
„Bei mir öffnet der Refresh nicht“ trägt also: Ein Abruf über diese Kennung liefert keinen Chiffretext mehr. Es trägt nicht: Die öffnende Person war die benannte Kollegin; sie hat nicht kopiert; sie hat keinen Screenshot gemacht; ein Vorschaubot oder ein Sicherheitsscanner hat nicht zuerst eine Lesung verbraucht. Ohne Konten gibt es keinen namentlichen Lesenachweis. Die Zahl lebt auf dem Server. Sie ist kein Audit des Empfängergeräts.
Experimentieren Sie nicht mit einem echten Passwort, einem API-Schlüssel oder einem ungeschwärzten Verbindungsstring. Schreiben Sie einen Satz, der nur für diese Prüfung existiert. Sie vergleichen Statusaufruf, Chiffretext-Abruf und den Hinweis beim zweiten Öffnen – Sie sollen keine lebenden Zugangsdaten erneut preisgeben.
Warum Screenshot, Kopie und Chatverlauf außerhalb dieser Schicht liegen
Sobald Klartext auf einem Bildschirm steht, verlässt die Frage „hat der Server noch Chiffretext?“ und wird zu „was ist am anderen Endpunkt passiert?“. Ein System-Screenshot, eine Bildschirmaufnahme oder ein zweites Handy vor dem Display schickt dem Host keine Anfrage. Die Leseseite kann diese Handlungen nicht abfangen und Sie danach nicht benachrichtigen. Das ist kein unerledigtes Produktkästchen. Gewöhnliche Webseiten bekommen keinen Schalter, der der Gegenseite verbietet, den eigenen Bildschirm aufzunehmen.
Kopieren liegt hinter derselben Grenze. Die Leseseite kann „Klartext kopieren“ anbieten und das Feld beim Verlassen leeren. Was sie leert, ist dieser DOM-Knoten – nicht die System-Zwischenablage und nicht ein Chat-Entwurf. macOS und manche Eingabemethoden führen eine Zwischenablage-Historie. „Von dieser Seite entfernt“ heißt nur: Dieser Tab zeigt den Satz nicht mehr. Es heißt nicht, der Satz sei nie in die Zwischenablage gelangt.
Der Chatverlauf ist ein eigener Speicher. Stand der vollständige Link in einem Kanal, können Gruppenhistorie, Suche, Mehrgeräte-Sync und ein späterer Export den Schlüssel hinter der Raute erneut zeigen. Auch nachdem der Server den Chiffretext verbrannt hat, bleibt die URL der Beleg, dass der Link einmal funktionierte – und reicht, damit jemand, der die verbrauchte Zahl nicht kennt, weiterklickt und „der Link ist kaputt“ entscheidet. Die HTTP-Schicht kann trotzdem sauber bleiben: Referer darf kein Fragment tragen. Für alle, die den Chat öffnen können, ist dieser Schutz bereits weg.
Tickets, Mail und Browser-Historie folgen derselben Trennung. Ein #-Fragment, das in der Adresszeile stand, landet meist in der lokalen Historie; ein angemeldeter Browser kann diese Zeile auf andere Geräte synchronisieren. Den Tab zu schließen ist nicht dasselbe wie Historie zu leeren. Burn-after-Read verkürzt, wie lange der Server ein Blob behält, und begrenzt, wie oft derselbe Chiffretext geholt werden kann. Es ist kein Kopierschutz und kein Gutachten.
Warum eine Statusabfrage keine Lesung verbraucht
Würde schon der erste Aufruf der Landeseite den Chiffretext holen, könnte eine Chatvorschau, ein E-Mail-Sicherheitsgateway oder ein Unternehmensscanner die einzige Lesung verbrauchen, bevor die Empfangsseite klickt. Sie sähe dann „Wurde verbrannt“, obwohl der Schlüssel dem Vorschaurechner nie übergeben wurde. Verbrannt ist die Lesezahl, nicht die Geheimhaltung des Fragments. Eine frühere Notiz erklärt, warum die Raute standardmäßig nicht in HTTP geht. Diese hier bleibt bei der Zahl: Vorschauanfrage und echter Chiffretext-Abruf müssen getrennt sein, sonst trägt „Wurde verbrannt“ nicht einmal „die Empfangsseite hat gelesen“.
Die Leseseite von FastPwd trennt diese Schritte. Beim Öffnen geht nur /secrets/{id}/status: Liegt der Chiffretext noch? Das Blob wird nicht geholt. Nach „Öffnen und anzeigen“ macht der Tab GET /secrets/{id} und entschlüsselt lokal mit dem Schlüssel hinter der Raute. Fehlt der #-Schlüssel, holt die Seite keinen Chiffretext, damit restliche Lesungen nicht verschwendet werden. Weder die Erstellungsseite noch die Leseseite braucht ein Konto.
Vorschaubots ziehen in der Regel die Landeseite und klicken die Schaltfläche nicht. Das senkt die Chance „Vorschau gleich verbrannt“. Es beweist nicht, dass jeder Scanner dort stehen bleibt. In Network sollten Sie zuerst einen Statusaufruf sehen, danach den Chiffretext-Abruf; ein Laden ohne Klick sollte keinen erfolgreichen Blob-Abruf zeigen. Die Zahl bleibt ein Zähler auf dem Server. Sie ist kein Teil des Fragments.
| Was Sie sehen | Was das tragen kann | Was das nicht tragen kann |
|---|---|---|
| Zweites Öffnen zeigt „Wurde verbrannt“ | Ein Abruf über diese Kennung liefert keinen Chiffretext mehr | Die Gegenseite hat keinen Screenshot und keine Kopie gemacht |
| Die Seite zeigt „Abgelaufen“ | Die TTL ist um, der Server hat den Datensatz gelöscht | Jemand hat erfolgreich gelesen |
| Die Seite zeigt „Fragment-Schlüssel fehlt“ | In der Adresse fehlt der Schlüssel hinter # |
Der Chiffretext ist bereits abgeholt |
| Die Seite ist geladen, die Schaltfläche wurde nicht geklickt | Eine Statusabfrage sollte keine Lesung verbrauchen | Jeder Vorschaubot weigert sich, Chiffretext zu holen |
| Network zeigt beim POST nur Chiffretext | Dieses Erstellen hat den Originalsatz nicht als Fachfeld gesendet | Nach dem Einfügen des vollständigen Links in den Chat sehen nur Sie ihn |
| Klartext wurde von dieser Seite entfernt | Dieser Tab zeigt den Satz nicht mehr | Zwischenablage und Screenshots sind ebenfalls leer |
Jetzt prüfen: zwei Öffnungen, Status und Network
Ein Slogan ist kein Beweis. Bereiten Sie einen wegwerfbaren Canary vor, etwa canary-fp-20260905-burn-vs-shot. Wiederverwenden Sie kein lebendes Passwort. Lassen Sie die Lesezahl beim Standard 1, den Ablauf bei 24 Stunden.
- Schreiben Sie den Canary auf die Erstellungsseite und erzeugen Sie einen Link. Öffnen Sie Network in den DevTools und aktivieren Sie Preserve log. Suchen Sie Canary und den Schlüssel hinter der Raute getrennt: Der Körper von
POST /secretssoll Chiffretext, Ablauf und Lesezahl enthalten – nicht den Originalsatz und nicht den Schlüssel. - Öffnen Sie die Leseseite mit demselben vollständigen Link. Klicken Sie „Öffnen und anzeigen“ noch nicht. Network sollte
/secrets/{id}/statuszeigen und keinen erfolgreichenGET /secrets/{id}, der das Blob geholt hat. Die Seite sollte auf Bestätigung warten. - Klicken Sie „Öffnen und anzeigen“. Erst dann sollte Chiffretext über die Kennung geholt und auf diesem Gerät mit AES-256-GCM entschlüsselt werden. Der Erfolgshinweis sagt, der Server habe diesen Chiffretext gelöscht – oder, wenn Sie die Zahl über 1 gesetzt haben, dass die Löschung erst bei erreichter Zahl erfolgt.
- Laden Sie die Leseseite neu oder öffnen Sie denselben Link in einem frischen Browserkontext. Bei einer Lesung sollten Sie „Wurde verbrannt“ sehen. Suchen Sie Network erneut: Der Chiffretext-Abruf sollte 410 oder eine als verbrannt behandelte Antwort liefern. Der Canary darf in keinem Anfragekörper wieder als Klartext erscheinen.
Diese vier Schritte beweisen eine Änderung: Zwischen zwei Öffnungen, die Sie steuern, ist der Chiffretext auf dem Server von „vorhanden“ nach „abwesend“ gegangen. Sie beweisen nicht, dass bei einem echten Passwort für eine Kollegin niemand einen Screenshot gemacht hätte. „Wird die Gegenseite eine Kopie behalten?“ gehört in die Übergabenotiz – nicht screenshotten, Klartext nicht zurück in den Kanal kleben, Geheimnis nach Gebrauch rotieren – nicht in die Hoffnung, „Wurde verbrannt“ prüfe den Endpunkt für Sie.
Schicken Sie den vollständigen Link und den Chiffretext nicht über denselben Weg. Legen Sie eine .lock-Datei auf ein Laufwerk oder in die Mail und schicken Sie die Passphrase über Burn-Link. Legen Sie die vollständige Burn-Link-URL nicht in die Notizen dieses Ordners. Reisen Schlüssel und Kiste in einer Nachricht, hilft das Verbrennen des Chiffretexts niemandem, der die ganze Zeichenkette schon gesehen hat.
Drei Arten, „Wurde verbrannt“ zu weit zu lesen
Erstens wird „Abgelaufen“ als Beweis gelesen, jemand habe gelesen. Erstellen nutzte 1 Stunde; die Kollegin klickte am nächsten Tag; die Seite sagt „Abgelaufen“. Der Server hat den Chiffretext gelöscht, der Grund ist TTL, nicht eine verbrauchte Lesezahl. Ungelesener, abgelaufener Inhalt lässt sich nicht wiederherstellen. Das ist nicht dasselbe wie „er war schon geöffnet“.
Zweitens wird ein fehlendes Fragment als bereits verbrannt gelesen. Slack, Teams und manche Mailprogramme schneiden alles nach # ab. Die Empfangsseite öffnet s.html?id=… ohne Schlüssel. Die Leseseite holt ohne Schlüssel keinen Chiffretext. Öffnen Sie später den vollständigen Link, kann der Inhalt noch da sein. Bitten Sie um die Zeichenkette einschließlich Raute. Entscheiden Sie nicht „jemand war zuerst da“.
Drittens wird „Von dieser Seite leeren“ als globale Wische gelesen. Die Leseseite kann das Feld beim Verlassen leeren und mit history.replaceState das Fragment aus der Adresszeile nehmen. Das ändert nur, was dieser Tab zeigt und ob ein späterer Refresh den Schlüssel noch trägt. System-Screenshots, Zwischenablage-Historie, Chat-Sicherungen und synchronisierte Browser-Historie liegen außerhalb dieser Leerung.
Häufige Fragen
Wenn die Gegenseite neu lädt und „Wurde verbrannt“ sieht, heißt das, sie hat nichts behalten?
Nein. Es heißt nur: Der Chiffretext liegt nicht mehr auf dem Server, ein erneuter Abruf über die Kennung liefert die Originalbytes nicht. Screenshot, Kopie, Bildschirmaufnahme, Chat-Sicherung und das Weiterleiten des vollständigen Links laufen nicht durch diese Löschung. „Wurde verbrannt“ ist kein Nachweis, dass das Gerät der Gegenseite leer ist.
Kann die Linkvorschau einer Chat-App den Inhalt zuerst verbrennen?
Eine Vorschau lädt in der Regel nur die Landeseite. Die Leseseite fragt zuerst, ob der Chiffretext noch da ist, und holt ihn nicht; „Öffnen und anzeigen“ holt den Chiffretext über die Kennung. Die meisten Vorschaubots klicken diese Schaltfläche nicht für Sie – Sie dürfen aber nicht annehmen, jeder Scanner bleibe auf der Landeseite stehen. Die Lesezahl ist ein Zähler auf dem Server. Die Prüfung: Beim Laden ohne Klick sollte Network keinen erfolgreichen Chiffretext-Abruf zeigen.
Kann ein Einmal-Link beweisen, wer den Link geöffnet hat?
Nein. Erstellen und Lesen brauchen kein Konto, und der Server kennzeichnet Lesende nicht über eine Login-Identität. Prüfen können Sie, ob nach einem Abruf noch Chiffretext zur Kennung liegt. Aus „Wurde verbrannt“ lässt sich kein Name ableiten, und Sie können es nicht als Lesenachweis schreiben.
Muss ich mich zum Erstellen oder Lesen registrieren? Wird Klartext hochgeladen?
Nein. Dieser Tab verschlüsselt mit AES-256-GCM und lädt danach Chiffretext hoch. Der Schlüssel sitzt im #-Fragment. Suchen Sie in Network mit einem Canary: Der Körper soll Chiffretext enthalten, nicht den Originalsatz und nicht den Schlüssel hinter der Raute. Für mehr als 32 KB oder eine ganze Datei nutzen Sie Datei verschlüsseln auf diesem Gerät. Behandeln Sie einen Burn-Link nicht als Laufwerk.
Denselben Canary an einem sofort nutzbaren Tool prüfen
Wenn Sie an einer Seite üben möchten, die die Rechengrenze offen schreibt, öffnen Sie Burn-Link von FastPwd. Kein Konto nötig. Fügen Sie den Canary oben ein, lassen Sie die Lesezahl bei 1, erzeugen Sie den Link und führen Sie die zwei Öffnungen aus dem Prüfabschnitt zu Ende. Beobachten Sie Network dabei: Sie sollten den Chiffretext-POST beim Erstellen sehen, Status auf der Leseseite, den Abruf nach dem Klick und eine verbrannte Antwort beim zweiten Öffnen. Sie sollten den Originalsatz und den Schlüssel hinter der Raute nicht als Fachfeld sehen.
Nutzen Sie diesen Weg nur, wenn ein Passwort eine Kollegin oder einen Kollegen erreichen muss. Das Zufallspasswort können Sie zuerst im Passwort-Generator lokal erzeugen, Länge 6–128, Standard 16; unter 8 Zeichen gilt als schwächer. Die Erzeugung wird nicht hochgeladen. Ein ganzer Vertrag, ein Ausweis-Scan oder alles über 32 KB gehört in Datei verschlüsseln, mit demselben AES-256-GCM nach .lock / .enc, eine Datei höchstens 5 GB. Schicken Sie die Passphrase allein über einen Burn-Link. Schreiben Sie sie nicht in die Notizen des Laufwerks.
Vor dem nächsten Versand drei Tatsachen behalten. Erstens: „Wurde verbrannt“ beweist, dass der Chiffretext auf dem Server weg ist – nicht, dass die Gegenseite keinen Screenshot gemacht hat. Zweitens: Das Laden der Landeseite sollte keine Lesung verbrauchen; „Öffnen und anzeigen“ holt den Chiffretext. Drittens: Nach dem Einfügen des vollständigen Links in den Chat ist der Schlüssel hinter der Raute für alle sichtbar, die diese Nachricht sehen. Nur eine Beobachtung, die Sie wiederholen können, gehört in Ihre eigenen Übergabenotizen.
Weiterlesen
Warum der Teil hinter der Raute standardmäßig nicht in HTTP geht und welche Schicht fällt, wenn Sie den vollständigen Link weiterleiten, steht in Warum sich ein Schlüssel hinter der URL-Raute eignet – und wann der Schutz fällt. „Lokale Verschlüsselung, nichts hochgeladen“ ist kein Beweis, bis Sie Network mit einem Canary durchsuchen: So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet. Müssen Sie Ausweisnummern in einem Ticket noch vor dem Verlassen dieses Geräts maskieren, siehe Bevor Sie Tickets und Logs in eine KI einfügen: Welche Felder dieses Gerät verlassen.