Add packaged DLP broker and protected Windows service foundation

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.