How secure is DayBlock? My threat model, openly explained

A day planner knows a lot about you: when you see the doctor, who you meet, how you felt on a Tuesday evening. That is why DayBlock encrypts all content on your device before it leaves it. But what does that mean exactly – and where does the protection end? Here I write down openly who DayBlock protects you from, who it does not, and what is still missing. As of October 2026, DayBlock is still in testing.

Why I make this public

A threat model is an honest list: what is valuable, who might want it, what stops them – and what remains anyway. Many providers of encrypted services publish something like this. The reason is simple: good security does not depend on nobody knowing how it is built. Only the keys stay secret. If you can read how DayBlock is built, you can trust me – or prove me wrong. Both help.

A few things are deliberately not here: server addresses, operating settings and vulnerabilities that are not fixed yet. Those are added only after the fix.

What is protected

• Your content: entries, appointments, routines, habits, notes, journal, mood, people and settings. All of it is encrypted in your browser. The server only receives gibberish.
• Your password: it never leaves your device – not even when you sign in. DayBlock uses a method called OPAQUE: your browser and the server check together that you know the right password without the server ever seeing it.
• Your keys: the main key that encrypts everything is created in your browser when you sign up. The server only holds it wrapped – once with your password, once with your 24-word recovery key.

What the server still sees

It does not work entirely without information. These things are readable on the server, and I think you should know them:

• Your email address – for signing in and important emails.
• Your subscription status – whether you are testing, paying or have cancelled.
• How many records you have and when you changed them. What they say, whether it is an appointment or a note and which day it belongs to, the server does not see. The size is rounded up to fixed steps so that little can be read from the length.
• Technical logs without content, with shortened IP addresses, for at most 14 days.
• What you deliberately make public, for example a public group, and totals like “213 are joining in” – with no account behind them.

What this means day to day I also show on the page What René sees. The legal side is in the privacy policy.

Who might attack – and what happens then

Who or what	What protects	What remains
Someone steals the database or a backup	There is only encrypted content. Passwords cannot even be tried out with it, because that needs another secret that is not in the database.	Email addresses and subscription status would be visible.
The host or I myself get curious	Same picture: only encrypted content, the password never arrives.	See the last row: whoever controls the server could change the code that is delivered.
Someone listens in on the Wi-Fi	Every connection is encrypted with TLS, the browser enforces HTTPS.	That you use DayBlock is visible on the network – not what you plan.
Third-party scripts, ads, a flaw on the website	The app loads nothing from other servers and only allows its own code. App and website run under separate addresses; the website knows no keys.	A flaw in the app itself would be serious. That is what the external audit is for.
Someone guesses your password	Sign-in attempts are limited, the password is hardened with Argon2id.	A short or reused password remains the biggest risk. Two-factor sign-in does not exist yet.
Someone has your unlocked phone	“Stay signed in” is off by default. Signing out deletes the key from the device.	Whoever holds your open device sees what you see. No encryption protects against that.
Someone gets your invitation link	The key of a private group is only in the link and never goes to the server.	Whoever has the link can read and join – as with any invitation link.
You forget your password and recovery key	With the 24 words you set a new password without losing data.	Without both, nobody can get your data back – not even me. That is the price of encryption.
The delivered code is changed	Strict rules for allowed code, everything served by DayBlock itself. Planned: verifiable releases (see below).	The honest limit of every encrypted web app – more in the next section.

The honest limit: code from the browser

Every web app with end-to-end encryption has a catch: the server delivers the code that holds your keys. A server that has been taken over or has bad intentions could deliver changed code that reads along. In the browser this cannot be fully solved today – even large providers of encrypted services do not solve it on the web; they name it and also offer apps with built-in code.

That is why I advertise “Your data is encrypted on your device” – and not “I can technically never read along”. My goal is that a change can be noticed. These steps are planned for that:

1. For the beta: every delivered release can be rebuilt exactly from the source code, and I publish its checksums.
2. For the public launch: the app's code becomes publicly viewable, and an external security audit of encryption, sign-in and sync is published with a report.
3. Later: phone apps with built-in code. Then the server only delivers encrypted data, no more code.

What is still missing

So that nothing sounds nicer than it is: these points are planned, but not there today.

• Two-factor sign-in (code app or passkey).
• Verifiable releases with published checksums.
• Public source code of the app.
• The external security audit. It is mandatory before the public launch.

The building blocks in short

For everyone who wants to know exactly: DayBlock uses the well-reviewed library libsodium and no home-made cryptography. Content is encrypted with XChaCha20-Poly1305, each record with a fresh random number and bound to its ID so encrypted records cannot be swapped. Sign-in uses OPAQUE (RFC 9807) with Argon2id. Separate sub-keys for records, storage on the device and fixed IDs are derived from the main key. The recovery key is 256 bits of randomness, written as 24 words with a checksum against typos.

Found a vulnerability?

Then please write to me at hallo@dayblock.de with the subject “Security”. Describe what you found and how it can be reproduced. I will reply, fix the flaw as fast as I can and gladly name you afterwards if you like. Please only test with your own account and do not access other people's data.

When something important about DayBlock's security changes, I change this article too. The date at the top shows when I last updated it.