safetynet/docs/immutable-upload-feasibility.md

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: protocol request body and trusted initiator origin.
• Electron session.fetch documentation: 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.