Guide

How browser-side encryption works in Vox

What is encrypted, who holds keys, and what the design does not claim.

Technical product description. Last updated 2 November 2026.

In Vox, report content is encrypted in the browser before it is sent for storage. Vox stores ciphertext. The reporter’s case key is shown once; the server stores a hash of that key for lookup, not the key itself. Handlers decrypt on their own devices. Algorithm family: X25519-XSalsa20-Poly1305 via libsodium. Encryption does not remove identification risk from the facts written in a report.

What is encrypted?

Case content (the written concern and follow-up messages) is encrypted to the public keys of permitted recipients (handlers who were not excluded) and to a key derived from the reporter’s case key.

What does the server store?

  • Ciphertext for case content.
  • A hash of the case key for lookup (constant-time comparison).
  • Staff authentication and audit events that record who did what, not plaintext report bodies.

How does the reporter come back?

Submitting creates a 256-bit case key, shown once as word groups. That key is how the reporter returns, reads a handler question, and replies, without an email login.

Staff access

Staff sign in with a passkey and TOTP backup. Handler private keys are protected on the handler side; Vox is designed so the operator does not hold plaintext keys that can read customer case content.

Honest limits

Metadata
Operational metadata needed to run the service still exists (for example that a case was created).
Endpoints
A compromised handler device that is allowed on the case can still read decrypted content.
Identification
Unique facts in the text can identify a person even when no name is stored.

Where is data held?

Data, backups, and processing are hosted in the European Union (Frankfurt) on Render. See the security and trust hub.

Read the trust documents buyers usually request.

Security hub Data processing agreement