Das Bedienerprofil und die Liste der Websites

Wo es liegt

~/.config/mcp-server-diwall-browser/profile.json oder unter $XDG_CONFIG_HOME, wenn diese Variable gesetzt ist, oder der absolute Pfad in MCP_DIWALL_BROWSER_PROFILE. Die Datei schreiben Sie selbst, im Modus 600, in einem Verzeichnis im Modus 700; der Server lehnt sie sonst ab, und seine Meldung nennt das auszuführende chmod. Sie enthält kein Geheimnis. Der Server liest sie bei jedem Aufruf neu: Eine Änderung wirkt ohne Neustart.

Ein Schlüssel außerhalb des Schemas wird abgelehnt. Ein Schlüssel, der die gesperrten Aktionen konfigurieren würde, wie payment oder deletion, wird mit redlist_in_profile abgelehnt: Nur der Code entscheidet, was auf Ihre Bestätigung wartet.

Die drei Listen der Websites

"allowed_origins": ["https://account.example.invalid", "https://*.shop.example.invalid"],
"confirm_each_change": ["https://account.example.invalid"],
"local_model_origins": []

• allowed_origins: die Websites, die der Server liest und auf denen er handelt, höchstens 200. Mit strict erhält das Modell von jeder anderen Seite den Origin und sonst nichts.
• confirm_each_change: Websites, bei denen jeder Klick, jede Eingabe, jede Auswahl in einer Liste, jede Eingabetaste und jeder akzeptierte Dialog Ihre Bestätigung verlangt, nicht nur Zahlungen, Löschungen und Änderungen eines Geheimnisses.
• local_model_origins: genaue Origins, die ein auf diesem Rechner laufendes Modell bearbeiten soll. Der Server führt sie in status auf und sonst nichts, da er nicht erkennen kann, wo ein Modell läuft.

Ein Eintrag ist ein Origin (Schema, Host, Port) oder ein Platzhalter für Subdomains. https://*.shop.example.invalid deckt jede Subdomain von shop.example.invalid ab, eine Ebene tief oder mehr, mit demselben Schema und Port, aber nicht shop.example.invalid selbst, das einen eigenen Eintrag braucht. Ein Platzhalter allein (*), ohne Schema, an einer anderen Stelle als dem ersten Label oder vor einem Namen mit einer Ebene (https://*.test) macht das Profil ungültig. Ein Platzhalter erweitert das Lesen und Handeln, nie das Tippen: Ein Zugangsdatensatz wird nur auf dem genauen Origin getippt, den seine Datei nennt (Zugangsdaten). Der Server führt keine Liste öffentlicher Suffixe; einen Platzhalter vor einem Namen mit zwei Ebenen, etwa einem, der auf co.uk endet, müssen Sie selbst vermeiden.

Die Ursprungsrichtlinie

Die Liste der Websites begrenzt, was das Modell liest und worauf es handelt, nie, wohin es navigiert. Der Schlüssel origin_policy sagt, was der Server mit einem Origin tut, den die Liste nicht enthält. Sie wählen ihn im Profil; der Server liest ihn bei jedem Aufruf neu, und kein Werkzeug des Modells ändert ihn.

• strict (der Standard, und was ein Profil ohne den Schlüssel tut): Der Origin wird abgelehnt, und das Modell erhält den Origin und sonst nichts.
• discovery: Der Server fragt Sie in einem Fenster, einmal je Origin: Refuser (die Standardantwort), Cette séance (gelesen, bis der Server anhält, nichts geschrieben) oder Ajouter à la liste (genau dieser Origin wird in allowed_origins geschrieben). Höchstens fünf Fenster je Serverprozess; eine Ablehnung oder keine Antwort in 90 Sekunden wird nicht erneut gefragt.
• open: Jede öffentliche Website wird gelesen und darauf gehandelt, und was das Modell liest, geht an seinen Anbieter. Es ist die freieste Richtlinie und die riskanteste, und die Wahl liegt bei Ihnen. localhost, die Namen auf .local und die im Internet nicht routbaren Adressen bleiben auf der Liste.

In allen drei Richtlinien behalten eine Zahlung, eine Löschung und eine Änderung eines Geheimnisses ihr Bestätigungsfenster, und Zugangsdaten werden nur auf dem genauen Origin getippt, den ihre Datei nennt. Um einen Origin von Hand hinzuzufügen, tragen Sie ihn in allowed_origins ein. Die Einzelheiten stehen in Abschnitt 5 des Bedienerhandbuchs.

Der Rest der Datei

• secrets_dir und secrets_crypt_dir: wo das verschlüsselte Verzeichnis geöffnet ist und wo seine verschlüsselten Dateien liegen. Mit dem zweiten unterscheidet status ein geschlossenes Verzeichnis von einem nie angelegten.
• browser: family (chrome, chromium oder brave), profile_dir (das --user-data-dir des eigenen Profils) und debug_port (das --remote-debugging-port, standardmäßig 9222).
• limits: standardmäßig mindestens 250 ms zwischen zwei Aktionen, 200 Aktionen und 50 Seiten pro Serverprozess. Eine Aktion zählt, wenn sie beginnt, sobald der Server verbunden ist; ein Neustart des Clients setzt die Zähler zurück.
• declarations: zwei Aussagen von Ihnen, dass das Modell des Clients auf diesem Rechner läuft und dass der Client nie von selbst eine Bestätigung beantwortet. Der Server kann sie nicht prüfen und zeigt sie in status so, wie sie geschrieben sind. Nur mit der zweiten darf er eine Bestätigung über den Client erfragen, wenn kein Fenster angezeigt werden kann.

Ein vollständiges Beispiel, das der Server so, wie es geschrieben ist, akzeptiert, steht in Abschnitt 5 des Bedienerhandbuchs.

Was eine Änderung der Listen hinterlässt

Wer die Datei schreiben kann, kann ihr eine Website hinzufügen, und der Server kann das nicht verhindern. Es bleibt eine Spur: Wenn eine der drei Listen oder origin_policy von dem abweicht, was der Server beim vorherigen Aufruf sah, oder bei seinem ersten Aufruf von dem, was der letzte Lauf gespeichert hat, geht eine Zeile profile_changed ins Journal im verschlüsselten Verzeichnis, und status trägt die Änderung in server.notices:

"notices": ["profile_changed : allowed_origins +https://shop.example.invalid"]

Es ist eine Erkennung im Nachhinein: Sie fügt keine Bestätigung hinzu, und wer unter Ihrem Konto eine Shell hat, kann auch das Journal bearbeiten. Lesen Sie nach einer Sitzung, in der ein Client mit Shell angebunden war, das Journal:

grep profile_changed \
  ~/Vaults/Main/mcp-server-diwall-browser/journal/operations.jsonl