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

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

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. Ä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 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 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. 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.

14 KiB Raw Blame History