Security Model
Overview
On an UnoLock Federated Node, the browser app encrypts Safe contents before sending them to the node. The node stores encrypted data and transports encrypted messages. Node administration and Safe access use separate credentials. With trusted client software, administrative access alone does not expose Safe contents.
This page explains what is encrypted, what the node stores and sees, and where the trust boundaries are.
What the browser encrypts
The bundled client encrypts these before they reach node storage or federation transport:
- vault records (notes) and files;
- message content;
- user-authored private metadata, such as subjects, labels, filenames and Space names;
- client content keys;
- Shared Space private signing keys;
- Protected Space key material.
Plaintext, decrypted metadata, content keys, private signing keys and recovery shares stay in the active client. They must never cross into the node server, logs, federation transport or storage.
As a result:
- the persisted node database and archive files alone are not enough to recover client-encrypted vault content;
- the node, its storage, and federation peers do not receive vault plaintext, file plaintext, user-authored private metadata, or client private content keys;
- a complete remote cache contains only encrypted bytes and does not grant access.
What the node stores and sees
Client-side encryption does not mean the server sees no data. To do its job, the node necessarily processes operational metadata:
- authentication verifiers;
- opaque IDs;
- object sizes and timing;
- routing hashes and queue state;
- provider state, policy flags, and retention state;
- version and integrity metadata;
- operational configuration.
Production node storage uses an encrypted SQLite (SQLCipher) database. A copy of that database file without its key does not expose address ownership or messaging relationships. Encryption at rest does not protect against a compromised running node: the running service can still see Receive Address ownership, local inbox and outbox IDs, attachment references and routing fields, and an actively compromised node can observe the routing it processes.
Federation peers can observe timing, ciphertext size, pseudonymous address-hash activity, and the onion peer they contact. See Federation.
What the node is trusted to do
The node is trusted to enforce its configured policy, resource ownership, retention, concurrency and availability. It is not trusted with vault plaintext or client private content keys.
A malicious node can deny, delay, drop, replay or substitute ciphertext. Authenticated encryption, signatures and conditional writes make unauthorized substitution detectable. Signatures prove that data is authentic, not that it is the latest version: a node that controls both the data and its history can show an authentic older snapshot. A client cannot bypass Safe scope, server policy, quota or integrity checks by constructing its own requests, and a node cannot manufacture client archive authority or Protected Space approvals.
Trust in the delivered app and the active device
Two things remain trusted:
- The app delivered from the node's HTTPS origin. The browser app is a PWA served by the node. Content Security Policy, SHA-256 cache hashes and same-origin API channels provide defense in depth, but the node's HTTPS origin remains the code-delivery trust boundary. A node that controls delivery can replace the application and service worker together. Browser updates follow the ordinary PWA lifecycle: a ready update can activate only at startup before sign-in, and an update found while the app is running waits for the next open. This does not create a trust root independent of the node.
- Your active browser and device. An authenticated client is trusted with plaintext, content keys, Contact names, Space names, sharing decisions and private signatures. A compromised browser, extension, operating system or device can access data available to that session.
Host security protects the delivered app
Because the app is delivered from your node, protecting the node host protects your users' app. See Host Security.
Admin access and user recovery material
Node administration and Safe access are separate logins with separate PINs and recovery material.
- The node administrator cannot see a Safe's PIN, plaintext or private content keys.
- The node administrator cannot reconstruct missing user recovery material. Safe users must keep their own Safe credentials and recovery material.
- Admin sign-in uses passkeys or security keys and a PIN. Admin callbacks to the node are encrypted and protected by HTTPS, WebAuthn and server-side authorization.
- The hosted-client signing key stays in the node. The admin browser authorizes signing but never receives or supplies the private signing key.
Sharing limits
- An authorized recipient can retain the keys, ciphertext and plaintext they were given.
- Shared membership is not selectively revocable. Excluding a recipient requires a new Space and keys.
See Shared Spaces Across Nodes.
Tor limits
Tor hides direct network locations and supports onion reachability. It does not guarantee delivery, latency or capacity, and it does not protect against all timing and volume analysis. Malicious relays or network observers can attempt guard discovery and traffic correlation. See Tor and the Relay.
Threats addressed
- copied databases and archive directories;
- compromised storage or federation intermediaries;
- confusion between Safes, Spaces, providers or authorities;
- request replay and delegation misuse;
- silent last-write-wins replacement of notes;
- incomplete upload, relay or cache publication;
- probing for who owns a Receive Address;
- persistent Protected Space unlock material.
What UnoLock does not claim
- That the node observes no metadata.
- That Tor makes activity untraceable or guarantees delivery.
- That shared access can be revoked from a recipient who kept the disclosed keys.
- That passing automated tests proves deployed end-to-end security.
Full reference
FAQs
Can the node operator read my notes and files?
No. The browser encrypts Safe contents before sending them to the node, and the node does not receive plaintext or client private content keys. The operator does control the node that delivers the app, which is why the delivered app and your device remain trusted.
Does the node see anything about me?
Yes. It processes operational metadata such as authentication verifiers, opaque IDs, object sizes, timing, routing hashes and queue state. UnoLock does not claim the node sees no metadata.
If I lose my Safe recovery material, can the admin restore it?
No. The node administrator cannot reconstruct missing user recovery material.
Is a stolen copy of the node database enough to read Safes?
No. The persisted database and archive files alone are not enough to recover client-encrypted vault content.
What if my own device is compromised?
A compromised browser, extension, operating system or device can access data available to that session. Keep the devices you use to open your Safe secure.