Threat model
Security guarantees, explicit limitations, metadata leakage, and requirements for applications embedding Ownfold.
Protected
The guarantees in this section apply to the browser E2EE profile:
- A database, backup, or honest-but-curious application server cannot read record content.
- AEAD authentication detects changes to ciphertext, wrapped keys, nonces, versions, vault identifiers, namespaces, record identifiers, ownership context, and encodings.
- A record copied into a different authenticated context fails to decrypt.
- A Recovery Kit plus its secret can restore a vault after browser storage is lost.
- Per-device root-key envelopes prevent the server from learning the root key during enrollment.
- Existing-device pairing verifies the complete out-of-band offer before encrypting to its public key, preventing silent recipient-key substitution by the coordination server.
- Public APIs do not expose raw root or record keys.
Trusted backend encryption profile
When a service imports @ownfold/crypto and owns the root-key handle, Ownfold still authenticates
encrypted content and context and protects persisted records from storage-only compromise. It does
not protect plaintext from the backend process, its operators, runtime instrumentation, or an
attacker who can access the service’s key secret. Those are application-controlled trust and
authorization boundaries.
Do not describe trusted backend encryption as end-to-end encryption. Keep root-key handles short-lived, store Recovery Kit material separately from its secret, restrict decrypting roles, and prevent plaintext from entering logs, traces, analytics, queues, or crash reports.
Not protected
- Malicious JavaScript, XSS, compromised dependencies, extensions, devices, or a malicious application deployment while the vault is unlocked.
- Plaintext captured before encryption or after decryption.
- Deletion, denial of service, or replay of an older complete valid envelope by the server.
- Account identity, vault existence, counts, timestamps, approximate sizes, device metadata, key versions, or access timing.
- Offline guessing when a user chooses a weak Recovery Kit password.
- Revocation cannot erase keys or plaintext already captured by a compromised device, and an offline device cannot observe revocation until it contacts the application backend again.
- Pairing cannot protect a user who transfers or approves an offer through a compromised channel, or who approves a pairing request they did not initiate.
- Automatic and cross-tab locking reduces accidental exposure time but cannot stop malicious same-origin JavaScript from suppressing the lock or reopening a device envelope.
- The non-extractable AES key prevents direct export of the locally protected X25519 private key, but malicious same-origin JavaScript can still ask Web Crypto to decrypt it while the origin is running. This is defense in depth, not protection from XSS.
Host requirements
Use a strict Content Security Policy and Trusted Types where practical. Remove unnecessary third-party scripts from vault pages. Never send plaintext to analytics, logs, crash reports, or search indexes. Pin dependencies, audit supply-chain changes, minimize clipboard use, and lock vaults when plaintext is no longer needed.
The operational controls are expanded in Host security guidance. Production integrators must complete the deployment checklist and maintain an incident-response runbook.
Losing every authorized device and the Recovery Kit or its secret permanently loses access to encrypted data. Ownfold has no master key or recovery service. See Lost access and device failure for the exact outcomes.