Site Ring1 Sandboxing

Every site in HAVI runs in its own sandbox. When a page’s JavaScript calls window.repo.get(), it’s using a Ring1 identity specific to that site. This prevents one site from reading or writing another site’s data.

Why Site-Specific Ring1s?

On the web, same-origin policy prevents evil.com from reading cookies set by bank.com. But HPPR doesn’t have domains or cookies—it has packets in a shared repository.

Without sandboxing, any site could read //any-group/any-app/user/secrets. Site Ring1s solve this by giving each site a limited identity that can only access its own namespace.

Ring1 Naming

Each site gets a Ring1 named:

HAVI-site:<group>#<app>

The # separator is forbidden in group and app names, so there’s no ambiguity. The full name fits within the 128-byte Ring1-Name limit (max 124 bytes for group+app).

Default ACL Rules

When HAVI creates a site Ring1, it configures these ACL rules:

ACL-Rule: rdl //<group>/<app>/
ACL-Rule: rwl //<group>/<app>/user/
ACL-Rule: rwl //repo/admin/ring1/HAVI-site:<group>#<app>/
Rule Meaning
rdl //<group>/<app>/ Read and list the app’s content, but can’t modify it
rwl //<group>/<app>/user/ Full access to a user/ subdirectory for app data
rwl //repo/.../ Access to its own Ring1 config (for Ring0-Proxy requests)

A site can read its own published content but can only write to user/. This is where apps store user preferences, cached data, and local state.

How It Works

Site Ring1s are created automatically during page load:

  1. Protocol handler receives a page request
  2. Embedder calls ensure_site_ring1() to create/verify the Ring1
  3. Credentials are attached to the HTTP-like Response
  4. The Document stores them for window.repo

The Ring1 is created before JavaScript runs, so window.repo is always ready.

Enforcement

ACL enforcement happens in hpprd, not the browser. When JavaScript calls window.repo.store(packet):

  1. Browser signs the request with the site’s Ring1 credentials
  2. hpprd verifies the signature
  3. hpprd checks the ACL rules for that Ring1
  4. Request succeeds or fails based on permissions

The browser doesn’t enforce permissions—it just provides the identity. A malicious site can’t escalate privileges because hpprd validates everything server-side.

Site Signing Keys

For authenticated access to remote servers, a site needs signing keys. These enable window.route.

Storage: //repo/admin/ring1/HAVI-site:<group>#<app>/keys/|/seal/<ring0-key>

The packet includes Secret-Key: and Key-Verify: headers.

When a page loads with a configured route, HAVI checks if any of the site’s keys match the route’s Upstream-Verification-Key. If there’s a match, window.route becomes available for authenticated remote operations.

Keys are never auto-generated. Create them explicitly using ring0.pac() when setting up remote access for a site.