Was diese Seite beweist, und was nicht
Der Tresor verschlüsselt deine Dateien auf deinem Gerät. Das ist eine Behauptung. Diese Seite zeigt dir, wie du sie selbst überprüfst, ohne uns zu glauben und ohne Spezialwerkzeug. Du brauchst nur die Entwicklertools, die in deinem Browser schon eingebaut sind.
Der wichtigste Satz zuerst
Alles auf dieser Seite beweist, was dein Browser heute in dieser Sitzung ausgeführt hat. Es beweist nicht, was unser Server dir morgen schickt. Wer eine Web-Anwendung ausliefert, könnte einem einzelnen Nutzer jederzeit anderen Code schicken als allen anderen. Dagegen hilft keine Prüfung im Browser, sondern nur ein unabhängig veröffentlichter Prüfwert, gegen den viele Leute gleichzeitig vergleichen. Wir schreiben das hierhin und nicht ins Kleingedruckte, weil es die ehrliche Grenze dieses Verfahrens ist. Was wir dagegen tun können, steht im Abschnitt Das Logbuch.
Für diese Seite brauchst du kein Konto. Du kannst alles hier nachprüfen, bevor du dich anmeldest, und das ist Absicht. Wer wissen will, ob er uns seine Dateien anvertraut, soll das vorher herausfinden können und nicht erst danach.
Im Tresor selbst gibt es dafür noch eine zweite Ansicht, den Maschinenraum. Der läuft nur angemeldet und zeigt dir Schritt für Schritt mit, was gerade mit einer konkreten Datei passiert. Das ist die Frage nach deiner Datei. Hier geht es um die Frage nach dem Code: läuft in deinem Browser überhaupt das, was wir beschreiben. Zwei verschiedene Fragen, deshalb zwei getrennte Ansichten.
Deine Sitzung, gerade eben
Die folgenden Angaben sind nicht eingetippt. Sie werden ausgelesen, während du diese Seite ansiehst. Die Dateinamen enthalten einen Prüfwert des Inhalts und ändern sich bei jeder Änderung am Code.
Wird ausgelesen…
Den Prüfwert rechnet dein Browser selbst aus, mit derselben eingebauten Funktion, die auch der Tresor benutzt. Wir liefern ihn nicht mit. Vergleiche ihn mit dem, was andere Leute sehen. Stimmen die Werte überein, bekommt ihr alle dieselbe Datei.
Vorher einmal frisch laden
Dein Browser speichert diese Dateien lange zwischen. Wenn du den Tresor schon länger benutzt, rechnet dein Browser den Prüfwert womöglich über eine ältere Fassung aus, die noch bei dir liegt. Dann weicht dein Wert von dem eines neuen Besuchers ab, ohne dass irgendetwas faul wäre. Drück einmal Strg+Shift+R, bevor du Prüfwerte mit jemandem vergleichst. Das holt alles frisch vom Server.
Das Logbuch, und warum eine Kopie davon nicht reicht
Ganz oben steht der unangenehmste Satz dieser Seite: gegen Code, der gezielt nur an dich ausgeliefert wird, hilft keine Prüfung in deinem eigenen Browser. Dieser Abschnitt ist der Versuch, wenigstens einen Teil davon einzuholen.
Bei jeder Veröffentlichung schreiben wir die Prüfwerte der beiden Dateien in ein Logbuch. Das liegt offen unter /pruefwerte.json . Jeder Eintrag trägt zusätzlich ein Kettenglied: einen Prüfwert über den Vorgänger und sich selbst. Wer einen alten Eintrag nachträglich umschreibt, zerreißt damit alle folgenden. Dein Browser rechnet diese Kette gerade nach.
Warum hier kein grüner Haken steht
Diese Datei liegt auf demselben Server wie der Code, den sie bestätigen soll. Wer dir gezielt ein anderes Bundle schickt, kann dir genauso gut ein dazu passendes Logbuch schicken, samt heiler Kette. Deshalb gilt hier eine Asymmetrie, und wir halten uns daran: Wenn dein Prüfwert fehlt, ist das ein echtes Warnzeichen. Wenn er drinsteht, ist das nur eine Tatsache und kein Freispruch. Der Freispruch kommt erst aus der Archivkopie weiter unten.
Logbuch wird geprüft…
Der Schritt, der wirklich zählt
Vergleich das Logbuch mit einer Kopie, die wir nicht bearbeiten können. Zu jedem Eintrag, der es ins Internet Archive geschafft hat, liegt dort eine eigene Fassung mit Zeitstempel. In der Tabelle oben führt die Spalte Archiv direkt dorthin. Wenn wir einen alten Eintrag stillschweigend ändern würden, stünde die alte Fassung weiterhin dort. Wo in der Spalte keine Kopie steht, gibt es diesen Vergleich nicht. Warum, steht weiter unten.
Was du dort siehst, ist der komplette Stand des Logbuchs zum Zeitpunkt der Kopie. Der Prüfwert, den dein Browser oben ausgerechnet hat, muss darin auftauchen. Tut er das, hat jemand ausserhalb unserer Reichweite festgehalten, dass dieser Wert spätestens zum Zeitstempel der Kopie in unserem Logbuch stand. Mehr sagt ein Schnappschuss nicht aus, und weniger auch nicht.
Der Zeitstempel in diesen Links steht in unserem Logbuch, also könnten wir ihn theoretisch auf einen anderen Schnappschuss zeigen lassen. Wenn du das ausschliessen willst, nimm den Zeitstempel aus der Adresse heraus und ersetz ihn durch eine 2. Dann sucht das Archiv selbst den neuesten Stand zu dieser Adresse. Direkt nach einer Veröffentlichung landest du damit kurzzeitig auf der Speicherseite des Archivs, weil dessen Index ein paar Minuten hinterherhinkt. Der festgenagelte Link funktioniert dann schon.
Jeder Eintrag bekommt eine eigene Adresse, weil das Archiv sonst dedupliziert und bei zwei Veröffentlichungen kurz hintereinander nur die erste ablegt. Die Adressen unterscheiden sich nur im angehängten Zeitstempel und liefern alle dieselbe Datei. Neueste archivierte Fassung
Diesen Vergleich musst du selbst anklicken, wir holen ihn absichtlich nicht automatisch. Würde diese Seite das Archiv im Hintergrund abfragen, müsste in unserer Sicherheitsregel eine vierte Adresse stehen. Dann wäre der Satz in Abschnitt 2 nicht mehr wahr, dass dein Browser mit genau drei Adressen spricht. Ein Beweis, der einen anderen Beweis kaputt macht, ist keiner.
1. Der Worker, in voller Länge
Das ist der schnellste Beweis, und deshalb steht er zuerst. Die eigentliche Verschlüsselung läuft in einem eigenen kleinen Programm, einem Worker. Diese Datei ist so klein, dass du sie ganz lesen kannst, auch ohne Programmierkenntnisse. Sie steht unten vollständig da, geholt von derselben Adresse, von der dein Browser sie holt.
Zwei Dinge sind daran wichtig. Erstens: in dieser Datei steht keine einzige Anweisung, die etwas ins Netz schicken könnte. Zweitens: in dieser Datei steht nichts über Passwörter. Der Worker bekommt einen fertigen Schlüssel gereicht und weiß nicht, woher der kommt.
2. Wohin dein Browser überhaupt spricht
- F12 drücken, Reiter Netzwerk öffnen.
- Seite mit Strg+R neu laden, damit alles mitgeschnitten wird.
- Die Spalte Domain einblenden. Rechtsklick auf die Spaltenüberschrift, dann Domain anhaken.
- Nach Domain sortieren und die Liste ansehen.
Du wirst genau drei Adressen finden: tresor.datenputzer.de, datenputzer.de für die Anmeldung und nbg1.your-objectstorage.com für den Speicher selbst. Eine vierte gibt es nicht. Kein Google, kein Analysedienst, kein Werbepixel, kein Schriftarten-Anbieter.
Auf dieser Seite hier siehst du zusätzlich eine Anfrage nach /pruefwerte.json und je eine nach den beiden Dateien aus dem Abschnitt darüber. Die holt diese Seite selbst, um dir die Prüfwerte auszurechnen. Sie gehen an unsere eigene Adresse und kommen auf den anderen Seiten des Tresors nicht vor.
Das musst du nicht als Versprechen nehmen. Unser Server schickt bei jedem Aufruf eine Sicherheitsregel mit, die dem Browser verbietet, mit anderen Adressen zu sprechen. Sie heißt Content-Security-Policy. Du siehst sie im Netzwerk-Reiter, wenn du die erste Anfrage anklickst und unter Antwortheader nachsiehst. Wenn wir es uns morgen anders überlegen und einen Fremdanbieter einbauen, müssten wir diese Regel öffnen, und das ist von außen sichtbar.
Der Speicher-Anbieter sieht dabei verschlüsselte Blöcke und wie groß sie sind. Er sieht keine Dateinamen und keine Inhalte. Was er trotzdem erfährt, steht offen in der Dokumentation unter Metadaten.
3. Läuft wirklich diese Datei?
Eine Datei zu lesen, die irgendwo herumliegt, beweist noch nichts. Die Frage ist, ob genau diese Datei ausgeführt wird. Dafür gibt es zwei kurze Wege.
Weg A: die Konsole fragen
Entwicklertools öffnen, Reiter Konsole, folgende Zeile einfügen und Enter drücken. Sie listet auf, welche Skripte diese Seite tatsächlich geladen hat.
[...document.scripts].map(s => s.src).filter(Boolean)Manche Browser verlangen beim ersten Mal, dass du erlauben eintippst, bevor Einfügen in die Konsole freigeschaltet wird. Das ist ein Schutz vor Betrugsmaschen und völlig in Ordnung.
Weg B: den Worker im Baum sehen
Reiter Quellen öffnen, dann links in der Leiste den Bereich Threads aufklappen. Solange der Tresor entsperrt ist und du eine Datei hoch- oder herunterlädst, taucht dort ein zweiter Eintrag neben dem Hauptfenster auf. Das ist der Krypto-Worker. Klick ihn an, dann siehst du genau die Datei, die er ausführt, und kannst den Namen mit dem aus Abschnitt 1 vergleichen.
4. Haltepunkt setzen und in den Klartext sehen
Das ist der Beweis, der wirklich zählt, denn er zeigt dir die Daten in dem Moment, in dem sie verschlüsselt werden. Wir liefern seit dem 27.08.2026 absichtlich Sourcemaps mit. Das sind Übersetzungshilfen, mit denen dein Browser den zusammengestauchten Code wieder in den ursprünglichen, lesbaren Quelltext zurückverwandelt, samt unserer Kommentare. Viele Anbieter lassen die weg. Im Frontend liegt kein Geheimnis, also gibt es keinen Grund dafür.
- Entwicklertools öffnen, Reiter Quellen.
- Strg+Shift+F drücken. Das ist die Suche über alle geladenen Dateien.
- Einen der Begriffe aus der Tabelle unten eingeben.
- Auf den Treffer klicken. Du landest im lesbaren Original, nicht im gestauchten Code.
- Links auf die Zeilennummer klicken, um dort anzuhalten. Dann im Tresor eine Datei hochladen.
- Der Browser hält an. Fahre mit der Maus über die Variablen, dann siehst du die echten Werte.
| Suchbegriff | Wo das hinführt | Treffer |
|---|---|---|
| It never receives a password. | Kommentar in cryptoWorker.js | |
| There is deliberately NO password-to-master-key derivation | Kommentar in crypto.js | |
| 6e5 | die echte Iterationszahl im ausgelieferten Code |
Such am besten aus der Anwendung heraus und nicht von dieser Seite aus. Die Suchbegriffe stehen hier ja als Text auf dem Bildschirm, und die Suche der Entwicklertools durchsucht auch die Seite, die du gerade ansiehst. Im ausgelieferten Programmcode haben wir sie absichtlich zerlegt hinterlegt, damit sie deine Suche nicht verfälschen.
Wir schreiben die Trefferzahlen nicht fest hin, sondern zählen sie auf Knopfdruck in dem Code, den du gerade geladen hast. Eine festgetippte Zahl wäre spätestens nach dem nächsten Update falsch. Das Nachzählen lädt die Übersetzungshilfen herunter, das sind ein paar Megabyte, deshalb passiert es erst, wenn du es willst.
Wenn du nur gestauchten Code siehst
Dann liegt vermutlich eine ältere Fassung in deinem Browser-Zwischenspeicher, aus der Zeit vor den Sourcemaps. Drück einmal Strg+Shift+R. Das lädt alles frisch, und danach ist der lesbare Quelltext da.
5. Nachsehen, welche Zeilen wirklich liefen
Es reicht nicht, dass guter Code da ist. Er muss auch ausgeführt werden. Dafür haben die Entwicklertools ein Werkzeug namens Coverage, auf Deutsch Abdeckung.
- Entwicklertools öffnen, Strg+Shift+P drücken, Coverage eintippen und den Eintrag zum Anzeigen wählen.
- Auf Aufzeichnen drücken, dann im Tresor eine Datei hochladen.
- Auf das Bundle doppelklicken. Ausgeführte Zeilen sind grün markiert, nie ausgeführte rot.
So siehst du zum Beispiel, dass die Verschlüsselungsfunktion beim Hochladen tatsächlich durchlaufen wird und nicht nur dekorativ herumsteht.
6. Der Gegenbeweis: Code ändern und zusehen
Das ist der strengste Test auf dieser Seite. Alle bisherigen Schritte zeigen dir Code. Dieser hier zeigt dir, dass es derselbe Code ist, der läuft. Denn wenn du ihn kaputt machst und die Anwendung daraufhin kaputt geht, dann war es der echte.
- Reiter Quellen, links den Bereich Überschreibungen öffnen und einen Ordner auf deiner Festplatte dafür auswählen.
- Den Krypto-Worker aus Abschnitt 1 im Baum suchen und im Kontextmenü das Überschreiben einschalten.
- Irgendetwas darin verändern. Zum Beispiel "AES-GCM" in "AES-XXX" ändern, dann speichern.
- Seite neu laden und eine Datei hochladen.
Der Upload muss jetzt scheitern. Tut er das, hast du bewiesen: die Datei, die du gelesen hast, ist die Datei, die deine Dateien verschlüsselt. Nicht eine Kopie, nicht eine Beruhigungsfassung für neugierige Nutzer.
Danach die Überschreibung wieder abschalten, sonst bleibt sie in deinem Browser aktiv und der Tresor funktioniert weiter nicht. Diese Änderung passiert nur bei dir und erreicht unseren Server nie.
Grenzen, ohne Schönfärberei
- Es gilt für diese Sitzung. Alles hier prüft den Code, den du gerade geladen hast. Ein Anbieter könnte einem einzelnen Nutzer gezielt anderen Code schicken. Dagegen hilft nur, Prüfwerte öffentlich zu vergleichen. Deshalb steht der Prüfwert oben zum Kopieren.
- Das Logbuch steht auf unserem eigenen Server. Es gibt eine fortlaufende Liste der Prüfwerte, und ihre Einträge sind untereinander verkettet. Gegen jemanden, der dir gezielt ein anderes Bundle schickt, hilft trotzdem erst der Vergleich mit der Archivkopie, weil nur die außerhalb unserer Reichweite liegt.
- Dein Browser und dein Betriebssystem bleiben außen vor. Wer deinen Rechner kontrolliert, sieht deine Dateien, bevor sie überhaupt verschlüsselt werden. Keine Verschlüsselung der Welt ändert daran etwas.
- Erweiterungen können mitlesen. Eine Browser-Erweiterung mit Vollzugriff auf die Seite kann alles sehen, was du siehst. Für einen ernsthaften Test nimm ein frisches Profil ohne Erweiterungen.
- Das hier prüft den Client. Was auf dem Server läuft, kannst du von außen nicht nachsehen. Der ganze Aufbau ist genau deshalb so gebaut, dass es egal ist: der Server bekommt nie deinen Schlüssel. Ob das stimmt, prüfst du an dem, was dein Browser rausschickt, und das steht in Abschnitt 2 und 4.
Findest du etwas, das nicht zu dieser Beschreibung passt, schreib uns: support@datenputzer.de. Ein Widerspruch zwischen dieser Seite und dem echten Code ist ein Fehler, den wir wissen wollen.