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.

Jeder Desktop-Browser liefert einen Netzwerk-Monitor, der jede Anfrage einer Seite aufzeichnet. In der richtigen Reihenfolge angewendet beantwortet er die Upload-Frage direkt: Hat eine Anfrage meine Datei von diesem Gerät getragen?

Schließe die Arbeit ab und lade das Ergebnis herunter, während das Panel aufzeichnet. Die Einheit der Evidenz ist die ganze Sitzung: Ein Upload kann nur in einer Anfrage geschehen, und eine Anfrage kann einem vollständigen Protokoll nicht entgehen.

• 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 die Aufgabe mit einer Testdatei aus, die du nur dafür erstellt hast: konvertieren, drehen, komprimieren. Ein sauberes Startprotokoll bedeutet, dass jede sichtbare Anfrage zu deiner Aufgabe gehört.
• 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-AnfragenShell-Anfragen sind klein, cachebar und tragen Software-Namen — Skript-, Style-, Schrift- und Engine-Dateien unter den eigenen Pfaden der Site. Sie bringen den Code auf dein Gerät; sie tragen deine Datei nirgendwohin.
• Die Upload-SignaturEin Upload sieht aus wie eine POST-, PUT- oder Multipart-Anfrage mit einem Inhalt von etwa der Größe deiner Datei, gesendet an ein anderes Ziel als die eigene Origin der Seite. Wenn beim Klick auf Konvertieren so etwas abgeht, hat die Datei das Gerät verlassen.
• Ö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 blockierenDie stärksten Aufzeichnungen beginnen jeden Lauf in einem frischen Browser-Kontext mit blockierten Service Workern, sodass nichts aus dem Cache bedient und nichts vor der Aufzeichnung abgefangen wird. Der öffentliche Harness unten zeichnet genau so auf.

Der entscheidende Schritt über das bloße Beobachten hinaus: Gib deiner Testdatei eine eindeutige Markierung — einen Canary-String — und suche die aufgezeichneten Anfragen danach ab. Erscheint der String in keiner Anfrage, ist die Datei nicht gereist.

Das ist die überzeugendste Technik für Laien, weil sie die Bytes selbst prüft statt die Absichten des Tools.

• 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 durchsuchenSuche nach der Aufgabe die aufgezeichneten Anfragen des Panels nach der Markierung ab — Anfrage-URLs, Query-Strings und Inhalte. Ein Treffer bedeutet, die Bytes deiner Datei haben das Gerät verlassen; kein Treffer in der ganzen Sitzung ist starke, direkte Evidenz dafür, dass sie es nicht taten.
• 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 Privacy-Proof-Seite mit aufgezeichnetem Verkehr und ein maschinenlesbarer Beleg, der seine Grenzen so klar ausspricht wie seine Ergebnisse.

• Offengelegte HostsDie Privacy-Proof-Seite 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.

Dieselben Prüfungen sind als lauffähiger Harness im offenen Repository verpackt, sodass die Behauptung des lokalen Verarbeitens verifizierbar ist, ohne Toolars um irgendetwas zu bitten. Er steuert die Live-Site, zeichnet jede Anfrage einschließlich Worker-Zugriffe auf und schlägt lautstark an, wenn eine Grenze überschritten wird.

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.

• Vier SzenarienDer Harness steuert die Live-Site in headlessem Chromium durch vier Szenarien: eine Bildkonvertierung mit Download; eine HEIC-Konvertierung, deren gemessener Lauf nach dem Aufwärmen des Decoders null Anfragen ausgeben muss; eine OCR-Aufgabe mit einem zweiten Sprachpaket, das aus der eigenen Origin der Site kommen muss; und eine PDF-Drehung mit dem gebündelten Beispiel.
• Drei InvariantenÜber jedes gemessene Fenster hinweg beharrt er auf drei Invarianten: null Upload-Anfragen, null Canary-Lecks — die Bytes der Eingabedatei tragen eine zufällige Markierung — und null unerwartete Cross-Origin-Anfragen über den eigenen, offengelegten First-Party-Analyse-Proxy der Site hinaus, der gezählt und benannt statt ignoriert wird.
• Tägliche NeuerfassungEin terminierter Workflow erfasst den Beleg täglich neu gegen die Live-Site, und das Privacy-Proof-Badge des Repository ist nur dann grün, wenn das Ergebnis des neuesten Belegs verified lautet — ein fehlgeschlagener Lauf heißt violation oder inconclusive, niemals still grün.

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.

Weil jedes Szenario in einem frischen Browser-Kontext mit blockierten Service Workern beginnt, bedeutet eine Null-Anfragen-Messung das, was sie zu bedeuten scheint: Nach dem Warm-up hat der gemessene Lauf das Netzwerk überhaupt nicht berührt.

• 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.