Security, Without the Slogans
What protects your tallies, what does not, and what has not been checked by anyone outside the project yet.
The Model
Content is encrypted and signed on your device. The server receives ciphertext, stores it, and passes it to your other devices. There is no administrator function that decrypts content, because the server never holds the keys.
That protects the contents of your tallies from a copy of the database, from a backup, and from the people who run the service. It does not hide the account and routing information the service needs to operate.
Seen and Not Seen
What the Service Can See
- Your account email address, kept in a protected form so sign-in mail can reach you.
- Which sign-in method you used, and a reference from that provider.
- Routing details: random identifiers for your devices, spaces and tallies, the order events arrived in, and when.
- Sizes and counts: how much encrypted data you store and how many requests you make.
- Usage counts with no account attached, and only if you turn them on in the app: for example that a tally was created, or which built-in theme was picked.
- How many accounts were created and how many sign-ins succeeded each day, as daily numbers with no account attached. The service counts these itself, whatever you choose in the app.
What It Cannot Read
- Tally names and folder names.
- Values: every count, increment and total.
- Notes and descriptions.
- The emoji you pick.
- Which theme your account uses, and the names and colors of themes you make.
The Parts
- Content Encryption. AES-256-GCM, with a fresh nonce for every item. The item's routing identity is authenticated along with it, so ciphertext moved to a different tally is refused.
- Key Derivation. HKDF-SHA-256 for deriving keys, and Argon2id for anything derived from something you type.
- Key Wrapping to a Device. A hybrid of X25519 and ML-KEM-768 in the web app. Hybrid means both must be broken to expose a wrapped key. This is a precaution about the future, not a promise about it, and each new platform will be stated here only after it is tested.
- Signatures. Every tally event is signed with Ed25519. Device keys in your key list are signed twice, with Ed25519 and ML-DSA-65.
- Sessions. A cookie the page cannot read, stored on the server only as a hash, with an origin check on every change.
- Operators. The administrative console is a separate address with passkey sign-in. It shows daily totals and its own operator records, and has no database permission on user content.
- Protected Items. A second unlock in front of chosen tallies and folders on your device. It conceals them on the screen; it is not a separate layer of encryption.
What It Does Not Protect Against
- A device that is already compromised: malware or someone with your unlocked device sees what you see.
- A changed copy of the web app. A web app is delivered by its server each time you load it, so you rely on that delivery being honest. Strict content rules limit what a page can load, but they do not remove this trust.
- Loss of every enrolled device together with your recovery method. Nobody can recover the vault then.
- A revoked device keeping what it already downloaded. Revoking stops it from syncing; the vault's keys are not changed afterward yet.
- A protected item being read by someone who can already unlock your vault and knows your passphrase, or by hostile code running in the unlocked page.
- Observation of routing information, as listed above.
What Has Not Happened Yet
The design and the code have not been through an independent security review, and the product holds no security certification. When a review happens, its scope and result will be linked from this page.
Report a Vulnerability
Use the contact form and choose Security. Include steps to reproduce, and please leave other people's content out of it. Expect an acknowledgment within three business days, and please allow a reasonable time for a fix before publishing.