You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Home: split into a Runtime-owned host and a sandboxed Home GUI capsule #176
Part of #173 (isolation plan). Depends on the design in #172.
Current source has a trusted top-level host and an opaque Home GUI. The GUI still receives app bearer fragments and mounts app frames. This task gives the host ownership of app authority, frame placement and approvals, while the GUI keeps delegation intents.
Design proposal: #172 note. Irzhy and Sasha acceptance gates implementation.
The Home GUI runs as a capsule in an opaque sandbox. Its only channel is the Runtime, and its only capability is delegation: launch, stop and broker. It never receives another app's capability. Test: the hacked-Home suite.
The host mounts every app frame. The Home GUI receives only instance IDs and drives placement, overview (Expose), the phone stage and the switcher through the host. A hacked-Home suite test proves Home never holds an app frame or capability.
First-party capsules work when their parent is the top-level host (today some assume a Home GUI parent). Each first-party capsule's smoke test passes under the host.
No other document on the host's origin runs script, and the host enforces Trusted Types (require-trusted-types-for 'script'). A test checks the CSP header on every document served from that origin.
The shared Hacked-Home regression suite in CI #180 suite enumerates every gateway/Runtime route and capability at test time; this issue supplies operation-specific attacks from hacked Home, hacked app frames and a foreign origin, with a permitted control for each allowed scope.
Activity
andersalm commentedon Oct 13, 2026
Postponed to 0.8.1: isolation S1/S2 is not a 0.8.0 blocker (Anders, 12 Oct); #170 states the real isolation.