Threat model
1. Goal
The content you capture (clips, screenshots, recordings, transcripts, notes, AI conversations) is readable only on your own devices. The relay that moves it between them, and the person operating the relay, cannot read it, at rest or in transit, even under compulsion.
2. What the relay is
A server at api.clavarius.com with an auth service (accounts, sign-in, device pairing, OAuth for connected apps) and a relay (mailboxes of sealed envelopes, presence, remote-procedure routing). The relay does not index, search, or embed anything. There is no server-side plaintext storage mode.
3. How content is sealed
- Every item is encrypted on the device with AES-256-GCM before upload. The envelope carries a version prefix; the relay stores the ciphertext as an opaque string.
- Media (images, audio) travels as sealed blobs.
- Messages between devices on the shared bus, and the arguments and results of remote-procedure calls between your devices, are sealed the same way.
- Each device has an Ed25519 identity and an X25519 key, pinned on the relay at pairing; the relay refuses a device whose proof does not match.
4. Keys: the account-password caveat
There are two key generations, and which one you are on matters.
| v1: password-derived key | v2: device key | |
|---|---|---|
| How it is made | PBKDF2 (600,000 iterations) of your account password and a random salt the auth server stores. | 32 random bytes generated on the device. |
| When | At sign-in. This is the default for a new account. | When you choose "Migrate to device key" in Settings, Sync. Existing data is re-encrypted; the old key is retained read-only. |
| Where it lives | Keychain of each signed-in device. | Keychain of each device. |
| How a new device gets it | By QR code. The paired device seals the key and its sign-in tokens with a one-time random key, uploads that ciphertext to the auth server (kept two minutes, consumed once), and shows a QR code carrying the pairing token and the one-time key. The one-time key never reaches the server. | |
| What the operator could do | At sign-in the auth server receives your password (it must, to check it). A malicious operator who captured it at that moment could derive the v1 key. Nothing stored on the server allows this later; the stored hash does not. | Nothing. The key is never derived from anything the server sees and never sent to it. |
| Recovery | Your password and the salt. | A recovery code shown once at migration (the key in base64). Save it. Without it, and without any device that still holds the key, sealed data cannot be recovered by anyone. |
Recommendation: migrate to the device key and store the recovery code somewhere that is not one of the synced devices.
5. What the operator can see
Metadata. Stated before anyone asks:
- Which account has which devices: device id, the device's own name, platform, capabilities, public keys, online state, last seen, connection stamps.
- Traffic shape: which device sent an envelope to which device, when, on which channel (channel names such as
clipboard.itemsornotes.itemsare not hidden), the kind of envelope, and its size. From this the operator can infer how often you copy things and how large they are, but not what they are. - With "keep backup" on: the size and growth of your sealed archive.
- Remote-procedure requests between your devices: source, target, plugin and method name (for example
claude.ask), timing. The payload is sealed when both devices hold the key. - IP addresses, paths and user agents in the web server log, for 14 days.
- Your email address, and the password hash.
6. Where plaintext does pass through the relay
Relay MCP: an app you connected through OAuth (for example a support desk that wants your Mac's answer) sends a question addressed to your Mac. The relay queues it while the Mac is offline, the Mac answers, the relay passes the answer back. The question and the answer are readable by the relay while they wait, because the connected app has no key of yours. The payload is erased the moment the request leaves the pending state (answered, cancelled or expired); expired rows are swept hourly. What the Mac will do with such a request is limited by policy on the Mac: read-only tools inside a scratch workspace, no clipboard access, no settings files.
7. What the operator cannot see
- The content of any clip, screenshot, recording, transcript, note or AI conversation you sync.
- Any key, on either generation, after the sign-in moment described in section 4.
- Anything on a device that is not signed in. Local use makes no network calls except the daily version check.
8. Retention on the relay
- Envelopes are deleted once every live device has fetched them (24-hour grace), and unconditionally 30 days after posting. Blobs: 30 days.
- Remote-procedure payloads: erased on completion; expired rows swept hourly.
- A device that has been away longer than 14 days is treated as new: it rebuilds its history from a live peer or from the sealed backup, not from the mailbox.
- Deleting the account purges the relay first and the auth row second; if the purge fails, the account survives and you are told.
9. Not protected
- A device that is unlocked in someone else's hands. The local database is not encrypted by the app; it relies on FileVault or iPhone data protection. Everything the app captured is readable there.
- A compromised device: malware with your user's rights reads the keychain and the database.
- Metadata: everything in section 5 can be logged, subpoenaed or leaked. Do not rely on Clavarius to hide that you have devices and that they talk.
- The AI tab: what you send there goes to the AI vendor under your own account, by their software, on their terms. Clavarius does not see it and cannot protect it.
- A cloud transcriber you opt into (a Groq key) receives your recordings in the clear.
- A malicious build of the app. Builds are signed and notarized, not reproducible; you are trusting the signer.
- The auth moment of the v1 key (section 4).
- Key loss: if every device loses the v2 key and the recovery code is gone, the sealed data is gone. This is by design and there is no support path around it.
10. Verification status
- Source: the apps and the relay are not published yet. Publishing the relay under an open license is on the plan.
- Audit: none. Until an independent audit exists, the claim is exactly this: encrypted on your devices with keys the operator never receives, protocol described here, unaudited.
- Incident record: on 29 July 2026, during development and before any public release, a token-rotation bug signed the developer's own Mac out and cleared its key, and a second pairing overwrote the phone's key; that account's synced ciphertext became unreadable and was rebuilt from the Mac's local copy. Fixes: a previous key is always retained as legacy on pairing, and sign-out no longer follows token rotation. No third party's data was involved.
11. Reporting a weakness
Write to support@clavarius.com with "security" in the subject. You will get an answer from a person, and the fix and the date will be added to this page.