Ce que Dinoer ne fait pas dans votre dos

Vous vous apprêtez à donner à une chaîne de recherche l’accès à vos identifiants et au trafic sortant de votre machine. Voici sur quoi cela repose, avec le fichier qui garantit chaque point.

Dinoer ne met jamais vos identifiants dans un terminal

Ils ne passent jamais par votre shell, votre historique de commandes ni les journaux de Dinoer : la valeur est lue dans le répertoire chiffré, à l’intérieur du processus qui pilote le navigateur, au moment où un champ est rempli.

→ lib/repertoire_chiffre.py. Comment un identifiant atteint un formulaire →

Un scénario qui écrit un secret en clair est refusé avant le démarrage du navigateur : une action remplir sur un champ dont le sélecteur paraît sensible (password, token, otp, cvv et d’autres) avec une valeur autre que depuis_secrets, ou un script evaluer qui contient un jeton ou une clé à forte entropie.

Ce que Dinoer écrit est filtré par défaut : les valeurs renvoyées par evaluer, les URL et les messages d’erreur envoyés à la sortie ou au journal des opérations sont neutralisés. --no-filtre-evaluer désactive ce filtre, et la sortie l’indique alors (boussole.filtre_evaluer_actif: false).

→ lib/sanitisation.py

Ce que cela ne couvre pas : l’agent qui pilote Dinoer a son propre accès à votre machine. Avec un terminal, il peut lire votre répertoire monté comme n’importe quel autre fichier. Dinoer protège le chemin qu’il contrôle, pas celui que vous ouvrez à côté.

Le modèle qui rédige le rapport reste à l’écart du web

À chaque appel à OpenCode, invoquer_opencode() passe websearch et webfetch à deny dans OPENCODE_CONFIG_CONTENT, en fusionnant avec la valeur que vous aviez déjà définie. L’interdiction tient donc quel que soit le répertoire d’où Dinoer est lancé ; le fichier opencode.jsonc à la racine du dépôt dit la même chose pour un lancement depuis cet endroit. Mesuré le 25 septembre 2026 avec opencode debug config (OpenCode 1.18.32), lancé depuis /tmp : avec cette valeur, websearch et webfetch valent deny ; sans elle, allow.

→ lib/modeles.py::invoquer_opencode()

L’interdiction existe parce que, le 14 août 2026, une campagne a surpris le modèle en train de lancer douze recherches web pendant qu’il rédigeait le rapport. Elles n’apparaissaient que dans l’enregistrement complet de ses événements, pas dans le texte qu’il a rendu.

Ce que cela ne couvre pas : bash reste autorisé, parce que certains scénarios demandent au modèle d’envoyer une notification avec curl. Un modèle privé de websearch a atteint le web par bash curl lors d’un essai. Des garanties de cette page, c’est la seule qui soit incomplète.

Dinoer signale, il ne décide pas

pret_a_agir: false signifie que quelque chose a été remarqué : une signature de pare-feu applicatif (WAF), une dérive de session, un plafond de navigation atteint, des erreurs JavaScript. L’exécution continue : Dinoer signale, vous décidez.

La détection de WAF repose sur des mots-clés et peut se tromper. Elle apparaît comme un compte, jamais comme une erreur qui interrompt l’exécution, et --ignorer-waf existe pour le cas où vous avez vérifié.

Le cœur de navigation ne fait que ce qu’énumère le scénario, à une exception près

Chaque clic, chaque frappe et chaque navigation du cœur de navigation est une ligne d’un fichier de scénario, vérifié contre un schéma avant le démarrage du navigateur.

→ scenarios/schema.json

La chaîne de recherche est différente : campagne.py demande à un modèle de juger si une page répond à une question ouverte, ou si deux pages décrivent le même événement. Cette garantie couvre le cœur de navigation, pas ce jugement.

Vous pouvez tout revoir après coup

Chaque exécution est consignée dans un journal des opérations où l’on ne fait qu’ajouter : ce qui a été tenté, où, avec quel résultat, et l’intention déclarée. journal.py le lit.

→ journal.py, /var/log/dinoer/operations.jsonl

Ce qui sort de votre machine

En plus des requêtes vers les pages elles-mêmes, trois choses peuvent sortir, chacune par votre choix : les requêtes envoyées à votre instance SearXNG, le texte collecté envoyé au modèle OpenCode, et une notification vers un serveur ntfy (ntfy.sh sauf si vous en indiquez un autre). Vos identifiants, non. Le tableau complet, avec le fichier derrière chaque ligne, se trouve sur la page d’architecture.

Ce que Dinoer ne prétend pas

Il n’est pas plus prudent que le scénario ou le manifeste que vous lui donnez. Un scénario faux fait de vrais dégâts, à la vitesse de la machine. Et la garantie sur le corpus porte sur l’origine d’une réponse, pas sur la pertinence de la question.