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.

Le panneau Réseau permet d'examiner les requêtes d'un test. La preuve se limite au contexte du navigateur, aux canaux et à la période effectivement capturés.

Enregistrez jusqu'à la fin du traitement et du téléchargement. Notez la version, l'état du navigateur et le périmètre de capture. Un journal DevTools seul ne garantit pas que tous les canaux réseau possibles ont été capturés.

• 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 uniquement la tâche à vérifier avec un fichier de test préparé à cet effet. Des requêtes de fond restent possibles : examinez leur contenu avant de les attribuer à la 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'enveloppeScripts, styles, polices et moteurs sont des ressources normales de la page. Un chemin connu, une extension ou une petite requête ne prouvent pas l'absence de données utilisateur. Examinez la destination et le contenu envoyé.
• La signature du téléversementLes données du fichier peuvent partir vers la même origine ou une autre. Examinez les corps POST, PUT et multipart ainsi que les autres canaux. La méthode, la destination ou la taille seules ne prouvent pas un envoi de fichier.
• 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 workerLe script public démarre chaque scénario dans un nouveau contexte avec les Service Workers bloqués, afin de réduire l'influence de l'état précédent. Notez aussi les ressources préchargées et le début de la période mesurée.

Insérez un marqueur unique dans un fichier de test, puis cherchez-le dans les requêtes capturées. L'absence de correspondance exacte signifie seulement que le marqueur n'a pas été trouvé. Encodage, compression, chiffrement, transfert partiel ou capture incomplète peuvent le masquer.

Associez la recherche du marqueur à l'inspection du contenu envoyé et documentez le périmètre de capture. Précisez les observations de cette exécution et ce qu'elle ne permet pas d'exclure.

• 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 traficCherchez dans les URL, paramètres et corps capturés. Une correspondance indique que le marqueur figure dans une requête sortante enregistrée ; vérifiez aussi son état. Cela ne prouve pas le transfert du fichier entier. L'absence de correspondance ne prouve pas qu'aucune donnée du fichier n'a quitté l'appareil.
• 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 Centre de confiance 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 Centre de confiance 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.

Le dépôt ouvert fournit un script exécutable sur le site public. Ses contrôles couvrent les requêtes et les périodes enregistrées. Consultez le rapport de chaque exécution pour ses résultats et ses limites.

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.

• 6 scénarios configurésLe script configure 6 scénarios : conversion d'image avec téléchargement, conversion HEIC, OCR, rotation PDF, transfert CSV et chaîne d'outils personnalisée. Une configuration n'est pas un résultat réussi : vérifiez chaque statut, période de mesure et révision dans le rapport.
• Trois invariantsLes contrôles signalent les envois détectés, les correspondances de marqueurs et les requêtes interorigines inattendues. Le proxy d'analyse propriétaire déclaré est compté séparément. Une réussite concerne ces contrôles sur la période mesurée, pas tous les transferts possibles.
• Vérifier la versionUn workflow planifié est configuré pour capturer le site en production. Vérifiez la dernière exécution terminée, son résultat et sa révision. Le reçu du site est un échantillon archivé que ce workflow ne met pas à jour automatiquement. Une capture échouée ou incomplète ne prouve pas à elle seule une fuite de données.

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.

Zéro requête signifie que l'enregistreur n'en a observé aucune pendant cette période. Le trafic de préparation documenté séparément est exclu ; cela ne prouve rien hors des canaux, de la version ou de la session capturés.

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