Preview

Security

How Sovernote protects your data — and how to report a vulnerability responsibly.

Architecture overview

Sovernote is designed around a local-first model. Here’s how data flows in each mode:

Local (offline) mode

The desktop application runs a full SQLite backend inside a Tauri-compiled binary. All data is stored in a SQLite file on your device. No network connections are made. The attack surface is limited to the local file system — physical access to your device and OS-level file permissions are your primary security boundary.

We recommend enabling full-disk encryption (FileVault on macOS, BitLocker on Windows) for protection against physical access attacks.

Cloud sync mode

When cloud sync is enabled, documents are encrypted on your device before being transmitted to our servers. The server stores and relays only ciphertext; it cannot read your content. Real-time collaboration works through encrypted Yjs CRDT update blobs relayed via the Hocuspocus WebSocket protocol.

Cryptographic design

Key derivation

Your password is never transmitted. On the client, it is processed through Argon2id (with your username as the salt) to derive a 32-byte seed. Two keypairs are derived from this seed:

  • Ed25519 — used for authentication (challenge-response signing).
  • X25519 — used for key agreement in document encryption.

The server stores only your Ed25519 public key. Your local data always remains on your device and is accessible regardless of your password. However, losing your password means losing access to cloud sync and real-time collaboration — there is no server-side reset because we don’t hold your key. We strongly recommend keeping a secure backup of your credentials.

Authentication

Login is performed via an Ed25519 challenge-response protocol:

  1. The client requests a random nonce from the server.
  2. The client signs the nonce with its Ed25519 private key.
  3. The server verifies the signature against the stored public key and issues a session token.

No password is transmitted at any point. There are no password hashes stored on the server. Session tokens are short-lived (24 hours) and tied to the issuing IP address.

Document encryption

Documents are encrypted using XChaCha20-Poly1305 with a random nonce per operation. Workspace encryption keys are derived via X25519 key agreement, meaning all members of a workspace must explicitly share the workspace key — the server cannot derive it.

Infrastructure

  • All API traffic uses TLS 1.2+ with HSTS enforced.
  • Servers are hosted in the EU (Contabo) and are accessible via SSH with key-based authentication only. Password authentication is disabled.
  • SQLite databases on nodes are backed up daily with encrypted snapshots.
  • Dependencies are pinned and audited regularly using pnpm audit and Dependabot alerts.

Responsible disclosure

We take security seriously and welcome reports from security researchers. If you discover a vulnerability in Sovernote, please disclose it to us privately before making it public.

How to report

Email security@sovernote.com with:

  • A description of the vulnerability and its potential impact.
  • Steps to reproduce or a proof-of-concept.
  • Any relevant environment details (OS, app version, etc.).

We will acknowledge your report within 2 business days and aim to provide a remediation timeline within 7 days. We request that you give us at least 90 days to resolve the issue before public disclosure.

Scope

The following are in scope:

  • The Sovernote desktop application (macOS, Windows)
  • The Sovernote mobile application (iOS, Android)
  • The Sovernote web application (sovernote.app)
  • The cloud API and Hocuspocus sync server
  • The web application at sovernote.app
  • The marketing website at sovernote.com

The following are out of scope:

  • Denial-of-service attacks against our infrastructure
  • Vulnerabilities in third-party dependencies that are already publicly known
  • Social engineering of our team members

Good faith

We will not pursue legal action against researchers who act in good faith, provide sufficient detail to reproduce and fix the issue, and do not access or modify user data beyond what is necessary to demonstrate the vulnerability.

Current status

Sovernote is currently in open beta. A full third-party security audit is something we aspire to once the project becomes economically self-sufficient. We will publish the report if and when one takes place.

Contact

Security vulnerabilities: security@sovernote.com
General enquiries: hello@sovernote.com