Last updated 3 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 Notchbox 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: Sign in, at the top of this page.
2. Choose I've forgotten my password.
3. Look at what it asks for: 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: 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 Notchbox tab: sign in.
2. In the developer tools: go to the Network panel.
3. In the Notchbox 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. Notchbox 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 _; one named nonce, a short run of the same; baseVersion, a version number; and usually 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: open our server's response to it. It holds only a version number and a sequence number.

Then, signing in:

1. In the Notchbox 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: public values the Notchbox tab needs to work out your sign-in proof.
3. In the developer tools: find the request to /auth/login. Its body has two fields: email, your address, and authKey, a 43-character run of letters, numbers, - and _. That is the sign-in proof the Notchbox tab worked out from your password. 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: 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 Notchbox 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 notchbox-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: 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, with no ciphertext.
5. Open meta. It holds one item, state: Notchbox'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 Notchbox 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: notchbox-lastExport, the date of your last backup; notchbox-mapsNoticeSeen, whether you have read the map notice; notchbox-noticeClosed, a notice from us that you closed; while you use a map, the map provider's own items, which Notchbox clears when it locks, though your browser's ordinary cache may keep map images for a while; and, just after you sign up, notchbox-signupEmail in session storage, your email address, 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: 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 Notchbox 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 Notchbox 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: Notchbox's own requests can go only to the Notchbox 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': no plugins, no change to the page's base address, no framing by another site, and forms post only to the Notchbox 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 Notchbox tab, or loaded from another site, would not run, and the Notchbox tab's connections (the requests its code makes, like the ones under Watch what is sent) can go only to the Notchbox 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 Notchbox tab: sign in, so Notchbox has loaded its encryption code.
2. In the developer tools: open the panel that lists the Notchbox 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 Notchbox asks a passkey for. This one is in the Notchbox 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: 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 tell us: Report a vulnerability.

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