Security & privacy
This page describes the system as it is built — including the parts that are not end-to-end encrypted yet. If a claim here stops being true, the page changes.
The ledger
Life check-ins & diary E2EE, always
Mood, sleep, energy and diary text are AES-256-GCM encrypted on your device with keys only you hold. Without your keys the app refuses to write them at all — there is no plaintext mode.
Boards, goals, canvas text E2EE, opt-in
Task titles, board and column names, goal titles and canvas labels encrypt on-device once you set up encryption keys (Account & Security). Forward-only: it covers content created after setup. The honest edges are listed below.
Files in your vault Encrypted at rest
XChaCha20 envelope per object — a fresh data key for every file, wrapped by a master key. Thumbnails go through the identical seal. Honest caveat: the master keys are server-held today, so files are encrypted but not zero-knowledge; a ZK tier is designed.
Backups Encrypted, nightly
Nightly encrypted backups with a full restore drill performed end-to-end — a rehearsal, not a plan.
Auth tokens Memory + revocable cookie
Access tokens live in memory only — never localStorage. A signed HttpOnly same-site refresh cookie resumes your session; signing out revokes it everywhere, immediately.
This website No third-party code
No trackers, no analytics, no ad pixels, no font CDNs, zero external requests. The only JavaScript is a handful of tiny inline snippets — theme, scroll animations, docs navigation — all readable in the page source.
Your files: encrypted, versioned, yours
Every file in the vault is envelope-encrypted at rest: a fresh XChaCha20 key per object, wrapped by a named master key, stored in a namespace that belongs to you alone. Reads are verified against content hashes, so silent corruption is detected rather than served. Images are stripped of EXIF/XMP metadata on ingest.
Versions are immutable — restoring is a pointer flip, not a copy — so your history is auditable and reversible. Deleted files sit in trash for 30 days and are then purged from the index.
Two rights are implemented as endpoints, not policy prose: export your entire vault, and delete your namespace outright.
And the vault isn't locked in the browser: Quest Vault for desktop keeps it as a real folder on your machine — offline-first, delta-synced, with concurrent edits forked visibly instead of clobbered. Devices pair with a short code and hold their own revocable credential; the app never sees your password.
Structured data: end-to-end encrypted, with honest edges
Since July 2026, the text of your boards, goals and canvas labels encrypts on your device before it syncs — the server stores ciphertext it cannot read. Two things you should know, because you would find out anyway: it is opt-in (set up encryption keys in Account & Security) and forward-only (content created before setup stays server-readable until the migration affordance ships). And the coverage has edges we list rather than blur: canvas card bodies (rich text), sub-goal titles, project names and comments are not yet encrypted, and metadata that makes sync work — dates, positions, colours — never is. Life check-ins and diary text are stricter: always encrypted, no plaintext mode, writes refuse without keys. Underneath all of it, the same access controls hold for everything:
- Row-level security on the sync layer. Every table is filtered server-side to your identity — a subscription cannot be crafted to read another user's rows.
- Owner-guarded writes. Every mutation verifies the caller owns what it touches, in the module, not in the UI.
- Identity derived from claims. Your database identity is cryptographically derived from the auth token's issuer and subject — there is no anonymous write path.
The key model: a recovery code only you hold unwraps your root key (600k-iteration PBKDF2), which lives on each of your devices as a non-extractable browser key — set up, unlock, or forget a device in Account & Security. One consequence stated plainly: encrypted containers can't be shared with other people yet; per-recipient key wrapping is designed, not shipped.
Identity and sessions
Sign-in is OIDC against our own identity service (at id.getquest.gg) with ES256-signed tokens. Access tokens are held in memory only — never localStorage — and a signed HttpOnly refresh cookie resumes your session across reloads; signing out revokes it everywhere, immediately. Google sign-in is optional; using it tells Google that you logged in, and nothing else.
No surveillance
No third-party trackers, no analytics scripts, no ad pixels, no external font or CDN requests — on this site or in the app. This site makes zero external requests; its only JavaScript is a few inline snippets you can read in the page source.
What's still open
Honesty cuts both ways, so the current edge list: canvas card bodies, sub-goal titles, project names and comments are not yet field-encrypted; content created before key setup has no migration affordance yet; encrypted containers can't be shared; and the vault's zero-knowledge tier is designed, not shipped. This page tracks each as it lands — transport encryption everywhere and the encrypted, restore-drilled backup story already did.
Want to go deeper?
Everything above is the plain-language version, and it's the whole truth — nothing important is hidden behind jargon. But if you're an engineer (or just curious) and want the mechanism — how identity is derived, how row-level security is enforced, the vault's exact envelope format, the threat model — read the docs.