Devices and storage

Research, not an audit

These pages are research and development and may not match the live app. Do not treat this as an audit. Shared for testing and demo only. Please use responsibly.

This page is the device: what is sealed at rest, what the GUI saves anyway, how a second device joins, and what “stolen” means in three different cases.

Persistence mechanics: Persistence. Record list: Data structures. Platform rows: Platforms.

At rest vs in session

Store	What is in it	Unlock
Mailbox git tree	Schema stamps, public rows, sealed documents	Encryption password → Argon2id (19 MiB, t=2, p=1) → AES-256-GCM on @encrypted types
api-core session (memory)	RSA keys, protocol secrets, password, device id	Process lifetime; cleared on logout
glitr:connect (GUI)	Remotes, tokens, CORS URL — not the encryption password	Same-origin / local storage the shell uses
glitr:connect (TUI merge)	Workdir, remotes, display name — not the password	Same key name; merge leaves password as it was
glitr:profiles	Native mailbox paths and labels (cap 12)	Local files
glitr:device-id / glitr:native-device	Stable device id	Local storage / kv files
Arti data dir	Tor cache and keys	Separate from the mailbox

Sealed folders are contacts, groups, inbox, sent, secrets, protocol sessions, file transfers. GraphQL inside the running app still sees plaintext. A clone without the password sees envelopes.

Git tokens in the connect form are host credentials. The GUI persists them on SavedConnect. Optional peer-clone credentials are described in the UI as staying encrypted in your mailbox. Revoke host tokens on the host.

Web identity keys

First-run profile setup generates a real RSA-4096 identity (WebCrypto on wasm). The unlock password is not written to glitr:connect; the user retypes it each session. Git tokens may still persist there.

Three theft cases

What was stolen	Sealed mailbox	Unlocked session	Recipient cascade
Locked workdir / OPFS, no password	Envelope — Mitigated	Not present	Not present
Password typed by the user	Opens — Open	Attacker can log in as you	They have your long-term keys once they open the mailbox
glitr:connect only (no password)	Still sealed — Mitigated for unlock	Tokens/remotes may leak — Partial	Not present without the password
Unlocked running app (or an extension that can read it)	Already open	Open	Open

Forward secrecy in the Double Ratchet library model means old message keys are not derivable after a ratchet step. It does not mean a stolen laptop is safe. The verification report says the same thing.

Multi-device

One person, several devices:

1. Login calls POST /devices/ensure and registers this device.
2. Live pair uses session id __device__ and frames of kind glitrDevicePair on a data channel.
3. The DC carries a public pair_snapshot (no privateKey / protocolSecrets). Merge preview/apply uses a full local_snapshot only on this device.
4. Adopting the other profile’s identity needs that mailbox opened locally with the same password (fail closed otherwise).
5. The app can publish encrypted signaling to your own other devices so they can meet without a new QR.
6. A browser tab can route git HTTPS through a linked native device (self:*, glitrProxy).

Public mailbox rows on the DC are still a merge surface. Long-term secrets are not. Sensitive routes require a local request source — a remote DC peer should not call merge apply through dispatch_from as if they were the UI. That is a Documented boundary, not a reviewed IPC audit.

The proxy allowlist (known git hosts, known onions) is the same Partial control as on the Tor page.

Clipboard, notifications, files

Surface	Risk
Clipboard	Invite URLs, safety numbers, sometimes git credentials
Desktop notifications	Incoming-message hints when the window is unfocused
File picker	The app reads bytes you attach; live transfer sends the sealed blob
QR / camera	Ingests a pairing payload you pointed at the camera
document::eval	WebView / PWA bridge for WebRTC JS, clipboard, service worker

A hostile OS or a browser extension is outside the app. The residual page does not pretend otherwise.

Next: Residual risk — what this folder will not claim.