security

We sell a service that reaches your development machine.

So trust is not a footer link here; it is the product itself. This page is the whole of what our side can see, the anchor the threat model hangs on, and the three places where this design is weaker than a slogan would suggest.

the anchor

A stolen account is not a shell on your Mac.

Every command a viewer sends — type this, run that schedule now, start a session — is signed by that device's own key and encrypted under your account's content key, and your Mac verifies both before it injects anything. Someone who steals your login session can add a new viewer device to the account. Without an existing device scanning the pairing QR, that device holds no content key: it cannot read a session, and it cannot compose a command your Mac will accept. Our servers cannot compose one either, and that is not a policy we are promising to keep — it is a key we have never had.

visible to us

The metadata list, in full.

Two halves: what rides on an envelope, and what the control plane has to hold for an account to exist at all. The first list and the protocol specification are required to match. If one changes, both change.

on every envelope

v: envelope format version
ch: the channel: which machine and which session or handoff, by id
seq: position within that channel
ts: when the envelope was composed
class: one of stream, ctl, dispatch, ho — routing and billing, nothing finer
key_id: which generation of your master secret sealed it
nonce: random per envelope, public by necessity
ct: the sealed payload itself — we see that it is there and how many bytes it is, and nothing that is inside it
sender: which of your devices composed it, by device id
sig: Ed25519 by that device over v, ch, seq, ts, class, key_id, nonce and ct — the routing fields and the ciphertext, and not sender
connection times: when a machine or viewer was connected
byte counts: how much moved, in and out

in the control plane

account: the identity you signed in with, and your subscription state
machines: each Mac by name, platform and last seen — the same list the app shows you
devices: each phone or browser by name, platform, last seen, capabilities, and its public key
usage: the counts we bill and rate-limit from: dispatches, connect minutes, bytes, concurrent sessions

never visible to us

Content, on any day, for any reason.

Sealed with XChaCha20-Poly1305 under a secret generated on your first Mac and handed to your other devices by QR.

everything inside ct — which is every prompt, every answer, every transcript
your code, your file paths, your repository contents
handoff documents and their attachments
schedule definitions and task instructions
which claims a task holds, or what any command actually says

Under end-to-end encryption we are a dumb pipe, and abuse handling is what a dumb pipe has: rate limits, reports, and cutting a route. That limit belongs in the terms in those words — implying a moderation capability we do not have would be the dishonest alternative.

Three limits, said plainly

Every end-to-end encrypted product has edges. Naming ours is cheaper than being found out at them.

1. The browser client is a level weaker than a native one.

A web viewer runs JavaScript that we serve. A server of ours that was compromised could serve a malicious build to that browser, and no amount of client-side cryptography fixes it from inside. The mitigations are an open-source frontend you can diff, subresource integrity, and native apps in time — and none of them make the web client equal to a native one. We do not advertise it as equal.

2. Revoking a device takes a cache window, and content keys rotate later still.

Revoke a device and the cloud stops routing to it at the next entitlement refresh — normally inside a minute, because that is how long the relay caches what the control plane told it about your account. If the control plane is unreachable, the relay keeps serving the entitlements it last fetched rather than dropping every live connection, and that grace runs to 24 hours: a revocation issued in that window waits for the relay to hear about it. Separately, a device that already held the account master secret can still decrypt ciphertext it recorded before the revocation — content keys rotate lazily, not the instant a button is pressed. This is the same posture as comparable products; the difference we are trying to hold is that ours is written down here rather than left to be discovered.

3. The metadata boundary is the boundary.

The list above is not a summary of what we happen to log today — it is the list the protocol specification is required to match, and it is deliberately coarse: class distinguishes a work dispatch from other commands for billing, and nothing finer exists. The standing rule underneath it is that no payload ever reaches a log line, and that log retention is written down rather than left to whoever configures the box.

Accounts, devices and recovery

Default-off remote write is how the Mac app works today. Everything account-level below — the device roster, the recovery code, the encrypted history vault, the cloud-side audit log — is being built to the shape described here and has not shipped, which is why the section after this one is a roadmap rather than a feature list.

Reading and writing are separate grants, not two notches on one dial. On the Mac app today, an approved device can read; typing into a session needs the send capability and a per-machine write switch that is off in a fresh install, and turning one on does not turn the other on. The cloud's device tokens are being built to a finer split that never merges — read sessions, read transcript, send prompt, start session — so that a phone can be handed a transcript without being handed a keyboard.
A device list you can actually use: name, platform, last seen, capabilities, and one-press revocation for every machine and viewer — with a notification when a new device joins.
No support back door. Your recovery code is the only path back into an encrypted history vault. We cannot decrypt it for you, and an attacker cannot talk us into it either — immunity to social engineering is designed, not trained.
Losing every device is survivable, which is unusual for an end-to-end encrypted product: the source of truth was always your Mac. What is lost is the optional encrypted history vault, not the work.
An audit log of pairings, revocations, sends and dispatches — the cloud-side sibling of the one the app already keeps locally.

What we have committed to build

Listed as roadmap because that is what it is. None of it is on sale, and none of it is described above as though it already shipped.

A third-party audit of the protocol and its implementation, with the report published — the most useful answer we have to limit 1.
A published protocol specification and open-source client, so the encryption claims on this page can be checked by someone who does not work here, plus key-fingerprint comparison in the pairing screen.
security.txt and a disclosure channel, a status page and an incident-disclosure policy, self-serve export and deletion, and a named list of subprocessors.
Supply chain discipline: a signed and notarised Mac app with published checksums, pinned and audited cloud dependencies, and no long-lived cloud keys in CI.