So prüfst du, ob ein Online-Tool deine Dateien hochlädt

Eine Verarbeitungsbehauptung ist testbar. Jedes Tool kann sagen, deine Dateien verließen dein Gerät nie; zur Evidenz wird sie erst, wenn der Netzwerkverkehr während einer echten Aufgabe beobachtbar und wiederholbar ist. Dieser Guide lehrt eine Methode — beobachte, was der Browser sendet, während das Tool arbeitet — und zeigt dieselbe Methode anschließend als dauerhaftes öffentliches Artefakt, damit Behauptungen über Toolars geprüft statt geglaubt werden können.

• Versprechen vs. EvidenzEin Label ist ein Versprechen, eine Aufzeichnung ist Evidenz; der Unterschied: Eine Aufzeichnung kann erneut abgespielt, untersucht und angefochten werden.
• Eine Methode, jedes ToolDie Methode ist werkzeugunabhängig: Sie läuft im eigenen Netzwerk-Panel des Browsers, dauert etwa eine Minute und funktioniert auf jeder Site, die du testen möchtest.
• An uns selbst geprüftDieser Guide nennt keinen anderen Dienst und behauptet nichts über das Verhalten anderer Sites; er lehrt die Prüfung und demonstriert sie an Toolars' eigener veröffentlichter Evidenz.

Im Netzwerkpanel lassen sich Anfragen während eines Tests prüfen. Die Aussage gilt nur für den erfassten Browserkontext, die beobachteten Kommunikationswege und das Zeitfenster.

Zeichne bis zum Ende der Verarbeitung und des Downloads auf. Notiere Version, Browserzustand und Umfang der Aufzeichnung. Ein DevTools-Protokoll allein garantiert nicht, dass jeder mögliche Kommunikationsweg erfasst wurde.

• Zuerst öffnen und löschenÖffne zuerst die Seite des Tools und das Netzwerk-Panel — Entwicklerwerkzeuge, dann der Netzwerk-Tab —, lösche das Protokoll und lasse die Aufzeichnung laufen. Das Laden der Seite erzeugt immer Anfragen für HTML, Skripte und Styles; dieser Shell-Verkehr ist erwartet.
• Mit einer Opferdatei arbeitenFühre nur die zu prüfende Aufgabe mit einer eigens erstellten Testdatei aus. Hintergrundanfragen sind weiterhin möglich; prüfe ihre Nutzlast, bevor du sie der Aufgabe zuordnest.
• Die Aktion beobachtenDrücke die Aktion des Tools und beobachte die Liste. Ein lokales Tool kann Code, Schriften oder Engine-Bausteine beim ersten Mal laden — und nach einem Warm-up-Lauf idealerweise gar nichts mehr.

Die eigentliche Fähigkeit ist, Seitenverkehr von Datenverkehr zu unterscheiden. Shell-Verkehr liefert die Anwendung an deinen Browser; Datenverkehr trägt Inhalte davon. Im Panel sehen beide einmal gewusst ganz anders aus.

• Shell-AnfragenSkripte, Styles, Schriften und Engines sind normale Seitenressourcen. Ein bekannter Pfad, eine Dateiendung oder eine kleine Anfrage beweist jedoch nicht, dass keine Nutzerdaten enthalten sind. Prüfe Ziel und Nutzlast.
• Die Upload-SignaturDateidaten können an dieselbe oder an eine andere Origin gesendet werden. Prüfe POST-, PUT- und multipart-Inhalte sowie andere Kommunikationswege. Methode, Ziel oder Größe allein beweisen keinen Upload.
• Öffnen und prüfenDie Größe allein beweist in beide Richtungen nichts: Komprimierte Blöcke, wiederaufsetzbare Sitzungen und WebSockets können eine Übertragung aufteilen. Die Evidenz sind Methode, Ziel und Inhalt der Anfrage — öffne sie und schau hin.

Ein Netzwerkprotokoll misst diesen Lauf in diesem Browser-Zustand — und genau den verändern Caches und Service Worker. Das Protokoll gut zu lesen heißt, diesen Zustand zu kontrollieren.

• Warm-up ist normalBei einem Wiederbesuch liefert eine aufgewärmte Site ihre Shell aus dem Speicher oder einem Service Worker, und das Panel zeigt weit weniger Anfragen als beim ersten Mal. Weniger Anfragen nach dem Warm-up ist das gesunde Aussehen eines lokalen Tools — an sich noch kein Beweis für irgendetwas.
• Sauber startenFür eine saubere Messung starte aus einem frischen Browser-Profil oder einem privaten Fenster, aktiviere die Cache-Deaktivierung des Panels und denke daran, dass der private Modus in nicht jedem Browser Service Worker blockiert.
• Den Worker blockierenDas öffentliche Skript beginnt jedes Szenario in einem neuen Browserkontext mit blockierten Service Workern. Das reduziert Einflüsse früherer Zustände. Dokumentiere trotzdem vorab geladene Ressourcen und den Beginn des Messfensters.

Füge einer Testdatei eine eindeutige Markierung hinzu und suche danach in den erfassten Anfragen. Kein exakter Treffer bedeutet nur, dass die Markierung nicht gefunden wurde. Kodierung, Kompression, Verschlüsselung, Teilübertragungen oder unvollständige Erfassung können sie verbergen.

Kombiniere die Markierungssuche mit einer Prüfung der Nutzlast und dokumentiere den Erfassungsumfang. Benenne, was dieser Lauf beobachtet hat und was er nicht ausschließen kann.

• Datei markierenErstelle eine Opferdatei und bette eine Markierung ein, die du selbst erzeugt und nie veröffentlicht hast: eine zufällige UUID in einer Textebene, einem Bildkommentar, einer PDF-Notiz. Die Eindeutigkeit macht einen Treffer bedeutsam.
• Verkehr durchsuchenDurchsuche erfasste URLs, Query-Strings und Anfrageinhalte. Ein Treffer zeigt die Markierung in einer aufgezeichneten ausgehenden Anfrage; prüfe auch deren Status. Das beweist keine Übertragung der gesamten Datei. Kein Treffer beweist nicht, dass keine Dateidaten das Gerät verlassen haben.
• WiederholenEin Canary deckt nur die beobachtete Sitzung ab — deshalb zählen wiederkehrende, terminierte Aufzeichnungen mehr als eine einzige gründliche Handprüfung.

Toolars betreibt dieselbe Methode als dauerhaftes öffentliches Artefakt: eine typisierte Verarbeitungsdeklaration für jedes Tool, eine Seite Vertrauenszentrum mit aufgezeichnetem Verkehr und ein maschinenlesbarer Beleg, der seine Grenzen so klar ausspricht wie seine Ergebnisse.

• Offengelegte HostsDie Seite Vertrauenszentrum listet jeden externen Host, den der Site-Shell erreichen kann, die mit Antworten ausgelieferten Sicherheits-Header und Schritte zur Selbstprüfung, die du per Hand im selben Netzwerk-Panel ausführst.
• Maschinenlesbarer BelegEin maschinenlesbarer Prüfbeleg unter /privacy-proof/verification-receipt.json veröffentlicht die Prüfbefehle, die gemessenen Szenario-Ergebnisse, die offengelegten externen Hosts und die Release-Revision zum Abgleich mit dem X-Toolars-Release-Antwort-Header der Site.
• Ehrliche GrenzenDer Beleg sagt genauso klar, was er nicht beweist: Das gemessene Fenster deckt diesen Lauf ab, nicht eine Prüfung dessen, was der Dienst jemals tun könnte.

Das offene Repository enthält ein ausführbares Prüfskript für die Live-Site. Seine Prüfungen gelten für die erfassten Anfragen und Messfenster. Ergebnis und Grenzen jedes Laufs stehen im zugehörigen Prüfbericht.

Der Harness liegt im öffentlichen Repository https://github.com/aixtral/toolars-open unter evidence-harness/. Er ist unter der MIT-Lizenz veröffentlicht und prüft die bereitgestellte Site — das, worum die Behauptung eigentlich geht —, nicht eine private Staging-Kopie.

• 6 konfigurierte SzenarienDas Skript konfiguriert 6 Szenarien: Bildkonvertierung mit Download, HEIC-Konvertierung, OCR, PDF-Drehung, CSV-Weitergabe und eine eigene Werkzeugkette. Konfiguriert bedeutet nicht bestanden: Prüfe Status, Messfenster und Release-Revision jedes Szenarios im Bericht.
• Drei InvariantenDie Prüfungen melden erkannte Uploads, Treffer für Canary-Markierungen und unerwartete Cross-Origin-Anfragen. Der offengelegte eigene Analyseproxy wird separat gezählt. Ein Erfolg gilt für diese Prüfungen im Messfenster, nicht für jede denkbare Datenübertragung.
• Release prüfenEin geplanter Workflow ist für Aufzeichnungen auf der Live-Website eingerichtet. Prüfe den letzten abgeschlossenen Lauf, sein Ergebnis und die Release-Kennung. Der Beleg auf der Website ist eine archivierte Stichprobe und wird durch diesen Workflow nicht automatisch erneuert. Eine fehlgeschlagene oder unvollständige Aufzeichnung beweist für sich allein kein Datenleck.

Ein Beleg ist nur so wertvoll wie seine Reproduzierbarkeit. Der Harness ist gebaut, damit ihn jeder gegen die Live-Origin ausführt und Ergebnisse Zeile für Zeile prüfen kann.

Null Anfragen bedeutet: Der Rekorder beobachtete im Messfenster keine Anfragen. Separat dokumentierter Aufwärmverkehr ist ausgenommen; Verhalten außerhalb der erfassten Kanäle, Version oder Sitzung ist damit nicht belegt.

• Klonen und prüfenKlone das Repository, wechsle in evidence-harness/, installiere seine Abhängigkeiten und ein Playwright-Chromium und führe das Verify-Skript mit der Live-Site als Ziel aus.
• Exit-Codes sind das UrteilDer Lauf schreibt privacy-proof-receipt.json und endet mit einem von null verschiedenen Code, wenn Unerwartetes die Grenze überschreitet — eine Anfrage mit Inhalt, ein Canary-String in einer URL oder ein Host, der nicht auf der veröffentlichten Liste der Site steht.
• Nur MetadatenDer Beleg zeichnet nur Anfrage-Metadaten auf — Methode, Host, Pfad, Ressourcentyp, ob ein Inhalt vorlag —, niemals Dateiinhalte, Anfragen- oder Antwortinhalte.

Ehrliche Verifikation umfasst ihre eigenen Grenzen. Sie zu kennen hält dich davon ab, eine saubere Netzwerkspur als Garantie zu überlesen, die sie nie war.

• Ein FensterEine saubere Spur deckt die beobachtete Sitzung ab — dieser Lauf, dieser Browser, diese Datei. Sie prüft weder die Server eines Anbieters, noch dessen Personal oder künftigen Code.
• Dein Gerät zähltWas dein Gerät verlässt, hängt auch von deinem Gerät ab: Ein kompromittierter Browser, eine bösartige Erweiterung oder ein geteiltes Profil kann Daten unabhängig von der Architektur eines Tools abfließen lassen.
• Fortbestehende EvidenzBehandle jede Datenschutzbehauptung — auch die dieser Site — als fortbestehende Evidenz, die neu erfasst wird, nicht als lebenslange Garantie. Genau deshalb läuft der Harness terminiert immer wieder statt sich auf eine gute Aufzeichnung auszuruhen.