Your Data Stays Yours

That is not a marketing line. It is a design decision, and it cost us features to keep. This page explains exactly how it works, exactly what we gave up to do it, and exactly where the limits are.

Read it. Then decide if you trust us.

1 · Why we ask for your email

You might wonder why we don't just let you pick a username. Two honest reasons:

We need a way to reach you. If the service is going down, if your data is at risk, if there's a security issue you must know about — an email is the only way we can tell you.

We need a way to know you're you. If you ever write to us for help, we need one anchor that identifies your account. A username you might forget. An inbox you control is proof.

Your email is the most personal thing about you we can see. It sits in our database in plain text, alongside a little account housekeeping (your username, when you last used the app — the full list is in our Privacy Policy). Every word you write in your journal, tasks, money and notes we cannot read. We think that's a fair trade, and we'd rather tell you plainly than pretend otherwise.

We will never sell it, share it, or hand it to an advertiser. There are no trackers on this site.

2 · How your password is stored

It isn't.

We never store your password. Not encrypted, not hidden, not "securely saved somewhere." We do not have it. If someone stole our entire database tomorrow, your password would not be in it — because it was never there.

Here's what happens instead.

Hashing — the one-way door

When you type your password, your browser runs it through a hash function — a mathematical process that scrambles it into a fixed string of characters. The critical property: it only works in one direction.

Think of a fingerprint. You can match a fingerprint to a person. You cannot rebuild a face from a fingerprint. Hashing is the same: we can check that a password matches, but we can never work backwards to discover what it was.

So when you log in, we don't compare passwords. We compare fingerprints.

→ Go deeper: OWASP Password Storage Cheat Sheet

Salt — so no two fingerprints look alike

There's a weakness in plain hashing. If two people happen to choose the same password, their hashes come out identical. An attacker who spots two matching hashes learns something: these accounts share a password. Worse, attackers keep pre-computed tables of hashes for millions of common passwords, and can simply look yours up.

A salt is a random string, unique to you, mixed into your password before it's hashed. Same password, two different users → two completely unrelated hashes. The pre-computed tables become worthless overnight.

The salt itself isn't a secret. It sits in our database next to your hash. Its entire job is to make sure your fingerprint is yours alone.

Argon2id — deliberately, expensively slow

Not all hashing is equal. Some hash functions are fast — which is exactly what you don't want, because an attacker with a modern graphics card can compute billions of fast hashes per second, guessing passwords at enormous speed.

We use Argon2id, which won an international competition specifically for password hashing. It is deliberately slow and deliberately memory-hungry — every single hash must claim 19 megabytes of memory and work through multiple passes.

Think of a turnstile that takes a full second to turn. For you, logging in once, a second is nothing. For an attacker trying a hundred million guesses, that second is a wall they cannot climb.

Graphics cards are fast because they have thousands of tiny cores — but each has very little memory. By forcing every guess to demand real memory, Argon2id turns their greatest advantage into a bottleneck.

→ Go deeper: Argon2 (RFC 9106)

Pepper — the piece that isn't in the database

Salt lives in the database. If our database is stolen, the salts are stolen with it.

So we add one more ingredient: a pepper — a single secret value that is stored outside the database entirely, on the server itself, and mixed into every hash.

Think of a recipe where one ingredient is kept in a different building. Steal the recipe book, and you still cannot cook the dish.

An attacker who walks off with our entire database — every hash, every salt — still has nothing, because they don't have the pepper.

3 · How your writing is encrypted

Password storage protects your account. This section is about protecting your words — which, in a journal, is the part that actually matters.

The key never leaves your device

When you log in, your browser takes your password and derives two completely separate things from it, using two different salts:

1. A login fingerprint — sent to our server, so we can confirm it's you.
2. An encryption key — which never leaves your browser. Ever. It is not sent, not logged, not backed up. It is held in your browser only while your tab is open, and is cleared when you close it.

Because these come from different salts, the fingerprint we hold tells us nothing whatsoever about the key we don't.

We hold a photograph of your key so we can confirm it's yours. You keep the key.

What we actually store

Your journal entries are encrypted inside your browser, before a single byte travels to us, using AES-GCM — the same encryption standard used by governments and banks. What lands on our server is meaningless noise.

What we can see: your email · the date you wrote something · roughly how long it was · the shape of things, never their words (that a task is marked done, that a transaction is an expense). Full list: Privacy Policy, Section 2.

What we cannot see: every word you wrote. Your tasks. Your money notes. Your categories. Any of it.

We're stating the first list plainly because hiding it would be dishonest. Metadata — that you wrote on a Tuesday — is visible. Content is not. No system fully hides metadata, and we're not going to claim otherwise.

→ Go deeper: End-to-end encryption explained

Your notes vault: plain on your devices, encrypted on ours

Awaken Notes can live as plain markdown files in a folder on your own device, so Obsidian or your own AI tools can read and edit them, while Awaken keeps them in sync. On our server they're encrypted with your key, like everything else. 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 security review flagged it, and the same day we replaced it with encrypted storage and deleted every plain copy. We mention it because we'd rather tell you than have you find out: this page promises that we can't read your writing, and now that's true for Notes too. Details: Privacy Policy, Section 2.

Why your password can change without re-encrypting everything

There's a subtlety worth explaining, because it shows the design was thought through rather than bolted on.

Your entries aren't encrypted with your password directly. They're encrypted with a master key — a long random key generated once, when you sign up. That master key is then itself locked inside a box, and that box is what your password opens.

Your password opens a small safe. Inside the small safe is the key to the library.

Change your password, and we only need to re-lock that one small safe. Your entire journal — thousands of entries — never has to be touched.

4 · The trade-offs we accepted

Real security has a price. Anyone who tells you otherwise is selling something. Here is exactly what we gave up, and why we chose to.

🔍 Search happens on your device, not our server

Most apps search your data on their servers — which requires them to be able to read it. Ours can't. So search runs inside your browser, after your device has decrypted your entries. Slightly slower. Entirely private.

🤖 AI runs on your device, or not at all

This was the hardest trade-off, and I want to be honest about it.

An AI that reads your journal and finds patterns across your year would be genuinely useful. Every company building one sends your writing to their servers to do it.

We will never do that. Your journal will never be transmitted to any AI — not ours, not OpenAI's, not Anthropic's, not anyone's. If your data cannot leave your device, then the AI has to come to your device.

So AI features in Awaken will run locally, on your own machine, on data your browser has already decrypted. If your device can't run it, you simply don't get that feature — and that's an acceptable outcome to us. A useful feature is not worth breaking the only promise that matters.

5 · How we protect your session

Once you're logged in, your browser holds a session cookie. We've locked it down deliberately:

• httpOnly — no JavaScript on the page can read it, so a malicious script can't steal it.
• secure — it is never transmitted over an unencrypted connection.
• sameSite=Strict — other websites cannot trick your browser into using it.
• Regenerated on every login — a fresh session ID each time, which defeats a class of attack where someone plants a session ID on you before you sign in.

We also use no third-party scripts. No analytics. No advertising pixels. No fonts loaded from someone else's server. Every file this site runs comes from us — because a single third-party script is a single third party who could read your keys.

→ Go deeper: OWASP Session Management

6 · Held to a written standard — by one person

Most of what's on this page has been true since the first line of code. This section is new, and I'm proud enough of it to say so plainly: Awaken is held to a written 47-point security standard, checked against the current industry standard (OWASP's Application Security Verification Standard) and verified item by item against the actual running code — most recently on 1 October 2026. That check is also how we caught the beta-version Notes copy described in Section 3, and fixed it the same day.

To be plain about what this is: it's our own internal review. No outside security firm has audited Awaken yet. When one has, this page will say who and when.

A few things that review added, on top of everything already described above:

• Login attempts are watched per-account, not just per-address. Rate limiting alone stops one guesser at one location; this stops a distributed attacker spread across many.
• Every write to your account is rate-limited, not just login — so a bug or a hijacked session can't be used to hammer the server.
• Dependencies are scanned automatically, every week, so a newly-discovered vulnerability in a library Awaken depends on doesn't sit undiscovered.
• A public vulnerability-disclosure channel is live — a security researcher who finds a real problem can report it responsibly, in the open, standard-format: /.well-known/security.txt.

I'm one person building this, not a security department. I think that makes the standard worth holding to higher, not lower — there's no one else to catch what I miss, so the review has to actually be rigorous rather than a box-ticking exercise. Verified against the code, not just claimed on this page — the same rule Section 7 below asks of everything else here.

7 · What this means, in one paragraph

Your password never reaches us. Your encryption key never leaves your browser. Your writing arrives at our server already scrambled, and we have no way to unscramble it. If our servers were seized, hacked, or subpoenaed tomorrow, the people holding them would find only noise. The only person who can read your journal is you — and that is a fact about the architecture, not a promise about our good intentions.

Good intentions can change. Architecture doesn't.

8 · Where you can check us

We'd rather you verify than trust. Every rule and all 47 controls, in full: The Awaken Journal Standard.

• Our encryption code is public, with test vectors and an independent checker you can run yourself: github.com/Everything-Awaken/awaken-journal-security. The rest of the app's code is private for now.
• The standards we use are public: Argon2 (RFC 9106) · AES-GCM · OWASP ASVS
• Open your browser's developer tools, watch the network traffic while you write an entry, and see for yourself: what leaves your machine is unreadable.
• Found something? Report it through /.well-known/security.txt — I'd genuinely rather hear it from you first.

Don't take our word for it. Look.

Questions? help@everythingawaken.com. If it isn't resolved within 48 hours (it will be), email our founder at reet@everythingawaken.com.