safetynet/docs/windows-dlp-mvp.md

# 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
Texte oder Dateien durch Uploads, Copy/Paste oder KI-Prompt-Versand an nicht
erlaubte Ziele gelangen. Erst nach der folgenden Abnahme wird das MVP abgeschlossen.

## Abnahmekriterien

1. Ein Administrator kann vertrauliche Textbeispiele und Referenzdokumente
   registrieren, Regeln veröffentlichen und erlaubte KI-Ziele konfigurieren.
   Der Browser erzwingt die signierte aktuelle Policy; Benutzer können den Schutz
   nicht durch lokale Einstellungen abschalten.
2. Paste per Tastatur, Kontextmenü und Seiten-Clipboard wird vor Freigabe geprüft.
   Copy und Cut werden ebenfalls vor dem Schreiben in die Windows-Zwischenablage
   geprüft. Jeder Paste liest den aktuellen Inhalt, einschließlich Änderungen
   durch andere Anwendungen, und gibt ausschließlich den geprüften Snapshot
   frei. Die zentrale Policy kann vertrauliche Inhalte und gefährliche
   Ausführungsbefehle sperren. Änderungen von Ziel, Auswahl oder Policy während
   eines asynchronen Scans dürfen keinen ungeprüften Inhalt freigeben.
   Erlaubter öffentlicher Text funktioniert in normalen Eingabefeldern und den
   im MVP getesteten Web-Editoren unabhängig von Website oder Anwendung
   (Notizen, Webmail, Chat und KI). Vertraulicher Text wird blockiert. Anschließender
   Versand, getippter Text und durch Seitenskripte erzeugte Request-Bodies werden
   zusätzlich geprüft; Paste-Prüfung allein reicht nicht.
3. Gewöhnliche Windows-Dateiuploads per Dateiauswahl und Drag-and-drop werden
   anhand der tatsächlich übertragenen Bytes geprüft. Lokale Klassifikation,
   Fingerprints, semantische Erkennung und erforderliches OCR bleiben lokal.
   Änderung nach dem Scan darf keine ungeprüften Bytes freigeben.
4. Verschlüsselte, übergroße oder unvollständig geprüfte Dateien sowie nicht
   unterstützte Transferwege werden mit verständlichem Grund blockiert.
   Fehler, Scanner-Ausfall, abgelaufene Policy und Widerruf dürfen keine
   Freigabe vertraulicher Inhalte verursachen. Alternative Netzwerkwege dürfen
   die erzwungene DLP-Prüfung nicht umgehen.
5. Echte Windows-/Electron-Tests prüfen für jeden unterstützten Kernweg sowohl
   erlaubte Übertragung als auch vertrauliche Inhalte. Ein kontrollierter
   Empfänger beweist, dass blockierte Inhalte nicht angekommen sind. Die Tests
   schließen Policywechsel, Tab-/Frame-Wechsel und Scannerfehler ein.
6. Block-/Allow-Entscheidungen sind für den Administrator nachvollziehbar.
   Debug-Traces korrelieren Prüfung und Freigabe, zeigen Laufzeiten und Fehler;
   Passwörter und Tokens gelangen nicht in gewöhnliche Logs. Zentraler
   Diagnostikschalter verändert keine DLP-Entscheidung.
7. Ein reproduzierbarer Windows-Build enthält exakt den geprüften Code und die
   lokalen Scanner-Runtimes. Enrollment, Policy-Sync, mehrere Tabs, wiederholte
   Uploads/Paste und Neustart bestehen einen dokumentierten Stabilitätslauf.
   Keine offene kritische Umgehung oder Regression auf diesen Kernwegen.

## Aktueller Abnahmestand

**Letzter Quellstand:** Windows-Paket und beide Paketverifikationen bestehen;
Authenticode bleibt `NotSigned`. Native Clipboard-/Upload- und echte Neustarttests
bestehen erneut mit17+5 Prüfungen,13 öffentlichen Requests, null vertraulichen
Requests und zwei exakt übertragenen Dateien. Aktuelle und lebenslange
Exportfehler bleiben in diesen Prozessen0. Der frische öffentliche Diagnosetest
mit vier geprüften Policy-Veröffentlichungen besteht ebenfalls.

**Debug-Abnahme bestanden:** Nach begrenzter Export-FIFO, gemeinsamem Flush,
SDK-Abschlussbarriere und signierter Policy-Kontinuität bestehen alle vier
echten lokalen Gemma-Prüfungen und die vollständige WebTransport-Abnahme erneut
mit null aktuellen und lebenslangen Exportfehlern. Native Clipboard-/Upload-
und echte Neustarttests bestehen ebenfalls mit17+5 Prüfungen. Der Collector
meldet578 Commits, null Fehler/Ablehnungen und maximal14.87ms Queue-Wartezeit.
Timeout-Grenzen, Fehlerzähler und Abnahmeerwartungen wurden nicht gelockert.
Historische Timeout- und Cancellation-Fehler bleiben als Nachweise erhalten;
die früheren Timeout-Ursachen sind nicht rückwirkend bewiesen.
Details und Reproduktion: [begrenzte Diagnostik](diagnostics-backpressure.md).

**Noch offen:**
Der native WebRTC-Absturz bleibt ein separater offener Stabilitäts-Gate.
Das MVP ist deshalb weiterhin **nicht abgeschlossen**.

784 Tests bestehen im letzten vollständigen Lauf mit zwei parallelen Testdateien;
ESLint verlangt null Fehler und null Warnungen. Nachweis:
`artifacts/diagnostics-continuity-final-suite.log`. Ein späterer
Policy-Abbruch verlor ursprünglich seinen festen409-Fehler und lieferte500;
dieser echte Gateway-Fehler ist mit deterministischen Tests und exportierten
Traces behoben. Der stärker parallelisierte
Lauf scheiterte an einer Evidence-Schlüssel-Rechteprüfung. Die kontrollierte
ACL-Nachprüfung war geschützt; alle 18 Evidence-Tests bestanden anschließend
separat. Die ursprüngliche Ausnahme enthält keine ausreichende Ursache, um
einen Timeout rückwirkend als bewiesen zu behaupten. Kein Schutz wurde gelockert.
Die neue native Windows-Abnahme besteht mit 17 Checks, einschließlich echtem
Maus-Klick im contenteditable-Editor, Klartext/HTML-Clipboard, Policy-Race,
YARA-/ICAP-Block und Scanner-Ausfall. Danach startete ein anderer Browserprozess
mit demselben DPAPI-Profil, Gerät und Policy v4, ohne erneutes Enrollment.
Fünf weitere Neustart-Checks bestehen: insgesamt 13 erlaubte Requests,
null vertrauliche Requests und zwei exakt übertragene öffentliche Dateien.
Beide Prozesse exportierten korrelierte Clipboard-, URL- und Upload-Traces
mit null Exportfehlern. Nachweise: `artifacts/windows-dlp-mvp-process-restart-summary.json`,
`windows-dlp-mvp-first-process-native-proof.json` und
`windows-dlp-mvp-restart-native-proof.json`.
Der aktuelle integrierte Relay-/Proxy-/Preload-Stand bestand diese native
Abnahme erneut. Der gemeinsame Clipboard-/Transport-Owner bestand danach
wieder alle 17 plus fünf echten Neustart-Checks:
`artifacts/transport-owner-mvp-native.log`. Auch die echte lokale Gemma-Abnahme
bestand erneut: `artifacts/transport-owner-semantic-native.log`; Quellhashes
blieben unverändert.

Das Gateway prüft normalisierte Textdarstellungen einzeln und revalidiert
Policy/Widerruf vor Versand und Ausgabe. Tatsächliche ICAP-/Provider-Tests
blockieren auch codierte Scanner-Marker vor dem Anbieter. Begrenzte
Normalisierung ist kein universeller Deobfuskationsnachweis.

Ein Windows-Build ist abgeschlossen, einschließlich tatsächlicher
Fuse-Werte, eingebettetem ASAR-Header-Hash und Parser-ACL-Provisionierung.
Paket-/Runtime-Vergleich bestanden. Der korrigierte CLI-Inspector-Test und die
manipulierte ASAR-Kopie wurden danach tatsächlich negativ geprüft; die Kopie
wurde vor Anwendungseinstieg abgewiesen. Eine weitere unabhängige Prüfung fand
akzeptierte Zertifikats-/Feature-Bypass-Startparameter. Der Quellstand verweigert
diese inzwischen mit terminalem, festem Fehler. Der erneute Build, vollständige
Paketprüfung und elf zusätzliche negative Startfälle bestehen am tatsächlichen
Paket. Nachweis: `artifacts/package-fuses-proof.json`, einschließlich
`unsafeStartupOverridesRejected=true`. Der Installer bleibt `NotSigned`.
WebTransport ist inzwischen als tatsächlicher Umgehungsweg bestätigt:
HTTP-DLP-Hooks und Abschalt-Flags verhinderten die Übertragung nicht. Ein nativer
Proxy-Zwang wurde dagegen mit null empfangenen Paketen bei weiter funktionierendem
HTTP bewiesen. Der authentifizierte lokale Relay ist inzwischen in Enrollment,
Policywechsel und Quarantäne integriert; Browserverkehr erhält keinen DIRECT-
Fallback. Enterprise-Proxy-Zugangsdaten sind an Host und Port gebunden.
Die vollständige Browser-Abnahme mit echtem WebTransport-Empfänger besteht:
Eine ungeschützte Window-/Worker-Kontrolle übertrug 132 Bytes; der tatsächlich
enrollte Browser übertrug null Pakete und Bytes, auch nach reviewed DIRECT und
HTTPS-PAC→DIRECT-Policywechseln. Drei gewöhnliche HTTPS-POSTs funktionierten.
Nachweis: `artifacts/fullmain-webtransport-native-proof.json`, mit genauen
Quellhashes; spätere Änderungen betreffen ausschließlich Startparameterprüfung.
Die vor HTTP blockierten Versuche liefern weiterhin keine webRequest-Callbacks.
Der neue private native Observer erfasst jedoch tatsächlich sechs Created- und
sechs Closed-Lebenszyklen mit korrelierten Traces und ECS-/CEF-Metadaten.
Er teilt den begrenzten Kanal des Clipboard-Owners und trennt dessen Schutz
nicht. Die Reichweite ist Window und getesteter Dedicated Worker, keine
universelle Realm- oder Nutzlastprüfung. Details:
[Native Transportbeobachtung](native-transport-observability.md).
Ältere fehlgeschlagene Testläufe bleiben als solche erhalten.

## Verbleibende Abnahmen

Die lokale semantische Browser-Abnahme ist jetzt bestanden: reviewed Teaching
behält 36 Fragment-Fingerprints und Prüfmetadaten, keinen Originaltext. Mit
dem tatsächlichen gepinnten Modell wurden öffentliche Inhalte erlaubt und eine
nichtliteral vertrauliche Paraphrase bei Paste, Textversand und Dateiupload
blockiert. Drei öffentliche Requests und null vertrauliche Paraphrasen erreichten
den Empfänger; eine öffentliche Datei kam exakt an. Nachweise:
`artifacts/windows-semantic-dlp-native-proof.json` und
`artifacts/windows-semantic-teaching-proof.json`.

Neue Stabilitätsgrenze: Chromium 152 kann bei WebRTC in einem initialen
about:blank-Iframe unter der nativen Connection-Allowlist den Renderer beenden.
Der zusätzliche Frame-Preload verhindert entsprechende Konstruktoraufrufe in
srcdoc-, Blob- und Cross-Origin-Frames; initiales about:blank erhält diesen
Preload jedoch nicht. Diese verbleibende Grenze ist kein bestandener
All-Frame-Nachweis. Eine weitere native oder frühere Absicherung ist vor der
entsprechenden Stabilitätsabnahme erforderlich. Der zugehörige Chromium-Fix
ist Commit `46fcf3faed9db394de7046a100301f64c2842f0e`; auch die isoliert
getestete Electron-Nightly vom 13. Oktober enthält ihn noch nicht. Ein bloßes
Versionsupdate oder JavaScript-Wrapper gilt daher nicht als Lösung.
Ein kontextangepasster [Backport](native-runtime/README.md) besteht
`git apply --check` sowohl gegen die genaue Chromium-Basis als auch gegen die
vollständig verifizierten Electron-Patchserien. Der Backport ist inzwischen im
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 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.

- Aktuelle native Abnahmen zusammenführen und gegen den aktuellen Quellstand
  erneut prüfen; ältere grüne Tests belegen keinen später geänderten Build.
- Praktische Paste-/Versand-Coverage weiterer moderner Editoren prüfen.
  Einfache contenteditable-Textpfade sind nativ mit erlaubtem Text, vertraulichem
  Text und inert eingefügtem HTML geprüft. Komplexer Richtext und undurchsichtige
  Clipboard-Formate bleiben konservativ gesperrt; universelle Editor-Kompatibilität
  ist damit nicht belegt.
- Nicht unterstützte Hintergrund-/Streaming-/WebSocket-/WebRTC-Pfade auf
  tatsächliche Sperre prüfen; umfassende Worker-Unterstützung ist kein MVP-Ziel.
- Race-, Timeout-, Policywechsel- und Scannerfehler-Nachweise vervollständigen.
- Abschließende vollständige Tests, native DLP-Abnahme, Stabilitätslauf,
  Windows-Build und Paketprüfung durchführen und Ergebnisse dokumentieren.

Die Liste ist ein Arbeitsauftrag, keine Behauptung, dass jeder Punkt bereits
fehlt oder ein bestätigter Bypass besteht. Der folgende Audit bestimmt die
konkreten Defekte und fehlenden Nachweise.

## Verschoben

## WebSocket- und WebRTC-Ziel

Nutzerpräzisierung: WebSockets und WebRTC sollen nutzbar sein, wenn ihr jeweiliger
Datenweg überprüfbar ist. Pauschale Sperre ist eine vorläufige Schutzmaßnahme,
kein funktionales Endziel. Freigabe muss pro überprüfbarem Kanal erfolgen:
WebSocket-Nachrichten einschließlich binärer/komprimierter Nutzlasten und
WebRTC-DataChannels benötigen Inhaltsprüfung vor Übertragung sowie aktuelle
Policy- und Zielbindung. WebRTC-Audio/Video benötigen eigene Medienregeln und
Prüfnachweise; eine Signalisierungs- oder Domainprüfung belegt keine Inhalts-DLP.

Die vorhandenen Electron-webRequest-Hooks prüfen HTTP-Anfragen und den
WebSocket-Verbindungsaufbau, liefern jedoch keinen allgemeinen nativen Gate für
jede WebSocket-Nachricht oder WebRTC-Nutzlast. Ein JavaScript-Wrapper allein ist
keine belastbare Sicherheitsgrenze. Unterstützte Wege benötigen einen
kontrollierten Transport oder zusätzliche native Chromium-Enforcement-Hooks
mit echten Nachrichten-/Empfänger- und Umgehungstests. Bis dahin bleibt nur der
nicht überprüfbare Weg gesperrt, mit dokumentiertem Kompatibilitätsgrund.

## Weitere Roadmap

Andere Betriebssysteme und Mobile, vollständige KI-Agentensteuerung und eigene
Worker-Sitzungen, weitere Komfort-/Designfunktionen, zusätzliche Vault-Funktionen,
breitere Multimediaanalyse und zusätzliche Admin-Erweiterungen sind Roadmap.
Bestehender Code bleibt erhalten, wird aber nicht zur Voraussetzung dieser
MVP-Abnahme erweitert.

Produktionsrollout bleibt von Pilot-/MVP-Abnahme getrennt: signierter Installer
und Updatekanal, unabhängige Sicherheitsprüfung sowie kundenspezifische IdP-,
Proxy-/ICAP-/SIEM-Integration benötigen eigene Nachweise. Das MVP verspricht
keine universelle Erkennung aller Geheimnisse und keinen Schutz gegen einen
Angreifer mit lokalen Administratorrechten.