Chromeyumm runs as a local desktop application for live installations. It is not a general-purpose browser and does not process untrusted web input from the public internet (typical use is loading a trusted dev server URL such as http://localhost:5173).
| Surface | Risk Level | Notes |
|---|---|---|
contentUrl (local dev server) |
Low | Trusted content served from localhost |
contentUrl (external URL) |
Medium | If pointed at an untrusted URL, CEF renders arbitrary web content with elevated access |
display-config.json |
Low | Local file, not user-facing; parsed with JSON.parse (no eval) |
| Registry writes | Low | GpuPreference=2 written to HKCU\...\UserGpuPreferences — benign DirectX preference |
| FFI / dlopen | Low | libNativeWrapper.dll loaded from known path next to executable |
| Spout shared memory | Low | Win32 named file mapping accessible to same-user processes |
CEF runs with a V8 sandbox that restricts certain operations in the renderer process.
- Tier 1 Spout input (
CefV8Value::CreateArrayBufferbacked byMapViewOfFile) requires V8 sandbox OFF. When the sandbox is on,CreateArrayBufferreturns nullptr, and the code falls back to tier 2. - Tier 2 Spout input (persistent-buffer
memcpy) is sandbox-safe.
The current build does NOT explicitly disable the V8 sandbox — tier selection happens automatically at runtime.
in-process-gpu: trueruns the GPU thread in the main process (required for Optimus, see RELIABILITY.md)- The renderer subprocess (
chromeyumm Helper.exe) runs in a separate process with CEF's default renderer sandbox
At startup, setGpuPreference() writes to:
HKCU\Software\Microsoft\DirectX\UserGpuPreferences
Values written:
- Key: full path to
chromeyumm.exe→ Value:GpuPreference=2; - Key: full path to
chromeyumm Helper.exe→ Value:GpuPreference=2;
This uses reg add /f (force overwrite). These are standard DirectX user preferences — not a security concern, but worth documenting for auditability.
Win32 named file mappings (SpoutFrame_<id>) are created with default security attributes, meaning any process running as the same user can open and read them. This is inherent to Spout's design.
The shared memory region contains only pixel data (BGRA frames) with a 16-byte header (sequence counter, width, height, reserved). No executable code or sensitive data.
- No network server / listening ports (CEF's internal IPC uses named pipes)
- No file system writes beyond the registry preference (CEF cache goes to a temp dir)
- No elevation required (runs as standard user)
display-config.jsonis read-only from the app's perspective
display-config.jsonvalidated:windowsmust be a non-empty array, parsed viaJSON.parse(no eval, no JSONC parser)- URL parameters sanitized with
encodeURIComponentbefore appending to content URL - Spout sender names taken from config, not user input
- If deploying with
contentUrlpointing to an external/untrusted URL, consider enabling CEF's site isolation and renderer sandbox explicitly - Spout shared memory names should be unpredictable if multi-user scenarios are ever needed (currently not a concern for single-user installation deployments)
- RELIABILITY.md — Failure modes and recovery
- BACKEND.md — FFI and DLL loading details
- DEVELOPMENT.md — GPU preference registry details