Harden Windows DLP enforcement and Electron runtime packaging

docs/windows-dlp-mvp.md

@@ -0,0 +1,171 @@
+# Verbindliches Ziel: Windows-DLP-MVP
+
+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
+
+749 Tests bestehen im letzten vollständigen Lauf; ESLint verlangt null Fehler
+und null Warnungen. Nachweis: `artifacts/mvp-final-startup-suite.log`.
+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: `artifacts/windows-dlp-mvp-current-frozen-native.log`.
+
+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 keine webRequest-Callbacks und
+damit weiterhin keine einzelnen DLP-Audit-Ereignisse. Diese SIEM-Grenze bleibt offen.
+Ä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` gegen die genaue Chromium-Basis; er ist noch nicht kompiliert
+oder nativ abgenommen.
+
+- 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.