Our encryption ensures that no plain text or readable bookmark data—titles, URLs, or encryption passwords—are ever stored on our servers when encryption has been enabled. All encryption, hashing, and key derivation are performed entirely in your browser using the Web Cryptography API, meaning that plaintext data never leaves your device. Even if our servers were compromised, only encrypted values and cryptographic hashes resistant to brute-force attacks would be exposed.
Encryption & Hashing Methods
- AES-GCM (256-bit, 500,000 iterations) encrypts bookmark URLs and titles client-side before transmission.
- HMAC-SHA-512 (512-bit, 500,000 iterations) hashes plain-text bookmark URLs and titles, allowing us to detect modifications without knowing the underlying data's contents, previous or new state.
Key Derivation & Security
- PBKDF2 (500,000 iterations, SHA-256) derives cryptographic keys from your encryption password.
- Two separate keys are generated:
- AES-GCM encryption key (256-bit) for encrypting and decrypting bookmark data.
- HMAC-SHA-512 key (512-bit) for signing and verifying data integrity.
- Your encryption password is never stored on our servers or your device—keys are derived and securely stored locally.
- If keys are lost, you will be prompted to re-enter your encryption password to regenerate them securely.
- We enforce a minimum password length of 32 characters to ensure the security of key derivation, ensuring it is resistant to brute-force attacks.
Key Storage & Protection
- IndexedDB securely stores PBKDF2-derived keys on your device.
- These keys are non-exportable, ensuring they cannot be sent to our servers in error or extracted by malicious scripts running inside your browser (e.g., XSS attacks).
By leveraging the Web Cryptography API, our system ensures that encryption, hashing, and key derivation happen entirely in your browser, eliminating the risk of plaintext data exposure. Even in the event of a server breach, only the structure of your bookmarks would be visible—titles and URLs remain encrypted, and brute-force attacks against the stored hashes are computationally infeasible.
Encryption Setup
This section outlines how encryption is initialised, how new users and devices securely access encrypted data, and how passwords are validated without being exposed. It details the generation, storage, and protection of encryption keys and the security measures to prevent unauthorised access.
First-time Setup
- A user provides a new encryption password; this must be at least 32 characters long.
- A request is made over our API to generate a server-side salt securely, this salt is unique per organisation.
- The encryption password is processed into a cryptographic verifier using PBKDF2 (500,000 iterations, SHA-256) and the server-provided salt.
- This cryptographic verifier is sent to our API and stored with the server-generated salt.
- PBKDF2 (500,000 iterations, SHA-256) derives two cryptographic keys from the encryption password:
- AES-GCM encryption key (256-bit, 500,000 iterations) – Encrypts & decrypts bookmark data.
- HMAC-SHA-512 key (512-bit, 500,000 iterations) – Ensures data integrity and detects modifications.
- The derived keys are generated in both the client-side web app and browser extension service worker, then stored in IndexedDB as non-exportable, ensuring:
- They cannot be extracted or transmitted.
- They are only accessible within the user's browser for encryption and decryption.
- Any existing non-encrypted shared folders on our servers from your organisation are deleted, ensuring all stored data is fully encrypted. This prevents mixing encrypted and non-encrypted data, eliminating the risk of accidental information disclosure.
New User/New Device Setup
- A user is added to an encrypted organisation, and the encryption password is securely shared within the organisation. We recommend using a password manager with access controls (ACL) for secure distribution.
- When logging into an encrypted organisation, users without a stored cryptographic key in IndexedDB are prompted to enter the organisation's encryption password.
- The client requests an encryption challenge from the server. The server generates a random 16-byte challenge, stores it in the database, and returns it along with the server-side salt generated during setup.
- The client derives a password verifier using PBKDF2 (500,000 iterations, SHA-256) with the server-provided salt, then HMAC-signs the challenge using the verifier. The signed challenge is sent back to the server.
- The server retrieves the stored encryption verifier, recomputes the expected signature, and compares it with the client’s signed challenge. If they match, the password is verified; otherwise, access is denied.
- Once the encryption password has been validated, PBKDF2 (500,000 iterations, SHA-256) derives two cryptographic keys from the encryption password:
- AES-GCM encryption key (256-bit, 500,000 iterations) – Encrypts & decrypts bookmark data.
- HMAC-SHA-512 key (512-bit, 500,000 iterations) – Ensures data integrity and detects modifications.
- The derived keys are generated in both the client-side web app and browser extension service worker, then stored in IndexedDB as non-exportable, ensuring:
- They cannot be extracted or transmitted.
- They are only accessible within the user's browser for encryption and decryption.
Additional Notes:
- If an authentication attempt fails, the challenge is invalidated, and a new challenge must be generated for subsequent attempts. This prevents attackers from repeatedly testing signed responses with the same challenge.
- Encryption challenges are only valid for 30 minutes. If a challenge expires before it is used, the client must request a new challenge from the server before proceeding with authentication.
Encryption Key Storage
This section explains how encryption keys are securely stored, protected, and managed on the client side. It details where keys are stored, how they are safeguarded against extraction and unauthorised access, and the measures to prevent accidental exposure. Additionally, it covers what happens if encryption keys are lost and how users can regain access to their data while ensuring that encrypted information remains secure and inaccessible without the correct credentials.
Where Are Encryption Keys Stored?
Once derived, encryption keys are securely stored in IndexedDB within the user's browser and browser extension service worker. These keys are marked as non-exportable, meaning:
- They cannot be extracted or transmitted, preventing accidental exposure.
- They are only accessible within the user's browser, ensuring encryption and decryption happen entirely on the client side.
How Are Keys Protected?
- Non-Exportable Keys – Keys are marked as non-exportable, preventing extraction and mitigating any risks from programming errors or XSS-based attacks.
- Tied to the User’s Device – Since keys are only stored locally, they do not sync across devices. If a user logs in from a new device or clears their IndexedDB storage, they will need to re-enter their encryption password to regenerate their keys.
- No Server-Side Storage – Our servers never store or have access to encryption keys. Even if our system were compromised, an attacker could not decrypt user data without access to the user's device or encryption password.
What Happens if Keys or Passwords Are Lost?
If users lose access to their stored encryption keys (e.g., by clearing browser storage or using a new device), they can re-enter their encryption password to regenerate the keys and regain access to their data. However, if the encryption password and the stored keys are lost, the encrypted data stored on our servers will be permanently inaccessible. Since our system follows a zero-knowledge model, we do not store passwords, derived keys, or plaintext recovery data, meaning we cannot recover lost encrypted data to its plain-text version.
That said, even if encrypted data becomes inaccessible, unencrypted bookmarks would still be available on the user's local device within their browser’s native bookmark storage. While cloud-stored encrypted bookmarks would be lost, users would still retain access to their bookmarks locally, ensuring that no data is permanently erased.
How Encrypted Bookmark Data is Stored and Managed
This section explains how bookmark data is encrypted before storage, ensuring no plaintext information is ever transmitted or accessible. It details how encryption protects titles and URLs, how integrity verification detects modifications without exposing content, and how our zero-knowledge change detection mechanism ensures that bookmark updates can be tracked without revealing any sensitive data.
How Bookmark Data is Encrypted
All bookmark data sent over the network is fully encrypted before transmission, ensuring that no plaintext titles, URLs, or sensitive information ever leave the user's device. Encryption is performed client-side using AES-GCM (256-bit, 500,000 iterations), while HMAC-SHA-512 (512-bit, 500,000 iterations) is used to detect modifications.
What a Third Party Can and Cannot See
Without access to the encryption keys or encryption password, a third party cannot decrypt bookmark titles or URLs. However, specific metadata remains visible because encrypted data must remain stored and synchronised.
A third party can see:
- Bookmark hierarchy – The structure of folders and nested bookmarks remains visible.
- Bookmark count – The number of bookmarks stored in a folder is observable.
- Change detection – A third party can determine if a bookmark title or URL has changed by comparing HMAC hashes.
A third party cannot see:
- Bookmark titles and URLs – All values are encrypted using AES-GCM, making them unreadable without the encryption key. Additionally, the HMAC is non-reversible, ensuring that changes can be detected without exposing the original data.
- Previous or updated bookmark values – Only the fact that a change occurred is detectable, not what was changed.
Access Control
Our encryption model ensures that a third party, primarily us, never has access to plaintext bookmark data. However, encryption alone does not define access—permissions and user management determine who can decrypt and interact with encrypted data.
Since access control is handled separately from encryption, revoking a user’s access does not require changing the encryption password or re-encrypting data. Instead, permissions dictate whether a user can retrieve the encrypted data. If access is revoked, the user can no longer download the encrypted data.