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

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