Comment vérifier qu'un outil en ligne ne téléverse pas vos fichiers

Une affirmation de traitement est testable. N'importe quel outil peut dire que vos fichiers ne quittent jamais votre appareil ; l'affirmation ne devient une preuve que lorsque le trafic réseau pendant une tâche réelle est observable et reproductible. Ce guide enseigne une méthode —regardez ce que le navigateur envoie pendant que l'outil travaille— puis montre cette même méthode fonctionnant comme un artefact public permanent, pour que les affirmations sur Toolars puissent être vérifiées plutôt que crues.

• Promesses et preuvesUne étiquette est une promesse, une capture est une preuve ; la différence tient à ce qu'une capture peut être relue, inspectée et contestée.
• Une méthode, tous outilsLa méthode est indépendante de l'outil : elle s'exécute dans le panneau réseau du navigateur, prend environ une minute et fonctionne sur n'importe quel site que vous choisissez de tester.
• Vérifié sur nous-mêmesCe guide ne nomme aucun autre service et n'affirme rien sur le comportement d'aucun autre site ; il enseigne la vérification, puis la démontre sur la preuve que Toolars publie sur lui-même.

Chaque navigateur de bureau embarque un moniteur réseau qui enregistre chaque requête d'une page. Utilisé dans le bon ordre, il répond directement à la question du téléversement : une requête a-t-elle quitté cet appareil en portant mon fichier ?

Terminez le travail et téléchargez le résultat pendant que le panneau enregistre. L'unité de preuve est la session complète : un téléversement ne peut se produire qu'à l'intérieur d'une requête, et une requête ne peut se dissimuler à un journal complet.

• Ouvrir et vider d'abordOuvrez d'abord la page de l'outil et le panneau réseau — outils de développement, onglet Réseau —, videz le journal et laissez l'enregistrement actif. Le chargement de la page produit toujours des requêtes pour le HTML, les scripts et les styles ; ce trafic d'enveloppe est attendu.
• Utiliser un fichier sacrificielExécutez la tâche avec un fichier de test créé uniquement pour cela : convertissez-le, pivotez-le, compressez-le. Un journal propre au départ garantit que chaque requête visible appartient à votre tâche.
• Observer l'actionDéclenchez l'action de l'outil et observez la liste. Un outil local peut charger du code, des polices ou des moteors lors de la première utilisation — et, après un échauffement, idéalement plus rien.

La compétence consiste à distinguer le trafic de la page du trafic de données. Le trafic d'enveloppe livre l'application à votre navigateur ; le trafic de données emporte du contenu. Une fois qu'on sait quoi regarder, les deux n'ont plus du tout le même aspect dans le panneau.

• Requêtes d'enveloppeLes requêtes d'enveloppe sont petites, cachables et portent des noms de logiciel —scripts, styles, polices et moteurs sous les chemins propres du site—. Elles amènent le code sur votre appareil ; elles n'emportent votre fichier nulle part.
• La signature du téléversementUn téléversement ressemble à une requête POST, PUT ou multipart dont le corps fait à peu près la taille de votre fichier, envoyée vers une origine différente de celle de la page. Si une telle requête part quand vous cliquez sur convertir, le fichier a quitté l'appareil.
• Ouvrez et regardezLa taille seule ne prouve rien dans aucun sens : les fragments compressés, les sessions reprenables et les WebSockets peuvent découper un transfert. La preuve tient dans la méthode, la destination et le contenu de la requête — ouvrez-la et regardez.

Un journal réseau mesure cette exécution dans cet état du navigateur — et c'est précisément cet état que les caches et les service workers existent pour changer. Bien lire le journal, c'est contrôler cet état.

• L'échauffement est normalLors d'une visite répétée, un site déjà chaud sert son enveloppe depuis le disque ou un service worker, et le panneau affiche bien moins de requêtes que la première fois. Moins de requêtes après l'échauffement est l'aspect sain d'un outil local — ce n'est pas, à lui seul, une preuve de quoi que ce soit.
• Partir de zéroPour une lecture propre, partez d'un profil de navigateur neuf ou d'une fenêtre privée, activez l'option de désactivation du cache du panneau, et rappelez-vous que le mode privé ne bloque pas les service workers dans tous les navigateurs.
• Bloquer le workerLes captures les plus solides commencent chaque exécution dans un contexte de navigateur neuf avec les service workers bloqués, pour que rien ne soit servi depuis un cache ni intercepté avant d'être enregistré. Le harnais public ci-dessous enregistre exactement ainsi.

L'amélioration décisive par rapport à la simple observation : donnez à votre fichier de test un marqueur unique — une chaîne canari — puis cherchez cette chaîne exacte dans les requêtes capturées. Si les octets n'apparaissent dans aucune requête, le fichier n'a pas voyagé.

C'est la technique la plus convaincante à la disposition d'un non-spécialiste, parce qu'elle éprouve les octets eux-mêmes plutôt que les intentions de l'outil.

• Marquez le fichierCréez un fichier sacrificiel et incorporez un marqueur que vous avez généré vous-même et jamais publié : un UUID aléatoire dans un calque de texte, un commentaire d'image, une note PDF. C'est l'unicité qui donne son sens à une correspondance.
• Cherchez dans le traficAprès la tâche, cherchez le marqueur dans les requêtes capturées du panneau —URL, chaînes de requête et corps—. Une correspondance signifie que les octets de votre fichier ont quitté l'appareil ; l'absence de correspondance sur toute la session est une preuve directe et solide qu'ils ne l'ont pas fait.
• RépétezUn canari ne couvre que la session observée — c'est pourquoi des captures périodiques et récurrentes comptent plus qu'une seule vérification manuelle minutieuse.

Toolars fait tourner la même méthode comme un artefact public permanent : une déclaration de traitement typée pour chaque outil, une page Privacy proof avec du trafic capturé et un reçu lisible par machine qui énonce ses limites aussi clairement que ses résultats.

• Hôtes déclarésLa page Privacy proof liste chaque hôte externe que l'enveloppe du site peut atteindre, les en-têtes de sécurité servis avec les réponses, et des étapes d'autovérification que vous pouvez exécuter à la main dans le même panneau réseau.
• Reçu lisible par machineUn reçu de vérification lisible par machine à /privacy-proof/verification-receipt.json publie les commandes de vérification, les résultats de scénarios mesurés, les hôtes externes déclarés et la révision de publication à comparer avec l'en-tête de réponse X-Toolars-Release du site.
• Limites honnêtesLe reçu dit ce qu'il ne prouve pas aussi clairement que ce qu'il prouve : la fenêtre mesurée couvre cette exécution, pas un audit de tout ce que le service pourrait un jour faire.

Les mêmes vérifications sont empaquetées en harnais exécutable dans le dépôt ouvert, de sorte que l'affirmation de traitement local soit vérifiable sans rien demander à Toolars. Il pilote le site en production, enregistre chaque requête y compris celles des workers, et échoue bruyamment quand une frontière est franchie.

Le harnais vit dans le dépôt public https://github.com/aixtral/toolars-open, sous evidence-harness/. Il est publié sous licence MIT et vérifie le site déployé — la chose dont l'affirmation traite réellement —, pas une copie de préparation privée.

• Quatre scénariosLe harnais pilote le site en production dans Chromium headless à travers quatre scénarios : une conversion d'image avec téléchargement ; une conversion HEIC dont l'exécution mesurée doit émettre zéro requête après l'échauffement du décodeur ; une tâche OCR avec un second pack de langue qui doit arriver depuis la propre origine du site ; et une rotation PDF sur l'exemple fourni.
• Trois invariantsSur chaque fenêtre mesurée, il impose trois invariants : zéro requête de téléversement, zéro fuite de canari — les octets du fichier d'entrée portent un marqueur aléatoire — et zéro requête cross-origin inattendue au-delà du proxy d'analyse de première partie déclaré par le site, qui est compté et nommé plutôt qu'ignoré.
• Une recapture quotidienneUn flux planifié recapture le reçu contre le site en production chaque jour, et le badge privacy-proof du dépôt n'est vert que lorsque le résultat du dernier reçu est verified ; une exécution échouée se lit violation ou inconclusive, jamais silencieusement verte.

Un reçu ne vaut que par sa reproductibilité. Le harnais est conçu pour être exécuté par n'importe qui, contre l'origine en production, avec des résultats écrits dans un fichier inspectable ligne par ligne.

Comme chaque scénario commence dans un contexte de navigateur neuf avec les service workers bloqués, une mesure à zéro requête signifie ce qu'elle semble signifier : après l'échauffement, l'exécution mesurée n'a pas touché le réseau du tout.

• Cloner et vérifierClonez le dépôt, entrez dans evidence-harness/, installez ses dépendances et un Chromium Playwright, puis exécutez le script de vérification avec le site en production comme origine cible.
• Les codes de sortie sont le verdictL'exécution écrit privacy-proof-receipt.json et se termine par un code non nul si quelque chose d'inattendu franchit la frontière — une requête avec un corps, un canari dans une URL, ou un hôte absent de la liste publiée du site.
• Métadonnées seulementLe reçu n'enregistre que les métadonnées des requêtes —méthode, hôte, chemin, type de ressource, présence d'un corps—, jamais le contenu des fichiers, des requêtes ou des réponses.

La vérification honnête inclut ses propres limites. Les connaître empêche de surinterpréter une trace réseau propre en garantie qu'elle n'a jamais été.

• Une fenêtreUne trace propre couvre la session observée — cette exécution, ce navigateur, ce fichier. Elle n'audit ni les serveurs d'un fournisseur, ni son personnel, ni son code futur.
• Votre appareil compteCe qui quitte votre appareil dépend aussi de votre appareil : un navigateur compromis, une extension malveillante ou un profil partagé peut déplacer des données indépendamment de l'architecture de n'importe quel outil.
• Preuve permanenteTraitez chaque affirmation de confidentialité — y compris celle de ce site — comme une preuve permanente à recapturer, et non comme une garantie à vie. C'est exactement pourquoi le harnais se réexécute selon un calendrier au lieu de se reposer sur une bonne capture.