Client-Side Runtime CompositionTechnical Reference

This page covers the technical implementation of the browser runtime composition system: how each component works, how data changes shape as it moves through the system, how the cryptographic chain fits together, and where observable signals remain for defenders. For the product thinking and design rationale, start with the narrative.

System Overview

The system is a two-layer web application. The visible layer is a normal React application that boots, registers a service worker, and renders a public interface. The second layer is an encrypted payload that can be unlocked locally, decrypted in the browser, and rendered inside a sandboxed iframe without fetching any additional files from the network.

The visible host must be a substantial, data-heavy application in its own right. A service worker sitting idle on a simple static page would look unusual under inspection. A service worker that actively caches and serves a rich web application (the kind that works offline, sometimes called a progressive web app) is expected behaviour. The host justifies the application’s size, memory footprint, and service worker registration simply by being a credible product.

Four components make this work:

The components are organised as a monorepo with workspaces:

Execution Timeline

The system moves through ten steps from initial page load to a rendered isolated runtime. Each step is a handoff: one component finishes its job and passes the result to the next.

Representative code

These snippets illustrate three key moments in the flow. They are simplified for clarity.

// Worker registration (host app startup)
navigator.serviceWorker.register("/stealth-runtime-sw.js");

// Key derivation (controller, after trigger match)
const key = await crypto.subtle.deriveKey(
  { name: "PBKDF2", salt, iterations: 600000, hash: "SHA-256" },
  baseKey,
  { name: "AES-GCM", length: 256 },
  false,
  ["decrypt"]
);

// Fetch interception (service worker)
self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);
  if (url.pathname.startsWith("/vfs/") && volatileVfsMap) {
    event.respondWith(serveFromRAM(url.pathname));
  }
});

Component Contracts

Each component has a strict boundary: what it owns, what it produces, and what it deliberately avoids. These boundaries are what keep the system modular.

Payload Compiler

Runtime Controller

Key source files: StealthWrapper.tsx (main wrapper), useEnvironmentInput.ts (trigger hook), useDecryption.ts (decryption hook), crypto.ts (hex conversion utilities).

Runtime Service Worker

The memory-only design is deliberate. The worker never writes decrypted content to IndexedDB, Cache Storage, or any other persistent mechanism. When the worker is terminated or purged, the data is gone. This means the runtime exists only for as long as it is actively being used.

Host Application

Data Transformations

The payload changes form five times as it moves through the system. Each transformation moves the data closer to something the browser can render.

Cryptographic Design

The cryptographic chain serves two purposes: it keeps the payload unreadable until the correct trigger is supplied, and it verifies that the payload data has not been altered. The system uses standard Web Crypto API primitives throughout.

At a high level, the trigger phrase becomes a key, and that key unlocks the payload. PBKDF2 is used so the browser derives proper key material instead of treating the raw phrase itself as the key. AES-GCM is used because it provides both confidentiality (the data is unreadable without the key) and integrity (the browser can reject altered payload data rather than rendering it). Each encrypted bundle includes the small pieces of metadata the browser needs to reverse the process: a salt (randomness added during key derivation), an initialisation vector (randomness added during encryption), and an authentication tag (a check that confirms the data has not been tampered with).

Key derivation (PBKDF2)

The trigger phrase is the starting material for key derivation. Rather than using the phrase directly as an encryption key, it is passed through PBKDF2 (Password-Based Key Derivation Function 2), which turns a human-readable phrase into cryptographic key material. This adds intentional computational cost, making brute-force guessing slower, and it means the raw phrase is never used as a key directly.

Encryption (AES-256-GCM)

AES-GCM (Galois/Counter Mode) provides both confidentiality and integrity. Confidentiality means the data is unreadable without the key. Integrity means the browser can detect if the ciphertext has been tampered with, and will reject it rather than producing a corrupted result.

The encrypted bundle stores all four values together: salt, IV, authentication tag, and ciphertext. That is everything the browser needs to derive the same key and reverse the encryption.

Trigger verification (SHA-256)

The trigger phrase is stored in the source code as a hash: a one-way fingerprint produced by running the phrase through a mathematical function (SHA-256). You can produce the fingerprint from the phrase, but you cannot reverse it to recover the phrase. That means someone inspecting the application’s code would find only the fingerprint, and working out what produced it requires already knowing the answer.

On every key press, the controller tests every possible suffix of the current input buffer by hashing each one with SHA-256 and comparing the result to the stored fingerprint. This suffix search means the trigger phrase can be recognised regardless of what was typed before it.

Lifecycle States

The system moves through six states during a complete session. The transitions are deterministic: each state leads to the next through a specific event.

Two intermediate behaviours sit alongside these states:

• Conceal (blur or tab switch): The iframe overlay is hidden, but the worker retains its memory and the runtime stays loaded in the background. The system remains in the Serving state, just visually concealed.
• Reveal (trigger re-entered while concealed): The overlay becomes visible again without repeating decryption or re-hydrating the worker. The system was already Serving; it simply shows the iframe again.

Failure Modes

Each step in the execution chain has a specific failure condition. The system is designed to fail silently: a wrong trigger produces no error message, a corrupted payload is rejected cleanly, and a missing worker simply means the virtual files cannot be served.

Observable Signals

This architecture shifts where visibility sits. Visibility persists across every layer. Every capability used is a standard browser feature, and standard browser features leave traces that defenders, monitoring tools, and browser developer tools can inspect.

Inspecting in DevTools

The system can be examined directly using standard browser developer tools:

• Application panel: inspect service worker registration, activation status, and scope
• Network panel: watch for /vfs/... requests appearing after the unlock sequence, and note that responses come from the service worker rather than the network
• Memory panel: take heap snapshots while the runtime is active to see where decrypted content and hydrated objects sit in memory
• Sources panel: step through the controller and worker source to follow the unlock path

Defensive Controls

Organisations and security teams retain practical leverage over this architecture at multiple layers.

Defensive framing: This architecture moves where visibility occurs, shifting signals between network, runtime, memory, and UI layers. A layered defensive approach that watches across all these surfaces retains clear leverage.

Performance and Tradeoffs

Costs of this design

• PBKDF2 computation: key derivation adds intentional CPU work during unlock. This is a deliberate security property (slowing brute-force attacks) but it also means the unlock is perceptibly slower than a simple password check.
• Memory pressure: base64 decoding, Blob construction, and hydrating the worker’s in-memory map all consume transient memory. For large payloads this becomes a meaningful cost.
• Service worker hop: every virtual file request passes through the worker’s fetch handler, adding a processing step between the iframe’s request and the response. For small assets this is negligible; for many assets it accumulates.
• Bundle size inflation: the encrypted payload ships with the initial page load, increasing the host application’s total download size. The host must be substantial enough to justify this.

Alternatives considered