Datenschutz · 9 Min. Lesezeit

Die versteckten Sicherheitsrisiken von Cloud-PDF-Convertern (und warum lokale Verarbeitung gewinnt)

Einen Vertrag bei einem kostenlosen Online-Converter hochzuladen fühlt sich an wie das Benutzen eines Taschenrechners. Technisch ähnelt es eher dem Versand des Dokuments an ein nie geprüftes Unternehmen, in einer nicht recherchierten Rechtsordnung, unter ungelesenen Aufbewahrungsbedingungen. Das Ergebnis sieht meist gut aus — genau deshalb bleibt das Risiko unsichtbar.

Dieser Beitrag zeigt, was zwischen Upload-Knopf und Download-Link tatsächlich mit der Datei geschieht, welche konkreten Pflichten diese Kette für jeden auslöst, der fremde Daten verarbeitet, und wie browserbasierte WebAssembly-Verarbeitung die Kette entfernt, statt sie abzusichern.

Was der Upload-Pfad wirklich berührt

Ein Dokument wandert nicht vom Browser zu einer einzelnen Maschine. Es passiert ein CDN oder einen Reverse Proxy, der TLS terminiert, einen Upload-Endpunkt, der in Objektspeicher schreibt, eine Queue, einen Worker-Pool mit lokalem Scratch-Verzeichnis und einen Download-Endpunkt, der das Ergebnis oft über eine URL mit langem Zufallstoken statt über eine authentifizierte Sitzung ausliefert.

An jeder Station existiert der Klartext. TLS schützt die Leitung, nicht die Server: Am Proxy wird die Datei entschlüsselt, bevor sie erneut verschlüsselt oder auf Platte geschrieben wird. Objektspeicher mag verschlüsselt sein, doch den Schlüssel hält der Anbieter — Verschlüsselung im Ruhezustand schützt gegen eine gestohlene Festplatte, nicht gegen den Betreiber, eine falsch konfigurierte Bucket-Policy oder ein kompromittiertes Admin-Konto.

Am unsichtbarsten sind Scratch-Dateien. Konvertierer schreiben Zwischenartefakte — gerasterte Seiten, extrahierte Bilder, temporäre Schriften — und die Aufräumroutine setzt voraus, dass der Prozess normal endet. Abgestürzte Jobs hinterlassen regelmäßig Reste, die keine Löschfrist erfasst, weil Fristen auf dem Speicher-Bucket durchgesetzt werden, nicht auf flüchtigen Container-Dateisystemen.

Dazu kommen Token-URLs. „Ihre Datei liegt unter /d/8f2c…“ ist eine Berechtigung, keine Authentifizierung. Solche Links landen im Browserverlauf, in Proxy-Logs, in Chatnachrichten beim Weiterleiten und in Referer-Headern. Wer die Zeichenkette hat, hat das Dokument, solange es gespeichert bleibt.

  • TLS endet am Edge — der Origin sieht Klartext
  • Verschlüsselung im Ruhezustand schützt nicht vor dem Betreiber
  • Abgestürzte Worker hinterlassen Reste außerhalb der Löschfrist
  • Token-Download-URLs sind Zugangsdaten, die über Logs abfließen

Löschversprechen sind betrieblich schwer einzuhalten

„Dateien werden nach einer Stunde gelöscht“ ist meist ehrlich gemeint und trotzdem schwer zu garantieren. Ein Objekt aus einem Bucket zu löschen entfernt es nicht aus Backup-Snapshots, regionsübergreifenden Repliken, dem CDN-Cache, der den Download ausgeliefert hat, oder aus dem Observability-Stack, der bei einer Fehlersuche einen Request-Body mitgeschnitten hat.

Besonders relevant sind Log-Pipelines. Fehler-Tracking erfasst im Fehlerfall häufig Request-Kontext. Stürzt eine Konvertierung an einer ungewöhnlichen Datei ab, kann ein Stacktrace mit Nutzdatenfragment oder vollständigem Speicherpfad bei einem Drittanbieter mit ganz anderer Aufbewahrungsfrist und Rechtsordnung landen.

Nichts davon setzt böse Absicht voraus. Es ist die normale Folge eines verteilten Systems mit Backups, Caching und Monitoring. Ehrlich gelesen bedeutet die Stunde: „Die Primärkopie ist nach einer Stunde zur Löschung vorgesehen“ — eine deutlich schwächere Aussage, als die meisten Nutzer verstehen.

Die Compliance-Ebene, die übersprungen wird

Enthält das Dokument personenbezogene Daten Dritter — eine Gehaltsabrechnung, einen Mandantenvertrag, einen Arztbrief, einen Lebenslauf —, sind Sie Verantwortlicher und der Dienst Auftragsverarbeiter. Art. 28 DSGVO verlangt dafür einen schriftlichen Vertrag zu Zweck, Datenkategorien, Sicherheitsmaßnahmen, Unterauftragsverarbeitern und Löschung. Ein kostenloses Tool mit AGB-Häkchen und ohne AVV erfüllt das nicht, unabhängig davon, wie sorgfältig der Betreiber arbeitet.

Unterauftragsverarbeiter verschärfen das. Ein Dienst, der OCR über eine fremde API laufen lässt, in einer Cloud speichert und mit einer anderen überwacht, hat eine Kette, die Sie in Ihrem Verarbeitungsverzeichnis benennen können müssen. Die wenigsten kostenlosen Tools veröffentlichen sie.

Übermittlungen außerhalb des EWR kommen hinzu: Angemessenheitsbeschluss oder Standardvertragsklauseln plus Transfer Impact Assessment. Berufsgeheimnisse gehen noch weiter. In Deutschland ist die Offenbarung von Mandanten- und Patientendaten durch Anwälte, Steuerberater oder Ärzte über §203 StGB geschützt; die Einbindung externer Dienstleister verlangt besondere Vorkehrungen. „Die Datei lag nur eine Stunde dort“ ist keine Verteidigung.

Es gibt zudem eine Beweisebene ohne Datenschutzbezug. Handelt es sich um einen Vergleichsentwurf, ein Term Sheet oder einen unveröffentlichten Abschluss, geht es nicht um die Vertrauenswürdigkeit des Anbieters, sondern darum, ob Sie belegen können, dass das Dokument Ihren Kontrollbereich nie verlassen hat. Bei einem Upload-Dienst können Sie das nicht.

Dokumente verraten mehr als ihren sichtbaren Inhalt

Ein PDF trägt ein Document Information Dictionary und ein XMP-Paket: Autorname, erzeugende Anwendung samt Version, Erstellungs- und Änderungszeitpunkt. Exporte aus Office-Suiten behalten oft den ursprünglichen Autor und den internen Vorlagenpfad. Scans enthalten Gerätemodell und häufig eine Seriennummer.

Bei Schwärzungen wird das brisant. Ein schwarzes Rechteck über einem Absatz ist eine Annotation über einem Content-Stream, der den Text weiterhin enthält. Kopieren oder eine Textextraktion holt ihn wortgetreu zurück. Zuschnitte verhalten sich genauso: Die CropBox ändert den sichtbaren Bereich, die vollständigen Bilddaten bleiben in der Datei. Echte Schwärzung erfordert das Neuschreiben des Content-Streams und das Neucodieren betroffener Bilder.

Inkrementelle Speicherungen verschärfen das weiter. PDF erlaubt anhängendes Speichern, sodass eine mehrfach bearbeitete Datei sämtliche früheren Fassungen enthalten kann, rekonstruierbar über die älteren Querverweistabellen. Ein Upload legt dann nicht nur das Sichtbare offen, sondern die gesamte Bearbeitungshistorie.

„Der Converter brauchte doch nur das Layout“ unterschätzt die Offenlegung also deutlich. Alles Weitere — frühere Fassungen, nicht geflachte Schwärzungen, Änderungsreste, eingebettete Vorschaubilder weggeschnittener Bereiche — geht mit.

Wie clientseitige Verarbeitung tatsächlich funktioniert

Der Browser ist unauffällig zu einer leistungsfähigen Dokumentenlaufzeit geworden. WebAssembly führt kompilierten Code nahe nativer Geschwindigkeit in einer Sandbox ohne eigenes Dateisystem und ohne eigenen Netzzugriff aus. Eine nach Wasm kompilierte C- oder Rust-PDF-Bibliothek läuft damit in der Seite mit denselben Algorithmen wie auf einem Server — nur ohne Server.

Der Datenweg ist kurz. Die File System Access API oder ein einfaches Datei-Input liefert ein File-Objekt; das Lesen ergibt einen ArrayBuffer im Speicher des Tabs. Dieser Puffer geht in den linearen Wasm-Speicher, wird verarbeitet und kommt als neuer Puffer in einem Blob zurück. Der Download entsteht aus einer blob:-URL, die auf das Dokument beschränkt ist und nie über das Netz aufgelöst wird. Keine Anfrage transportiert die Bytes irgendwohin.

Rechenintensives läuft in Web Workern auf eigenen Threads, damit die Oberfläche reagiert; SharedArrayBuffer und Wasm-Threads ermöglichen paralleles Dekodieren, sofern Cross-Origin-Isolation-Header gesetzt sind. Die Darstellung nutzt Canvas und WebGL, OCR läuft als Wasm-Erkennungsmodul mit einmalig geladenen und gecachten Sprachmodellen. Textextraktion, Seitenumsortierung, Zusammenführen, Komprimieren, Rastern und Verschlüsseln sind reine Rechenoperationen auf einem Byte-Array — kein Algorithmus davon braucht einen Server.

Die ehrlichen Grenzen: Sehr große Dateien sind durch den Tab-Speicher begrenzt, je nach Browser und 64-Bit-Wasm-Build grob wenige Gigabyte; beim ersten Besuch wird das Wasm-Modul geladen, das größer ist als eine typische Seite; und was wirklich einen entfernten Dienst braucht, etwa ein Cloud-KI-Modell, wird durch Wunschdenken nicht lokal.

Am wichtigsten ist die Überprüfbarkeit. Entwicklertools öffnen, Netzwerk-Tab wählen, Konvertierung starten und zusehen: Ein lokales Werkzeug lädt Modul und Assets — und danach passiert während der Verarbeitung nichts. Diese Prüfung dauert zehn Sekunden und wiegt schwerer als jede Datenschutzerklärung. Aus demselben Grund funktioniert ein echt lokales Werkzeug auch mit getrennter Netzverbindung.

Eine praktikable Entscheidungsroutine

Klassifizieren Sie vor dem Konvertieren. Drei Fragen: Enthält die Datei personenbezogene Daten anderer Personen? Ist sie geschäftlich oder rechtlich sensibel? Unterliege ich einer Berufsverschwiegenheit? Jedes Ja schließt ein Upload-Tool aus, solange kein unterzeichneter AVV und keine dokumentierte Übermittlungsgrundlage existieren.

Für Dateien, die doch zu einem Anbieter gehen, erledigen Sie die unspektakuläre Prüfung: AVV, Unterauftragsverarbeiterliste, Hosting-Region, Löschfrist. Fehlt eines der vier, behandeln Sie das Werkzeug als ungeeignet für fremde Daten, statt das Fehlen als Versehen abzutun.

Besser sind Werkzeuge, bei denen sich die Frage nicht stellt. Eine browserbasierte Werkbank entfernt die Übermittlung — und damit Auftragsverarbeitung, Transfer Impact Assessment, Löschfristenfrage und Meldepflichtrisiko in einem Schritt; nicht durch eine gesicherte Pipeline, sondern durch das Fehlen einer solchen. Die PDF-Werkzeuge von Toolula arbeiten so: Zusammenführen, Teilen, Komprimieren, Drehen, Schwärzen, Signieren, OCR und Konvertieren laufen in Ihrem Tab, nachprüfbar im Netzwerk-Tab.

Behandeln Sie schließlich Metadaten bewusst. Vor externer Weitergabe Dokumentinformationen und XMP entfernen, Annotationen und Formularfelder flachlegen, echte Schwärzung statt gezeichneter Rechtecke anwenden und neu speichern, um die inkrementelle Historie zu entfernen. Lokal erledigt, wird dieser Bereinigungsschritt nicht selbst zur neuen Offenlegung.

Häufig gestellte Fragen

Reicht HTTPS nicht aus, um ein hochgeladenes Dokument zu schützen?

HTTPS schützt den Transportweg. Über das, was nach der TLS-Terminierung am Edge passiert, sagt es nichts: Dort wird die Datei entschlüsselt, in den Speicher geschrieben, in Worker-Scratch kopiert und womöglich in Logs erfasst. Transportsicherheit und Verarbeitungssicherheit sind verschiedene Probleme.

Wie prüfe ich, ob ein Werkzeug wirklich lokal arbeitet?

Entwicklertools öffnen, Netzwerk-Tab leeren und eine Konvertierung starten. Ein lokales Werkzeug lädt Code und Assets und stellt während der Verarbeitung keine Anfragen. Als zweite Probe die Netzverbindung trennen: Echte lokale Verarbeitung funktioniert offline weiter.

Entfernt das Löschen bei einem Converter wirklich jede Kopie?

Nicht zwingend. Gelöscht wird das Primärobjekt; Backup-Snapshots, regionsübergreifende Repliken, CDN-Caches und Monitoring-Logs folgen eigenen Zyklen. Das ist eine normale Eigenschaft verteilter Systeme — weshalb der vermiedene Upload verlässlicher ist als das Löschversprechen.

Warum ist ein schwarzer Balken keine echte Schwärzung?

Das Rechteck liegt über einem Content-Stream, der die Originalzeichen weiterhin enthält, sodass jede Textextraktion sie zurückholt. Echte Schwärzung schreibt den Content-Stream neu und codiert betroffene Bilder neu, sodass die Daten nicht mehr in der Datei stehen.

Gibt es Aufgaben, die im Browser wirklich nicht laufen?

Ja. Alles, was ein entferntes Modell oder eine lizenzierte Serverkomponente braucht, sowie Dateien, die den Tab-Speicher sprengen — typischerweise mehrere Gigabyte große Scans. Übliche PDF-Operationen wie Zusammenführen, Teilen, Komprimieren, Drehen, Signieren, OCR und Formatumwandlung sind reine Rechenarbeit und laufen lokal problemlos.

Lokale PDF-Werkbank öffnen