Add packaged DLP broker and protected Windows service foundation

docs/broker-siem.md

@@ -17,6 +17,12 @@ events. The standard `outcome` field reflects unknown authorization or failure;
 Microsoft documents its mapping to `EventOutcome` in
 [CommonSecurityLog](https://learn.microsoft.com/en-us/azure/sentinel/cef-name-mapping).
 
+Typed download records use `download.scan` / `download.block` with the original
+request authorization UUID and real file size, magic-derived type and SHA-256.
+They never attach a generic request-body hash. A blocked download has a failure
+outcome and a denied event type. A successful scan reports inspection success;
+it does not prove that the user received or saved the file.
+
 These format and exporter tests do not establish a customer's remote SIEM
 deployment, retention, key custody or incident-response configuration. Production
 browser-to-broker integration remains a separate acceptance gate.

docs/core-dlp-current-status.md

@@ -0,0 +1,443 @@
+# Windows DLP: aktuelle Abnahmegrenzen
+
+Stand: 14. Oktober 2026. Diese Übersicht unterscheidet produktive Integration
+von isolierten Baustein- und Empfängertests. Das MVP ist nicht abgenommen.
+
+| Bereich | Autoritativer aktueller Nachweis | Noch erforderlich |
+| --- | --- | --- |
+| Unveränderte Runtime | Offizielles Electron; eigener Chromium-Build abgebrochen | Ersatz der abstürzenden WebRTC-Header-Sperre erst nach vollständigem Netzwerk-Nachweis |
+| Broker-Transport | Gepackter Production-Child mit privater IPC, authentifiziertem CONNECT, TLS-Ausstellung und scoped Pin-Helper; öffentliche Originalbytes übertragen, Geheimnisse vor Zielverbindung gesperrt | Vollständige Anbindung an den Hauptbrowser und geschützten Windows-Dienst |
+| Signierte Regeln | Bestehende Core-Signaturprüfung, Device-Assignment, Ablauf, Widerruf, Generation und Rollback geprüft | Geschützte dauerhafte Mindestversion und vollständiger produktiver Bootstrap |
+| Transferprüfung | Header, URLs und Multipart-Verträge; tatsächlicher Production-Child blockiert geheime PDF-Teile in JSON und Prozent-Data-URLs mit lokalem Parser | Hauptbrowser-Abnahme einschließlich aller Clipboard-/Editor-Pfade; echte Unternehmens-Scanner-Endpunkte |
+| Downloads | Production-Child prüft Inline-PNG/PDF samt tatsächlichem Datei-Hash, sperrt Attachment bei deaktiviertem Speichern und geheimes PDF ohne PDF-Bytes; kausale Audit-Ereignisse persistiert | Hauptbrowser-SaveAs-, Blob- und Cache-Pfade |
+| PDF | Gepaarter nativer AppContainer-/PDFium-/OCR-Test besteht: Geheimnis erkannt, null Zielverbindungen; öffentliches statisches PDF exakt übertragen | Erweiterung und ausdrücklich dokumentierte Grenzen für weitere PDF-Funktionen; finale Browser-/Installer-Abnahme |
+| Office | Nativer AppContainer-/Broker-Test besteht für reale DOCX/XLSX: öffentliche Originalbytes übertragen; Geheimnisse in Metadaten/Hidden Sheet erkannt und ohne Zielverbindung blockiert | Weitere Office-Funktionen; komplexes PowerPoint und unbekannte Inhalte bleiben unvollständig und gesperrt |
+| Windows-Netzwerkgrenze | Resolver- und STUN-Teilnachweise; WFP-Plan und Installer-Fehlertests. Aktueller nicht erhöhter Token kann WFP öffnen, Filterenumeration scheitert mit Access Denied (5) | Geschützter SCM-Host und Dienst-SID, Receiver-/Portübernahmeschutz, erhöhte Installation und Filter-Readback; IPv4/IPv6/UDP/TCP/Loopback/DNS-Umgehungstests |
+| Broker-Runtime | Neunter geprüfter Payload: offizielles Node 24.21.0, 313 Dateien / 64 Quellnachweise, sechs tatsächliche Isolationsprüfungen einschließlich Management- und WFP-Module | Neuere Credential-/Policy-Änderungen erneut paketieren und prüfen; produktiven nativen Host und signierte Installation ergänzen |
+| Auslieferung | Standalone-Payload außerhalb des Repositorys getestet; historischer Node-24.20-Nachweis bleibt erhalten | Gemeinsamer finaler Installer mit Broker, Scanner und Modellen; Fresh-System-Test |
+| Unternehmens-Proxy | Achter gepackter Production-Child besteht HTTPS-Proxy und aktive IP-Policy mit sechs numerisch gebundenen CONNECT-Routen, ursprünglicher TLS-Hostname-Prüfung und gesperrten kodierten Geheimnissen | Hauptbrowser-/Dienst-Anbindung; PAC/system/SOCKS/NTLM/Kerberos noch nicht unterstützt |
+| Diagnose und Audit | Bestehende Browser-Diagnostik sowie tatsächliche isolierte Broker-OTLP-Tests | Broker-Diagnostik und dauerhafte Sicherheitsereignisse im produktiven Prozesspfad; zentrale Abschaltung beibehalten |
+
+Die nächste Abnahme folgt dieser Reihenfolge: frisches gepacktes Proxy-/Download-
+Verhalten, geschützter Dienst samt authentifizierter Benutzeranbindung, vollständiger
+Hauptbrowserpfad, gemeinsamer Installer und native Netzwerk-/Clipboard-Umgehungstests.
+Bausteintests erlauben kein Entfernen der bestehenden WebRTC-Sperre. Management,
+Inspector und autorisierte OTLP-Exporte müssen vor einer Browser-EXE-Netzwerksperre
+über ausdrücklich erlaubte Dienstoperationen laufen; eine breite Ausnahme wäre
+kein Ersatz für diesen Pfad.
+
+Konkrete Transport-Migration vor Aktivierung:
+
+- Enrollment und Management benötigen einen im signierten Deployment gebundenen
+  HTTPS-Origin und den bestehenden ML-DSA-87-Kanal-Pin. Das bisherige Deployment
+  v1 enthält diese Bindung nicht; ein vom Renderer eingegebener Server darf keine
+  allgemeine Dienst-Fetch-Berechtigung erzeugen. Versionierter Vertrag in Arbeit.
+- Device-Identität, Challenge, verschlüsselte Policy/Evidence, Heartbeat, Ereignisse,
+  Bookmarks und Library brauchen begrenzte typisierte Operationen statt beliebiger
+  URL-/Header-/Token-Weiterleitung. Pre-Enrollment bleibt gesondert nachzuweisen.
+- Browserseitige Clipboard-/AI-/manuelle Scans verwenden noch authentifiziertes
+  Loopback-HTTP zum Inspector. Sie müssen über den Dienst laufen; bereits
+  brokerseitig erfolgreiche Upload-Scans beweisen diese Browser-Pfade nicht.
+- Große Dokumente brauchen begrenzte Chunk-Transfers oder geschützte Handles;
+  der 2-MiB-Bootstrap und spätere 64-KiB-Frames sind keine 16-MiB-Datei-RPC.
+- Autorisierte OTLP-Exporte brauchen ihren eigenen begrenzten Dienstpfad.
+  Agentensteuerung muss vom Browser-Loopback-Listener auf authentifizierte lokale
+  Pipes wechseln und vorhandene PQ-, Grant- und Replay-Prüfungen erhalten.
+
+Der Dienstadapter ist unabhängig auf seine Paketauflösung geprüft: tatsächliches
+electron-builder File-Matching, ASAR-Erstellung/Extraktion und isolierter Modul-
+Load bestehen. Ausschließlich `apps/network-broker/framed-channel.cjs` wird als
+zusätzliche Browser-Abhängigkeit eingebettet, kein allgemeines Broker-Wildcard.
+Dies beweist keine fertig installierte Dienstverbindung.
+
+Aktuelle Broker-Regression (ohne den separat zu prüfenden Payload-Staging-Test):
+188 Fälle, davon 181 bestanden und sieben ausdrücklich aktivierbare native
+Prüfungen übersprungen; keine Fehler. Die übersprungenen Tests werden nicht als
+native Abnahme gezählt. Die vier gezielten Diagnose-/Factory-/Download-/Proxy-
+Dateien bestanden zuvor mit 28 Fällen einschließlich tatsächlichem privatem
+OTLP-Empfänger. Der vorhandene geschützte Collector meldet null Commitfehler und
+null abgewiesene Schreibzugriffe; der bestehende Trace
+`e5ebf887a1ad8d90f065739a86cd2261` wurde mit 55 Spans abgerufen. Das beweist keine
+neuen produktiven Broker-Exporte. Lokale Evidenz:
+`artifacts/core-broker-development-check-2026-10-14.json`.
+
+Der erste native Lauf des fünften Payloads mit tatsächlichem HTTPS-Unternehmens-
+Proxy ist fehlgeschlagen: öffentlicher Roh-Upload wurde übertragen, decodierte
+Dokumentprüfungen erreichten jedoch das feste fünfsekündige Request-Limit statt
+eines vollständigen Scannerurteils. Der Inspector erlaubt bis zu 29 Sekunden
+begrenzte Arbeit. Diese Zeitbudget-Inkompatibilität und die Unterdrückung später
+Urteile nach einem bereits protokollierten Timeout sind vor einer erneuten
+Proxy-Abnahme zu korrigieren. Ein funktionierender Roh-Upload beweist hier keine
+Dokumentabdeckung. Der Testprozess endete; ursprüngliche Fehlerevidenz bleibt.
+
+Nach Korrektur auf ein absolutes 30-Sekunden-Gesamtbudget besteht der sechste
+gepackte native Lauf (1/1, 26,5 Sekunden): geheime Raw-/JSON-/Data-URL-Inhalte
+werden mit tatsächlicher Scanner-Regel vor zusätzlicher Zielverbindung gesperrt.
+Öffentliche äußere JSON-Bytes bleiben unverändert. PNG-Inline-Inhalt funktioniert
+trotz allowDownloads=false, Attachment-Speicherung wird gesperrt. Öffentliches
+Inline-PDF funktioniert, geheimes PDF gibt keine PDF-Bytes frei. 13 persistierte
+Ereignisse enthalten geprüfte echte Dateigrößen und SHA-256 sowie kausale UUIDs.
+Privater Testempfänger: 22 echte OTLP-Spans, 33.635 Bytes, null ungültige Exporte,
+null aktuelle/lebenslange Exportfehler; dauerhafte Trace-ID
+`2943810ad3499cd0d331a45206b2780d` wurde tatsächlich abgerufen, Audit-Span und
+Request-Elternspan verknüpft. Supervisor bestätigt geschlossen, ohne Quarantäne.
+Nachweis: `artifacts/broker-production-native/proof-2026-10-14T10-31-22.318Z.json`.
+Die Spans stammen vom privilegierten Test-Parent, nicht vom produktiven Child-
+Exporter. Hauptbrowser, Windows-Dienst und Installer bleiben separate Gates.
+
+Der Transportbaustein für den nativen Dienst verwendet längenbegrenztes UTF-8-
+JSON (initial maximal 2 MiB, danach 64 KiB), höchstens acht ausstehende Writes
+und feste Fehlercodes; acht Tests einschließlich fragmentierter Frames,
+ungültigem UTF-8 und tatsächlichem Duplex-Transport des bestehenden Audit-RPC
+bestehen. Disconnect bestätigt ausstehende Writes nicht als erfolgreich;
+ein später Callback kann kein zweites Ergebnis liefern. Dieser Baustein
+authentifiziert keinen Peer und ist
+noch nicht aktiviert. Die native Dienst-/Client-Identitätsprüfung vor dem ersten
+Frame sowie die Produktionsanbindung bleiben separate Abnahmebedingungen.
+
+Der eigene native Dienst-Host wurde mit MSVC 14.44 als Testvariante kompiliert
+(kein Chromium-Neubau). Ein tatsächlicher Windows-Selbsttest beweist die
+Ablehnung fehlender Dienst-SID, Job-Mitgliedschaft von Kind und Enkel, deren
+beendeten Zustand nach Job-Schließen und die Ablehnung eines falschen Hashes.
+`artifacts/native-service-host/proof.json` bindet diesen Nachweis an den damaligen
+Quell-/Binary-Hash und weist installed=false sowie wfpActivated=false aus.
+Die unabhängige Quellprüfung verlangt weitere Korrekturen vor Aktivierung:
+Pipe-DACL ohne FILE_CREATE_PIPE_INSTANCE für Benutzer, exakter geschützter
+Browserpfad, geschützter Deployment-Vertrauensanker, absolute Frame-Zeitgrenzen
+und abbrechbare Writes. Der Selbsttest beweist keine Dienstinstallation oder
+authentifizierte produktive Benutzerverbindung.
+
+Nachfolgende native Testvariante: explizite Benutzer-Pipe-Rechte verweigern eine
+zweite Instanz auch ohne FIRST_PIPE_INSTANCE; unberechtigter Client und zu großer
+Frame werden tatsächlich abgewiesen. Job-Tests bleiben grün. Ein zusätzlicher
+anonymer Pipe-Test unterscheidet erfolgreich abgeschlossenen Write mit gesundem
+Idle von einem blockierten, abgebrochenen Write. Die Installation bleibt
+unbewiesen; das aktuell weiterentwickelte Quellfile muss jeweils erneut zum
+Hash des kompilierten Nachweises passen.
+
+Ein noch nicht aktivierter Service-Bootstrap-Baustein verwirft einen vom Aufrufer
+gewählten Policy-Schlüssel, eine fremde Geräte-ID und eine Mindestversion unter
+der geschützten Zuordnung vor dem Factory-Aufruf. Sechs Tests bestehen, darunter
+eine echte Vendor-/Kundensignatur-Kette und die Ablehnung einer fremden in der
+Testfixture übergebenen SID. Das ist keine native Pipe-Identitätsprüfung. Sein
+privilegierter Trust-Loader muss zuvor Release-Signatur, delegierte Kundensignatur,
+geschützte dauerhafte Rollback-Grenzen und die tatsächlich vom nativen Pipe-Peer
+ermittelte SID prüfen; ein injizierter Test-Loader beweist diese Voraussetzungen
+nicht. Die Benutzer-SID darf ausschließlich aus der nativen Peer-Prüfung stammen,
+niemals aus dem START-JSON oder einer übernommenen Benutzer-Umgebungsvariable.
+Der Baustein sperrt zudem einen Start nach Deployment-Ablauf und schließt einen
+laufenden Broker bei Ablauf, auch wenn die Browser-Policy länger gültig wäre.
+Mehrere Close-Aufrufe warten auf denselben ursprünglichen Cleanup und erhalten
+dessen Fehler; ein bereits begonnener Cleanup gilt nicht als abgeschlossen.
+
+Die neue Service-Acceptance-Prüfung verifiziert Release-, Kunden- und Policy-
+Signaturen zusammen, erzwingt die Gerätezuordnung und erhält gespeicherte
+Policy-Mindestversionen pro Nutzer-SID, Gerät und Policy-Schlüssel. Auch eine
+neuere Deployment-Freigabe oder eine Schlüsselrotation löscht alte Grenzen nicht.
+Der kanonische vollständige Zustand ist auf 2 MiB und 8.192 eindeutige Einträge
+begrenzt; 1.024 Bytes des Frame-Budgets bleiben für den festen Snapshot-/CAS-
+Umschlag reserviert. Der vollständige serialisierte Commit wird zusätzlich
+gegen das 2-MiB-Limit geprüft. Überfüllung wird gesperrt. Der Commit-Gate wartet auf die exakte
+native Persistenzbestätigung und akzeptiert weder unsichere Ergebnisse noch
+automatische Wiederholung nach einem ungewissen Commit.
+
+Die unabhängige Prüfung reproduzierte außerdem einen Start-Binding-Fehler:
+eine andere gültig signierte Policy unter derselben Version konnte eine neue
+Factory erreichen, obwohl ein vorheriger Plan andere Inhalte bestätigt hatte.
+Der Start vergleicht jetzt zusätzlich den exakten Digest des bestätigten
+Policy-Payload-Feldes und die Version, bevor die Factory aufgerufen wird.
+Direkte Plan-/Commit-/Start-Komposition und gleichversionige Alternativ-Policy
+werden zusammen geprüft: acht Akzeptanz-/Commit-Tests und sechs Bootstrap-Tests
+bestanden. Ein weiterer Akzeptanztest beweist die Sperre von 8.000 einzeln gültigen
+Einträgen durch das gesamte serialisierte Byte-Budget (neun Akzeptanztests grün).
+Der Digest der Policy verwendet
+das Base64url-Payload-Feld als String; Release-/Deployment-Digests verwenden
+die decodierten kanonischen Bytes. Die native Implementierung muss diese
+unterschiedlichen Verträge einhalten.
+
+Diese Regeln und Callback-Bestätigungen beweisen noch keinen Registry-Commit.
+Offen ist ein tatsächlich geschützter einzelner AcceptanceState-Wert mit
+Vergleich des vorherigen Zustands, vollständiger monotoner Transition und
+RegFlushKey vor Bestätigung. Fehlender Zustand darf nicht als Version null
+initialisiert werden. Installation und Freigabe dieses Stores bleiben offen.
+
+Der native Store verwendet dafür feste Helper-Rollen `--trust-snapshot` und
+`--commit-acceptance`, einen einzelnen AcceptanceState-Registrywert und eine
+begrenzte Compare-and-swap-Anfrage. Der Quellpfad prüft Dienst-SID, tatsächlichen
+geschützten Node-Elternprozess, signierte Zuordnung, Flush und Rücklesen vor
+Bestätigung. Bisher wurde kein produktiver HKLM-Write ausgeführt; die
+uninstallierte Rollen-Ablehnung ersetzt keine positive Dienst-/Store-Prüfung.
+Die JavaScript-Anbindung wird separat auf genau eine gerahmte Antwort und
+bestätigtes Prozessende geprüft, ohne vom Renderer gewählte Pfade oder Schlüssel.
+
+Offene native Ownership-Prüfung: Eine aktivierte Dienst-SID ist nicht automatisch
+als Eigentümer zulässig. Windows verlangt für einen Gruppen-Owner das
+SE_GROUP_OWNER-Attribut; siehe [Microsoft TOKEN_OWNER](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_token_owner).
+Eine Alternative muss implizites WRITE_DAC des Kontoeigentümers ausdrücklich
+einschränken und tatsächlich testen; [Microsofts SID-Dokumentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers)
+beschreibt die OWNER-RIGHTS-SID. Ein Plan oder DACL-String allein ist kein
+Nachweis der tatsächlichen LocalService-/SCM-Berechtigungen.
+
+Der native Test bestätigt inzwischen eine Alternative ohne SeRestore und ohne
+angenommene Service-SID-Owner-Eignung: Standardkontoeigentümer plus ausdrückliche
+OWNER-RIGHTS-ReadControl-Berechtigung. Im tatsächlichen Test wird WRITE_DAC mit
+Access Denied (5) verweigert, während Mutex-Synchronisation und Modify erlaubt
+sind. Das prüft die Owner-Regel, nicht einen installierten SCM-Commit.
+
+Die JavaScript-Service-Anbindung besitzt einen eigenen festen Entry-Pfad und
+wartet auf die native Persistenzbestätigung vor Factory/Listen. 16 gezielte
+Transport-/Entry-/Akzeptanztests bestehen. Die unabhängige Quellprüfung fand noch
+Interoperabilitätskorrekturen vor einem nativen Lauf: Die vom Host ermittelte SID
+muss ausdrücklich an den Helper weitergegeben werden; der begrenzte rohe
+Release-Envelope muss den Base64-Overhead berücksichtigen; partielle Dateireads
+benötigen vollständige begrenzte Verarbeitung und Vorher-/Nachher-Prüfung.
+Die Fake-/Subprozess-Tests schließen diese tatsächlichen Dienst-Gates nicht.
+
+Nach unabhängiger Korrektur bestehen 18 gezielte Service-Store-/Entry-/Akzeptanz-
+Tests. Ein tatsächlicher Subprozess erhält nur die validierte vom Host ermittelte
+SID und die beiden Windows-Systemvariablen. Ein echter signierter Release mit
+6.007 Dateien und mehr als 2 MiB rohem Envelope wurde über begrenzte partielle
+Reads vollständig gelesen und kryptografisch verifiziert. Dateiidentitätswechsel
+und ungültige Antworten werden gesperrt. Das ist weiterhin keine positive
+SCM-/HKLM-Abnahme.
+
+Zusätzliche offene WFP-Abnahme: CONNECT-Filter allein reichen nicht aus.
+[Microsofts ALE-Dokumentation](https://learn.microsoft.com/en-us/windows/win32/fwp/ale-stateful-filtering)
+beschreibt, dass nach erster Freigabe eines eingehenden oder ausgehenden Flows
+beide Richtungen zustandsbehaftet erlaubt sind. Deshalb braucht die Browser-EXE
+auch RECV_ACCEPT-Sperren für neue eingehende IPv4-/IPv6-Flows und tatsächliche
+inbound-first-UDP-/TCP-Tests. Vor einer Aktivierung müssen bisherige lokale
+Agent-/Management-/Inspector-/OTLP-Listener bzw. Transporte über den Broker laufen.
+Der bisherige Vier-CONNECT-Filter-Plan und eine normale Unternehmens-Firewall
+beweisen diese Grenze nicht. Keine dieser neuen WFP-Regeln wurde aktiviert.
+
+Der Plan und die Installer-/Probe-Quellen enthalten jetzt sechs Browser-Regeln:
+vier CONNECT- und zwei RECV_ACCEPT-Sperren. Sechs JavaScript-Planprüfungen und
+21 Python-Vertrags-/Fehlertests bestehen. Das sind keine aktivierten Windows-
+Filter oder physischen Egress-Tests. Zusätzlich muss die tatsächliche WFP-
+Arbitration geprüft werden: höher priorisierte Hard-PERMITS können gewöhnliche
+Sperren beeinflussen; siehe [Microsofts Filterarbitration](https://learn.microsoft.com/en-us/windows/win32/fwp/filter-arbitration).
+Die bisherige niedrige Sublayer-Priorität allein beweist keine wirksame Grenze.
+Eindeutige Priorität/Kollisionsregeln, native Topologieprüfung, relevante
+Änderungsüberwachung und tatsächliche TCP-/UDP-Tests bleiben vor Freigabe offen.
+
+Die DNS-Migrationslücke ist im neuen Broker behoben: Alle aufgelösten Adressen
+werden gegen security.dns.blockedIPs geprüft; eine gesperrte Adresse verwirft
+die Route. Bei aktiver IP-Policy erhält der Unternehmens-Proxy ausschließlich
+die freigegebene numerische CONNECT-Adresse. SNI, Host und TLS-Zertifikatsprüfung
+bleiben an den ursprünglichen Namen gebunden. Der achte native Factory-Test
+beweist sechs tatsächliche numerische Tunnel und unveränderte DLP-Blockierungen.
+Der System-/VPN-Resolver bleibt der unterstützte Pfad. Konfiguriertes Secure DNS
+wird ausdrücklich als nicht unterstützt abgewiesen statt still heruntergestuft.
+Die Hauptbrowser-/Dienst-Migration und externe Kunden-Proxy-Abnahme bleiben offen.
+
+Für diese Release-Verifikation wird standardisierte P-256/ECDSA mit Windows CNG
+und getrennt delegiertem Kundenschlüssel entwickelt. Das ist klassische
+Signaturkryptografie und kein Nachweis quantensicherer Artefakt-Signaturen.
+Produktionssignierung und die vollständige Windows-Verifikation bleiben offen.
+
+Die unabhängige Prüfung des Release-Inventars fand einen Integrationsfehler:
+kanonisch signierte JSON-Objekte hatten eine andere Feldreihenfolge als das
+Dateiinventar und wurden deshalb fälschlich abgewiesen. Der Vergleich prüft jetzt
+explizit Pfad, Größe und SHA-256 bei unveränderter vollständiger Inventarabdeckung.
+Eine echte Signieren-/Verifizieren-/Dateisystem-Prüfung und anschließende
+gleichgroße Dateimanipulation prüfen beide Richtungen. Diese Testschlüssel liegen
+nur im Speicher; daraus entsteht kein produktiver Signaturnachweis.
+
+## Reihenfolge der verbleibenden Core-Arbeit
+
+Der erste echte Start des neuen gepackten Production-Childs war vor `READY`
+gesperrt. Der feste lokale Startcode `broker-startup-transport` identifizierte
+eine konkrete Typinkompatibilität: Die Factory lieferte ein CA-Array, während
+der geprüfte HTTPS-Forwarder ausschließlich PEM-String oder Buffer akzeptiert.
+Die Korrektur verbindet die freigegebenen öffentlichen PEM-Zertifikate zu einem
+String; TLS-Prüfung und Hostname-Prüfung bleiben aktiv. Der tatsächliche neu
+gestagte Prozess-/Transfernachweis bestand nach dieser Korrektur: tatsächlicher
+Production-Child mit offiziellem Node, enthaltenem Inspector und privater IPC,
+öffentlicher Upload exakt 16 Bytes / 201 / eine Zielverbindung, Geheimnis 403
+ohne zusätzliche Zielverbindung und tatsächliche erkannte Regel im fsync-Audit.
+Nachweis: `broker-production-native/proof-2026-10-14T09-10-08.981Z.json` unter
+`artifacts`; bestätigtes Prozessende. Dies ersetzt weder den Hauptbrowserpfad
+noch Download-, Unternehmens-Proxy- und WFP-Abnahmen.
+Ein später erfolgreicher direkter Inspector-Start ersetzt diesen Nachweis nicht.
+
+Umgesetzt: bekannte Base64-verpackte binäre Dokumente in JSON/Data-URLs erhalten
+vor Freigabe Magic-Byte-, Fingerprint- und lokale Parserprüfung. Native Nachweise
+stehen unten. Download-Blockierungen besitzen typisierte Download-Fakten und
+registrierte Scanner-Regel-IDs. Dies ersetzt keine allgemeine Abdeckung beliebiger
+Kodierungen oder die noch offene Hauptbrowser-Anbindung.
+
+Der neue begrenzte Carrier-Extractor ist implementiert und nach unabhängiger
+Prüfung um JSON-interne Prozentkodierung, verschachtelte Text-Envelopes und
+strikte JSON-Primitive erweitert. Acht Regressionstests und Lint bestehen.
+Die Integration erhält ein gemeinsames Byte-/Teil-/Knoten-/Rekursionsbudget über
+alle decodierten Teile und erzwingt tatsächliche Dokumentparser.
+Unbekannte rohe Binärkodierungen und Vektor-/SVG-Rendering sind damit nicht
+pauschal abgedeckt; ausdrücklich deklarierte unprüfbare Carrier müssen sperren.
+Die kombinierte native Production-Child-Prüfung besteht nach kontrolliert
+nachgewiesener Ergänzung von genau `USERPROFILE`, `LOCALAPPDATA` und `APPDATA` in
+der Windows-Umgebung. Geheimnisse im Hex-PDF werden in JSON und Prozent-Data-URL
+mit tatsächlicher registrierter Regel ohne zusätzliche Zielverbindung blockiert.
+Öffentliche äußere JSON-Bytes werden nach vollständiger Parserprüfung unverändert
+übertragen. Öffentlicher PDF-Download funktioniert; gesperrter PDF-Download gibt
+keine PDF-Bytes frei und erhält ein kausal verknüpftes `download.block`-Ereignis.
+Neun fsync-persistierte synthetische Ereignisse; bestätigtes Broker-Prozessende.
+Der ursprüngliche fehlgeschlagene kombinierte Nachweis bleibt erhalten. Die
+Umgebungskorrektur verändert weder ACLs noch Parser-, TLS- oder Policy-Prüfungen.
+Factory-Unternehmens-Proxy und Hauptbrowser-/Installer-Abnahmen bleiben offen.
+Nachweis: `broker-production-native/proof-2026-10-14T09-48-31.825Z.json` unter
+dem ignorierten lokalen `artifacts`-Verzeichnis.
+
+### Verbindlicher Auslieferungsvertrag
+
+Ein gemeinsamer Windows-Installer enthält Browser, separaten DLP-Broker,
+dessen private Runtime, lokale Scanner und Modelle. Auf dem Zielgerät ist keine
+Entwicklungsinstallation von Node oder Python und kein manueller Broker-Start
+erforderlich. Der Zielpfad startet und überwacht den enthaltenen Broker über einen
+geschützten Windows-Dienst; dessen Installation und produktive Anbindung sind
+noch nicht nachgewiesen. Fehlt
+dieser, ist er manipuliert oder fällt er aus, dürfen geschützte Transfers nicht
+auf einen ungeprüften direkten Netzwerkpfad ausweichen. Update und Deinstallation
+müssen auch die zugehörigen verwalteten Komponenten berücksichtigen.
+Ein entpacktes Entwicklungsverzeichnis allein erfüllt diesen Vertrag nicht.
+
+### Neue lokale Integrationsnachweise
+
+- Gemeinsamer Repository-Lauf: ESLint und sämtliche JavaScript-Syntaxprüfungen
+  bestehen; 1.119 Node-Tests, davon 1.107 bestanden, null Fehler und zwölf explizite
+  native Opt-in-Skips. Der Lauf ersetzt diese ausgelassenen nativen Abnahmen nicht.
+  Tatsächlicher privater OTLP-Trace `4a4cbe86f72921e7e1d9a2b94abcb4b8` enthält
+  fünf korrelierte Spans, null aktuelle/lebenslange Exportfehler. Zwei anschließend
+  ergänzte Credential-Lifecycle-Consumer-Regressionen bestehen separat.
+- Credential-Lifecycle korrigiert: Der native Request muss zuerst exakt zur
+  aktuellen angenommenen Policy passen. Für denselben SID, Device, Origin und
+  Policy-Key kann der jüngste zulässige ältere Credential-Datensatz wiederverwendet
+  werden; seine eigenen Metadaten bleiben an die DPAPI-Entropie gebunden. Ein
+  gleiches Versionsdatum mit anderem Digest, zukünftige Versionen und Mehrdeutigkeit
+  werden abgewiesen. Provisionierung ersetzt diese stabile Identität statt ihre
+  Versionshistorie unbegrenzt anzuhäufen. Native Auswahl-/CAS-/Registry-Ausführung
+  ist weiterhin nicht nachgewiesen; die zwei JS-Tests prüfen die Consumer-Grenze.
+- DPAPI-Capability-Helfer gehärtet: private Python-Runtime mit `-I -B` und
+  ausschließlich erlaubten Windows-Umgebungsvariablen. Ausgabe ist vorallokiert
+  und begrenzt; späte Daten nach einem Fehler werden ignoriert. Höchstens acht
+  ursprüngliche Helper-Prozesse bleiben bis zu ihrem tatsächlichen Ende belegt;
+  ein fehlgeschlagener Kill gibt keine Kapazität frei. Fehler bleiben bereinigt.
+  Tatsächliche Windows-DPAPI-Roundtrips bestehen auch für 32.768 Eingabebytes und
+  44.000 Ciphertext-Bytes sowie bei manipulierten Python-Umgebungsvariablen.
+  Fünf Tests, null Skips. Die früher kleinere Entschlüsselungsgrenze wurde an
+  den tatsächlich größeren Ciphertext angepasst, ohne Klartextgrenze zu erhöhen.
+  `artifacts/dpapi-helper/proof.json` enthält vier tatsächliche private OTLP-Spans,
+  Trace `a2f37753f5620155c4944b26ef1189bd`, null Exportfehler. Die beiden
+  Credential-Stufen wurden mit tatsächlichem Parent und Zeiten abgerufen.
+  Der Audit-Korrelationsanker ist synthetisch; kein Browser-Upload fand statt.
+- Begrenzte Management-Operationen prüfen jetzt Identität und verschlüsselte
+  Policy über fest vorgegebene HTTPS-Routen. ML-KEM-1024, gepinnte ML-DSA-87-
+  Signaturen, Device-Bindung, Mindestversion und gleicher-Version-Digest werden
+  geprüft. Beide Policy-Aufrufe teilen ein Deadline-/Job-Budget; Widerruf nach
+  Challenge verhindert den zweiten POST. 16 Tests bestehen. Das Policy-Ergebnis
+  aktiviert keine Regeln und ersetzt keinen geschützten Floor-Commit.
+- Native Topologie-/Credential-Quellen sind erweitert und kompilieren. Ihre
+  aktuelle Ausführung ist ausdrücklich nicht nachgewiesen: Beim Topologie-
+  Selftest war die EXE vor dem Start vorhanden und gehasht; der Start scheiterte
+  mit `UNKNOWN:spawn`, danach fehlte die Datei. Gezielte schreibgeschützte
+  Defender-/CodeIntegrity-Abfragen belegen keine Ursache dieses Fehlers.
+  `topology-compile-only-proof.json` und `current-compile-only-proof.json` unter
+  `artifacts/native-service-host` unterscheiden Kompilierung von Ausführung.
+  Frühere native v2-Erfolge gelten für den damaligen Hash. Kein Endpoint-Schutz
+  wurde deaktiviert, kein neuer Registry-/SCM-/WFP-Zustand aktiviert.
+- Neunter Payload: `broker-prepared-service-proof-ninth.json` unter `artifacts`,
+  313 Dateien / 64 Quellnachweise, sechs tatsächliche Paket-Isolationsprüfungen.
+  Native Test-EXEs, Signing-Assets und damals unreviewte Credential-Helfer sind
+  ausgeschlossen. Spätere Policy-/Credential-Quellen benötigen einen neuen
+  expliziten Snapshot; dieser Komponenten-Nachweis ist keine Installer-Abnahme.
+- Dienst-Lifecycle weiter geprüft (`broker-service-lifecycle-proof-2026-10-14.json`
+  unter `artifacts`): Paketprüfung, Startbereitschaft und Herunterfahren besitzen
+  benannte tatsächliche OTLP-Spans. Trace `d0e4c73944250d8f96864c043e6a83d9`
+  enthält fünf korrelierte Spans; aktuelle und lebenslange Exportfehler null.
+  Instrumentierung kann Prüfungen nicht überspringen, ersetzen oder wiederholen.
+  Der Prozesspfad wartet ursprüngliche Factory-/Listen-/Cleanup-Promises ab;
+  verspätete Ergebnisse geben keine Bereitschaft frei. Cleanup-Fehler bleiben
+  beim wiederholten Close erhalten statt als erfolgreicher Abschluss zu gelten.
+  25 gezielte Prozess-/Dienst-/Framing-Tests bestehen. Ein parallel noch mit
+  altem Testinhalt gestarteter Lauf hing an unterdrücktem Startup-Fault; der
+  korrigierte Test wartet die tatsächliche Quarantäne-Disconnection ab.
+- Deployment v2 bindet HTTPS-Management-Origin und bestehenden ML-DSA-87-Pin.
+  Native MSVC-Kompilierung besteht; sechs positive und 23 tatsächlich signierte
+  negative native Manifestfälle geprüft. Der native Parser validiert PQ-Key-
+  Metadaten; die tatsächliche PQ-Signaturprüfung bleibt im vorhandenen Node-
+  Kanal. Die erste begrenzte Management-Operation prüft Identität über HTTPS mit
+  Ed25519 und gepinntem ML-DSA-87. Sechs physische HTTPS-Tests bestehen. Geschützte
+  Credentials, Enrollment und produktive IPC-Anbindung sind noch nicht umgesetzt.
+- Dienst-Bootstrap akzeptiert ausschließlich Receiver-Port 43120, passend zur
+  festen nativen/WFP-Grenze. Andere Ports scheitern vor Trust-Load und Konstruktion;
+  20 kombinierte Bootstrap-/Acceptance-/Service-Tests bestehen. Der separate
+  isolierte Production-Child-Empfängertest darf weiterhin Testports verwenden.
+  Neue Trust-/Lifecycle-/Topologiequellen erfordern vor dem nächsten Paketnachweis
+  einen frischen explizit geprüften Payload; der achte bleibt historische Evidenz.
+- Achter Payload: `broker-prepared-service-proof-eighth.json` unter `artifacts`,
+  309 Dateien / 60 Quellnachweise, sechs physische Paket-Isolationsprüfungen.
+  Aktualisierter nativer Production-Child-Test besteht:
+  `broker-production-native/proof-2026-10-14T11-28-12.697Z.json`, sechs numerische
+  HTTPS-Proxy-Tunnel mit ursprünglichem SNI, 13 persistierte Ereignisse und
+  22 tatsächliche private OTLP-Spans. Trace `40c28b579ce1adb8010503bae74b40f5`
+  wurde mit seinem Audit-Kindspan abgerufen; aktuelle und lebenslange Exportfehler
+  null. Die Exporte stammen vom privilegierten Test-Parent, nicht vom Dienst-SDK.
+- Neuer Browser-Dienstadapter startet ausschließlich den fest installierten
+  nativen Host mit `--client-stdio`. Installation und Broker-Paket müssen vorher
+  unabhängig verifiziert sein. Fünf Adaptertests mit tatsächlichem Node-Testchild
+  plus zehn bestehende Supervisor-Tests bestehen. Das ist kein SCM-Positivnachweis.
+  Der zusätzliche OTLP-Test persistiert ein synthetisches Audit-Ereignis mit fsync
+  und ruft zwei tatsächliche, kausal verbundene Spans ab:
+  `8be57a1790a8429140f5eeb71e0e219c`, null Exportfehler. Ein erster Test scheiterte
+  an einer ungültigen Fixture-UUID; die strikte Validierung blieb unverändert.
+  Hauptbrowser-Aktivierung und native Dienst-Authentifizierung stehen noch aus.
+- Office-Timings mit tatsächlichem AppContainer-Inspector und privatem OTLP-
+  Testempfänger geprüft: `private-otlp-proof-2026-10-14T08-29-16.980Z.json`
+  unter `artifacts/office-native-observability`. Vier benannte Office-Spans hängen
+  am tatsächlichen Parse-Span; defektes Archiv erzeugt einen bereinigten Fehler-
+  Span. Aktuelle und lebenslange Exportfehler: null. Dies ist kein Nachweis der
+  produktiven Collector-Konfiguration; diese wurde nicht geändert.
+- Kurzlebige Broker-TLS-Zertifikate werden im Speicher erstellt, mit exakter SAN,
+  ohne CA-Berechtigung und mit begrenztem Cache. Physischer Node-HTTPS-Test prüft
+  die Zertifikatskette und verwirft einen falschen Hostnamen. Die Browser-
+  Vertrauensbindung und die produktive Factory bleiben gesondert offen.
+- Sitzungsgebundene Zertifikat-Pins mit tatsächlichem Stock-Electron 44.7.0 /
+  Chromium 152.0.7977.130 geprüft (`broker-certificate-pins/proof.json` unter
+  `artifacts`): registriertes kurzlebiges Leaf liefert 200, unregistriertes Leaf
+  wird ohne Anwendungsanfrage abgewiesen. Der Fingerprint wird aus Electrons
+  tatsächlichem `Certificate.data` berechnet. Generation, SAN, Ablauf und Policy
+  werden geprüft. Electrons Callback liefert keinen Port und cached Ergebnisse;
+  CONNECT-/SNI-/Host-Bindung sowie Schließen alter Verbindungen bleiben zwingend.
+  Der produktive Browser ist noch nicht auf diesen Helper umgestellt.
+- Der Parent-Audit-Adapter wurde mit tatsächlichem Windows-DPAPI und einer
+  synchronen `fsync`-/Rename-Persistenz geprüft (`broker-parent-audit/proof-7IKfqn`
+  unter `artifacts`). Die ursprüngliche Broker-Ereignis-ID wird erst nach Commit
+  bestätigt; Klartext-ID fehlt in der geschützten Datei. Fehler, asynchrones
+  Einreihen und uneindeutige boolesche Writer-Ergebnisse geben keine Bestätigung.
+  Die produktive Private-IPC-/Browser-Anbindung dieses Adapters bleibt offen.
+- Der tatsächliche lokale SIEM-Dateiexporter erhält die Broker-Ereignis-UUID und
+  die Verbindung zwischen Freigabe und anschließendem Übertragungsfehler.
+  ECS/CEF-Felder und deren Grenzen stehen in [broker-siem.md](broker-siem.md).
+  Eine Freigabe hat einen unbekannten Lieferstatus; Terminalfehler werden als
+  Fehler ausgewiesen. Dieser Nachweis ersetzt keine externe SIEM-Abnahme.
+
+1. Nativer PDF-/Office-Nachweis mit verpflichtender Audit-Persistenz bestanden:
+   `office-proof-2026-10-14T08-23-30.852Z.json` unter dem ignorierten lokalen
+   Evidenzverzeichnis `artifacts/broker-native-inspection`. Sieben mit `fsync`
+   persistierte synthetische Ereignisse, drei tatsächliche erkannte Geheimnisregeln,
+   keine Zielverbindung für gesperrte Dokumente und keine verbleibenden eigenen
+   Inspector-Prozesse. Die Fixture beweist weder produktive Audit-Verschlüsselung
+   noch SIEM-Auslieferung; Diagnostik war zentral deaktiviert.
+2. Sicherheitsereignisse für frühe CONNECT-/Framing-Blockierungen und Fehler nach
+   Transferfreigabe ergänzen. Eine protokollierte Freigabe ist kein Nachweis einer
+   erfolgreichen Übertragung. Erlaubte Dokumente müssen funktionieren; Geheimnisse
+   dürfen beim kontrollierten Empfänger nicht ankommen.
+3. Zertifikats-/Trust-, Proxy-, Audit- und Management-Pfade vollständig integrieren.
+   Kein ungeprüftes CONNECT-Piping oder DIRECT-Fallback als Ersatz.
+4. Windows-Regeln über den geprüften Installer-/Service-Pfad aktivieren und
+   unabhängig nativ prüfen. Erst dann die bisherige Header-Sperre ersetzen.
+5. Gemeinsamen Installer bauen und ohne Entwicklungsruntime abnehmen, einschließlich
+   Ausfall, Widerruf, Update und fehlender/manipulierter Broker-Dateien.
+
+Die detaillierten Anforderungen bleiben in [windows-dlp-mvp.md](windows-dlp-mvp.md).
+Diese Übersicht ersetzt weder deren Kriterien noch die übrige Enterprise-Roadmap.

docs/native-runtime/README.md

@@ -1,11 +1,39 @@
 # Chromium 152 WebRTC binder backport
 
+## Cancelled implementation path — stock runtime required
+
+The user explicitly rejected rebuilding Chromium/Electron on2026-10-14. The
+owned native build was stopped and its terminal failure/cancellation evidence
+retained. No custom binary was activated or shipped. This document's backport,
+compiler and source-checkout records are historical evidence, not instructions
+to resume that implementation. **Do not restart this build or make a custom
+Chromium runtime a product dependency.**
+
+The current direction is an unchanged official Electron/Chromium runtime plus
+an independently enforced Windows network boundary and separate controlled DLP
+broker. This alternative is not yet implemented or accepted. The existing relay
+allows opaque CONNECT forwarding and shares Electron's executable/process with
+upstream management traffic, so merely adding per-executable firewall blocking
+or removing the WebRTC header would not provide the required boundary. Retain
+the present protection until hostile native transport and DNS tests prove its
+replacement. A JavaScript constructor wrapper alone is insufficient.
+
 Status: source patch prepared and checked; **not compiled or runtime verified**.
 Do not distribute this patch as a proven security fix until the acceptance gates
 below pass against the resulting binary.
 
 ## Latest stable candidate checked
 
+On2026-10-14 the newer official Electron44.7.2 Windows x64 binary was also tested.
+Its ZIP matches the official SHA256 manifest:
+`10a89447ef64ac5cb9f782af48ffd83734a40ae91681259d1048ca3c9e6c5da4`.
+Both initialabout:blank andsrcdoc positive controls delivered exact synthetic
+RTC data and benign POSTs. Both corresponding managed-policy cases still
+crashed with missing MdnsResponder, bad IPC123 and renderer exit3. The earlier
+run's positive timeout remains preserved separately. Evidence:
+`artifacts/native-rtc-4472-second-proof.json`. No project dependency was upgraded.
+Thus this newly available binary does not replace the native backport either.
+
 The official [Electron44.7.1 release](https://github.com/electron/electron/releases/tag/v44.7.1)
 uses Chromium152.0.7977.149. Its Windows x64 ZIP was downloaded into an isolated
 ignored directory, checked against the official SHA256 manifest and extracted
@@ -254,6 +282,61 @@ is not identified as a compiler tool, but the official full sync remains failed.
 This read-only analysis authorizes neither skipping dependencies nor changing
 antivirus policy. ATL/MFC remains independently missing at the host check.
 
+## Alternative dependency installation, 2026-10-14
+
+The normal Microsoft installer subsequently completed. `vswhere` now finds
+`Microsoft.VisualStudio.Component.VC.ATLMFC` in the existing BuildTools instance
+and reports both `isComplete=true` and `isLaunchable=true`; the installer process
+has ended. Ignored evidence: `artifacts/native-build/atl-mfc-installed-proof.json`.
+Thus the earlier missing-component prerequisite is resolved. This does not by
+itself prove a generated GN graph or a working native compilation.
+
+The user's explicit alternative-build request was implemented without changing
+Defender. A reviewed CIPD ensure manifest preserves all forty original requested
+package/subdirectory/version bindings from the existing `.gclient_entries`,
+except the single rejected Chrome-x86 updater fixture described above. The
+thirty-nine remaining bindings were processed by the official CIPD client with
+exit0 in119.7seconds. No new antivirus error occurred. Original version tags
+were preserved; this is not a claim that every tag was resolved offline to an
+immutable instance ID. The source entries and both manifests retain their
+verified hashes. Native Chromium/Electron HEADs and captured references remained
+unchanged before/after; no full Git sync or patch replay occurred.
+
+Ignored evidence: `cipd-manifest-offline-proof.json`,
+`cipd-reviewed-ensure-journal.json` and `cipd-reviewed-ensure.log` under
+`artifacts/native-build`. The original failed full sync remains retained.
+Updater regression tests using the omitted fixture are not accepted. A generated
+Electron/native-test GN dependency graph must confirm that the omitted target is
+not needed before compiling. Required hooks, ATL/MFC, compilation and real native
+acceptance remain separate gates. The signed Microsoft installer was launched
+through normal Windows UAC; installation is not confirmed by starting it.
+
+The selected original RC and four version-generation hooks subsequently exited0.
+RC matches its checked-in SHA1 and has recorded SHA256 provenance. Electron's
+Yarn4.18.0 immutable install also completed with unchanged lockfile and config.
+`enableScripts:false` stayed set, but the upstream workspace fixtures and explicit
+`dependenciesMeta.built:true` entries executed their permitted builds; this is
+not an all-scripts-disabled claim. All native HEAD/reference snapshots remained
+unchanged, with no Defender modification or new antivirus error. Evidence:
+`selected-hooks-journal.json` and per-action logs. The official local toolchain
+check also exited0, recognizing VS2022 and Windows SDK10.0.26100.0 without a Google
+toolchain download (`local-toolchain-proof.json`). GN generation, target-graph
+verification and product compilation remain separate steps.
+
+GN generation subsequently succeeded in the fresh `out/SafetyNetTestingPython314`
+directory with the supported explicit Python interpreter switch; the original
+Windows-Store-alias failure remains retained. Actual recursive GN graphs for
+Electron and content_unittests contain no omitted updater-fixture dependency.
+Both NoOp test sources are present and `enable_mdns`/`is_p2p_enabled` are true.
+Evidence: `gn-generation-python314-proof.json` and `gn-target-graph-proof.json`.
+Physical Ninja aliases were also checked. The initial compile launch was
+controlled-stopped before observed compiler progress for insufficient memory;
+that failed attempt remains retained. A fresh continuation started only after
+the measured available commit memory exceeded4GiB, using one compiler job,
+bounded disk/memory guards and no remote execution. This running build is not
+yet a completed compilation or native acceptance. The shipped runtime remains
+unchanged until the required real tests pass.
+
 ### Patch readiness before compilation
 
 ATL/MFC is required for the native toolchain, not for the Python patch import

docs/requirements-audit.md

@@ -7,7 +7,23 @@ Die breiteren Anforderungen und Erweiterungen unten bleiben Roadmap.
 
 ## Aktuelle nächste Abnahmen
 
-**Aktualisierung des Windows-MVP:** 784 Tests bestehen mit begrenzter
+**Stand 14. Oktober 2026:** Das neue Windows-DLP-MVP ist nicht abgenommen.
+Maßgeblich ist die [aktuelle Abnahmematrix](core-dlp-current-status.md).
+Ein gepackter separater Broker ist mit privater Runtime und realen lokalen
+Scannern geprüft, aber noch nicht im Hauptbrowser aktiviert. Der eigene
+Chromium-Build wurde abgebrochen; stock Electron bleibt Voraussetzung. Der
+geschützte Windows-Dienst, native Netzwerkdurchsetzung, gemeinsame Installation
+und erneute vollständige Clipboard-/Upload-/Download-Abnahme sind offen.
+
+Aktuelle Arbeit: Timeout-Korrektur für die reale Unternehmens-Proxy-Prüfung,
+authentifizierter Diensttransport und getrennte Release-/Kundendeployment-
+Signaturen. Klassische Release-Signaturen sind kein quantensicherer Nachweis.
+Baustein-/Fixture-Tests und frühere Browser-Builds ersetzen weder den aktuellen
+Hauptbrowserpfad noch einen final installierten gemeinsamen Broker-Installer.
+
+### Historische Integrationsnachweise
+
+**Vorangegangener Windows-MVP-Stand:** 784 Tests bestehen mit begrenzter
 Parallelität. Der aktuelle Windows-Build besteht Paket-, Fuse- und
 Manipulationsprüfungen, ist aber nicht signiert. Native Clipboard-/Upload-Tests,
 Prozessneustart bestehen auf dem finalen Quellstand. Die lokalen semantischen
@@ -21,7 +37,7 @@ WebRTC-Absturz bleibt offen, bis ein korrigiertes Binary geprüft ist.
 Die folgenden älteren Integrationszahlen beschreiben historische Zwischenstände;
 die aktuelle verbindliche Abnahme steht im [Windows-MVP-Ziel](windows-dlp-mvp.md).
 
-Aktueller Integrationsstand: 713 Tests bestehen
+Früherer Integrationsstand: 713 Tests bestehen
 (`artifacts/worker-integration-suite.log`). Der echte Admin-Workflow für typisierte
 Login-Regeln, unabhängige Veröffentlichung und Auditor-Leserechte ist geprüft:
 193 abgeschlossene Anfragen mit korrelierten exportierten Traces, eine abgebrochene

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.