Slogans lassen sich nicht prüfen. Traffic schon.
Viele beurteilen eine Seite zur „Online-Verschlüsselung“ nach einem Satz: lokal gerechnet, null Upload, Ende-zu-Ende. Solche Worte können auf jeder Website stehen – auch auf einer, die die Datei per POST an einen Server schickt und dort verschlüsselt. Sie sind kein Beleg.
Was Sie wirklich sehen können, sind die Anfragen dieses Tabs. Das Network-Panel listet Methode, URL, Query-String, Body und Teile der Analytics. Erscheinen dort der gerade gewählte Dateiname, die Passphrase oder ein Canary, den nur Sie kennen, ist lokale Verschlüsselung bereits gescheitert.
Die Umkehrung ist enger. Ein leeres Network-Panel zeigt nur, dass dieser Lauf jene Felder nicht als Geschäftsdaten gesendet hat. Es beweist nicht, dass der Speicher keinen Klartext hält, dass keine Erweiterung die Zwischenablage gelesen hat oder dass die nächste Version gleich bleibt. Der Nutzen: aus nicht prüfbarem Text eine wiederholbare Beobachtung machen.
Was „lokal“ wirklich meint
„Browser-lokal“ heißt nicht „diese Domain wirkt vertrauenswürdig“. Es heißt: Ver- und Entschlüsselung laufen in dem Tab, den Sie gerade sehen. Für AES-256-GCM ist der übliche korrekte Weg die Web Crypto API: Schlüsselableitung, Verschlüsselung und Auth-Tag laufen in der Krypto-Schnittstelle des Browsers – statt Klartext an eine entfernte API zu geben.
Ein typischer Dateiablauf: Sie wählen eine lokale Datei, das Skript liest sie als Binärblöcke im Speicher, verschlüsselt jeden Block, danach lädt der Browser den Chiffretext herunter. Die Datei .lock oder .enc ist das Ergebnis, keine Upload-Quittung. Eine Obergrenze von 5 GB pro Datei beschreibt die lokale Streaming-Kapazität, nicht einen Server, der 5 GB Klartext angenommen hat.
Trennen Sie außerdem „fachlichen Upload“ von „Anfragen, die die Seite sowieso sendet“. Eine sofort nutzbare Tool-Seite lädt weiter CSS und Skripte und kann Analytics ohne Nachrichtentext senden. Solche Anfragen belegen keinen Datei-Upload. Steht in einer Analytics-Query oder einem Body die gerade eingegebene Passphrase, ist das ein anderer Befund.
Ein prüfbarer Satz schlägt Adjektive: Klartext und Schlüssel für Passwortgenerator, Passwortstärke-Prüfung, UTM entfernen und Schwärzen und Datei-Ver-/Entschlüsselung bleiben standardmäßig im Browser; Einmal-Link darf nur Chiffretext senden, der Entschlüsselungsschlüssel liegt im URL-#-Fragment. MakePwd setzt Werkzeuge an dieser Grenze um – alle sofort nutzbar, ohne Konten. Ein Versprechen bleibt ein Versprechen. Network macht daraus eine Checkliste.
Testen Sie nicht mit echten Schlüsseln, Ausweisnummern oder ungeschwärzten Tabellen. Nutzen Sie eine wegwerfbare kleine Datei und eine einmalige lange Passphrase. Sie prüfen Traffic, nicht die Privatsphäre ein zweites Mal.
Eine wiederholbare Network-Prüfung
Wählen Sie zuerst eine Markierung, die in echter Arbeit nicht vorkommt. Nennen Sie die Datei canary-local-2026.xlsx, nutzen Sie eine zufällige lange Passphrase und schreiben Sie einen Satz ins Dokument, der nur in diesem Test existiert. Der Canary dient der Suche: im Network-Filter einfügen. Ein Treffer ist ein Fehlschlag.
Öffnen Sie DevTools, wechseln Sie zu Network, aktivieren Sie Preserve log und filtern Sie XHR / Fetch. Schauen Sie nicht nur erfolgreiche Anfragen an – abgebrochene oder 4xx-Aufrufe können bereits Klartext mitgeführt haben.
Führen Sie dann eine vollständige Aktion aus: Datei wählen, Passphrase eingeben, Verschlüsseln oder Erzeugen klicken. Lassen Sie das Panel offen und prüfen Sie die drei Stellen unten.
- Fügen Sie den Canary zuerst in den Filter ein und achten Sie auf einen roten Treffer. Gibt es einen, halten Sie an und lesen Sie diese Anfrage. Beurteilen Sie nicht weiter danach, ob es sich „lokal anfühlt“.
- Gibt es keinen Treffer, öffnen Sie jede XHR-/Fetch-Anfrage und vergleichen Sie Anfragezeile, Query-String und Body. Statische Ressourcen, Schriften und Skripte können Sie ignorieren.
- Filtern Sie Analytics-Pfade getrennt und öffnen Sie Query und Body. Seitentitel und Pfade dürfen vorkommen. Die gerade eingegebene Passphrase, das geprüfte Passwort, unbereinigte Ausgangstexte und Dateiinhalte nicht.
Die Anfragezeile lesen
Lesen Sie Pfad und Query nach ? Zeichen für Zeichen. Locator-Felder wie id dürfen vorkommen. Dateinamen, Passphrasen, geprüfte Passwörter und der Schlüssel hinter # nicht. Vergleichen Sie die volle Adresszeile mit der Anfragezeile: Ist der Teil hinter der Raute in der Anfragezeile, hat die Umsetzung ein Fragment wie eine Query behandelt oder ein Skript ihn gelesen und in eine Anfrage geschrieben.
Den Request-Body lesen
POST-/PUT-Payloads sind die zweite Stelle. Beansprucht Dateiverschlüsselung, lokal fertig zu sein, darf der Body weder Originaldatei-Bytes noch die Passphrase enthalten. Einmal-Link darf ein Chiffretext-Feld haben – das ist erwarteter ausgehender Datenverkehr; prüfen Sie, dass er nicht wie der gerade eingegebene Text aussieht. Sendet eine Passwortstärke-Prüfung das Passwort per POST, hat es das Gerät bereits verlassen – egal ob der Zweck als „Leak-Suche“ oder „Stärkebewertung“ steht.
Analytics extra prüfen
Analytics werden leicht übersehen. Eine saubere Produkt-API mit einem Analytics-Treffer, der die volle Eingabe trägt, scheitert weiter am Satz „Klartext blieb im Browser“. Wenn Sie Analytics-Pfade filtern, nehmen Sie nicht an, „das Analytics-Skript sei harmlos“. Es ist eine weitere ausgehende Anfrage, geprüft wie eine Produkt-API.
Aktivieren Sie Preserve log. Nach der Verschlüsselung kann eine Navigation oder ein Reload die erste Anfrage mit Klartext löschen, wenn das Kästchen nicht gesetzt ist – und Sie erhalten ein falsch leeres Panel.
Queries gehen über HTTP. Fragmente in der Regel nicht.
Eine URL hat zwei Teile, die oft vermischt werden. Die Query hinter dem Fragezeichen kommt in die HTTP-Anfragezeile. Server, Reverse-Proxys und Zugriffsprotokolle können sie sehen. Das Fragment hinter der Raute bleibt standardmäßig im Browser für die Skripte der aktuellen Seite und wird mit dieser Dokumentanfrage nicht mitgeschickt.
Legt ein einmaliger Chiffretext-Link den Schlüssel in #, sieht der Server beim Öffnen von s.html?id=...#key absichtlich nur id, nicht den Schlüssel. Das ist kein zusätzliches Krypto-Protokoll, sondern das Standardverhalten von Fragmenten. Es hat Grenzen: Fügen Sie die volle Adresse in ein Ticket, einen Gruppenchat oder eine Weiterleitung ein, die den Hash verwirft, wandert der Schlüssel von „nicht in HTTP“ zu „auf fremden Bildschirmen und in Protokollen“.
Die Prüfung ist ebenso konkret: Legen Sie einen Test-Einmal-Link an und prüfen Sie, dass der Create-Body nur Chiffretext enthält; öffnen Sie die Leseseite und prüfen Sie, dass Dokumentanfrage und spätere APIs nur id enthalten. Der Teil hinter # in der Adresszeile darf in diesen Anfragen nicht vorkommen. Die Leseseite ist für Empfängerinnen und Empfänger öffentlich und braucht keine Anmeldung.
| Wohin schauen | Geht es über HTTP? | Was als bestanden gilt |
|---|---|---|
| Seiten-Slogan | Nicht beteiligt | Kein Beleg – nur zum Vergleich |
| Anfragezeile / Query | Ja | Kein Canary, keine Passphrase, kein Fragment-Schlüssel |
| POST-Body | Ja | Kein Klartext; Einmal-Link darf nur Chiffretext senden |
URL-#-Fragment |
In der Regel nein | In der Adresszeile vorhanden, in der Anfragezeile nicht |
| Analytics | Hängt von der Umsetzung ab | Kein Rohtext aus dem Eingabefeld |
Was Sie beweisen können – und was nicht
Die Schlussfolgerung dieser Prüfung ist eng. Diese Grenze aufzuschreiben ist nützlicher, als sie zu dehnen.
Sie kann stützen: In diesem Browser, dieser Version und diesem Vorgang haben Klartext, Passphrase und Fragment-Schlüssel den Tab nicht als beobachtete HTTP-Geschäftsdaten oder Analytics-Ausgangstext verlassen.
Sie kann nicht stützen: Kein anderer Tab und keine Erweiterung liest die Zwischenablage; der Download-Ordner ist sicher; Empfängerinnen und Empfänger machen nach dem Entschlüsseln kein Screenshot; die Passwortstärke-Prüfung deckt jedes Leak-Korpus ab. Macht die Prüfung nur lokale Entropie plus eine öffentliche Top-Liste schwacher Passwörter, beantwortet sie „wirkt das wie ein gängiges schwaches Passwort“, nicht „es kam nie in einem Leak vor“. Das ist kein netzweiter HIBP-Abgleich. Wie Sie den Geltungsbereich aufschreiben und die Zeilen der Liste sofort zählen, steht in Was eine lokale Liste schwacher Passwörter beweisen kann – und warum das kein netzweiter Leak-Abgleich ist.
Verstehen Sie es auch nicht als Penetrationstest. Sie haben weder WebSockets noch Service-Worker-Caches geprüft und keine verschleierten Skripte reversiert. Das Ziel: Kolleginnen und Kollegen sagen zu können: Ich habe Network geöffnet, den Canary gesucht, Anfragezeile und Body waren sauber. Das kommt einer technischen Diskussion näher als das Weiterleiten von „die Seite sagt, nichts wird hochgeladen“.
Dieselben Schritte auf sofort nutzbare Werkzeuge anwenden
Wenn Sie eine Seite wollen, die die Rechengrenze klar schreibt, beginnen Sie mit der MakePwd-Dateiverschlüsselung. Sie öffnet sich ohne Registrierung. Wählen Sie eine kleine Datei ohne echte Privatsphäre, nutzen Sie eine Canary-Passphrase, verschlüsseln Sie und laden Sie eine .lock herunter. Beobachten Sie Network: Statische Ressourcen und vielleicht Analytics ja, Originaldatei oder Passphrase als Geschäftsfelder nein. Die Site dokumentiert AES-256-GCM in Web Crypto, eine Datei bis 5 GB.
Einmal-Link ist die zweite Übung: Legen Sie einen harmlosen Testtext an und prüfen Sie, dass ausgehende Daten Chiffretext sind. Die Leseseite ist für Empfängerinnen und Empfänger öffentlich; die Linkform ist s.html?id={id}#{key}. Die Passwortstärke-Prüfung übt „kommt das Eingabefeld in Analytics“ – das geprüfte Passwort wird nicht hochgeladen, der Abgleich läuft gegen eine lokale Liste.
Diese Übungen beweisen nicht, dass eine Site „absolut sicher“ ist. Sie machen dieselbe Checkliste vertraut. Auf jeder Seite, die lokale Verschlüsselung behauptet, bleiben die Schritte: Canary, Preserve log, Anfragezeile, Body, Analytics.
Drei Dinge für das nächste Mal
Erstens: Traffic beobachten, nicht Slogans. Zweitens: Ausgehender Chiffretext kann akzeptabel sein; Schlüssel und Klartext nicht. Drittens: Canary-Suche nach Browser-, Versions- oder Funktionswechsel erneut ausführen. Nur eine wiederholbare Beobachtung gehört in Ihre eigenen Sicherheitshinweise.
Wenn die nächste Frage lautet, warum ein Schlüssel hinter der Raute stehen darf, lesen Sie Warum ein URL-Fragment hinter der Raute ein passender Ort für einen Schlüssel ist – und wann dieser Schutz wegfällt. Dieser Text macht aus „hat Klartext diesen Tab verlassen?“ eine Prüfung, die Sie sofort abschließen können.