System architecturePhase 1 · complete
Architecture explorer
The modular map of the ITISYOU browser. Select a module to inspect its responsibility, interfaces, and security boundary. Statuses are the real project state — nothing is marked "available" until it has shipped with verification evidence.
Data source: content/architecture.json,
embedded at build time. Legend: Available now In development Planned
All modules
Full reference (shown when JavaScript is unavailable; the explorer above shows the same data interactively).
Browser Engine
In developmentChromium 144.0.7559.261 embedded via the CEF binary distribution (CEF 144.0.34), selected in ADR-001. Provides the full Chromium navigation, rendering, and network stack with the upstream process model — browser, renderer, GPU, and network service processes — left intact.
Interfaces- CEF C++ API (libcef + libcef_dll_wrapper)
- CefBrowserView per tab (Views framework)
- CefRequestContext for profile and cache isolation
- CefPermissionHandler for permission routing
Chromium sandbox and Site Isolation preserved at upstream defaults. On Windows the sandbox is kept intact via the bootstrap.exe + application-DLL launch pattern. No --no-sandbox, no --disable-web-security, no single-process mode.
Browser Shell
In developmentThe browser's own chrome — tab strip, omnibox, panels — implemented as trusted HTML/CSS/JS served over the internal itisyou:// scheme inside a dedicated privileged view, separate from all web content views.
Interfaces- itisyou:// internal scheme handler
- origin-gated JS-to-native message router
- window and tab management commands
Privileged UI is separated from untrusted web content at three independent layers: renderer-side bindings are only installed for itisyou:// frames, the browser-side message router rejects queries from non-internal origins, and content tabs are blocked from navigating to the privileged host.
Tabs
In developmentTab Mode: the classic multi-tab browsing model. Manages tab lifecycle (create, close, activate, reorder) with one sandboxed browser view per tab, and feeds session snapshots to the storage layer for crash recovery.
Interfaces- TabManager (create / close / activate / move)
- per-tab navigation state
- session snapshot feed for recovery
Each tab hosts untrusted web content in its own sandboxed renderer with no privileged bindings and no filesystem or native API surface.
Workspaces
In developmentWorkspace foundation: named contexts that group tabs so research, development, and personal browsing can be kept apart. Phase 1 delivers the foundation only; the full persistent Workspace Mode grows in Phase 2.
Interfaces- WorkspaceManager (create / switch / persist)
- workspace-scoped tab lists
Workspace metadata is local-only. There is no sync service, no cloud component, and no account system.
Storage
In developmentLocal persistence with deliberately separate datasets: session state (for crash recovery), browsing history, and workspace data each live behind their own boundary rather than in one merged profile blob.
Interfaces- session store (crash recovery)
- local history store
- workspace store
All datasets are local to the machine and separated by purpose. Nothing is transmitted anywhere; there is no sync, telemetry, or cloud backup path in the codebase.
Permissions
In developmentA central PermissionService that all site permission requests (camera, microphone, location, notifications, and the rest) route through. The policy is deny-by-default: nothing is granted unless the user explicitly says yes.
Interfaces- CefPermissionHandler integration
- default-deny policy engine
- structured decision log (local)
Web content cannot bypass the service: permission prompts are resolved in the browser process, and unanswered or unsupported requests are denied.
Network Layer
In developmentChromium's network service via CEF, wrapped in a network-mode abstraction. Phase 1 implements standard mode only. The abstraction exists so future modes (proxy, Tor) can be added in Phase 2/3 without rearchitecting.
Interfaces- network-mode abstraction (standard mode only)
- proxy configuration surface (reserved, unused)
- scheme and resource handlers
The network service runs inside Chromium's sandboxed process model. Tor and proxy modes are planned and not implemented — no anonymity properties are claimed today.
AI Runtime (disabled)
In developmentInterface definitions for future, optional AI assistance — and nothing more. In Phase 1 the AI runtime exists only as disabled interfaces: no provider is configured, no API keys exist anywhere in the project, and zero provider calls are made.
Interfaces- AI runtime interface definitions (disabled)
- global enable/disable state (fixed OFF in Phase 1)
OFF by default and structurally inert: there is no code path that contacts an AI provider. Any future AI capability (Phase 3) will be opt-in, explicit per action, and auditable — never granted silent access to browsing data.
Skills Runtime (planned)
PlannedA planned system for user-defined automation ('skills') that would run under explicit user grants. Not designed in detail yet; listed here so the boundary it must respect is on record before any code exists.
Interfaces- not yet defined
Will follow the same deny-by-default grant model as the PermissionService. Nothing exists today.
Extension Runtime (planned)
PlannedPlanned extension support. CEF's Chrome runtime style offers partial extension support; full Chrome-store-level support may require moving to a Chromium source derivative, a path documented in ADR-001.
Interfaces- not yet defined
Extensions will be sandboxed and permission-gated when they arrive. Nothing exists today.
Platform Adapter
In developmentIsolates OS-specific behavior — paths, process launch, windowing — behind adapters so the core stays portable. The Windows adapter is being developed and verified now; Linux and macOS layouts are architecture-ready in the build system but unverified.
Interfaces- platform adapter contract (src/platform/)
- Windows launch path: bootstrap.exe + itisyou.dll
Windows sandbox preserved via the CEF bootstrap pattern. The Linux chrome-sandbox and macOS helper-bundle patterns are wired in CMake but remain unverified until those environments are available.
Diagnostics
In developmentStructured local logging and diagnostics used as development evidence: milestone events, permission decisions, crash data. Exists so every claim about the browser can point at a verifiable record.
Interfaces- structured log sink (local files)
- progress event records
Diagnostics never leave the machine. There is no telemetry endpoint in the codebase, and crash data is not uploaded anywhere.
The engine decision
ITISYOU embeds Chromium 144.0.7559.261 via the CEF binary distribution (144.0.34+g8fc21c8+chromium-144.0.7559.261), running Chrome runtime style with the Views framework. A full Chromium source fork was rejected for now — the build environment audit showed 29.7 GB free against the 100+ GB a source checkout demands — and Electron, WebView2, and Qt WebEngine were rejected on security, platform, and currency grounds.
The decision preserves what matters most: Chromium's process model,
sandbox, and Site Isolation stay at upstream defaults. On Windows, the app
is built as a DLL launched by CEF's bootstrap.exe — the
upstream-required pattern for a fully sandboxed CEF app. The sandbox is
not disabled.
A migration path to a Chromium source derivative is documented in the ADR for the day CEF blocks a required capability.
- Integration
- CEF binary distribution
- Chromium
- 144.0.7559.261
- Runtime style
- Chrome runtime + Views
- Sandbox
- preserved (bootstrap pattern)
- Site Isolation
- upstream defaults
- Languages
- C++ / CMake
- Windows
- In development
- Linux / macOS
- Architecture-ready, unverified