How your work is protected

This page describes what is encrypted, what the server can see, and what happens when someone loses a device. It is written for the people using the editor and for anyone reviewing it before a deployment.

The chain of keys

Each key opens the next. Only the first one is held by your browser; the rest are recovered by unwrapping, every time you open a document.

Reading the rows across: every key on the left exists on the right only in a form that needs the key above it to open. The dashed lines are that pairing, not data moving.

Three things this arrangement buys:

• The device key never leaves the browser. It is generated as non-extractable, so even the application's own code cannot read it out - only ask the browser to use it.
• Each sealed change is bound to its place. A document's id, the kind of change, and its version are authenticated alongside the ciphertext, so a change cannot be moved into another document or replayed as a later version. It fails to open rather than opening into something plausible.
• The storage key is derived, never stored. It comes from the document key by HKDF at the moment a document is opened.

What the workspace can and cannot see

Default mode

It holds ciphertext and wrapped keys. A database dump yields no titles, no diagram content, and no key that can open any of it.

It does see, by design, and records in its audit log:

• document identifiers, sizes and timestamps
• who signed in, from which provider, and when
• which documents each person read or changed, and who granted access to whom

A deployment can be configured to store documents unencrypted - for local development, or where an organization has decided the server should read content. When it is, the editor shows a warning that cannot be dismissed, because you should never have to check a configuration file to know whether your work is readable.

The relay that carries live sessions holds no key at all. A session's room name is a hash of the document key, and its traffic is encrypted with that key, so the relay sees opaque rooms and opaque bytes. It cannot tell which document, workspace, or even which deployment a session belongs to.

Three ways back in

Losing a device must not mean losing documents, and must not mean anyone else can read them either.

They differ in who they need:

Route	Needs	Typical use
Another browser	Someone with a working browser	A new laptop, a colleague joining
Recovery code	Only you	Every browser gone
Offline recovery key	The organization, not you	Someone has left; a records request

The offline key is why every document must carry a recovery wrap. A workspace that accepted documents without one would accumulate content that nobody - including the organization that owns it - could ever recover. The store refuses them rather than let that happen.

Replacing a key

Revoking a browser stops the workspace serving it, but that browser still holds the workspace key it already had. Rotating the key replaces it: each document key is re-wrapped under the new one and the document list is re-sealed. No content is re-encrypted, nothing is lost, and documents that are deleted but still within their retention period are re-wrapped too, so they stay restorable.

Anyone holding the old key can still read what they could read before - copies already made cannot be recalled - but nothing saved afterwards.

What this does not protect against

Stated plainly, because a security page that only lists strengths is not much use:

• A compromised browser. Anything your browser can open, malware running in it can open too.
• Someone you gave access to. Access is a person deciding to trust another person. Revocation stops future reads, not copies already taken.
• Traffic analysis. The workspace sees sizes, times and who touched what, even though it cannot read content.
• A lost recovery code with no devices left. That is an administrator re-grant, and the documents written under the old keys stay unreadable unless the organization's offline key recovers them.