Last updated 5 October 2026

Check our claims

For everyone

The offline test

If the app really works in your browser, it should keep working with no connection at all. Do this whole test in one tab, and don't close or reload that tab while you're offline. The app works offline only in a tab you unlocked while online, and a closed or reloaded tab needs a connection to unlock again.

1. Sign in to Notchcount while you're online.
2. Turn off your connection. Switch on airplane mode, turn off Wi-Fi, or disconnect from your network.
3. Open Stats, then its Charts tab. Your figures and charts appear as usual.
4. Open List and search for a word you know is in one of your entries. The matching entries appear.
5. Choose Add, write a short entry and choose Save. It saves.
6. Look near the top of the screen. A line beginning with the word Offline says your change will upload when you're back online.
7. Turn your connection back on. The Offline line goes away once your entry has uploaded.

What it shows: the reading, counting, charting, searching and saving all happened in your browser while it could not reach our server. We can't search your entries for you, because we can't read them. Your browser does it. The entry you saved offline waited on your device, encrypted, until the connection came back. The one part of the app that won't work offline is the map, because the map is drawn from the map provider's servers.

The "forgot password" test

1. Open the sign-in page in a new tab, using Sign in at the top of this page.
2. Choose I've forgotten my password.
3. Look at what it asks for. It wants your email address, your recovery code and a new password. There is no option to email you a reset link.

You don't need to fill it in. Reload the page to go back to the sign-in screen.

What it shows: a reset link works only for a service that can open your account without your password. We can't. We hold no key to your entries, so only something you hold can open them, which is your password, your recovery code or a passkey you have added. If you lose all of them, nobody can open the entries we hold for you, including us. That is why the recovery code matters, and why you should keep it somewhere safe (see No key escrow).

What we can see

Encryption hides what you write, not everything about your account. We, and the companies that carry data for us, can see:

• your email address
• how many entries you have, roughly how big each one is, and when each one changes
• some facts about how you sign in, such as whether two-factor sign-in is on and how many passkeys you have
• our server's logs of each request, including the internet address it came from
• our network and security provider sees every request on its way to us, encrypted entries included, but cannot open them
• the map provider sees the map areas you view

None of us can see what you write in an entry, your password or your recovery code. The Privacy Policy is the complete list, including who else handles data and how long it is kept.

For technical users

Watch what is sent

First, an entry being saved:

1. In the Notchcount tab: sign in.
2. In the developer tools: go to the Network panel.
3. In the Notchcount tab: choose Add, write an entry and choose Save.
4. In the developer tools: find the request whose method is PUT and whose address is /records/ followed by a long id. Notchcount makes that id up at random for each entry. It is not taken from what you wrote.
5. In the developer tools: open the request's body (shown under Payload or Request). You'll see a field named ciphertext, a long run of letters, numbers, - and _. There is one named nonce, a short run of the same, and baseVersion, a version number. Usually there is also epoch, a random id that is the same for every account on our server and changes only if our database is ever restored from a backup, so your devices know to upload again anything it lost. Nothing you wrote appears.
6. In the developer tools: look at the same request's headers. One is x-signature, an 86-character run of the same kind. The Notchcount tab made it with a signing key it created when you signed in and never hands out, and our server refuses a save or a deletion without a valid one, so a copied session cookie alone cannot change your entries.
7. In the developer tools: open our server's response to it. It holds only a version number and a sequence number.

Then, signing in:

1. In the Notchcount tab: with the developer tools' Network panel still open, choose Lock, and sign in again with your password.
2. In the developer tools: find the request to /auth/login/challenge. Its body holds only your email address. Its response holds your salt and your Argon2id settings. These are public values the Notchcount tab needs to work out your sign-in proof.
3. In the developer tools: find the request to /auth/login. Its body has three fields. email is your address. authKey, a 43-character run of letters, numbers, - and _, is the sign-in proof the Notchcount tab worked out from your password. sessionKey, 87 characters of the same kind, is the public half of the signing key the Notchcount tab made for this sign-in. It is not secret, and our server uses it to check the signatures on your saves. There is no password field.
4. In the developer tools: find the request to /keys/password. Its body carries the same proof, as currentAuthKey, and its response carries your data key, locked under your password as a nonce and a ciphertext that only your password can open.

If you use two-factor sign-in, a request carrying your code may come between the last two.

Look at what is stored on your device

1. In the Notchcount tab: sign in.
2. In the developer tools: go to the Application panel (in some browsers, Storage). Everything below is in this panel.
3. Open IndexedDB. You'll find a database named notchcount-cache- followed by 16 letters and numbers. It holds three stores.
4. Open records. Each row is one of your entries, or another item you have saved, such as a setting, exactly as our server stores it. A row holds its id, a version number, a sequence number (seq), a deleted flag, and a nonce and a ciphertext, runs of letters and numbers. A deleted entry keeps its id and version. In place of its content it has either nothing or a deletion marker, a sealed proof that the deletion was yours, which holds nothing you wrote.
5. Open meta. It holds one item, state, which is Notchcount's bookkeeping (what is waiting to upload, and where syncing stands), again only a nonce and a ciphertext.
6. Open pending. It holds changes not yet uploaded, in the same locked form, and is usually empty.
7. Open Local storage and Session storage for the Notchcount site, and Cache storage. You may see a few small items, none of them a key, a salt or text from an entry. For example, notchcount-lastExport holds the date of your last backup, notchcount-mapsNoticeSeen records whether you have read the map notice, and notchcount-noticeClosed remembers a notice from us that you closed. While you use a map, the map provider keeps its own items, which Notchcount clears when it locks, though your browser's ordinary cache may keep map images for a while. Just after you sign up, notchcount-signupEmail holds your email address in session storage, and it is deleted as soon as the sign-in screen has read it.

What you won't find anywhere is a key, a locked copy of your key, your salt or your Argon2id settings, so there is nothing a password guess could be tested against. Cookies are a separate list, in the Privacy Policy's cookies section.

Read the security headers

1. In a new browser tab: open the developer tools first and go to their Network panel, then load the Notchcount sign-in page, /app, in that tab.
2. In the developer tools: select the first request, the sign-in page itself, and look at its response headers.
3. In the developer tools: find Content-Security-Policy. In it, script-src 'self' 'wasm-unsafe-eval' means script runs only from the Notchcount site, with permission to compile WebAssembly, which Argon2id needs.
4. In the developer tools: find connect-src. It lists 'self' and a short list of the map provider's addresses, each ending in a specific path. Notchcount's own requests can go only to the Notchcount site and to those map paths.
5. In the developer tools: find object-src 'none', base-uri 'none', frame-ancestors 'none' and form-action 'self'. Together they mean no plugins, no change to the page's base address, no framing by another site, and forms that post only to the Notchcount site.
6. In the developer tools: find Strict-Transport-Security, a separate header. Browsers that have visited use HTTPS only.

Your browser enforces this policy. A script slipped into the Notchcount tab, or loaded from another site, would not run, and the Notchcount tab's connections (the requests its code makes, like the ones under Watch what is sent) can go only to the Notchcount site and those map paths. The policy arrives from our server with the page, though, so it cannot protect you from tampered code sent by us or our providers (see What no check can prove).

Find the fixed values

1. In the Notchcount tab: sign in, so Notchcount has loaded its encryption code.
2. In the developer tools: open the panel that lists the Notchcount tab's files (Sources or Debugger), or find them in the Network panel.
3. In the developer tools: find the file whose name starts with crypto.worker. It is the worker that does all the key work and encryption.
4. In the developer tools: search it for each of these labels. They are fixed. Each turns your password, recovery code, passkey or backup passphrase into a different key, and changing one would leave every account, or every backup file, impossible to open. They are also in the security design's fixed-values table.
   • encounters.auth.v1: your password → your sign-in proof
   • encounters.kek.v1: your password → the key that locks your data key
   • encounters.recovery-auth.v1: your recovery code → its sign-in proof
   • encounters.recovery-kek.v1: your recovery code → the key that locks your data key
   • encounters.passkey-kek.v1: a passkey → the key that locks your data key
   • encounters.export-kek.v1: a backup passphrase → the backup file's key, never a key to your account
   • encounters.prf-salt.v1: what Notchcount asks a passkey for. This one is in the Notchcount tab's main code rather than the worker, because a passkey prompt is started from there.
5. In the developer tools: search the worker for 65536. You'll find the Argon2id settings for new accounts and the minimum, each written as memoryKiB 65536, iterations 3 and parallelism 1.
6. In the developer tools: search it for 102400. You'll find the maximum of memoryKiB 102400, iterations 10 and parallelism 4.

What no check can prove

Every check on this page looks at the code your browser received this time. None of them can prove that it is the code everyone else receives, or the code you will receive next time.

The app's code comes from our server, through our hosting provider and our network and security provider, on every visit, and any of them could alter it. A tampered copy runs inside your page, where keys are unwrapped, and could send your password away before anything is encrypted. It could be sent to one person only, which nobody else would see, and it would not need to misbehave while you were watching. This is the one compromise the design cannot survive, and it is the first of our Known limits.

If something you see doesn't match what we say, please report a vulnerability.

If something you see doesn't match what we say, please tell us through the contact form, choosing Security issue.