Add packaged DLP broker and protected Windows service foundation

docs/windows-dlp-mvp.md

@@ -1,5 +1,192 @@
 # Verbindliches Ziel: Windows-DLP-MVP
 
+## Verbindliche Runtime-Grenze
+
+Nutzerpräzisierung vom14. Oktober2026: Chromium/Electron darf für dieses Produkt
+nicht selbst gepatcht oder neu gebaut werden. Offizielle, unveränderte Runtime-
+Updates bleiben Voraussetzung. Der bisherige native Backport-/Compilerpfad ist
+abgebrochen; kein Custom-Binary wurde aktiviert. Eine unabhängige Windows-
+Netzwerkgrenze mit separatem DLP-Broker muss die bisherige WebRTC-Sperre ersetzen,
+bevor der abstürzende Response-Header entfernt werden darf. Dieser Ersatz ist
+noch nicht implementiert oder nativ abgenommen. Das unveränderte Runtime-Ziel
+reduziert die erforderlichen DLP-/Umgehungs-/Stabilitätsnachweise nicht.
+
+## Gemeinsame Auslieferung
+
+Nutzerpräzisierung: Browser, DLP-Broker, lokale Scanner und benötigte Modelle
+werden gemeinsam in einer finalen Windows-Installer-EXE ausgeliefert. Der Broker
+darf ein eigener interner Prozess sein, aber kein separat zu installierendes
+Produkt oder manuell zu startendes Programm. Auf einem frischen Zielsystem dürfen
+kein Node-/Python-/Broker-Download und keine Entwicklungsumgebung erforderlich
+sein. Der Installer provisioniert die nötigen Schutzgrenzen und Dateirechte;
+Startup und Paketprüfung müssen fehlende/manipulierte Broker-Dateien, falsche
+Versionen sowie nicht aktive Schutzgrenzen erkennen und fail-closed reagieren.
+Ein grüner Paketnachweis des alten In-Process-Relays beweist die neue Broker-
+Auslieferung nicht; der neue vollständige Installer benötigt eigene Native-Tests.
+
+## Aktueller Ersatzpfad: Nachweise und offene Grenzen
+
+Die folgenden Einträge dokumentieren die schrittweise Entwicklung und enthalten
+auch frühere Zwischenstände. Die aktuelle Abnahmematrix und neuesten Paket-,
+Proxy-, Diagnose- und Dienstadapter-Nachweise stehen in
+[core-dlp-current-status.md](core-dlp-current-status.md). Frühere offene Punkte
+gelten nicht als aktuelle Lücke, wenn dort ein neuerer begrenzter Nachweis steht;
+die vollständige Browser-/Dienst-/Installer-Abnahme bleibt erforderlich.
+
+Der isolierte Baustein `apps/network-broker/http-request-gate.cjs` puffert explizite
+HTTP-Requests vollständig vor der Freigabe. Er prüft Framing und Authority,
+begrenzt Größe und Laufzeit und prüft nach dem Scan den Policy-Widerruf erneut.
+Die Scan-Kopie kann die freigegebenen Originalbytes nicht verändern. Er ist noch
+nicht im produktiven Relay oder Installer eingebunden. TLS-Terminierung,
+Broker-Authentifizierung und WebSocket-/WebRTC-Prüfung sind dadurch nicht gelöst.
+Die neun gezielten Tests umfassen einen echten HTTP-Empfänger und zeigen null
+TCP-Verbindungen vor der Freigabe sowie keine Auslieferung blockierter Inhalte.
+
+`scripts/broker-package-contract.mjs` erzeugt und prüft eine vollständige
+Broker-Dateiliste mit SHA-256, Version und Protokollkennung. Neun gezielte Tests
+prüfen fehlende, zusätzliche und manipulierte Dateien sowie unsichere Pfade und
+Junctions. Der erwartete Manifest-Inhalt muss aus der integritätsgeschützten
+Anwendung stammen. Das ist noch keine Installer-Integration und keine atomare
+Startgarantie; geschützte Installationsrechte bleiben Voraussetzung. Beide
+Testdateien und Bausteine bestehen den lokalen ESLint-Check. Die isolierten Tests
+erzeugen noch keine produktiven Broker-OTEL-Traces.
+
+Weitere isolierte Vorarbeiten: `tls-authority.cjs` bindet CONNECT, inneren Host,
+HTTPS-Ziel und SNI an dieselbe unveränderliche Authority; fünf Tests bestanden.
+Es terminiert noch kein TLS. `windows-package-plan.mjs` trennt Unpacked-Build,
+Pflichtprüfungen und NSIS-Erstellung aus dem geprüften Verzeichnis; sechs Tests
+bestanden. Die Freigabe ist an Source-, Runtime- und Paketidentität gebunden.
+Der damalige Packaging-Aufruf verwendete nur `--dir`. Der aktuelle Aufruf
+bereitet den verpflichtenden Broker vor, verifiziert das entpackte Paket und
+erstellt standardmäßig anschließend NSIS; `--unpacked-only` bleibt ein expliziter
+Entwicklungsmodus. Ein finaler Installer mit aktiviertem geschütztem Broker-
+Dienst ist weiterhin nicht gebaut oder abgenommen.
+
+`https-inspection-server.cjs` prüft jetzt einen echten entschlüsselten HTTPS-Leg
+mit vorab authentifizierter CONNECT-Bindung und vom vertrauenswürdigen Aufrufer
+bereitgestelltem Zertifikat. Fünf TLS-Tests prüfen erlaubte Originalbytes und
+null Ziel-TCP-Verbindungen bei Geheimnissen, Widerruf, Host-/SNI-Fehlern sowie
+vor verzögerter Freigabe. Client und Testziel validieren ihre TLS-Zertifikate.
+Der Baustein ist kein vollständiger CONNECT-Proxy: Zertifikatsausstellung,
+Browser-Vertrauensintegration, Zielantwort-Weiterleitung und produktive
+Einbindung fehlen. Die Gesamtsuite vor diesem zusätzlichen TLS-Testlauf bestand
+823 Tests; der anschließende separate TLS-Lauf bestand fünf Tests.
+
+Inzwischen gibt der isolierte HTTPS-Leg die echte gepufferte Zielantwort zurück.
+Ein Response-Gate begrenzt Body und Header, berechnet Content-Length neu und
+entfernt Hop-by-hop-Header. Nicht unterstützte Kompression bleibt gesperrt.
+Der vertrauenswürdige Forwarder muss seine eigene Socket-/Response-Sammlung
+ebenfalls begrenzen. Die OTLP-Adaptertests prüfen echte Exporte mit Parent-/Child-
+Korrelation und Laufzeiten, unveränderte Fehler bei deaktivierter Diagnostik und
+den Ausschluss von Inhalt, Authority und Fehlermeldung. Der Adapter konfiguriert
+keinen Exporter selbst und benötigt die bereits autorisierte Diagnostik des
+Aufrufers. Das ist noch keine produktive Broker-Telemetrie-Integration.
+
+Der Forwarding-Leg hat nun einen eigenen, nicht durch Netzwerkaktivität
+verlängerbaren Zeitrahmen und signalisiert Abbruch bei Client-Disconnect oder
+Fristüberschreitung. Neun HTTPS-Tests einschließlich realer Zielantwort,
+Upstream-Fehler, einmaligem Abbruch und Konstruktor-Limits bestehen. Die sechs
+Broker-Diagnosestufen besitzen getrennte feste `broker.*`-Operationsnamen.
+
+`windows-wfp-plan.cjs` beschreibt vier komplementäre Deny-Filter für den nativen
+Application-ID-Blob: IPv4 Nicht-TCP, TCP zu anderen Adressen, Loopback-TCP zu
+anderen Ports und sämtliches IPv6. Es installiert keine Regeln und enthält
+keinen Permit-Override für Unternehmens-Firewalls. Vier Tests prüfen alle
+65.536 Portwerte, Protokoll-/Adressgrenzen und unveränderliche Identitäten.
+Die GUIDs stimmen mit dem installierten Windows SDK 26100 überein. Native
+BFE-Installation, Enumeration und physische Empfängertests sind noch offen;
+der Entwicklungsprozess besitzt nur ein Medium-Integrity-Token.
+
+Der isolierte `connect-inspection-proxy.cjs` führt nun einen echten CONNECT-
+Durchlauf aus: zufällige Launch-Capability, konstante Tokenprüfung, autorisierte
+Zielbindung, verifiziertes TLS, Inhaltsprüfung und echte HTTPS-Zielantwort.
+Falsche Tokens werden vor Zertifikatsauflösung abgewiesen; gesperrte Inhalte
+erzeugen keine Zielverbindung. Es gibt kein opaques Upstream-Piping und keinen
+zusätzlichen ungeschützten lokalen Listener. Zertifikatsausstellung und produktive
+Browser-Vertrauensintegration fehlen weiterhin. Die unabhängige Prüfung fand
+eine noch offene Ressourcenlücke: Socket-Limits begrenzen nicht Scanner-/Forward-
+Jobs, die Abbruchsignale ignorieren. Vor Integration ist gemeinsame Job-Admission
+nötig, deren Plätze bis zum tatsächlichen Ende der zugrunde liegenden Arbeit
+belegt bleiben. Timeout allein darf keine belegte Kapazität freigeben.
+
+Diese Lücke ist im isolierten Prototyp geschlossen: gemeinsame Work-Admission
+für Zertifikatsauflösung, Scan und Forwarding über alle CONNECT-Tunnel, Freigabe
+erst nach tatsächlichem Promise-Ende. Wiederholte Timeouts überschreiten das
+Job-Limit nicht; belegte Kapazität bleibt fail-closed verbraucht. Private Buffer
+werden nach tatsächlichem Arbeitsende gelöscht. 37 Broker-Tests und Lint bestehen.
+
+Der native read-only WFP-Adapter besteht neun Python-Tests. Der tatsächliche
+Medium-Integrity-Prozess erhält einen nativen Application-ID-Blob, den der Plan
+akzeptiert. Filter-Enumeration endet mit Access Denied (5), korrekt als
+`verified: false`; native Ressourcen werden geschlossen. Der Adapter installiert
+keine Regeln. Installer-Aktivierung, Service-Provenienz und native Abnahme bleiben
+offen. Nachweis: ignorierter `artifacts/stock-wfp-readonly-proof.json`.
+
+Der separate Broker-Prozess ist jetzt mit der offiziellen gebündelten Node-
+24.20.0-Runtime getestet: drei echte Child-Prozess-Tests bestehen, einschließlich
+CONNECT/TLS, blockiertem Geheimnis, exakten öffentlichen Bytes sowie geschlossenem
+Listener nach privatem IPC-Disconnect oder Stop. Der aktuelle Factory-Code nutzt
+nur eine explizite synthetische Testfixture; produktive Policy-/Scanner-Anbindung
+ist damit noch nicht implementiert. Node-Binary und Lizenz liegen ignoriert unter
+`.runtime/windows/broker`; offizielle Archiv- und Binary-SHA-256 stimmen,
+Authenticode ist gültig. Das Browser-Binary bleibt unverändert. Installer-
+Einbindung und Fresh-System-Abnahme fehlen weiterhin.
+
+`policy-authority.cjs` verwendet die bestehende Core-Signatur-/Schema-Prüfung
+und dieselbe Device-Assignment-Prüfung wie der Browser. Enrollment-Key, Device-ID
+und Mindestversion stammen aus vertrauenswürdigem Bootstrap; unveränderliche
+Snapshots und Generationstokens verhindern Freigabe nach Policywechsel. Sechs
+Tests mit echten synthetischen Signaturen prüfen Ablauf, falsches Gerät, Änderung,
+Rollback und Widerruf. Mindestversionen müssen bei produktiver Integration in
+geschütztem Enrollment-Storage dauerhaft gespeichert werden. Die drei Child-
+Prozesstests verlangen jetzt ausdrücklich die verifizierte gebündelte Node-Runtime
+und besitzen keinen Entwicklungs-Node-Fallback. Fünf Runtime-Manifest-Tests prüfen
+Version, Hashes, zusätzliche Dateien und Junctions. Kombinierter Lauf: 14/14.
+
+Der integrierte signierte Managed-Proxy prüft Header/Cookies und volle URLs mit
+dekodierten Darstellungen. Jeder nicht-textuelle Magic-Typ erfordert vollständige
+lokale Dokumentanalyse, auch bei UTF-8-Rohbytes. Der begrenzte Multipart-Parser
+prüft alle Teile: Metadaten, Dateityp und Inhalt müssen freigegeben sein, bevor
+die ursprünglichen Request-Bytes weitergehen. 13 echte TLS-/Empfängertests und
+neun Parser-Tests bestehen, ebenso Lint. Ihre Dokument-Scanner sind injizierte
+Verträge; ein echter AppContainer-/Modell-Nachweis über diesen Broker fehlt noch.
+Der Managed-Proxy ist weiterhin nicht produktiv im Browser eingebunden.
+
+Stock-Resolver-Teilnachweis: `MAP * ^NOTFOUND, EXCLUDE 127.0.0.1` verhindert im
+isolierten offiziellen Electron-44.7.2-Test `Session.resolveHost(example.com)`
+mit `ERR_NAME_NOT_RESOLVED`, während der explizite Loopback-Proxy weiterhin
+einen harmlosen Hostname-HTTP-Request empfängt. Der positive Ausgangslauf löst
+den Namen auf. Das unveränderte Runtime-Binary bleibt hashgleich. Ohne exakte
+Loopback-Ausnahme scheitert auch der Proxy; diese Einschränkung bleibt sichtbar.
+Der bisherige RTC-UDP-Ausgangstest empfängt schon ohne Regeln null Pakete und
+beweist daher keine Sperre. Physische DNS-/mDNS-/LLMNR- und WFP-Umgehungsnachweise
+fehlen weiterhin. Nachweise: ignorierter `artifacts/stock-resolver-proof`-Ordner.
+
+Ein zusätzlicher gepaarter nativer STUN-Test verwendet nun einen vorab nur auf
+die eigene nicht-loopback IPv4 aufgelösten Testhostnamen. Der Ausgangslauf
+empfängt fünf anhand der STUN-Magic validierte UDP-Pakete; mit derselben
+Resolver-Regel empfängt der eigene Receiver null Pakete und die Namensauflösung
+scheitert. Beide unveränderten Stock-Runtime-Läufe enden mit Exit 0 und bestehen
+den harmlosen HTTP-Proxy-Durchlauf. Das bestätigt den getesteten hostnamebasierten
+STUN-Pfad; Literal-IP, TURN/TLS, mDNS/LLMNR und physische DNS-Ausleitung sind
+weiterhin keine bestandenen Abnahmen. Eigene Nachweise bleiben getrennt als
+`baseline-stun-owned.log`, `mapped-stun-owned.log` und `stun-owned-summary.json`.
+
+Die unveränderte offizielle Electron-44.7.2-Runtime startet im bisherigen
+AppContainer-Versuch mit null Capabilities nicht bis `READY`. Auch isolierte
+Profil-/Temp-Umgebungsvariablen ändern den Fehler nicht. Ein auf den synthetischen
+Testprozess begrenzter Microsoft-Debugger erfasst `0x80000003`, anschließend
+`0xC000001D`, bei Runtime-Offset `0x72ac2bb`. Ohne aufgelöste private Symbole
+beweisen benachbarte Exportnamen keine Fehlerursache. Dieser Versuch beweist
+weder Browser-Kompatibilität noch DNS-/Netzwerkisolation. Lokale Nachweise liegen
+ignoriert unter `artifacts/stock-appcontainer-feasibility`.
+
+Nächste Abnahme: funktionsfähige Windows-Netzwerkgrenze einschließlich DNS,
+separater authentifizierter Broker mit tatsächlicher HTTPS-Inhaltsprüfung,
+Integration ohne ungeprüfte Ausweichwege und gemeinsamer Installer-Test auf
+einem System ohne Entwicklungsruntimes. Die bisherige Schutzmaßnahme bleibt
+bis zum erfolgreichen Ersatznachweis aktiv; das MVP ist noch nicht abgenommen.
+
 Der Nutzer hat am 13. Oktober 2026 den bisherigen breiten Funktionsumfang
 ausdrücklich ersetzt. Dieses Ziel hat Vorrang vor älteren Aufgabenlisten:
 Ein stabiler, zentral verwalteter Windows-Browser verhindert, dass vertrauliche
@@ -161,9 +348,14 @@ isolierten Build-Checkout als Commit
 `6f8b80fef13bfdc9d9c70df567ebcad722d70467` angewendet, mit genau16 Dateien und
 separatem Provenienzjournal. Er ist noch nicht kompiliert oder nativ abgenommen;
 das ausgelieferte Runtime-Binary bleibt unverändert. Aktuelle Build-Grenzen:
-ATL/MFC wird vom Visual-Studio-Komponentencheck nicht gefunden; der vollständige
-Windows-Dependency-Sync scheiterte an einer protokollierten Antivirus-Ablehnung
-des Chromium-Updater-Testpakets. Keine Antivirus-Ausnahme wurde vorgenommen.
+ATL/MFC fehlte ursprünglich; die normale Microsoft-Installation ist inzwischen
+abgeschlossen und `vswhere` bestätigt die Komponente in einer vollständigen,
+startfähigen BuildTools-Instanz. Der ursprüngliche vollständige Windows-Sync
+scheiterte an einer Antivirus-Ablehnung des Chromium-Updater-Testpakets. Ein
+separat geprüftes CIPD-Manifest verarbeitete danach39 unveränderte Bindings mit
+Exit0 und ließ ausschließlich die benannte Updater-Testfixture aus. Keine Antivirus-
+Ausnahme wurde vorgenommen. Build-Hooks und GN-Targetabhängigkeiten werden
+separat geprüft; ein vollständiger neuer Native-Build ist noch nicht belegt.
 Quellkompatibilität und Strukturprüfungen ersetzen weder Binder-Unittests noch
 die echten erlaubten und blockierten WebRTC-Übertragungen im neuen Binary.