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 one thing about you we can actually see. It sits in our database in plain text. Everything else you create — every word you write — 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 exists in your device's memory while you're using Awaken, and vanishes when you close the tab.

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.

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

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 · 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.

7 · Where you can check us

We'd rather you verify than trust.

• Our code is open for inspection.
• The standards we use are public: Argon2 (RFC 9106) · AES-GCM · OWASP Guidelines
• 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.

Don't take our word for it. Look.

Questions? Everythingawaken@gmail.com