safetynet/docs/windows-dlp-mvp.md

# 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

**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` 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.