Privacy tiers — the canonical configuration, and how modes trade down

This is the spine for the privacy story. Every other doc describes a feature; this one describes the maximally-private configuration once, then defines each real-world mode as a delta from it — what it gains and, precisely, what it leaks and to whom. Read this first; the feature docs hang off it.

Honesty rule (read before quoting anything here). This page describes the ceiling — the maximal configuration, including mechanisms that are still Design. What is actually in production today is in the Status table and what you can check yourself is in Verify it yourself. Every mechanism below carries its own maturity (Production / Implemented / Design) so the ideal is never mistaken for the real.

1. The always-on foundation (every Space, live, not optional)

These are not a "tier" — they are the floor beneath every Space, live and checkable today:

• Admission gate — a gated Space refuses reads and writes without an allow-listed identity, even with the room key.
• Egress lock — the browser-visible app can reach only a published allowlist (connect-src); everything else is refused by the browser.
• Content-blind storage — the store holds only ciphertext sealed to the room key; there is no operator recovery recipient.
• Signed, reproducible build — each origin — the deployed render and the mk-holding vault/kernel — publishes a /cert.json + assets-manifest binding its exact deployed bytes to published source, which rebuilds to that hash. (Store origin + a CI rebuild-and-compare job still to come.) This is the keystone: it is what makes the claims above checkable rather than asserted.
• Key confinement (vault sandwich) — room keys live in the L1 vault + Kernel worker; the app frame is keyless, enforced by Same-Origin Policy, not app discipline. See Client architecture.

Everything in §2 layers on top of this foundation.

2. The canonical maximum — the "Maximum" tier

The highest trust level is the foundation plus all seven of the mechanisms below, each of which closes one specific leak against one specific party. They are orthogonal — independently switchable, each shutting a different door — so the "levels" in §5 are bundles of these, not a single ladder.

Foundation (always on)
  + Server attestation   → operator/cloud can't read plaintext in use
  + Client attestation   → the running client is provably the genuine build
  + Client verification  → the locks are provably enforced in YOUR browser
  + OHTTP                → the server can't see WHO (your IP) is connecting
  + Client shaping       → a network observer can't read sizes / timing / patterns
  + No notification      → no push provider learns THAT / WHEN you got a message
  + Confidential model   → the model that answers the turn can't read it either
= Maximum

The platform ships this; apps configure it. The "Maximum" above is the platform's supported capability, not an aspiration — everything except the roadmap items (client attestation and client shaping) is shipped and available to every Space. A mode (§5) is a bundle of these mechanisms; a lower mode simply omits some. Which mode the first-party Spaces app ships at is a separate, app-level concern — see The Spaces app: default configuration.

3. What the platform ships today

Mechanism-level view — the platform's status for each. (What the first-party Spaces app enables by default is a separate concern: The Spaces app: default configuration. Full product map: Status. Client-side checks: Verify it yourself.)

Everything above is Production today except client attestation and client shaping, which are Design — the gap between what ships and the full ceiling. (OHTTP is Production, off by default behind the "Hide my IP" toggle.)

4. The seven mechanism axes (orthogonal)

Each axis: the leak it closes, the party it closes it against, and its platform state.

Note — client verification comes in three forms: the self-run tool (on-demand; Verify it yourself §8), the Windows/desktop extension (continuous — pins the release + forces the CSP; Implemented), and a mobile native companion (Design). "Client-verify on" in §5 means the extension/companion (continuous) or a tool run (on-demand). This is software release-attestation — distinct from client attestation above, which proves the binary/device is genuine via hardware.

See: The attested tier, The attested client, The power-user stack, The verifier, Away notification.

5. Named modes = bundles of axes

Modes are named bundles of the §4 mechanisms — the platform supports the Maximum; a lower mode simply omits some. Names encode the trade, not a number. (Which mode the first-party Spaces app ships at is documented separately: The Spaces app: default configuration.) ● on, ○ off, ◐ Design (not built yet).

Governance overlays (regulator access, full audit trail, owner rule) are orthogonal to these privacy modes — a compliance opening is a named-recipient disclosure, not a privacy-mode step-down. Keep them on a separate axis; see Delegated authority, The owner rule. Air-gapped / on-prem deployments compose on top of any mode — see Air-gap, On-prem.

6. Feature × mode matrix

Cells: ✓ available and privacy-neutral · ✓·leak(party) available but discloses something specific · ✗ unavailable at this mode. Only rows that actually trade are shown — every other feature (posting turns, membership, recovery, offline export) is mode-invariant and simply ✓.

† The model residual. If an external model answers, the model vendor receives plaintext to compute — attestation covers the render, not the vendor. The Confidential model axis (§3–§4) closes this and is Production on the confidential (attested) tier: the render enclave's measured image routes the turn only to an attested no-log gateway into confidential-compute inference on an open-weights model, each link verifying the next (verification is transitive from the render measurement; the weights themselves are vouched by the attested stack, not measured — see the attested tier). Modes that use a frontier model still leak the turn to that vendor — that is the frontier-vs-confidential trade, chosen per room. See The double blind.

7. Opting out — what each step gains and what it leaks

Each step omits one platform-supported protection — an explicit, named trade. Read top-to-bottom as "relax one thing, gain one thing, leak one named thing to one named party."

• Maximum → Attested. Gain: the egress tools (web search / flights / places) — real external capability. Leak: each tool call's content to that named API; and OHTTP/shaping being off means the network path sees your IP, sizes, and timing. Party: the specific tool API + a network observer.
• Attested → Verified. Gain: runs on any deployment (no enclave required), lower cost. Leak: the operator + AWS can read plaintext during the render instant (server attestation off). Party: the operator + cloud. Client integrity is still verified.
• Verified → Baseline. Gain: no verifier step, frictionless. Leak: you're back to trusting the server's declaration that the locks hold, rather than confirming them; cloud connectors become available (content to the cloud). Party: yourself (trust restored) + any cloud you connect.
• Baseline → Connected. Gain: away notifications (and convenience integrations). Leak: the push provider learns that and when you received a message (content-free, but the tickle + timing). Party: Apple/Google/the push service.

8. Residual limits (the honest floor, at every mode)

No mode removes these; state them plainly so the tiers never over-reach:

• Model vendor (frontier rooms only) — a room that chooses a frontier model hands that vendor the turn's plaintext (§6 †). The Confidential model axis (§3–§4) that removes this is Production: on the confidential tier the LLM runs as confidential-compute inference (Intel TDX + NVIDIA confidential GPU) behind an attested no-log gateway the render enclave verifies in its measured image, trading a frontier model for an open-weights one (the attested tier). The residual stands only where the frontier trade is chosen.
• The endpoint / analog hole — plaintext must exist on a device for a human to use it; a compromised endpoint (keylogger, screenshot, a connector the client doesn't know about) is outside every software guarantee. Managed devices / air-gap raise this bar; software alone cannot. See Air-gap.
• Metadata — IP hidden, shape not yet. Your IP is hidden by OHTTP ("Hide my IP", Production) — no party sees both your IP and your rooms. Message sizes, timing, and access patterns remain visible to the network path until client shaping ships.
• Revocation offline — attestation/verification chains verify offline against pinned roots; revocation freshness needs connectivity.
• Availability is not privacy — the operator can refuse service; content-blindness is a claim about reading, not about guaranteeing access forever.

How this reorganizes the doc set

This page is the entry point for privacy claims. The existing docs slot under it:

• Maturity detail → Status · Client-side proofs → Verify it yourself · First-party app config → The Spaces app: default configuration
• Mechanism deep-dives → The attested tier, The attested client, The verifier, The double blind, The power-user stack
• Deployment overlays → Air-gap, On-prem, Deployment options
• Feature docs each state their mode row from §6 at the top, instead of describing privacy ad-hoc.

Update rule: when a mechanism changes state, update §3 and Status together; when a feature's disclosure changes, update its §6 row.

Machine-readable source: privacy-tiers.md · Generated 2026-08-29T18:46:30Z · build f3ff88cc · every doc in one fetch: llms-full.txt (HTML) · ← trust-model · spaces-app-defaults →