1 - The Model

The Model

XRUIOS splits into permission groups, and every group is made of per-class workers. The group is how you reason about access; the worker is where the isolation actually lives.

The seven groups

Group Workers
Media Songs, MusicPlayer, MediaAlbum, Creator, MediaTagger, RecentlyRecorded
Time Calendar, Alarm, Timer, Stopwatch, Chrono
Spatial AreaManager, WorldEvents, DataManager, Geo, DeviceManager
Audio Volume, SoundEQ, ExperimentalVolume
Interface Theme, Notification, Clipboard, Note
Identity Identity
System SystemInfo, App, Processes

That's ~27 workers. Each is its own executable (XRUIOS.Worker.<Class>), launched and supervised by the Manager.

Why a worker per class, not per group

A shared library would put every class's code in one process. The permission check only guards the network boundary - it does nothing about code already loaded in memory. So a breached worker holding one big library could call any function in it, granted or not.

Instead, each worker compiles only its own class. The Songs worker literally does not contain Calendar's code. There is nothing to reach.

Cross-class calls go through the broker, never in-process. When a worker needs another class it asks the Manager, which permission-checks and routes to that worker. Same wall between workers as between apps and workers - and it's what lets an Android or macOS worker slot in later without changing any caller.

The three walls

1. Process isolation - one class per worker.
Compromise a worker and you get its class, full stop. The other 26 classes aren't in that process.

2. Password isolation - one PSK per worker.
The Manager mints a fresh 256-bit password for each worker and hands it over out-of-band at launch. Only the Manager holds it, so only the Manager can complete a worker's handshake. A leaked PSK unlocks exactly one worker. On top of that, the worker verifies the Manager's signature, so a compromised worker (which holds only the Manager's public key) can't impersonate it.

3. Key isolation - one key per worker.
Each worker's store is encrypted under a key derived from the master (HKDF(master, "xruios-worker:<name>")). The Manager can reproduce any worker's key, but each worker only ever receives its own. A breach reads that worker's data and nothing else - see 2 - Login and Keys.

How a request flows

  1. An app connects to the Manager's broker with its own app password + stable id.
  2. It asks for a capability by name.
  3. The broker checks the app's grant in XRUIOS.Permission - the encrypted {app → {capability: level}} store. Not granted means denied, before the request goes anywhere.
  4. If allowed, the broker relays it to the worker over the Eclipse channel and returns the result.

The app never learns which worker answered, never holds a worker key, and never touches the OS directly.

Threat model - what a breach actually gets you

The point of three separate walls is that breaching one doesn't cascade. Concretely:

If an attacker... They get Because
Fully compromises one worker's process Only that class's code + data No other class is loaded there (process isolation); no other key is present (key isolation)
Steals one worker's PSK The ability to talk to that one worker - if they're also the Manager The PSK authenticates the Manager↔worker link; a worker also verifies the Manager's signature, so a worker holding only the public key can't impersonate the Manager to reach siblings
Reads a worker's on-disk store Ciphertext Each store is AES-encrypted under that worker's own HKDF key, which lives only in the Manager and that worker's memory
Runs a rogue app against the broker Rejected at the handshake The broker's PSK resolver returns null for an unknown app id, so the transcript never completes
Modifies a worker binary A worker that won't start Notary Blake3-checksums the folder against a signed baseline before launch, and periodically after
Gets the machine before login Nothing decryptable The master key is sealed (Argon2-wrapped + OS-vault); no login, no keys, no worker launch

The walls are independent on purpose: code isolation survives a key leak, key isolation survives a PSK leak, and the login gate survives everything downstream being wrong, because nothing downstream has a key until a human authenticates.

Next: how login unlocks all of this - 2 - Login and Keys.