The Awaken Journal Standard

Adversary 1 is the server owner, with root access to the host, a full database dump and every backup. Adversary 2 is an outside attacker: stolen database, stolen backup, compromised host, intercepted traffic. Adversary 3 is any AI model, ours or a vendor's. A design that stops attackers but not the server owner is rejected — encryption at rest alone isn't enough. The promise we can make: a full server compromise yields ciphertext, not your writing.

• Argon2id derives both values from your password (19 MiB memory, 2 iterations, parallelism 1 — the OWASP baseline), in your browser.
• Two independent salts: one derives the login proof sent to us; the other derives the encryption key, which is never transmitted. Nothing we store lets us derive the key.
• A pepper — a server secret kept outside the database — is mixed into the stored login proof, so the login proofs in a stolen database can't be used to test guesses. Your locked key sits beside them and can be guessed against offline, so a long password is what protects it.
• AES-GCM (your browser's built-in crypto.subtle) encrypts content and detects tampering. Every encryption uses a fresh random 12-byte IV.
• Master-key indirection: your content is encrypted with a random master key; that key is locked by your password-derived key. Changing your password re-locks one small key instead of re-encrypting everything.
• On the web, the unlocked master key is held only in your browser tab's session storage and cleared when the tab closes.

Visible to us in plain text: email, username · a one-way login proof and salts (never your password) · row IDs and timestamps · your Google/Apple sign-in ID, if you use one · when you last used the app · icon and colour choices · a push-notification address, only if you opt in · which reminders are on and at what time · the shape of your data (a task is a Frog and is done; a transaction is an expense in a given encrypted category; which journal section a line belongs to) · app settings (day cutoff hour, currency symbol, toolbar order, theme) · feedback messages you send us · a waitlist email, if you joined it · crash and usage telemetry (below).

Only ever ciphertext to us: journal entries · to-do titles and notes · money amounts, notes and category names · your own section, folder and review names · note titles and content.

Money totals and every score are computed on your device. We never receive a score or a total — only the ciphertext they're computed from.

Tier 1, always on, disclosed: crash/error reports (app version, module, device category, error message, stack trace — no request bodies, nothing decrypted) and per-account usage rows (account ID, module, action, timestamp), stored on our own server. Tier 2, opt-in, off by default: anything beyond that — patterns, scores, product analytics. Nothing exists in Tier 2 today. No session replay, ever. No device fingerprinting. The app never saves your IP address; rate limiting holds it in memory for at most an hour. Cloudflare, our network provider, carries all traffic (already encrypted end to end for your writing) under its own terms.

Today the folder works in Chrome and Edge on a computer (File System Access API); sync runs on login, logout or on demand, and imports external edits and new files back into the encrypted store. In the beta version, before 1 October 2026, an early "Awaken Server" option also kept a plain copy of those files on our server. Our own review flagged it and we removed it the same day: the server routes were deleted, the one affected folder was erased, and devices on the old setting moved to Awaken Cloud automatically. We list it here because being honest about our own history is part of this standard.

Anonymised crash reports survive with the link to your account removed — no identity, no content — so a bug bad enough to make someone leave is still visible to us. Plain note files in a folder on your own device are yours; deleting your account can't reach them.

• Every credential ever exposed during development has been rotated.
• Argon2id with OWASP baseline parameters; two independent salts; a pepper held outside the database.
• Unknown accounts get convincing fake salts, so login and signup can't reveal who has an account.
• Login proofs are compared in constant time against a same-length dummy when no account exists — no timing leak.
• Rate limits on every login and signup route, plus a per-account lockout after repeated failures that replies exactly like a wrong password.

• Cookie flags: httpOnly · secure · sameSite=Strict · __Host- prefix.
• A fresh random session ID on every login, including Google/Apple sign-in — same code path, no weaker route.
• Every session has an expiry. On the web, logging in ends every other session for that account, so a lost device is signed out the moment you log in elsewhere.
• Admin sessions are separate, expire, and are all revoked on an admin password change.

• AES-GCM via crypto.subtle; master-key indirection; the database holds ciphertext only for everything you write.
• A fresh random IV at every encryption site; none reused or hard-coded.
• Your exported backup file uses the same key derivation and cipher as login, with its own fresh salt — not a weaker side scheme.
• No decryption failure is ever logged; the crypto code contains no logging at all.

• Every data query is filtered by the account in your session, never by an ID the client sends.
• Every admin route sits behind its own admin check, and the admin console is additionally behind a separate identity gate at the network edge.
• Our automated bug-fixing agent can propose a fix but can't deploy one without a human tapping Execute; its worker uses a separate credential that no user session can reach.
• Deleting an account cascades through every table that belongs to it — verified table by table, including one gap we found and fixed (usage history).
• A written retention and deletion policy (Part 1, above).

• All database access goes through an ORM with parameterised queries; there is no raw SQL anywhere in the codebase.
• Every place the app writes HTML was audited (August 2026), and the rule since then is fixed: user text goes through safe text APIs or escaping only.
• One markdown renderer, with raw HTML disabled and dangerous links filtered.
• Request bodies are size-capped.

• A strict Content Security Policy, enforced in production: scripts, styles, images and fonts load only from our own origin; no inline scripts.
• HSTS, X-Frame-Options: DENY, nosniff and a same-origin referrer policy on every response.
• Rate limits on waitlist and invite checks, on telemetry, and on every write to your account, so a bug or a hijacked session can't hammer the server.

• Patch rules: current Node LTS; base images rebuilt monthly and on every release; dependencies scanned automatically every week, with high and critical issues fixed within 7 days; automatic operating-system security updates with a monthly review.
• Nightly backups are encrypted on the app server before they leave it, so the backup machine only ever stores ciphertext. Restore has been proven by actually restoring, not by inspecting files.
• The pepper is backed up separately, under its own passphrase.
• A written incident-response plan. Not yet done, stated plainly: a full restore drill onto a rebuilt server and a rehearsal of the incident plan — both scheduled before our first app test build.

• No third-party scripts, fonts or CDNs — every file the app runs comes from us, because one third-party script is one third party who could read your keys.
• The service worker only delivers notifications; it caches nothing, so there's nothing sensitive in it to leak.
• A public vulnerability-disclosure channel: security.txt.

• The server writes almost nothing to its logs, and never request bodies, headers or anything decrypted — there's no path for your writing or keys to reach a log.
• Dependency versions are locked and committed.