Security modelPhase 1 · complete
Security architecture
The security decisions below are real and already made — recorded in ADR-001 and the project's security notes. The build implementing them is in development and not yet independently audited; we say so plainly rather than borrow credibility we haven't earned.
The sandbox is not negotiable
ITISYOU keeps Chromium's process model — browser, renderer, GPU, and
network service processes — and its sandbox and Site Isolation at
upstream defaults. There is no --no-sandbox,
no --disable-web-security, and no single-process mode anywhere
in the project.
On Windows this required adopting CEF's modern launch pattern: the
application is built as itisyou.dll and launched by CEF's
bootstrap.exe — the upstream-required arrangement for a fully
sandboxed CEF app since CEF 133. The legacy unsandboxed-exe shortcut was
rejected.
- Process model
- upstream Chromium
- Sandbox
- enabled, upstream defaults
- Site Isolation
- upstream defaults
- Windows launch
- bootstrap.exe + app DLL
- --no-sandbox
- never
- Single-process mode
- never
Three layers between chrome and content
The browser's own UI is trusted HTML served over the internal
itisyou:// scheme in a dedicated privileged view. Web pages are
untrusted, always — they get no Node-like runtime, no filesystem API, and no
IPC surface. The one JS-to-native bridge is denied to web content at three
independent layers, so a single bug cannot open the door:
- Renderer bindings are only installed for
itisyou://frames — content renderers never receive them. - The browser-side message router rejects queries from non-internal origins even if a renderer misbehaves.
- Navigation blocking prevents content tabs from reaching the
privileged
itisyou://chromehost at all.
Permissions start at no
All site permission requests route through a central PermissionService with a deny-by-default policy and structured local logging. An unanswered prompt is a denial. An unsupported capability is a denial. Web content has no path around the service.
The browser process resolves every prompt via CefPermissionHandler;
renderers never decide anything.
Vulnerability reporting
There is no bug bounty program and no formal disclosure process yet — pretending otherwise with a decorative PGP fingerprint would be theater. A real security contact and disclosure policy will be published before the first public release, and this page will carry it. Until then, there is no shipped product to report against; the development process runs its own security review at each milestone.
Not yet implemented (and not claimed): audits, a hardened update pipeline, signed releases. Those belong to Phase 4 — see the roadmap.