Scope and assumptions
This page summarizes the web application, Chromium Extension, linked-device connections, and optional Online Services. Detailed controls, implementation references, and known limitations remain in the repository documents linked below.
The protected data includes vault contents, the keys and recovery material that unlock them, and credentials used to access Online Services. Both clients rely on the browser, operating system, and application code to handle decrypted data during an unlocked session.
Local vault operations do not require Online Services. Loading the hosted web application still contacts its web host. The synchronization and managed-backup scenarios below apply when those features are used.
Main scenarios
| Attacker access | Protection | Remaining capability |
|---|---|---|
| A copied encrypted vault or backup | Reading its contents requires a valid unlock path. Password derivation adds cost to guessing. | Offline guessing remains possible. A matching vault recovery code provides a separate way to decrypt it. |
| Network traffic or a signaling/TURN server | Authenticated, application-encrypted peer sessions protect synchronized vault contents. | Connection metadata can be observed. A server on the connection path can delay or interrupt communication. |
| Control of the managed backup service | Vault snapshots are encrypted on the client before upload. | The service can see backup metadata and withhold or delete stored copies. Encryption does not guarantee availability. |
| A website using extension autofill | Credential-matching rules and extension message permissions limit access to vault operations. | The website can read credentials filled into its fields. It can also interfere with the autofill interface. |
| An authorized linked device | Peer authentication checks the established linking relationship. | The device can read records it receives and send changes. Revoking service access does not erase its existing local data. |
Access to an entire browser profile is different from possession of a backup file. The profile may also contain locally retained protection-phrase key material. That material does not unlock the vault by itself; the master password is still required. Control of a running, unlocked client can expose decrypted data; encryption at rest does not prevent that access.
Copied passwords, screenshots, and cleartext exports are outside the encrypted vault. Changing a vault secret also leaves older backup copies protected by their original secrets. The key-change comparison explains that distinction.
Client-specific boundaries
Web application
The browser runs code delivered by the application host. That host is therefore trusted to serve the intended application. If the delivered code is compromised, it can access data when the vault is unlocked. Self-hosting changes who controls delivery, but the browser still relies on the code it loads.
Operating a signaling, relay, or backup service does not by itself grant access to the client's decrypted vault.
Chromium Extension
The installed extension and its updates are trusted application code. Visited websites do not receive the extension's full vault privileges. The service worker checks messages from extension contexts, and credential-matching rules govern autofill requests. Filling a credential deliberately makes it available to the destination page.
The extension threat model documents the message permissions, autofill and passkey controls, local-session assumptions, and remaining risks. Its scope does not include the web application.
Detailed documentation
- Chromium Extension
- Repository threat model. The detailed reference for extension-specific controls and known limitations.
- Web application
- Web application threat model in
web/threat-model.md. - Related technical guides
- Cryptography describes key protection, Synchronization covers peer sessions, and Privacy and metadata describes service visibility.
See the Security page for audit status and the responsible disclosure policy for reporting vulnerabilities.