So prüfen Sie, dass Ihre Dateien nicht hochgeladen werden
Jede dieser Seiten behauptet, alles bleibe privat. Wie prüfe ich das wirklich nach?
Gehen Sie von der richtigen Annahme aus
Ein Datenschutzversprechen auf einer Marketingseite ist kein Beweis. Ein Schloss-Symbol, ein Siegel oder ein Satz in einer Datenschutzerklärung ebenso wenig – sie beschreiben Absichten, und was Sie wissen wollen, ist das Verhalten. Zum Glück lässt sich Verhalten beobachten: Jeder Browser bringt Werkzeuge mit, die Ihnen genau zeigen, was eine Seite versendet, und man muss kein Entwickler sein, um sie zu lesen.
Führen Sie diese Prüfungen auf dieser Website durch. Führen Sie sie auf der Website durch, die Sie vorher benutzt haben. Es geht nicht darum, einem anderen Versprechen zu vertrauen, sondern darum, überhaupt keines mehr zu brauchen.
Prüfung eins: das Netzwerk-Panel beobachten
- Öffnen Sie die Entwicklertools. In den meisten Desktop-Browsern geht das mit F12, Strg+Umschalt+I oder Cmd+Option+I.
- Wählen Sie den Tab „Netzwerk“ und vergewissern Sie sich, dass die Aufzeichnung läuft.
- Laden Sie die Seite neu und leeren Sie dann die Liste, damit Sie mit einem leeren Protokoll beginnen.
- Wählen Sie Ihre Datei aus und starten Sie den Vorgang.
- Sortieren Sie nach Größe oder achten Sie in der Spalte „Methode“ auf POST- und PUT-Anfragen.
Sie suchen nach jeder Anfrage, deren Nutzdaten in der Größenordnung Ihrer Datei liegen, und nach jeder Anfrage überhaupt an einen Host, der nicht die Website ist, auf der Sie sich befinden. Ein lokales Werkzeug zeigt Anfragen für seinen eigenen Code – Skripte, Stylesheets, WebAssembly-Module, vielleicht eine Modelldatei – und danach nichts mehr, solange die Arbeit läuft. Ein Uploader zeigt in dem Moment, in dem Sie die Schaltfläche drücken, eine Anfrage, die mehrere Megabyte trägt.
Prüfung zwei: das Netzwerk wegnehmen
Das ist die stärkste Prüfung, und sie erfordert überhaupt keine Fachkenntnis. Laden Sie die Seite normal, benutzen Sie das Werkzeug einmal, damit jede benötigte Engine im Cache liegt, und trennen Sie dann die Verbindung: Flugmodus einschalten, WLAN abschalten oder den Offline-Schalter in den Entwicklertools benutzen. Verarbeiten Sie jetzt eine Datei.
Wenn der Vorgang durchläuft, kann die Verarbeitung nirgendwo anders als auf Ihrem Rechner stattgefunden haben. Da bleibt keine Mehrdeutigkeit, über die man streiten könnte. Scheitert er oder bleibt er hängen, hat irgendetwas in der Verarbeitungskette einen Server gebraucht – das kann legitim sein, etwa eine Modelldatei, die noch nicht im Cache lag, aber jetzt wissen Sie, dass Sie nachfragen sollten, welche.
Prüfung drei: die Content Security Policy lesen
Eine Content Security Policy ist ein Header, den die Website sendet und den der Browser durchsetzt. Ihre Direktive connect-src listet die Ziele auf, zu denen die Seite eine Verbindung öffnen darf. Ist connect-src auf das eigene Origin der Website beschränkt, blockiert der Browser selbst jeden Versuch, etwas anderswohin zu senden, ganz gleich, was der Code der Seite versucht.
Zum Nachlesen öffnen Sie den Tab „Netzwerk“, klicken auf die Anfrage des Dokuments – meist die erste Zeile – und sehen in den Antwort-Headern nach Content-Security-Policy. Eine Richtlinie mit connect-src 'self' und ohne externe Hosts ist eine belastbare, vom Browser durchgesetzte Einschränkung und kein Versprechen.
Was jede Prüfung beweist
| Prüfung | Was sie beweist | Was sie nicht abdeckt |
|---|---|---|
| Netzwerk-Panel | Was diese Seite in dieser Sitzung gesendet hat | Einen anderen Codepfad, eine spätere Version der Website oder eine Anfrage, nachdem Sie aufgehört haben hinzusehen |
| Offline-Test | Dass die Verarbeitung selbst lokal läuft | Ob etwas in eine Warteschlange gelegt und nach dem Wiederverbinden gesendet wird |
| Content Security Policy | Wohin der Browser Verbindungen überhaupt zulässt | Alles, was die Richtlinie erlaubt, einschließlich des eigenen Origin der Website |
| Den Quellcode lesen | Was der ausgelieferte Code enthält | Den Aufwand; und es muss wiederholt werden, wenn sich die Website ändert |
Zusammen sind sie stark. Für sich genommen hat jede eine Lücke, und wer Ihnen erzählt, eine einzelne Prüfung kläre die Frage, vereinfacht zu stark.
Anzeichen dafür, dass ein Werkzeug nicht lokal arbeitet
- Ein Fortschrittsbalken, dessen Tempo nichts mit Ihrem Gerät zu tun hat – gleichmäßig und identisch auf einem schnellen Laptop wie auf einem alten Handy.
- Ein Ergebnis, das als Link auf eine Download-URL unter deren Domain geliefert wird und nicht als Datei, die Ihr Browser bereits hält.
- Ein Hinweis, dass Dateien nach einigen Stunden von deren Servern gelöscht werden. Dieser Satz ist ein Eingeständnis, dass die Dateien dort waren.
- Eine Warteschlange oder ein Ratenlimit. Ihr eigener Prozessor hat keine Warteschlange, die er sich mit anderen Menschen teilt.
- Das Werkzeug arbeitet ohne Netzwerkverbindung nur bei der ersten kleinen Datei und hört dann auf.
Die Grenzen der Überprüfung
Eine Überprüfung sagt etwas über die Version der Website aus, die Sie getestet haben, an dem Tag, an dem Sie sie getestet haben. Eine Website kann sich morgen ändern. Deshalb zählen die strukturellen Prüfungen am meisten: Eine restriktive Content Security Policy und ein funktionierender Offline-Test sind Eigenschaften der Bauweise der Anwendung und keine Versprechen zu einer bestimmten Fassung.
Zwei Dinge bleiben außerhalb jeder Prüfung auf dieser Liste. Eine Browser-Erweiterung kann den Inhalt jeder Seite lesen, einschließlich der Datei, die Sie darin geladen haben, und keine Website kann das verhindern. Ihr Betriebssystem sieht jede Datei, die Sie öffnen. Wenn ein Dokument so heikel ist, dass das ins Gewicht fällt, verarbeiten Sie es in Offline-Software auf einem Rechner, den Sie kontrollieren, und betrachten Sie jede Website – auch diese – als das falsche Werkzeug für diese Aufgabe.
Passende Tools
Quellen
- W3C — Content Security Policy Level 3
- MDN — Content-Security-Policy connect-src
- Chrome DevTools — inspect network activity
- MDN — Firefox Network Monitor