Security & Privacy

Data is encrypted and local

SQLCipher at rest, keys in the OS secure store, hardware recovery, cloud recovery — and an honest threat model.

Encryption at rest

Your timeline, diffs and sessions are stored in local SQLite databases (recall.chdb plus one per workspace, e.g. ws_<id>.chdb) that are fully encrypted at rest with SQLCipher (AES-256). Everything is local — no cloud, no telemetry, no training on your data. Nothing leaves your machine unless you configure the optional team webhook (HMAC-signed, HTTPS).

Database key management

The database key is a random 32-byte secret, stored wrapped so it survives OS reinstalls:

Platform	Primary store
Windows	DPAPI-encrypted blob (user + machine bound)
macOS	Keychain generic-password item
Linux + recovery	AES-256-GCM wrapped with a key derived from the machine identity

There is also a hardware-wrapped recovery copy (recall.key.hw) — the key wrapped with a key derived from a machine fingerprint (HMAC-SHA256). This lets the key be recovered after an OS reinstall on the same machine.

The key is never regenerated once a database exists. Regenerating would orphan the encrypted file. If the OS key store and the hardware backup are both unavailable on an existing database, Recall fails with a clear error — it never silently creates a new key. Existing databases auto-migrate in place on first launch into the encrypted format (WAL folded → exported → atomically swapped → integrity-checked), restoring the original file on any failure.

Cross-device recovery (Stage 0)

The hardware recovery copy only survives an OS reinstall on the same machine. To recover on a formatted or replaced PC, opt into cloud recovery: Recall wraps the DB key under a key derived from a passphrase you choose (PBKDF2-HMAC-SHA256, 150,000 iterations → AES-256-GCM) and stores only the ciphertext blob.

# Enable recovery with a passphrase
recall recovery enable "a long strong passphrase"

# Build the opaque ciphertext blob to upload (e.g. POST /api/recovery/upload)
recall recovery build "a long strong passphrase"

# On a (possibly new) machine, recover the DB key from the blob + passphrase
recall recovery apply "a long strong passphrase" '{...blob json...}'

recall recovery status
recall recovery where
recall recovery disable

Privacy promise (honest): the recovery blob is opaque to the server — the server stores and returns bytes it can never decrypt. The passphrase and the plaintext DB key never leave the client; decryption happens only locally. Wrong or tampered blobs are rejected by AES-GCM authentication. There is no permanent local copy of the passphrase, and the plaintext key is never persisted in a new form — only re-encrypted wraps. The same wrapped-blob transport is what the account-linked device API (/api/recovery/*) handles for cloud backups.

Licensing security

The licensing layer (see Licensing & Plans) is designed so licenses cannot be forged or moved freely:

Licenses are Ed25519-signed by the license server — no offline forgery.
License delivery is encrypted with AES-256-GCM, keyed by an X25519 (ECDH) shared secret derived from a client ephemeral key + the server’s static public key.
Every license is bound to a machine fingerprint — an HMAC-SHA256 over the Windows MachineGuid + CPU id + volume serial (on Linux, /etc/machine-id).
The server enforces one active session per license via heartbeats (offline-first: the lock only applies while reachable).

The local agent WebSocket

Agents talk to the engine over a local WebSocket at ws://127.0.0.1:9876:

It binds to 127.0.0.1 only — loopback, intended for local agents on the same machine.
There is no authentication: any local process can issue commands. Do not run Recall on shared or untrusted machines.
Browsers are blocked: connections with a non-empty Origin header are rejected (a malicious webpage cannot roll back files on disk). Non-browser clients that send no Origin work normally.

Honest threat model

Recall’s guarantees are scoped. It protects data at rest and keeps a documented, local-first footprint. It does not claim to be:

A substitute for full-disk encryption of your OS (the key perimeter is the OS secure store; keep your device locked).
A sandbox against malware running as your user — anything that can read your process memory or OS key store can access your timeline, exactly like any local VCS or editor.
Encryption of the plaintext source files themselves — Recall watches and reads the files you edit; encryption is applied to the timeline database, not your working files.

In short: local-first by default, encrypted at rest, keys managed by your OS secure store with hardware and optional passphrase recovery — and no overclaimed cloud promises.