first commit

This commit is contained in:
Karl committed 2026-10-13 10:34:48 +02:00
commit ff482ebe23
251 files changed
+19126

No files matched your search

+31
View File
@@ -0,0 +1,31 @@
# Management access and deployment
Management is a separate web application. Browser enrollment never grants management authority. The server authenticates and authorizes each management endpoint, including personal bookmark routes registered before the general management router.
## Roles
Configure exact group names from the verified OIDC groups claim:
| Environment variable | Role | Authority |
| --- | --- | --- |
| `OIDC_ADMIN_GROUP` | Administrator | Publish policy and teaching references; all management operations |
| `OIDC_OPERATOR_GROUP` | Operator | Read policy/audit, enroll/revoke devices, review/edit personal bookmarks if policy permits, prepare teaching drafts and test integrations; cannot publish policy or change document inspection policy |
| `OIDC_AUDITOR_GROUP` | Auditor | Read overview, policy, security audit and teaching drafts; cannot mutate management state or inspect personal bookmarks |
Operator and auditor group mappings are disabled until configured. Multiple matching groups use the highest role: administrator, then operator, then auditor. Membership is validated during signed OIDC login. Sessions expire after eight hours; group removal at the identity provider does not yet immediately invalidate an existing session. Administrators can inventory active sessions and immediately revoke existing cookies through the Access & sessions panel. Continuous group synchronization remains production work. Revoking an existing session does not prevent a new login while the identity provider still grants the management group.
`GET /api/admin/session` and the overview return the normalized role and permission list. The frontend uses these to explain unavailable operations. Backend permission checks remain authoritative: session-supplied permission arrays are ignored, unknown roles are rejected and new endpoints have no access until assigned an explicit permission.
`GET /api/admin/sessions` returns at most 500 active sessions with opaque random revocation IDs, subject, display name, role and expiry. It never returns credentials or database session hashes. `POST /api/admin/sessions/:id/revoke` accepts an empty object and atomically deletes the session and its handle. Only the administrator's `sessions.manage` permission allows either route. Session review and revocation audit records contain the acting administrator and counts, without target credentials or target identities.
## Bootstrap and transport
`ADMIN_TOKEN` is a development credential accepted only with an HTTP loopback `PUBLIC_URL`. Development HTTP startup also rejects a non-loopback bind address. HTTPS management never accepts this shared token. HTTPS server startup requires `OIDC_ISSUER` and `OIDC_CLIENT_ID`, and the protected policy management channel. Configure the reverse proxy to terminate HTTPS and keep the management service bound privately; do not publish the development HTTP listener.
Cookie sessions use HttpOnly, SameSite=Lax and Secure for HTTPS. Cookie-authenticated mutations and logout require an exact `Origin` match with `PUBLIC_URL`; configure the externally visible canonical origin correctly. Cross-site writes are rejected. Responses have a restrictive same-origin CSP, forbid framing and disable caching. Bearer development fixtures do not need a browser Origin header.
This implements three application roles and optional mandatory independent policy approval through `REQUIRE_INDEPENDENT_POLICY_APPROVAL`. The author cannot approve its own immutable proposal; all policy publication paths use one publisher. See `policy-review.md`. Restrictive device groups and explicit pilot rollout are implemented in `group-policy-rollout.md`. Dynamic IdP membership, phishing-resistant MFA enforcement, IdP logout/back-channel revocation, HSM custody and independently assessed production deployment remain open.
## Verification
The server tests exercise real signed OIDC operator/auditor sessions, direct unauthorized management requests, personal bookmark read denial, policy publication denial, unknown-role rejection, forged session permission rejection, exact-origin cookie writes, remote bootstrap-token rejection, opaque session inventory and immediate session revocation.
+36
View File
@@ -0,0 +1,36 @@
# First-class agents and forensic observability
User clarification, 2026-10-13: agents must operate the application as first-class
clients, including tabs, permitted settings and bookmarks. Central administrators
can disable access and limit individual capabilities. Mandatory corporate policy
applies equally to a human and an agent. Generic JavaScript/CDP, cookie extraction
and overriding a centrally locked setting are not alternate control paths.
Agent authentication must support cryptographic client identity, narrowly scoped
revocable credentials, bounded requests, replay protection and attributable audit.
Current loopback capability tokens and Windows DPAPI are a foundation; delegated
per-agent identities, request proof of possession and individual revocation remain
required work. Full UI automation, history/library, safe screenshots and broader
application capabilities remain separately tracked from the implemented controls.
Security analysts need enough detail to reconstruct what happened: navigation,
download name/source/hash/scan outcome, click target, copy/cut/paste direction,
initiating tab/agent and the relevant rule and result. Confidentiality alone must
not suppress security-relevant evidence. Passwords and authentication tokens must
never enter logs. URLs, element labels and content may themselves contain secrets;
they need typed redaction and centrally governed evidence collection.
The security audit and confidential evidence store are distinct from operational
OpenTelemetry. The evidence store must encrypt records, bind them to immutable
event identities, restrict analyst access, log every access, enforce retention and
support incident correlation and SIEM references. Selected relevant content may be
retained by policy; storing entire documents is not required. Existing metadata
events do not satisfy this full forensic requirement. Detailed download records,
human click tracking and controlled content evidence are still to implement.
OpenTelemetry debug mode must expose correlated spans for IPC, agents, navigation,
network/DNS, document/OCR/YARA/semantic inspection, policy handling and management
requests, including durations and named code stages. Debug collection is centrally
managed, bounded and disableable. Operational spans do not silently become a raw
content or credential archive. Backend tracing and collector/SIEM permissions,
encryption and retention must complete the end-to-end pipeline.
+28
View File
@@ -0,0 +1,28 @@
# Security event retention
`AUDIT_RETENTION_DAYS=0` disables deletion by default. A deployment administrator
may opt in with 1..3650 days. The server checks hourly and removes at most 500
eligible database events per pass. It uses the current SIEM exporter's durable
cursor, never a historical destination's cursor. A successful HTTP response means
the receiving SIEM accepted a batch; it is not a guarantee of its archival policy.
Only expired events already delivered through that cursor are eligible. All
incident source events remain protected, including resolved cases. Sigma
correlations cannot be left pointing at removed source events across a batch
boundary. Related alert rows are removed in the same transaction. The device-event
UUID ledger remains intact, so retransmission cannot recreate expired events.
Policy history, signatures, users and device credentials are outside this job.
Deletion and its metadata-only audit event commit atomically. A failure rolls
everything back and appears in the administration status. The service account
must protect the SQLite database and backups. Logical deletion does not promise
secure erasure from SQLite pages, WAL files, disks or backups.
The module exports `pruneAuditEvents(..., {dryRun:true})` for deployment validation.
There is no browser-policy switch or unauthenticated cleanup endpoint. Status in
the admin console is read-only. Retention of incident notes/history, the durable
dedup ledger, local `security.ndjson`/CEF files, external SIEM records and backups
requires a separate lifecycle; this database job does not govern those stores.
`tests/audit-retention.test.mjs` verifies export and batch boundaries, incident
preservation, replay-ledger preservation, explicit opt-in and transactional failure.
+37
View File
@@ -0,0 +1,37 @@
# SafetyNet identity
SafetyNet is the project and management-platform name. **S Browser** names its managed browser. The visual identity gives a restrained enterprise product a recognizable, approachable symbol: two woven ribbons form an S and an open protective loop. It expresses governed access without implying that security is absolute.
## Assets
- `safetynet-lockup.png` — original transparent, AI-generated horizontal lockup, 2068 × 760. Use on white or a very pale neutral surface; the navy wordmark needs contrast.
- `safetynet-readme.png` — same artwork composited on a pale neutral surface for legibility in both light and dark repository viewers.
- `safetynet-icon.png` — 640 × 640 transparent crop of the same original symbol. Suitable for light and dark surfaces.
- `safetynet.ico` — PNG-compressed 256 px Windows icon, exported from the original symbol.
- `export-assets.cjs` — reproducible symbol and ICO export; run `node docs/brand/export-assets.cjs` from the repository root.
These are raster assets, not a vector master. Do not describe them as SVG or fabricate a redraw. A future vector production pass should preserve the approved mark and inspect small-size legibility.
## Palette and typography
| Role | Color |
| --- | --- |
| Ink | `#102449` |
| Action blue | `#1764F5` |
| Teal accent | `#13C8C8` |
| Light canvas | `#F4F7FB` |
| Dark canvas | `#101820` |
Use system-ui / Segoe UI for interface text. Keep headings concise, with generous spacing and readable contrast. Blue identifies primary actions; teal adds emphasis without becoming a security verdict. Reserve explicit success, warning, and danger colors for actual state.
## Usage
Leave clear space of at least one quarter of the symbol width. Preserve the artwork's proportions, transparency, and colors. Use the symbol alone when the wordmark is too small or lacks contrast. White-label deployments can replace identity through their managed branding configuration; this asset does not change policy or security behavior.
Product screenshots should show the real application. Describe the project as **under heavy development**. Avoid certification seals, promises of total protection, and unverified claims about compliance or production readiness. The mark is original artwork and does not reproduce Apple's logo or Safari compass; no trademark clearance is claimed.
## Generation provenance
Created with the built-in Codex ImageGen tool on 2026-10-13 using the Creative Production `produce` logo workflow. A direct Creative Production board capability was not exposed to this worker, so the asset was generated directly and saved into the repository. No external image API key or CLI fallback was used.
Prompt: “Create one polished original horizontal logo lockup for SafetyNet, an enterprise managed AI browser. Transparent background, clean vector-like graphic suitable for repository README, restrained premium software identity. On left a distinctive standalone geometric S mark made from two interlocking curved ribbons forming a protective open loop / woven safety net, no literal padlock or shield, vivid cobalt blue and cool turquoise, clear strong silhouette readable at small sizes. To right exact wordmark SafetyNet (capital S and N, no space), elegant contemporary dark navy sans-serif medium weight, excellent kerning. Logo centered with generous clear space, wide landscape composition, symbol and wordmark optically aligned. Flat refined geometry, subtle color gradient in symbol only; no glass reflection, no mockup, no badges, no certifications, no extra tagline, no watermark, no Apple logo, no Safari compass. Output an actual transparent PNG logo asset.”
+43
View File
@@ -0,0 +1,43 @@
// Deterministic export of the generated master artwork. No redraw or substitute mark.
const fs = require('node:fs');
const path = require('node:path');
const { PNG } = require('pngjs');
const root = __dirname;
const source = PNG.sync.read(fs.readFileSync(path.join(root, 'safetynet-lockup.png')));
// A neutral opaque presentation keeps the navy wordmark legible in dark README viewers.
const readme = new PNG({ width: source.width, height: source.height });
for (let i = 0; i < source.data.length; i += 4) {
const alpha = source.data[i + 3] / 255;
for (let c = 0; c < 3; c++) readme.data[i + c] = Math.round(source.data[i + c] * alpha + 250 * (1 - alpha));
readme.data[i + 3] = 255;
}
fs.writeFileSync(path.join(root, 'safetynet-readme.png'), PNG.sync.write(readme));
// The original symbol occupies the first 560 px. Keep its actual transparent edges.
const symbol = new PNG({ width: 640, height: 640 });
symbol.data.fill(0);
for (let y = 0; y < 640; y++) for (let x = 0; x < 560; x++) {
const from = ((y + 60) * source.width + x) * 4;
source.data.copy(symbol.data, (y * 640 + x + 40) * 4, from, from + 4);
}
fs.writeFileSync(path.join(root, 'safetynet-icon.png'), PNG.sync.write(symbol));
// PNG-compressed 256px Windows icon with box-filter downsampling.
const icon = new PNG({ width: 256, height: 256 });
for (let y = 0; y < 256; y++) for (let x = 0; x < 256; x++) {
let a = 0; const rgb = [0, 0, 0]; let n = 0;
for (let sy = Math.floor(y * 2.5); sy < Math.ceil((y + 1) * 2.5); sy++)
for (let sx = Math.floor(x * 2.5); sx < Math.ceil((x + 1) * 2.5); sx++) {
const offset = (sy * 640 + sx) * 4; const alpha = symbol.data[offset + 3];
a += alpha; n++;
for (let c = 0; c < 3; c++) rgb[c] += symbol.data[offset + c] * alpha;
}
const offset = (y * 256 + x) * 4;
for (let c = 0; c < 3; c++) icon.data[offset + c] = a ? Math.round(rgb[c] / a) : 0;
icon.data[offset + 3] = Math.round(a / n);
}
const encoded = PNG.sync.write(icon);
const header = Buffer.alloc(22);
header.writeUInt16LE(1, 2); header.writeUInt16LE(1, 4);
header.writeUInt16LE(1, 10); header.writeUInt16LE(32, 12);
header.writeUInt32LE(encoded.length, 14); header.writeUInt32LE(22, 18);
fs.writeFileSync(path.join(root, 'safetynet.ico'), Buffer.concat([header, encoded]));
console.log('Exported README presentation, original symbol PNG and 256px Windows ICO.');
Binary file not shown.

After

Width:  |  Height:  |  Size: 139 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 417 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 346 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

+51
View File
@@ -0,0 +1,51 @@
# Browser diagnostics and operational OpenTelemetry
Browser diagnostics use the actual OpenTelemetry JavaScript trace and log SDKs, exported as OTLP/HTTP JSON to a collector selected in signed company policy. They are distinct from durable security audit and encrypted forensic evidence. This module never sends document fragments, prompts, page text, password fields, access tokens, URLs or generic exception messages to the collector.
## Central configuration
`policy.diagnostics` is strict, signed and disabled by default. Only an administrator's normal policy publication workflow can enable, reconfigure or disable it. Endpoint, sampling and resource bounds cannot be changed through website JavaScript or renderer preferences.
Example:
```json
{
"enabled": true,
"mode": "debug",
"endpoint": "http://127.0.0.1:4318",
"sampleRate": 0.1,
"debugSampleRate": 1,
"maxQueueSize": 512,
"flushIntervalMs": 2000,
"maxRecordAgeMs": 30000,
"exportTimeoutMs": 2000
}
```
Operational mode uses `sampleRate`; debug mode uses `debugSampleRate`. Sampling 1 records every eligible operation within resource limits. Debug does not authorize raw content collection. Queue size is 16–4096 records per signal, export batches at most 128, concurrent active spans at most 128. Records expire after the configured age; exporter requests time out. Excess data is dropped rather than delaying or bypassing a security decision. Frequent configuration changes cannot accumulate unlimited retired SDK generations.
Collectors require HTTPS, or HTTP to a numeric loopback address for a local collector. URL user information, query parameters and fragments are rejected. There is no environment-selected endpoint or cloud fallback. HTTPS certificate validation is explicitly enabled. Ambient `OTEL_*` headers and resource attributes are excluded; telemetry contains neither environment credentials nor process command lines, hostnames or OS usernames. Redirect responses fail instead of forwarding telemetry to another destination.
A local collector is the preferred enterprise transport boundary: it can handle customer authentication, mutual TLS, proxy routing, SIEM distribution and retention. Browser OTLP uses Node's controlled HTTP transport, outside website requests. Direct exporter support for enterprise proxy credentials and customer certificate provisioning is not yet implemented.
## Recorded timing and correlation
The privileged browser instruments fixed operation families: IPC, local agent actions, management requests, navigation, DNS, outbound requests, local and enterprise inspection, download, clipboard, visual login checks, password fill, AI, network posture, tab and policy operations. Every recorded span has start/end timestamps and measured duration in milliseconds. Nested operations share trace IDs and parent span IDs through an isolated async context. Related diagnostic log records carry the same correlation identifiers. Durable security events may attach these identifiers without attaching content.
Attributes are explicitly typed and allowlisted: registered operation/component enums, UUID session/device IDs, policy version, bounded byte/count fields, duration, decision, request type and status. Failure spans receive a status and a fixed exception category (`Error`, `TypeError` or `RangeError`), never an exception message or stack. Arbitrary operation names are not recorded. Returned model answers, credential values and inspected content are never inferred as diagnostic attributes.
Detailed timing within Python parsing, OCR, YARA or model inference is not yet exported as its own child spans; the browser records the local-inspector call boundary. Renderer paint/layout and Chromium internal tracing are also separate future work. This is explicit application instrumentation, not a claim to trace every Chromium function.
## Lifecycle and security behavior
Only verified policy configures the provider. Reconfiguration immediately invalidates the old generation, drops queued old records and closes old exporter sockets. Disabling prevents future exporter requests and retries. Bytes already delivered cannot be recalled. Device revocation and expired policy disable diagnostics. A security block under otherwise valid policy can still be observed.
Export failure never repeats the protected operation, changes its result or authorizes blocked data. Successful and failing functions retain their original results/errors. Normal shutdown attempts a bounded flush; diagnostics are intentionally nondurable and can be lost in a crash. Durable audit and forensic evidence require their separate pipelines.
## Verification
`node --test tests/diagnostics.test.mjs` exercises a real local OTLP receiver: parent/child traces, measured durations, correlated logs, typed attributes, password/token/URL/error sentinels absent, environment headers/resources excluded, disable/reconfigure queue invalidation, expiry, bounded batches and failed export without operation retry.
`node scripts/native-tabs-smoke.mjs` additionally runs the actual production Electron main process with a signed debug policy and a separate local collector. It verifies native IPC/navigation/DNS/request timing, parent/child IDs and correlated logs, preserves the existing all-tab DLP assertions, and checks that centrally revoking the browser stops subsequent diagnostic exports. Evidence is written to `artifacts/native-browser-diagnostics-proof.json` alongside the native tab proof.
Passwords and access tokens must remain excluded from any future forensic store as well. Selective confidential evidence, encryption, access control and retention are handled independently; enabling operational diagnostics does not enable forensic content retention.
+11
View File
@@ -0,0 +1,11 @@
# Native transfer type controls
`fileTransfers.upload` and `fileTransfers.download` independently configure `maxBytes`, `allowTypes`, `blockedTypes`, `blockUnknown`, `blockExtensionMismatch`, `blockMimeMismatch`, and `allowWithoutMalwareScanner` in the signed managed policy. Types are `pe`, `elf`, `macho`, `pdf`, `zip`, `png`, `jpeg`, `gif`, `webp`, `gzip`, `text`, and `unknown`. A blocked type always takes precedence over an allowlist. Empty allowlists do not restrict types. Unknown and mismatch blocks are explicit options to accommodate enterprise compatibility requirements.
Classification reads actual bounded bytes, never trusts the filename or declared MIME type. Text recognition checks the entire UTF-8 payload for binary control bytes. MZ-family files are identified even if their PE headers are truncated. ZIP and Office OOXML share a container signature; this classifier does not distinguish document subtypes, recursively inspect archive members, prove a media decoder accepts the file, or detect every polyglot. Document extraction, YARA and ICAP remain separate inspection layers. A magic allow verdict is not a security verdict.
Downloads classify the complete bounded memory buffer before antivirus inspection, file-picker display or destination write. Their released digest remains bound to the exact scanned bytes. Supported document/media signatures additionally require complete contained local DLP extraction; semantic scanning applies when configured. Executable and unknown content may have antivirus coverage without document extraction coverage; configure blocked types or `blockUnknown` for stricter profiles.
Each enabled malware scanner remains mandatory. YARA can be disabled independently while selected-channel ICAP is enabled. Disabling both does not silently bypass the download gate: an administrator must explicitly set `allowWithoutMalwareScanner: true`, and complete local DLP is still mandatory. This flag cannot override an enabled scanner's outage or failure.
The helper returns sanitized filename, claimed MIME, detected type, byte count and SHA-256 for protected evidence. Ordinary download audit events carry only bounded byte count, detected type and SHA-256. Native file/data-pipe upload release remains blocked until immutable scanning and transport binding can be proved. Classification of a multipart request envelope does not prove classification of its individual attachments.
+24
View File
@@ -0,0 +1,24 @@
# Device groups and reviewed rollouts
The company policy is the mandatory baseline. Device groups can add blocked hosts, blocked content, company bookmarks, hidden/locked settings and mandatory document analysis; they can disable downloads, AI and local agents. Groups cannot turn off baseline controls, replace a block list or enable a feature denied by the company policy.
An administrator selects explicit device members. A pilot or expanded rollout selects a nonempty subset of those members; an all-members rollout applies to every selected member. There is no time-based or automatic promotion. Adding members, editing restrictions, changing the cohort and deleting a group are reviewed publication operations. When independent approval is required, the author cannot approve their own operation; the approved hash binds the complete group payload and the expected global generation.
Every publication increases the shared policy version. Each device receives a signed policy with its device ID and effective group IDs; Chromium enforcement, the AI gateway and bookmark mutation endpoints all use that effective policy. Conflict resolution is deterministic: groups are applied in ID order, block/section lists are unions and disabling controls win. Different definitions of the same company bookmark ID cause publication to fail. Group bookmarks cannot collide with the selected devices' personal bookmarks. Oversized merged policies also fail publication.
Policy history stores group configuration at each published generation. Restoring a historical version restores its cohorts and restrictions as a new, reviewed generation; it does not roll device versions backwards. History predating group snapshots is refused when restoring it could silently discard active groups.
## API
- `GET /api/admin/policy-groups`: current version, groups and per-device membership/effective-group/version reports.
- `PUT /api/admin/policy-groups/:id`: `{expectedVersion,group}` where the group contains `id`, `name`, `memberDeviceIds`, `restrictions` and `rollout:{stage,deviceIds}`.
- `DELETE /api/admin/policy-groups/:id`: `{expectedVersion}`.
- `POST /api/admin/policy-groups/preview`: `{deviceId,group?}`; returns the resulting policy, group IDs, baseline diff and current-policy diff without publishing.
Publication and deletion require policy-write authority, or policy-prepare authority when mandatory independent review is enabled. Read and preview require policy-read authority. `202` means queued for review, not applied. Version conflicts return `409`.
## Verification and boundaries
`tests/policy-groups.test.mjs` checks signed pilot/control behavior, promotion, removal, restrictive merge order, review/self-approval/revoked-device failures, permissions, preview, bookmark conflicts, historical restoration and actual gateway/bookmark endpoint enforcement.
Acknowledgment is a device's reported policy version equal to the target version. It is not remote attestation and does not prove endpoint health. The last-seen timestamp is displayed separately. Membership currently uses explicitly enrolled device IDs; dynamic IdP/SCIM department membership, percentage rings, automatic health gates and tenant isolation require further implementation.
+32
View File
@@ -0,0 +1,32 @@
# Immutable native upload binding: Electron 44.7 feasibility
This proof is **not a production upload implementation**. Existing managed browser file/data-pipe upload rejection must remain in place.
Run `node scripts/immutable-upload-probe.cjs`. It launches a finite, hidden, CPU-rendered, sandboxed Electron fixture against a loopback HTTP receiver. No managed browser configuration, actual credentials, OS clipboard, or website code is changed. The fixture uses a real HTML file input populated through test-only native CDP, then submits Chromium-generated multipart FormData.
## Evidence
`artifacts/immutable-upload-probe.json` records:
- `requestBodyAvailable: true`: `session.protocol.handle('http')` exposes the real multipart file stream through `Request.arrayBuffer()`.
- `mutatedAfterSnapshot: true`: the disk fixture is replaced after body capture and before forwarding.
- `exactBytes: true`: receiver SHA-256 equals inspected snapshot SHA-256; receiver contains the original bytes and excludes the replacement bytes.
- `credentialsPreserved: false`: both renderer `credentials: 'include'` and `credentials: 'omit'` become protocol requests reporting `credentials: 'same-origin'`, with no Cookie header. Forwarding through the same session attaches its synthetic session cookie to both. The original credential choice cannot be inferred from these fields.
- `redirectDenied: true`: forwarding with `redirect: 'error'` denies a 307 and never reaches the redirect destination. Transparent redirect compatibility is therefore not established.
The cookie behavior is a security blocker for a transparent HTTP(S) protocol bridge. The proof deliberately asserts this limitation rather than presenting a passing byte comparison as sufficient approval to ship.
## Compatibility and security boundaries
Electron documents that protocol requests include a trusted `initiatorOrigin`. This establishes the requesting origin; it does not recover the original Fetch credential mode, top-level site cookie context, authenticated request semantics, redirect chain, or full request policy context.
CORS preservation has **not been demonstrated**. Browser preflight handling, credential-dependent `Access-Control-Allow-Origin` rules, opaque responses, response URL/type, frame/site cookie partitioning, authentication challenges, and service-worker paths require separate receiver-based tests and implementation support. They must not be inferred from same-origin multipart success. Electron explicitly documents incorrect response `.type` and `.url` for `session.fetch`, and says bypassing custom protocols still invokes `webRequest` handlers. Consequently an integration also needs safe request identity and recursion handling; a broad trusted forwarding bypass would weaken existing enforcement.
The anonymous-only fallback was not implemented. A deployable solution must preserve original Chromium request semantics and bind the scanner decision to immutable bytes, destination, policy version, identity, and request context. Native Chromium interception or a verified native network integration remains required before file/data-pipe upload support can be enabled.
## Primary references
- [Electron protocol.handle documentation](https://www.electronjs.org/docs/latest/api/protocol#protocolhandlescheme-handler): protocol request body and trusted initiator origin.
- [Electron session.fetch documentation](https://www.electronjs.org/docs/latest/api/session#sesfetchinput-init): Chromium network stack, response limitations, custom-protocol bypass and continuing webRequest callbacks.
This test concerns one in-memory multipart upload. It does not prove full DLP coverage for streaming, WebSockets, WebRTC, browser uploads, or downloads.
+18
View File
@@ -0,0 +1,18 @@
# Incident management
The central HTTPS admin console provides a case workflow alongside the immutable security event stream. Administrators and operators can create one case per existing event, assign a subject identifier, set severity, investigate, resolve, dismiss or reopen. Auditors can read cases and their history but cannot mutate them. Unknown methods, including deletion, are denied by the central permission middleware.
Endpoints:
- `GET /api/admin/incidents`: bounded descending pagination (`limit` 1–100, `before` numeric case cursor), optional status and severity filters.
- `POST /api/admin/incidents`: `{eventId, severity?}`; returns a stable UUID and revision 1. Missing events return 404, duplicate event references return 409. Case audit events cannot recursively create cases.
- `GET /api/admin/incidents/:id`: current metadata and bounded immutable history.
- `PATCH /api/admin/incidents/:id`: `{expectedRevision, status?, severity?, assignee?, comment?}`. Stale revisions return 409; clients must refresh and deliberately reapply their changes.
Allowed statuses are `open`, `investigating`, `resolved`, `dismissed`; severities `low`, `medium`, `high`, `critical`. Assignments are explicit SSO subject identifiers, not a verified directory picker; all control characters are forbidden. Empty assignments use null. Analyst notes are limited to 1,000 characters and reject control characters. A case is limited to 1,000 history entries; further edits fail closed rather than truncating evidence.
Cases reference existing events without copying document or prompt contents. Their source event view allowlists decision, rule, policy version, destination host, severity, source reference, content type, classification and coverage metadata. Arbitrary event payload fields are excluded. Every successful mutation atomically updates the compare-and-swap revision, appends an immutable history entry and records an audit event. Analyst notes remain in the restricted case history; ordinary security events, ECS/CEF and telemetry receive only their character count. Hashes of notes are deliberately excluded because predictable text could be guessed. Notes must contain investigation summaries, not document excerpts, prompts, credentials or secrets; free text cannot automatically guarantee this constraint.
Initial audit retention preserves every incident source event, including resolved cases. There is no case deletion, case expiry, automatic case generation, notifications, external ticket integration, evidence attachment storage or directory synchronization. These require separate deployment policy and implementation. The current SQLite administration database needs a protected service account, backups, explicit access permissions and deployment retention arrangements.
Evidence: `node --test tests/incidents.test.mjs` exercises real HTTP routes, role separation, bounded metadata/notes, immutable source events, duplicate rejection, optimistic concurrency, reopening, filters and pagination.
+8
View File
@@ -0,0 +1,8 @@
# Screenshot provenance
These images contain synthetic fixtures only. They do not contain employee browsing, company documents, authentication tokens or production device inventory.
- browser-light.png and browser-dark.png: captured from the real trusted shell by `npm run preview:ui`, using isolated showcase state. They demonstrate appearance rather than real website enforcement.
- admin-profiles.png: captured by `scripts/profiles-admin-smoke.cjs` during the real custom-profile management workflow against a temporary synthetic management service.
The browser footer was refreshed to reflect independent native tab contexts. Regenerate browser captures with `npm run preview:ui`; inspect the output before copying it here. Never copy production screenshots without reviewing their visible content.
Binary file not shown.

After

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 288 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 236 KiB

+22
View File
@@ -0,0 +1,22 @@
# Native tabs: implementation and security integration
`apps/browser/tab-registry.cjs` supplies native view ownership, UUID sessions, lookup by WebContents ID, per-tab navigation and visual state, bounded capacity, context snapshots, all-tab quarantine and explicit destruction. Seven lifecycle/security tests pass. It is a foundation, **not yet wired into the running browser**.
## Exact integration map
1. **main.cjs globals / startup (currently lines 12, 55, 364):** replace the single `view` plus global visual fields with registry records. The injected factory creates each `WebContentsView` with the existing sandboxed session and site preload. Before any HTTP navigation, install native site hooks, clipboard controls and `attachPageClipboardGuard`; initialise about:blank and await guard readiness. Failure quarantines every tab and closes the affected view. Store one visual scanner per record; capture/describe closures must close over that record rather than the active view.
2. **hooks() (currently lines 277–340):** split session hooks, installed exactly once, from `installSiteHooks(tab)`, installed for every newly created WebContents. Resolve visual checks via `details.webContentsId`; unknown or destroyed tab requests fail closed. Requests with no page identity, including permitted service-worker traffic, still receive destination/body/DNS enforcement and may never inherit foreground visual approval. `will-download` must capture the originating tab; current `getContext()` always uses the active single view and rejects legitimate background downloads. Change download gate to accept an explicit origin context with captured native identity; require both policy and registry context before scan/save/release.
3. **navigation/layout/theme/state (lines 116–126, 195, 227):** native `create`, `activate`, `close` IPC returns authoritative `tabs`/`activeTabId`. Navigation targets a validated UUID and never reloads on activation. All main-frame navigations, including same-document changes, invalidate that record's navigation token. Theme/title events update their own tab only; active chrome takes that record's color. Attach only the active child view, leave others alive and hidden. Quarantine stops every WebContents; policy resume revalidates destinations and visual protection for every tab before the relevant page is displayed, rather than reloading only the active page. Policy restrictions close DevTools for all tabs.
4. **clipboard / password fill / link inspection (lines 367, 418, 465):** resolve native source WebContents through registry. Foreground-only actions require the same captured tab ID, native object, URL, navigation counter, policy version and activation epoch across asynchronous inspection. Switch-away-and-back must invalidate the old operation even at the same URL. UI clipboard remains a separate trusted-chrome context. Password fill and AI page-linked work must bind a captured tab rather than reading the global active view after `await`.
5. **visual/content IPC (lines 384, 386, 484):** resolve sender WebContents to a tab; require sender's own main frame and current URL/token/revision. An event from hidden tab B must never alter tab A's scanner or approval. A block can remain whole-browser quarantine initially, but must store the offending tab and must not be cleared by selecting another tab. Policy revocation/security failure always quarantines all tabs.
6. **agent-adapters.cjs and main startAgents():** replace hardcoded `managed` with opaque UUID IDs returned by native session inventory. `getContext(args.sessionId)` resolves explicit tab identity; absent ID may choose foreground once at operation start, then must be pinned. Navigation callback accepts that captured tab; read/click/type and visual checks refer to it throughout. Background read may be separately authorized; interaction should require foreground activation unless a deliberate policy and UX permit background interaction. Agent host authorization uses the requested target tab, not the active page. Changes in navigation or policy invalidate async read/AI results. Agent session listing requires its scope but cannot require a navigated active HTTP page; otherwise an empty start page cannot discover populated background tabs.
7. **preload.cjs / renderer.js (lines 2, 19–21):** expose fixed tab-create/activate/close calls only to trusted chrome. Remove renderer-owned UUID creation and navigation-on-select. Render authoritative native state; renderer tab groups use centrally bounded strings accepted by native module. Browser back/forward/reload target active native history. Close-last-tab creates a fresh guarded start tab. Correct overview and sidebar updates without stale async UI writes.
8. **shutdown (lines 509–530):** detach guards and close every WebContents explicitly, even hidden tabs; close registry before window teardown. A page cannot veto destruction with beforeunload. Never preserve live WebContents or credentials in renderer localStorage.
## Required native proof before claiming tabs complete
Use real Electron views and controlled HTTP pages. Page A retains DOM/input/scroll and its own back/forward history while B navigates and switches; no reload counter increments on selection. Hold asynchronous clipboard inspection, switch A→B→A, then verify no clipboard release or DOM mutation; repeat password fill and agent read. A hidden-tab phishing or content event must not approve another tab. Malicious/blocked background upload and download must be blocked. Revoke or expire policy while two views issue requests: both must stop and none may transmit. Close a tab during an agent action: the action cannot return its content. Validate actual main-frame and subframe preload guard installation for each new view. These native proofs complement, rather than replace, registry unit tests.
## API evidence
Electron documents multiple independent child [WebContentsViews](https://www.electronjs.org/docs/latest/api/web-contents-view), [navigation history per WebContents](https://www.electronjs.org/docs/latest/tutorial/navigation-history), and [explicit WebContents disposal responsibilities](https://www.electronjs.org/docs/latest/api/base-window). Same browser session intentionally shares enterprise cookies/proxy/network policy; independent tabs do not imply separate user profiles or tenant sessions.
+27
View File
@@ -0,0 +1,27 @@
# Native browser tabs
The privileged Electron process owns each tab's UUID, `WebContentsView`, navigation history and security state. The trusted shell renders snapshots and invokes fixed operations; it never allocates tab identities or reloads a URL merely to select a tab. All site views remain sandboxed, without Node or a bridge to management IPC.
`managed:tab-create`, `managed:tab-activate`, `managed:tab-close` and `managed:tab-group` return authoritative browser state. Navigation accepts `{url, tabId}` so an address submission is bound to its selected native tab. Group edits repeat centrally managed library permissions in the privileged process. Every state snapshot carries a monotonic `tabsRevision`; the shell rejects delayed responses older than the state already displayed.
A new tab starts as a guarded blank view. Its native clipboard primitive guard is installed before website navigation. The last tab closes its actual contents and is replaced with a new guarded start page. Switching tabs preserves document state and history. The shared managed browsing session keeps the existing company cookie/session behavior; separate tabs are not separate identity containers.
Network enforcement belongs to the managed session and identifies the originating native contents. Background requests therefore pass the same DLP and policy gates. Clipboard operations, vault fill and other foreground actions need the current tab context; the trusted shell does not expose arbitrary JavaScript or CDP to pages or agents.
## Verified evidence
Run `node scripts/native-tabs-smoke.mjs` for the isolated Windows/Electron proof using the actual production main process. It verifies:
- Two distinct native contents through real chrome New Tab, address submission and tab selection.
- Preserved input values and scroll position, with a receiver counter proving that selection does not reload the original page.
- Independent back histories. Controlled link activation uses Electron's user-gesture flag, matching Chromium's rule that unactivated programmatic history entries may be skipped by Back.
- Secret POST blocking and denied page clipboard writes in both foreground and background contents.
- No Node or privileged bridge in either remote website.
- Destruction of closed contents and a guarded replacement when the last tab closes.
- Central device revocation followed by denied public POST attempts from both surviving views. The controlled receiver records no blocked POST.
The proof writes `artifacts/native-tabs-proof.json`, `artifacts/native-tabs-receiver-proof.json` and a screenshot. Private CDP guards are detached only after all assertions, when the test exits; the fixture does not weaken production enforcement. It never writes to the OS clipboard.
`node scripts/ui-showcase.cjs` separately verifies the real chrome renderer with a clearly synthetic native-state fixture: eight light/dark/compact/settings/sidebar/vault captures, live policy locks and hidden settings, and delayed navigation while creating a new tab. This showcase is visual evidence, not evidence of native website enforcement.
Persistent session restoration, separate identity containers, tab drag/reordering and performance suspension of inactive tabs remain separate future work. File/data-pipe upload limitations and other documented DLP coverage boundaries still apply to every tab.
+19
View File
@@ -0,0 +1,19 @@
# Independent policy approval
Set `REQUIRE_INDEPENDENT_POLICY_APPROVAL=true` on the management server. This deployment control is outside signed browser policy, so neither a policy draft nor a restored version can disable it. The example deployment enables it. Absent configuration remains false for existing local development fixtures.
With the control enabled, global policy changes, teaching publication, blocklist changes, individual device document-scan changes, and historical restoration all create durable pending reviews and return HTTP 202. Nothing is signed or applied until a different authenticated administrator approves. Operators can prepare changes; auditors can inspect; only administrators can approve or reject. The same subject cannot review its own change, even if its role changes.
Each review freezes the normalized full policy, operation, expected current version and SHA-256 payload hash. Approval must present the displayed hash and expected version. Inside one SQLite write transaction the server verifies integrity, current policy version, expiry, bookmark consistency, applicable device/teaching state, then publishes a new monotonic version and applies associated effects. Changed policy versions make older drafts stale; the server never silently rebases them. Repeated approvals and changed hashes are rejected.
Review APIs:
- `GET /api/admin/policy-reviews`: latest 100 reviews, status and deployment requirement.
- `GET /api/admin/policy-reviews/:id`: immutable candidate, operation and bounded diff against current policy.
- `POST /api/admin/policy-reviews` with `{policy}`: explicit review preparation.
- `POST /api/admin/policy-reviews/:id/approve` with `{payloadHash,expectedVersion,approve:true}`.
- `POST /api/admin/policy-reviews/:id/reject` with `{payloadHash,reject:true}`.
Ordinary publication endpoints return `{reviewRequired:true,reviewId,status:"pending",expectedVersion,payloadHash}` instead of a new published version when approval is mandatory. Review audit records contain subjects, IDs, versions and hashes, without policy values or document content. Policy/review storage itself contains sensitive policy configuration and must be protected as management data.
Tests in `tests/policy-review.test.mjs` cover author/role separation, hash mismatch, stale versions, rejection, repeat publication, queue integrity corruption, and every alternative publication entry point including atomic teaching and device effects. Production operation still requires separate real SSO identities and protected management access; a shared loopback development bootstrap identity cannot demonstrate independent approval.
+27
View File
@@ -0,0 +1,27 @@
# Protected security evidence
Security analysts need attributable facts, including potentially confidential content. These facts belong in a separately encrypted evidence store, not unrestricted OpenTelemetry attributes or ordinary SIEM payloads. Operational traces remain separate and can refer to an evidence ID.
## Implemented server boundary
`POST /api/device/evidence` authenticates an enrolled, non-revoked device and requires an existing source event UUID belonging to that device. Supported typed records are download source URL, filename, MIME, SHA-256, size and decision; or interaction page URL, action, bounded target details and optionally selected text. No arbitrary JSON, full documents, password fields, authorization fields, cookies or credential-bearing URL are accepted. URLs exclude queries and fragments. Interaction callers must assert `sensitiveField: false`; the future browser capture path must enforce this authoritatively rather than trust page JavaScript.
Before encryption, a bounded second check rejects recognizable credentials in selected text, target labels, filenames and source/page URL paths, including decoded paths. It detects private-key headers, Bearer/Basic authorization, assigned password/API-key/access-token/refresh-token/client-secret values, common OpenAI/GitHub/AWS key formats and JWT-shaped tokens. General confidential company text remains eligible for protected evidence. This is not proof that every unknown password or secret can be recognized: an arbitrary password without context is indistinguishable from ordinary text. Native capture must exclude password and authentication controls independently; the client-provided `sensitiveField` bit alone is insufficient.
Each record is encrypted with AES-256-GCM and a fresh random 96-bit nonce. Authenticated associated data binds format, record ID, source event, device, type, key ID, creation and expiry. SQLite stores ciphertext and metadata only. Source/type uniqueness prevents duplicate replacement. Record insertion and metadata-only audit are transactional. Failure to persist the audit rolls back the insert.
`GET /api/admin/evidence/:id?reason=investigation` requires the explicit `evidence.read` permission, currently assigned only to administrators. Operators and auditors cannot read plaintext. Reasons are the enums `investigation`, `incident-response`, `compliance`. A durable attributable access audit must succeed before a response is returned. Neither plaintext nor free-form reasons appear in ordinary audit logs. HTTP responses inherit no-store, no-referrer and authentication controls.
## Deployment
Configure `EVIDENCE_KEY_FILE` with an absolute path to an independently generated binary file containing exactly 32 random bytes. Never put the key in SQLite, source control, command-line arguments or telemetry. The deployment operator must restrict Windows ACLs to the management service identity and designated recovery custodians. Linked paths are rejected; Unix deployments also reject group/other file permissions. A configured invalid or unreadable key fails startup. Without a configured key, evidence submission and reads return 503. This is intentional, not a plaintext fallback.
`EVIDENCE_RETENTION_DAYS` defaults to 30 and must be 1–365. Expired evidence cannot be read unless its source event belongs to an open or investigating incident. Audit retention preserves evidence source events. Physical ciphertext deletion is not automated in this initial version: expiry limits access but does not claim storage erasure. Key rotation, HSM/KMS custody, cryptographic erasure, legal holds and tested backup/recovery remain production work. Replacing the key without retaining its old version makes old records unreadable; their key IDs are checked explicitly.
## Scope and validation
This implements the server storage and access boundary, not browser human-click capture, settings to enable collection, client delivery or an analyst UI. These must use signed central policy, keep password/authentication fields excluded, bind events to native browser context and label partial coverage. An enrolled device is an authenticated reporter, not proof its endpoint was uncompromised.
`tests/evidence.test.mjs` uses real HTTP and SQLite to verify ciphertext storage, role denials, source ownership/type validation, password/token field and credential-URL rejection, replay rejection, missing-key behavior, authenticated metadata tamper rejection, audit-failure rollback, plaintext response suppression and retention correlation.
The credential-content test additionally verifies that recognizable secrets in free text, labels, filenames and encoded paths return 400 without inserting any evidence rows, while confidential engineering text is accepted.
+144
View File
@@ -0,0 +1,144 @@
# S Browser: Anforderungsabgleich und offene Arbeit
Stand: 2026-10-13. Diese Prüfung vergleicht die Anforderungen aus dem Chat mit vorhandenem Quellcode und benannten Testfällen. Ein vorhandener Test ist ein begrenzter Nachweis für sein Szenario, kein Sicherheitszertifikat. Laufende Änderungen anderer Agenten müssen nach Integration erneut geprüft werden.
## Ziel
Windows zuerst: einen zentral verwalteten Browser mit lokaler Inhaltsprüfung, freigegebenem KI-Zugang und einer verständlichen, abgesicherten Admin-Weboberfläche liefern. Vor einer Produktionsfreigabe müssen die unten genannten Sicherheits- und Betriebsgrenzen geschlossen oder ausdrücklich im erlaubten Produktumfang ausgeschlossen sein.
## Statusmatrix
| Anforderung | Stand | Nachweis und verbleibende Grenze |
|---|---|---|
| Chromium/Electron, Windows-Build | Teilweise | `apps/browser/main.cjs`, `scripts/package.mjs`, `scripts/verify-package.mjs`; sandboxierter Electron-Browser und geprüftes unpacked Windows-Paket. Kein eigener Chromium-Fork mit umfassenden nativen DLP-Hooks; kein signierter Produktionsinstaller oder Updatekanal. |
| Safari-artige Oberfläche, Light/Dark, Themes, kompakte/getrennte Tabs | Umgesetzt für Browser-Chrome | `apps/browser/index.html`, `style.css`, `renderer.js`, `scripts/ui-showcase.cjs`, `artifacts/sbrowser-ui-layout.json`. Websiteinhalte werden nicht umgestaltet. Echte native Tabs mit eigener DOM-/Scroll-/History-/Security-State-Verwaltung sind jetzt integriert; Tabwechsel lädt nicht neu. Tatsächliche DLP-/Revocation-Prüfung in `artifacts/native-tabs-proof.json`. Gemeinsame Unternehmens-Cookies bleiben absichtlich geteilt. |
| White Label | Teilweise | Zentrale Marke/Farbe in `packages/core/policy.mjs`; Paketprodukt/App-ID in `scripts/package.mjs`. Eigene Icons, rechtliche Hinweise, signierte Kundendistribution und vollständige Asset-Themes fehlen. |
| Zentrale Verwaltung und erzwungene/verborgene Einstellungen | Umgesetzt für unterstützte Einstellungen | `packages/core/managed-settings.mjs`, `apps/browser/managed-settings.cjs`, `main.cjs`, `tests/managed-settings.test.mjs`, `scripts/managed-settings-smoke.mjs`. Native IPC prüft Berechtigungen; UI-Verstecken ist nicht die Autorität. Lokale Administratoren/OS-Manipulation bleiben außerhalb dieser Garantie. |
| Sichere Policy-Verteilung | Teilweise | `packages/core/policy-channel.cjs`, `apps/server/policy-channel.mjs`, `apps/browser/management-channel.cjs`, `tests/policy-channel.test.mjs`: ML-KEM-1024/AES-GCM und ML-DSA/Ed25519, Replay-/Versions-/Ablaufprüfung. HTTPS und unabhängiges initiales Pinning bleiben nötig. Kein HSM, Schlüsselrotation oder unabhängiges Kryptografieaudit; keine behauptete „doppelt quantensichere“ Zertifizierung. |
| SSO | Teilweise | `apps/server/auth.mjs`, `tests/server.test.mjs`: OIDC-PKCE, Signatur/Issuer/Audience/Nonce, Admin-Gruppen. Mock-IdP getestet; echter Kunden-IdP noch nicht integriert. Drei serverseitige Managementrollen (Admin, Operator, Auditor) aus OIDC-Gruppen in `apps/server/admin-access.mjs`; kein direktes SAML/SCIM. Remote-Shared-Bootstrap-Token wird verweigert; Bootstrap nur HTTP-Loopback. |
| Admin-Management-Oberfläche | Teilweise | `apps/server/public/index.html`, `admin.js`, `style.css`; funktionierende Enrollment-, Policy-, Integrations-, Teaching-, Bookmark- und Event-Formulare. `scripts/enterprise-admin-smoke.mjs`, `scripts/bookmarks-admin-smoke.mjs`. In dieser Iteration ergänzt: gruppierte Navigation, Fleet-/Auditfilter, Draft-/Änderungsprüfung, Dark/Light-Konsole, responsive Layouts und rollengerechte Aktionen. Tatsächliche Electron-DOM-/Screenshot-Proofs in `artifacts/enterprise-admin-proof.json` und `admin-console-*.png`. Gruppen-/Pilotverwaltung, effektive Vorschau, Versionsmeldungen und verpflichtende Zweitfreigabe sind inzwischen mit echten UI-Proofs ergänzt. Incident-Verwaltung mit Rollen, Verlauf, Zuständigkeit und Revisionsprüfung ist ergänzt und im echten UI geprüft. Einige Security-/Agentenfelder bleiben Advanced JSON; externe Tickets, automatische Fälle und vollständiger Daten-Lifecycle bleiben offen. |
| Fleet, Gruppen, Rollout | Teilweise | Gerätebestand, widerrufbare Credentials, globale signierte Policy, per-Gerät Dokument-/Bookmark-Steuerung und serverseitige Rollen vorhanden. `policy-history.mjs` liefert Historie/Diff/Restore als neue Version. `policy-review.mjs` erzwingt bei aktiviertem Deploymentflag unterschiedliche Autor-/Prüferidentität für alle Veröffentlichungswege, einschließlich Teaching und Gerätescan. Restriktive Gerätegruppen, explizite Pilot-Ausweitung und gerätgebundene effektive Policies sind inzwischen implementiert (`docs/group-policy-rollout.md`). Dynamische IdP-Gruppen, automatische Gesundheitsgates, prozentuale Rolloutringe und Mandantenisolation bleiben offen. |
| Admin-Bookmarks lesen/bearbeiten, Firmenlinks und erlaubte persönliche Links | Umgesetzt innerhalb des aktuellen Fleet-Modells | `packages/core/bookmarks.mjs`, `apps/server/bookmarks.mjs`, `apps/browser/bookmarks.cjs`, `tests/bookmarks.test.mjs`, `tests/bookmarks-native.test.mjs`, beide Bookmark-Smokes und Proof-Artefakte. Signierte Firmenlinks, per-Gerät persönliche Revisionen, native und Backend-Rechte. Kein geräteübergreifendes Benutzerroaming oder Gruppenzuweisung. |
| Eigener Proxy, VPN, DNS | Teilweise | `apps/browser/network-posture.cjs`, `packages/core/enterprise.mjs`, `tests/network-posture.test.mjs`, `scripts/enterprise-browser-smoke.mjs`: Windows-DNS, Corporate DoH, Proxy/PAC, VPN-Adapter/DNS-Prüfung. Adapterpräsenz ist keine kryptografische Tunnel-/Routenattestation; Erkennung hat Polling-Latenz. Reale Kundentopologien müssen getestet werden. |
| Live Domain/IP-/Inhaltsblockierung, YARA/Sigma | Teilweise | `packages/core/security.mjs`, `tests/security.test.mjs`, `tests/dns-alias.test.mjs`, `apps/inspector/engine.py`: Domain/IP-Regeln und echte lokale YARA. Sigma unterstützt nur genaue Event-Metadaten-Selektion, keine vollständige Sprache/Korrelation. OS-weit andere Anwendungen werden nicht kontrolliert. |
| ICAP zu eigener AV/Sandbox | Teilweise | `apps/browser/icap-client.cjs`, `enterprise-inspection.cjs`, `apps/server/inspection.mjs`, `tests/icap-client.test.mjs`, `tests/enterprise-gateway.test.mjs`: vollständige unveränderte Bodies, OPTIONS, ICAPS, fail closed. Kein verzögertes Detonations-/Polling-Protokoll, Vendor-REST oder sichere Freigabe adaptierter Inhalte. |
| Downloads mit zentraler YARA vor OS-Dateischreiben | Umgesetzt für unterstützte GET-Downloads | `apps/browser/main.cjs`, `inspection.cjs`, `tests/download-gate.test.mjs`, `scripts/smoke.mjs`: native Downloads gestoppt, bounded Memory-Scan, SHA-Bindung vor Save-Dialog/Schreiben. POST-/Blob-/andere Downloads nicht unterstützt und blockiert. Ein YARA-Allow ersetzt keine DLP-Klassifikation. |
| Vollständige Upload-/Text-DLP | Teilweise, wichtige Grenze | `main.cjs`, `packages/core/policy.mjs`, `tests/policy.test.mjs`: unterstützte immutable HTTP-Body-/URL-Pfade geprüft. Dateibasierte/Data-Pipe-Uploads blockiert statt race-anfälliger Freigabe. WebSocket-Nachrichten bei Freigabe, WebRTC, Streaming und codierte/covert Exfiltration nicht vollständig geprüft. Native Chromium-Enforcement-Arbeit erforderlich. |
| Copy/Paste/Cut und ClickFix | Teilweise | `packages/core/clipboard.mjs`, `apps/browser/page-clipboard-guard.cjs`, `site-preload.cjs`, `tests/clipboard.test.mjs`, `tests/page-clipboard-guard.test.mjs`, `scripts/smoke.mjs`: echte Tastatur-/Kontextmenü-Pfade, Policy-/Ziel-/Selektionsbindung; Seiten-Clipboard/Legacy-Pfade geschützt. Richtext, Dateien, contenteditable und Subframe-Transfers blockiert. ClickFix-Regeln erfassen ausgewählte gefährliche Ausführungsketten, nicht sämtlichen Schadcode von GitHub. Kein OS-weiter Clipboard-/Print-/Screenshot-Schutz. |
| Lokales OCR und Parsing ohne Cloud | Teilweise, Windows-Isolation implementiert | `apps/inspector/engine.py`, `requirements.lock.txt`, `CAPABILITIES.md`: gepinnte RapidOCR/ONNX-Modelle, begrenzte Parser, kein Modellnachladen. Der Broker importiert keine Parser; pro Anfrage führt `windows_appcontainer.py` einen attestierten Worker mit null Fähigkeiten, privaten Pipes und freigegebenen Runtime-Leserechten aus. Job-Limits und Nachfahrenbeendigung bleiben aktiv. Zwölf native Isolationstests sowie echtes YARA/OCR/Gemma im Broker bestanden (`artifacts/windows-appcontainer-proof.json`). PDF/OOXML-/Mediencoverage bleibt unvollständig. Installer-ACLs für Program Files und unabhängige Sandbox-Bypass-Prüfung fehlen weiterhin. |
| Echtes semantisches GemmaEmbed2 | Umgesetzt als lokaler Klassifikationsbaustein | `apps/inspector/semantic.py`, `test_semantic_real.py`, `packages/core/semantic.mjs`, `scripts/provision-semantic-runtime.py`, `scripts/semantic-browser-smoke.mjs`, `artifacts/semantic-browser-proof.json`: reale gepinnte EmbeddingGemma-2 Q8_0-Gewichte, CPU, 768 Dimensionen, vollständige Tokenfenster. Kundenspezifische Schwellen, Accuracy-/False-Negative-Evaluation und Driftkontrolle fehlen. Das ist kein Fine-Tuning. |
| Bilder, Medien, Video | Teilweise | Lokales OCR und native Bildembeddings; begrenztes mono16kHz PCM16-WAV-Embedding in `semantic.py`/Realtests. Keine vollständige Audio-Transkription, Video-Frame-/Audiocoverage. Ein Medienvektor allein erlaubt keine unvollständig geprüfte Datei. |
| Internes Dokument „anlernen“, keine vollständige Speicherung | Umgesetzt für Features und konfigurierbare Zweitfreigabe | SHA-/Fragmenthashes und begrenzte semantische Vektoren, keine dauerhafte Quelldokument-/Plaintextspeicherung. Deploymentflag erzwingt unabhängigen Administrator für Veröffentlichung; Reviewer sieht Abdeckung/Modus und unveränderlichen Vorschlag. Hashes/Vektoren sind sensible Metadaten. Held-out Evaluation und automatisches Fine-Tuning fehlen. Forensisches Löschen von Prozess-/Paging-Speicher ist nicht garantiert. |
| Dokument-Scan je Browser aktivierbar | Umgesetzt | `app.mjs`, `main.cjs`, Fleet-UI; per-Gerät supplemental Scan. Pflicht-DLP/YARA bleibt davon unabhängig. Nachweise in Server- und Native-Smoke. |
| KI als First Class, kontrolliertes Gateway | Teilweise | `apps/server/app.mjs`, `inspection.mjs`, Browser-AI-UI, `tests/enterprise-gateway.test.mjs`: freigegebene lokale Ollama/kompatible Provider, serverseitige Credentials, Prompt-/Outputprüfung. Kein vollständiges Berechtigungs-RAG, Modellinventar, Provider-Tenantnachweis oder umfassendes KI-Tool-Autorisierungsmodell. |
| Lokale Agenten steuern Sessions | Umgesetzt für begrenzte API | `apps/browser/agent-control.cjs`, `tests/agent-control.test.mjs`, `tests/agent-adapters.test.mjs`, `scripts/agent-client.cjs`: Loopback, Capability-Pairing, Scopes und feste Aktionen. Kein freies JS/CDP, Passwort-/Cookieexport. Stabile native Tab-UUIDs, Kontextbindung sowie explizite App-/Einstellungs-/Bookmark-/Tab-Rechte sind ergänzt und mit echtem CLI geprüft. Freigaben bleiben zentral begrenzt. Vollständige UI-Steuerung, sichere Screenshots und delegierte kryptografische Agent-Identitäten bleiben offen. |
| Passwortmanager mit Post-Quantum-Kryptografie | Teilweise | `apps/browser/vault.cjs`, `password-fill.cjs`, `tests/vault.test.mjs`, `tests/password-fill.test.mjs`: ML-KEM-1024/AES-GCM/scrypt und Windows-DPAPI, Idle-/Blur-Lock, gebundene HTTPS-Formfüllung. Kein Sync/Recovery/Passkeys, keine unabhängige Kryptografieprüfung oder FIPS-Modulvalidierung. |
| UI+pHash+korrekte Login-URL gegen unbekannte Domains | Teilweise | `packages/core/visual-hash.cjs`, `visual-image.cjs`, `apps/browser/visual-phishing.cjs`, `visual-capture.cjs`, `tests/visual-*.test.mjs`, Native-Smoke: echte Pixel, DCT-pHash, exakte erlaubte HTTPS-Origins, Quarantäne/Audit. Admin muss vertrauenswürdige Referenzen liefern; keine voreingestellte Google-Bibliothek. Kein Pre-Render-Block; Layout-/Sprache-/Iframe-/Evasion-Abdeckung und Fehlalarmrate nicht ausreichend evaluiert. |
| OpenTelemetry und SIEM-Standardexport | Teilweise | `apps/server/telemetry.mjs`, `siem.mjs`, `packages/core/siem.mjs`, `tests/telemetry.test.mjs`, `tests/siem.test.mjs`: OTLP Signals, dauerhafte Audit-/Dedup-Pfade, ECS/CEF-Cursor und HTTPS/mTLS-Push. Keine Dokument-/Promptinhalte in regulären Events. Incident-Triage und standardmäßig deaktivierte Datenbank-Aufbewahrung implementiert. Incident-Belege und ausstehende SIEM-Exporte bleiben erhalten. Zentral signierte Browser-OTLP-Traces/Logs mit Laufzeiten und Trace-/Span-Korrelation sind jetzt integriert und mit realem Electron/Collector geprüft. Separater verschlüsselter Belegspeicher serverseitig vorhanden; Browser-Erfassung/Analystenansicht, detaillierte Python-Phasen, automatische Fälle, externe SIEM-/Datei-/Backup-Aufbewahrung und reale Kunden-SIEM-Tests bleiben offen. |
| Cross Platform und Mobile | Bewusst später | Benutzer hat Windows priorisiert. macOS/Linux/Mobile sind keine jetzt fertigen Produkte, auch wenn Paketkonfiguration Zielnamen enthält. |
## Priorisierte To-do-Liste und Abnahmekriterien
### P0: aktuell sichere Bedienung und überprüfbare Verwaltung
- [x] Admin-Weboberfläche in klare Arbeitsbereiche aufteilen: Übersicht, Fleet, Policies, DLP/Teaching, KI, Infrastruktur, Bibliothek, Ereignisse. Aktive Navigation, Suche/Filter, leere/Fehler-/Ladezustände und verständliche Entwurf-/Veröffentlichungszustände. Abnahme: echte DOM-/Screenshot-Tests durchlaufen Template, Änderung, Veröffentlichung und Geräteaktion; Backend-Rechte bleiben unabhängig von UI.
- [x] Admin-Authentifizierung und Workflow serverseitig überprüfen: Session-Lifecycle, Schreibschutz gegen fremde Origins, sichere Header und minimaler Bootstrapbetrieb. Abnahme: nicht authentifizierte/fremde/abgelaufene Requests scheitern; erlaubte SSO-Session arbeitet über denselben kontrollierten API-Pfad.
- [x] Produktionsgrenzen in Konsole/README sichtbar machen. Abnahme: kein „gesund/sicher“-Status nur wegen gespeicherter Konfiguration; aktueller Device-/Scanner-/Policy-Nachweis und tatsächliche Bereitschaft werden unterschieden.
- [x] Windows-Parser-Isolation als AppContainer mit echten Token-, privaten Datei-/Runtime-Schreib-, TCP-/UDP-, Kindprozess-, Deadline- und Pipe-Grenztests implementiert. Broker/Worker getrennt, keine Parser im Broker; zwölf native Tests und echte lokale YARA/OCR/Gemma-Operationen bestanden. Freigegebene Systemressourcen und Windows-Paketprivatspeicher bleiben nutzbar. Das schließt keine unbekannten Sandbox-Exploits aus.
- [x] Separates Installer-/Service-Provisionierungstool und native lesende Prüfung vorhandener Package-SID-ACLs implementiert. Normaler Scannerstart ändert keine Rechte; fehlende/writable/konfliktierende ACLs scheitern. Paketierung provisioniert erst nach vollständigem Kopieren. Native Tests prüfen echten Workerstart bei verbotenem Provisionierungs-Unterprozess.
- [ ] Geschützte Program-Files-Installation unter einem separaten Standardbenutzer sowie unabhängiger Sandbox-Bypass-Test. Ein eigener Entwickleraccount-Nachweis ersetzt diese Produktionsabnahme nicht.
### P1: Unternehmensbetrieb und Umfang erweitern
- [x] Verbindliche unabhängige Policy-Freigabe über Deploymentflag, dauerhafte unveränderliche Entwürfe, Hash/Diff/Basisversion und unterschiedliche Administrator-Identität implementiert. Alle Veröffentlichungswege einschließlich Teaching, Blocklisten, Gerätescan und Wiederherstellung durchlaufen denselben Publisher. Eigenfreigabe, falscher Hash, veraltete Versionen und doppelte Freigabe scheitern; echte Admin-/Operator-UI-Prüfung bestanden.
- [x] Restriktive Gerätegruppen mit expliziter Mitgliedschaft, deterministischen Konfliktregeln, gruppenspezifischen Firmenbookmarks und signierter gerätgebundener effektiver Policy implementiert. Baseline bleibt zwingend; Browser, AI-Gateway und Bookmark-APIs prüfen die effektive Policy. Dynamische SSO-/SCIM-Gruppenzuweisung bleibt offen.
- [x] Unveränderliche Policy-Historie, Versionsvergleich und explizit geprüfte Wiederherstellung als neue Version implementiert. CAS, aktuelle Schema-/Bookmark-Prüfung, frisches Ablaufdatum und Backend-Rollen gelten; sechs Backendtests und echter Admin-UI-Workflow bestanden.
- [x] Expliziter Pilot-/Expanded-/All-Members-Rollout mit zentraler Vorschau, versionsgebundener Zweitfreigabe und gemeldeten Geräteversionen implementiert. Gruppenstände werden historisiert und als neue Generation wiederhergestellt. Gemeldete Versionsgleichheit ist keine Gesundheitsattestation.
- [ ] Automatische Rollout-Freigabe-/Stop-Regeln, prozentuale Ringe und dynamische IdP-/SCIM-Mitgliedschaft.
- [ ] Sichere immutable Freigabe von Dateiuploads und vollständige unterstützte Netzwerkkanäle im nativen Browser. Abnahme: kontrollierter Receiver erhält niemals nach dem Scan ausgetauschte Bytes; Frames/Worker/WebSockets/Streams sind explizit abgedeckt oder gesperrt.
- [ ] Vollständige Dokument-Render-/Attachmentprüfung, Audio-Transkription und Video-Frames im isolierten lokalen Worker. Abnahme: bekannte Secrets in jeder unterstützten Modalität und im Dateiende werden erkannt; unvollständige Coverage kann nicht freigegeben werden.
- [ ] Semantische Teaching-Evaluation mit erlaubten/verbotenen/adversarial Beispielen, Schwellen und Review. Abnahme: messbarer Kunden-Testdatensatz, kein automatisches Abschwächen durch Benutzerfeedback, Policy-/Modellrevision pro Entscheidung.
- [x] Echte native Tabs mit unabhängigen Inhalten/Historien, gepinnten Agent-Kontexten und Aktivierungsepochen integriert. Native Tests zeigen DOM-/Scroll-Erhalt, keine Reloads, DLP in beiden Tabs, Schließen und zentralen Widerruf aller Views.
- [ ] Unerwartete WebContents-Crashes, atomare Renderer-Aktionsfreigaben über den Dispatch-Zeitpunkt und weitergehende Native-Race-Proofs härten. Sichtbarkeits-/Fokusprüfung bei Passwortfüllung mit echten Views bestanden.
- [x] Incident-Administration mit Ereignisreferenz, Rollen, revisionsgebundener Triage, unveränderlichem Verlauf und reinen Metadaten-Audits implementiert; tatsächliche UI-/HTTP-Prüfung bestanden.
- [x] Opt-in Datenbank-Ereignisaufbewahrung mit aktuellem SIEM-Cursor, Incident-/Sigma-Referenzschutz und erhaltener Replay-Deduplication implementiert; atomarer Fehler-Rollback und echter abgeschlossener Incident geprüft.
- [ ] Vollständiger Daten-Lifecycle: Fall-/Notizablauf, Exportdateien, SIEM, Dedup-Ledger, Backups und sichere Wiederherstellung; Benutzer-/Geräte-Lifecycle und automatische Fallbildung.
### P2: Produktionsfreigabe mit externen Voraussetzungen
- [ ] Reale OIDC-, VPN-/Proxy-/DNS-, ICAP-/AV- und SIEM-Kundenumgebungen testen. Keine synthetische Fixture als Kundennachweis verwenden.
- [ ] Windows-Code-Signing, signierte Installer und verifizierter Updater mit Release-Ringen und Recovery. Zertifikat/Signierservice und Betrieb müssen bereitgestellt werden.
- [ ] Schlüsselcustody/Rotation und optional HSM; unabhängige Prüfung von Policykanal und Vault; keine Zertifikatsbehauptung ohne Prüfung.
- [x] Implementierungs-Threat-Model mit Vertrauensgrenzen, Angriffsfällen und konkreten Abnahmekriterien in `docs/threat-model.md` erstellt.
- [ ] Unabhängiges Penetrations-/Bypass-/Tenant-Isolation-Testprogramm, Chromium-Update-SLA und Incident-Reaktion.
- [ ] Modell-/OCR-/Drittsoftware-Lizenzen und vollständige Notices vor Distribution prüfen.
- [ ] Nach Windows-Abnahme: Plattformdesign für macOS/Linux, später Mobile; native Schutzgrenzen pro OS neu nachweisen.
## Admin-Architekturentscheidung
Eine getrennte Weboberfläche ist die vorhandene und sinnvolle Verwaltungsarchitektur: Kunden betreiben sie hinter HTTPS und Enterprise-SSO. Adminrechte entstehen ausschließlich im Management-Backend, nicht aus dem Browser-Client oder ausgeblendeten UI-Elementen. Ein zusätzlicher nativer Admin-Browser würde die fehlenden Rollen-, Transport-, Session- oder Auditkontrollen nicht ersetzen. Der Verwaltungszugang sollte kundenseitig auf berechtigte Benutzer/Netze beschränkt werden; Konfiguration allein ist keine Produktionsabnahme.
## In dieser Iteration umgesetzt
- Admin/Operator/Auditor-RBAC in `apps/server/admin-access.mjs`, `auth.mjs` und `app.mjs`: explizite Route-Permissions, neu berechnete Sessionrechte und default-deny für unbekannte Adminrouten. Operatoren können Geräte betreuen und Teaching-Entwürfe erstellen, aber keine signierte Policy veröffentlichen. Auditoren lesen ohne Schreibrechte. Nachweise: `tests/server.test.mjs`.
- Remote Shared-Token-Anmeldung abgeschaltet; lokale HTTP-Loopback-Entwicklung behält Bootstrap. Enterprise-SSO bleibt für echte Deployments erforderlich.
- Sessionübersicht und sofortige Sessionwiderruf-API im aktuellen Code; IDs sind opake UUID-Handles, keine Cookies/Tokenhashes. Nur Admin darf inventarisieren/widerrufen. Origin-geschütztes Logout. Neue Servertests enthalten Rechte, Token-Nichtoffenlegung und sofortige Ablehnung widerrufener Cookies; endgültiger Gesamtlauf wird vom Root berichtet.
- Admin-Konsole mit Navigation, Suchfiltern, Änderungenprüfung und eigenem Theme; tatsächlicher Electron-Proof bestätigt Review ohne Veröffentlichung, Filter, Theme-Persistenz, mobile Breite und Read-only-Controls.
- Windows Inspector-Job-Containment mit echtem Prozessbaum-/Owner-Exit-Nachweis. Dies verbessert Ressourcenbegrenzung, ist aber ausdrücklich keine Parser-Sicherheits-Sandbox.
## Verifikation
### Aktueller Integrationsstand: Windows-Isolation, Historie und Zweitfreigabe
- `npm test`: 196 bestanden, keine Fehler (`artifacts/governance-unit-tests.log`).
- Python: 47 insgesamt, 43 ausgeführt und bestanden, vier optionale Modelldateitests im Routinelauf übersprungen (`artifacts/governance-python-tests.log`).
- Zwölf echte Windows-Isolationstests plus tatsächliches YARA, RapidOCR und Gemma im isolierten Broker bestanden (`artifacts/windows-appcontainer-proof.json`). Beinhaltet verweigerten Broker-Speicherzugriff und normalen Start ohne ACL-Provisionierungsprozess.
- Vollständiger nativer Browser-Smoke nach isolierter YARA-Integration bestanden (`artifacts/governance-native-smoke.log`).
- Tatsächlicher semantischer Browser-Clipboard-Test bestanden (`artifacts/isolation-history-semantic-browser.log`), einschließlich erlaubtem öffentlichen Text und blockierter Paraphrase.
- Tatsächliche Admin-Historien-/Wiederherstellungs- und unabhängige Freigabe-Workflows bestanden; einschließlich Geräteaktion vor/nach Freigabe, Operator-Beschränkung und verweigerter Eigenfreigabe (`artifacts/policy-history-admin-proof.json`, `artifacts/independent-review-admin-proof.json`).
- JavaScript-Syntax geprüft. Windows-Paket neu erstellt, spezifische Runtime-ACLs nach dem Kopieren provisioniert und finale Paketprüfung bestanden (`artifacts/governance-package-verification.log`): aktuelle Sicherheitsmodule, echter isolierter Kaltstart ohne neue Bytecode-Dateien, lokale CPU-Inferenz, DPAPI und nativer Agent-Helper. Hauptprogramm weiterhin `NotSigned`.
Die erste isolierte YARA-Integration scheiterte an geschützten DLL-Dateirechten. Explizite vorhandene Datei-ACLs und ein echter YARA-Upload-/Download-Test schließen diese konkrete Lücke. Beim Clipboard-Test wurde eine dynamisch eingefügte Testauswahl korrekt abgelehnt, wenn ihre noch laufende visuelle Revision den Kontext änderte; der Harness wartet jetzt auf Dokument-/Visual-Prüfung, ohne Produktionskontrollen abzuschwächen. Normale Laufzeitprovisionierung wurde inzwischen durch rein lesende ACL-Prüfung ersetzt. Ein geschützter Standardbenutzer-Installer und unabhängige Sicherheitsbewertung bleiben offen.
Vor Integration existieren die Unit-/Native-Testdateien und Proof-Artefakte oben. Diese Audit-Arbeit hat selbst keine neue Gesamttestsuite ausgeführt; die oben genannten neuen Nachweise stammen aus tatsächlichen Agentenprüfungen oder werden als noch zu integrierender Gesamtlauf bezeichnet. Der orchestrierende Agent muss geänderte Features mit passenden Tests, tatsächlicher Admin-DOM-/Screenshot-Prüfung und Windows-Paketvergleich verifizieren und die endgültigen Ergebnisse separat berichten.
### Integrationsprüfung durch Root, 2026-10-13
- `npm test`: 183 bestanden, keine Fehler (`artifacts/audit-unit-tests.log`).
- Python-Tests: 34 insgesamt, 30 ausgeführt und bestanden, 4 optionale echte Modelltests in diesem Routinelauf übersprungen (`artifacts/inspector-audit-tests.log`). Enthält zwei echte Windows-Prozessbaum-/Breakaway-Tests.
- `npm run check` und Syntaxprüfung des korrigierten Semantic-Testharness: bestanden.
- Vollständiger nativer Browser-Smoke: bestanden (`artifacts/audit-native-smoke.log`), einschließlich Clipboard, Frame-Bypass, YARA vor Save, pHash, Teaching und Revocation.
- Separater realer Gemma-Browser-Test: bestanden (`artifacts/audit-semantic-smoke-retry.log`); paraphrasierter vertraulicher Inhalt blockiert (0,843945), öffentlicher Text zugelassen (0,509778), keine Rohtexte im zentralen Audit.
- Tatsächliche Admin-Electron-UI-Prüfung: bestanden; Nachweis `artifacts/enterprise-admin-proof.json`, Light/Dark/Mobile-Screenshots und Bookmark-UI-Smoke.
- Windows-Paket neu erstellt und geprüft: aktueller Sicherheitsquellstand, wirklich gestarteter Job-begrenzter Paket-Inspector, lokale CPU-Modellinferenz, DPAPI und nativer Agent-Helper (`artifacts/audit-package-verification.log`). Authenticode-Status des Hauptprogramms weiterhin `NotSigned`.
Ein korrigierter erster Scanner-Smoke deckte den isolierten Python-Importpfad auf: Sibling-Module werden jetzt vom tatsächlichen Service-Verzeichnis geladen. Der erste separate semantische UI-Test scheiterte beim Sichern einer leeren Zwischenablage; der Harness behandelt leere MIME-Listen und synchrone Cleanup-Aufrufe jetzt korrekt. Beide gezielten Wiederholungen bestanden. Produktionsgates oben bleiben ausdrücklich offen; diese Ergebnisse gelten für die ausgeführten Szenarien.
### Gruppen-Integration, 2026-10-13
- 203 JavaScript-Tests bestanden (`artifacts/groups-unit-tests.log`); vollständiger nativer Browser-Smoke bestanden (`artifacts/groups-native-smoke.log`).
- Echter Admin-Gruppenworkflow mit Pilot, Vorschau und ausdrücklicher Ausweitung bestanden (`artifacts/groups-admin-proof.json`).
- Native Upload-Probe zeigt unveränderte Bytes nach Dateiänderung, aber unsichere Cookie-Erweiterung beim Electron-Protocol-Forwarding. Deshalb keine Produktionsfreigabe dieses Ansatzes; Details in `docs/immutable-upload-feasibility.md`.
- Verpflichtende Gruppen-Zweitfreigabe im echten Operator-/Admin-UI-Workflow bestanden: Vorschlag unveröffentlicht, Mitglieder/Kohorte/Regeln sichtbar, unterschiedliche Identität veröffentlicht (`artifacts/groups-review-admin-proof.json`).
- Neuer Windows-Build mit Gruppenpolicy-Empfangsbindung erstellt; finale Paketprüfung einschließlich aktuellem Quellvergleich, isoliertem Scanner, lokalem Gemma, Agent-Helper und DPAPI bestanden (`artifacts/groups-package-verification.log`). Authenticode weiterhin `NotSigned`.
### Incident-Integration, 2026-10-13
- 220 JavaScript-Tests bestanden (`artifacts/incidents-unit-tests.log`), Syntaxprüfung bestanden. Zehn gezielte Incident-/Retention-Tests zeigen Rollen, CAS, atomaren Rollback und Belegschutz.
- Echter Incident-Admin-Workflow inklusive Auditor-403, erhaltener Konflikteingaben und literal dargestellter HTML-Notiz bestanden (`artifacts/incident-admin-proof.json`). Gruppen- und Historien-UI nach Integration erneut bestanden.
- Lokaler Managementdienst auf Port 4310 mit aktuellem Backend neu gestartet. Datenbank-Aufbewahrung standardmäßig aus; Details in `docs/audit-retention.md` und `docs/incident-management.md`.
- Native Tab-Registry mit sieben Lifecycle-/Kontexttests vorbereitet (`docs/native-tabs-integration.md`), aber noch nicht in Hauptprozess, Renderer, Clipboard und Agenten integriert. Echte Tabs bleiben offen.
### Native Tabs, First-Class-Agenten und Observability, 2026-10-13
- 253 JavaScript-Tests bestanden (`artifacts/first-class-agent-unit-tests.log`). Vollständiger nativer Browser-Smoke inklusive echter Agent-App-/Settings-/Bookmark-/Tab-Aktionen bestanden (`artifacts/first-class-agent-native.log`, `artifacts/smoke-entry.txt`).
- Echte Tab- und OTLP-Collector-Proofs bestanden (`artifacts/native-tabs-proof.json`, `artifacts/native-tabs-receiver-proof.json`, `artifacts/native-browser-diagnostics-proof.json`). Parent/Child, Laufzeiten, korrelierte Logs und Deaktivierung nach Widerruf geprüft.
- Zentrale Diagnostik-Felder und neue Agent-Berechtigungen im echten Admin-UI veröffentlicht und Auditor-Schreibschutz geprüft (`artifacts/enterprise-admin-proof.json`).
- Verschlüsselter forensischer Server-Belegspeicher mit Deployment-Key, authentisierten Ereignisreferenzen, auditierter Entschlüsselung, Ablauf/Incident-Hold und neun HTTP-Tests implementiert (`docs/protected-evidence.md`). Nicht automatisch aktiviert: Browser-Erfassung, zentrale Sammelregeln und Analystenansicht fehlen.
- [ ] Vollständige forensische Browser-Erfassung: Downloadname/Quelle/Hash, menschliche Klickziele und Clipboard-/Form-Abläufe; relevante vertrauliche Inhalte kontrolliert verschlüsseln, Passwort-/Authentisierungsfelder nativ ausnehmen; Analystenansicht, SIEM-Belegreferenzen und physischer Daten-Lifecycle.
- [ ] Per-Agent-Identitäten, kryptografischer Request-Besitznachweis, Replay-Schutz, individuelle Widerrufe und umfassendere UI-/History-/Screenshot-Funktionen. Aktuelle DPAPI-/Loopback-Capabilities sind noch nicht das vollständige Delegationsmodell.
- [ ] Durchgehende Python-interne OCR-/YARA-/Gemma-Spans und Control-Plane-Codepfade instrumentieren; gegenwärtige Browser-Spans messen den lokalen Inspector-Aufruf, nicht alle internen Phasen.
- Anforderungen aus der jüngsten Nutzerpräzisierung stehen in `docs/agent-observability-requirements.md`: Vertraulichkeit darf relevante Security-Belege nicht unterdrücken; operationales Debug und geschützte Forensik sind getrennte Pfade.
- Windows-Paket mit stabilem Quellstand neu erstellt und vollständig geprüft (`artifacts/native-tabs-package-verification.log`), weiterhin `NotSigned`. Der erste parallele Build hatte eine während der ASAR-Erstellung geänderte Datei; neue Vor-/Nach-Quellprüfung verhindert die Abnahme solcher Artefakte.
+90
View File
@@ -0,0 +1,90 @@
# S Browser threat model and security acceptance gates
Status: implementation threat model, 2026-10-13. This is not an independent security
assessment. See `requirements-audit.md` for current implementation evidence.
## Assets and adversaries
Protect confidential document/prompt bytes, credential material, browser session
authority, signed policy versions, classification features, administrator identity,
audit integrity and availability. Hashes and semantic vectors are confidential
derived data, even though source documents are not retained.
Consider malicious sites and frames, hostile document/media files, malicious
clipboard instructions, compromised AI output, unauthorized local agents, stolen
device credentials, network interception, stale policy caches and unauthorized or
compromised management identities. A local OS administrator can replace executable
code or inspect process memory: protecting against that requires endpoint controls
outside this browser's present assurance boundary.
## Trust boundaries
1. **Remote site to privileged browser.** Website content has no trusted UI bridge,
Node access or administrative authority. Renderer requests and DOM observations
are untrusted; native policy checks own transfer decisions. Website appearance
cannot establish origin identity.
2. **Browser to clipboard/files/network.** Inspect before release. An approval must
bind destination, bytes, current policy and current target context. Unsupported
transfer paths remain blocked. Rich/file/subframe clipboard paths are not silently
downgraded to plain-text inspection.
3. **Document bytes to parser/model worker.** Authentication to the loopback broker
is separate from permission to parse a document. Untrusted documents must run in
a restricted worker with no broker credentials, host data access or network
capability. Job Objects limit resources but do not satisfy this boundary alone.
4. **Device to management.** Enrollment establishes device identity; it never
establishes admin authority. HTTPS, independently pinned policy keys, signed
monotone versions, expiries and authenticated device requests all remain required.
5. **Administrator to management.** Verified OIDC identity and exact role permissions
authorize every backend route. Hidden controls are a usability property. Session
revocation invalidates current cookies; removing an IdP group must also prevent
future logins. Mandatory independent approval is still a separate gate.
6. **Browser/AI gateway to approved model.** Classify locally/customer-side before
external transmission. Provider credentials stay at the gateway. Page content,
retrieved documents and model output cannot grant tool permissions or change
policies. Model similarity is evidence, not a proof of confidentiality absence.
7. **Local agent to browser.** Pairing capabilities are scoped, device-local and
revocable. Fixed actions validate the target/session again before execution.
No arbitrary JavaScript, CDP, cookie export or password export is exposed.
8. **Enforcement to audit/SIEM.** Record bounded metadata rather than source contents,
prompts or credentials. Durable event ingestion and deduplication are separate
from sampled operational traces. SIEM failures must retain a retryable backlog.
## Abuse cases and acceptance evidence
| ID | Abuse case | Required invariant / release test |
| --- | --- | --- |
| DLP-01 | Page swaps an approved file after scanning | Receiver obtains only the inspected immutable bytes; native file transfer binding is still open. |
| DLP-02 | Worker/frame/WebSocket/stream bypasses a form control | Every permitted channel is gated before transmission; explicitly block unsupported channels and test controlled receivers. |
| DLP-03 | Clipboard selection or destination changes during scan | Discard the pending release; scan approval cannot authorize a new selection, document or policy generation. |
| DLP-04 | ClickFix asks employee to execute copied instructions | Withhold covered dangerous command patterns; do not claim this heuristic detects all executable malware. |
| PARSE-01 | Document exploits native parser and reads user secrets | Native restricted-worker probe cannot read a synthetic private file outside explicitly approved roots. |
| PARSE-02 | Exploited parser sends document bytes to network | Native worker TCP/UDP probes fail without network capability; no loopback exemption or credential forwarding. |
| PARSE-03 | Worker forks, hangs, exhausts memory or survives owner | Process tree limits, no breakaway, deadline termination and clean subsequent scan; prove actual OS behavior. |
| POLICY-01 | Attacker replays old/expired/different-device policy | Signature, device binding, expiry and monotone revision reject it; emergency restore is published as a new version. |
| POLICY-02 | Operator forges admin permissions in session/UI | Backend recomputes role permissions; direct publication/revocation requests fail. |
| POLICY-03 | Cross-site page triggers an admin mutation | Exact Origin validation rejects cookie-authenticated writes and logout from other/missing origins. |
| AUTH-01 | Stolen/shared bootstrap token bypasses enterprise SSO | Remote HTTPS management rejects development bootstrap credentials. |
| AUTH-02 | Removed admin retains existing browser cookie | Explicit emergency session revocation rejects the next request; continuous IdP/back-channel revocation remains open. |
| PHISH-01 | Unknown domain renders a trusted login page | Pixel reference match plus exact HTTPS origin mismatch quarantines the page; validate layouts/languages/iframes and false positives before fleet-wide use. |
| AI-01 | Prompt injection asks agent/model to disclose other data | Policy and tool permissions are independent of prompt contents; retrieval ACLs and full tool governance remain open. |
| LOG-01 | Prompts, URLs with secrets or source documents enter logs | Allowlisted bounded metadata; inspect actual exported OTLP/ECS/CEF output and failure responses. |
| UPDATE-01 | Attacker supplies modified browser/model/update | Pinned artifact hashes and verified publisher signatures; production signed updater is still open. |
## Operational response and residual risks
Revoke compromised device credentials and management sessions; publish strengthened
rules as a new policy version and verify device acknowledgement. Preserve bounded
audit evidence under the customer's retention/access rules. Rotate affected keys
and provider credentials through deployment tooling; automated key rotation and
full incident workflow are not complete.
Unavailable scanners, unsupported content or expired policy must not be interpreted
as an allow verdict. Test recovery separately: a blocked parser request must not
force permanent loss of the scanner. Network/proxy/VPN detection has its documented
latency and cannot prove operating-system routing on its own.
Camera capture, manual retyping, other applications, administrator tampering,
unvalidated classifier accuracy and covert/encoded exfiltration remain residual
risks. Extend endpoint/network controls and independent bypass testing before
production approval. Each acceptance row needs evidence matching its full scope;
a green synthetic test for one path does not close all related paths.
+13
View File
@@ -0,0 +1,13 @@
# Centrally managed user profiles
Administrators can create arbitrary named profiles; employee, developer and executive are examples, not fixed roles. Profiles can target explicit device IDs or verified OIDC subject IDs. A subject applies to all devices enrolled through verified SSO for that subject. Provisioning-code labels and user-supplied enrollment fields never become verified identities. Existing provisioning-code devices can be assigned explicitly by an administrator.
The policy publisher reviews profile CRUD, category edits and delegation changes through the same independent-review flow as other policy changes. Successful publication advances the shared signed generation. Each device receives only effective policy and assigned profile IDs, not the profile's subject lists. Profile/category snapshots accompany every policy generation; history restoration restores them at a new generation. Historical snapshots missing profile configuration cannot silently restore current profile assignments.
Host denials and administrator-maintained domain categories combine with union. Nonempty profile allowlists intersect with the company allowlist and other matching profiles. A disjoint intersection denies every host; it never becomes unrestricted. Category matching uses the same exact/wildcard host enforcement as normal browser navigation; categories are curated host lists, not a commercial classification feed. Existing device-group restrictions apply after user profiles.
Features currently support DevTools inherit/allow/deny; downloads, AI and agents inherit/deny; and mandatory local document scanning. DevTools allow requires the signed company `userAccess.delegatableFeatures.devTools` ceiling. Conflicting profile denies win regardless of ordering. Administrators can leave the ceiling off to prohibit delegation globally. These profiles do not disable mandatory DLP, signatures, sandboxing or parser isolation.
API: `GET /api/admin/user-profiles`, `PUT/DELETE /api/admin/user-profiles/:id`, `POST /api/admin/user-profiles/preview`, and `PUT /api/admin/user-profile-configuration`. Mutations use `expectedVersion`; mandatory review returns 202 with the existing review ID/hash. Preview and read require policy.read; writes require policy.write, or policy.prepare when independent approval is mandatory. The configuration endpoint replaces categories and sets the DevTools delegation ceiling. It does not replace profile assignments.
Verified automated evidence: `tests/user-profiles.test.mjs` covers same verified subject on two devices, different subjects, false user labels, explicit delegation, deny precedence, category blocking, allowlist intersection, independent review, stale publication, auditor denial and historical restore. The admin Electron smoke independently exercises custom profile creation and review. SCIM, automatic identity-group synchronization, profile-specific proxy overrides and additional feature flags remain future work.
+11
View File
@@ -0,0 +1,11 @@
# User-profile management workflow
The management console separates user classes from restrictive device groups. Profiles have administrator-chosen identifiers and names; the examples do not limit available classes. Employee, developer and high-protection templates populate a local draft; they never silently publish or grant access. Administrators explicitly assign verified enterprise subjects or managed device identifiers.
The profile editor supports website allowlists, denylists and centrally maintained domain categories. Categories are administrator supplied host lists, not automatically inferred reputation. The effective preview compares the resulting device policy against the mandatory baseline. Denials accumulate across applicable profiles, and allowlists cannot override a denial.
Developer tools grants require separate central delegation. Ordinary employee and high-protection templates deny developer tools. High protection additionally denies downloads and local agents and requires document analysis. The administrator can customize the draft before submitting it. Mandatory DLP and centrally locked or hidden settings remain authoritative.
Profile publication and category/delegation publication use the existing policy publisher and independent approval workflow. The review screen displays exact subjects, device assignments, category definitions and feature flags through safe text rendering. On installations requiring independent approval, operators can prepare changes but another administrator must approve. Policy generation conflicts must be refreshed rather than silently overwritten.
The assignment table distinguishes a verified subject from an unverified asset-owner label. Explicit device assignment is available when the browser has no authenticated enterprise subject; entering an employee name is not identity verification.
+26
View File
@@ -0,0 +1,26 @@
# Windows parser runtime ACL installation
The inspector broker verifies every approved source, Python-runtime and local-model object with Windows `GetNamedSecurityInfoW`. Normal startup does not run `icacls`, change permissions, or require `WRITE_DAC`. It fails closed if the exact deployment AppContainer SID lacks read/execute permission, receives write permission, encounters conflicting deny ACEs, or finds a reparse point. Permission verification is conservative; administrators must resolve conflicting ACLs explicitly.
After copying **all** installation files, the installer or deployment owner runs the installation's private Python:
```powershell
# Development installation, from the workspace root:
.runtime/windows/python/python.exe apps/inspector/provision_runtime_acl.py --provision
# Packaged installation, from the resources directory:
python/python.exe inspector/provision_runtime_acl.py --provision
```
Omit `--provision` to verify without changing permissions. The command does not accept arbitrary grant paths. It derives the three approved roots from its own installed location and rejects an unrelated Python executable. It grants only read/execute to the deployment-specific package SID, never Everyone or ALL APPLICATION PACKAGES. It does not grant network capabilities or loopback exemptions.
For a Program Files installation, provisioning requires an elevated installer or trusted service possessing permission to modify those installation DACLs. A standard user subsequently launches the broker without administrative rights; the broker can create its user AppContainer profile and read existing ACLs. An ordinary user cannot provision protected Program Files by running this command. The native tests currently prove read-only startup under the current Windows account and fail-closed missing permissions; they do **not** claim a separate standard-user Program Files deployment has been exercised on this machine.
Provision again after replacing or adding runtime/source/model files or changing installation paths, because the SID is bound to the complete canonical root set. Run verification after provisioning and before service start. Updates must stop the broker during replacement. Production installation roots must be administrator-owned and unavailable for ordinary-user modification: read-only AppContainer grants do not prevent a deployment owner from modifying source or racing ACL provisioning. The command rejects existing reparse points but cannot protect an administrator-owned installation from a malicious administrator.
Native verification:
```powershell
.runtime/windows/python/python.exe -m unittest discover -s apps/inspector -p test_windows_appcontainer.py
```
The tests provision synthetic/development roots explicitly, intercept any startup subprocess invocation, launch an actual AppContainer worker under verified ACLs, and reject an unprovisioned directory. Existing token, denied private-file access, denied runtime writes, denied networking, child containment, parser/YARA and deadline tests remain active.