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 development

Chromium 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
Security boundary

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 development

The 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
Security boundary

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 development

Tab 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
Security boundary

Each tab hosts untrusted web content in its own sandboxed renderer with no privileged bindings and no filesystem or native API surface.

Workspaces

In development

Workspace 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
Security boundary

Workspace metadata is local-only. There is no sync service, no cloud component, and no account system.

Navigation

In development

Omnibox input handling: distinguishing URLs from search queries, dispatching navigations, resolving internal itisyou:// pages, and recording visits into local history.

Interfaces
  • omnibox parse and dispatch
  • per-tab navigation controller
  • internal page routing (itisyou://)
Security boundary

Web content cannot navigate a tab to the privileged itisyou://chrome host; internal pages are reachable only through trusted UI paths.

Storage

In development

Local 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
Security boundary

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 development

A 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)
Security boundary

Web content cannot bypass the service: permission prompts are resolved in the browser process, and unanswered or unsupported requests are denied.

Network Layer

In development

Chromium'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
Security boundary

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 development

Interface 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)
Security boundary

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)

Planned

A 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
Security boundary

Will follow the same deny-by-default grant model as the PermissionService. Nothing exists today.

Extension Runtime (planned)

Planned

Planned 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
Security boundary

Extensions will be sandboxed and permission-gated when they arrive. Nothing exists today.

Platform Adapter

In development

Isolates 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
Security boundary

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 development

Structured 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
Security boundary

Diagnostics never leave the machine. There is no telemetry endpoint in the codebase, and crash data is not uploaded anywhere.

ADR-001 — accepted 2026-09-02

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.

Engine facts
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