What encryption can't protect you from: a threat model for normal people

End-to-end encryption protects your data from people who don't have the key: the company running the server, a thief who copies its database, someone watching the network. It does not protect against what happens on your own device while your notes are open, against a fake page that tricks you into typing your password, or against a server that sends you malicious code. Those gaps are not flaws of one app. They are the edges of what encryption can do.

This article lists those edges honestly, shows what actually helps against each one, and gives you a five-question method for deciding which risks matter in your life.

What end-to-end encryption does protect

First, the good news. With end-to-end encryption (E2EE), your notes are encrypted on your device before they leave it, and only your device holds the key to open them. The server stores ciphertext: scrambled data it cannot read. If the database or its backups are stolen, the thief gets ciphertext. If someone intercepts the traffic, they get ciphertext.

Think of an armored truck. The cash is safe in transit and in the vault, but at the counter, where someone counts it, it is out in the open. Your device is that counter. Encryption covers the journey and the storage; it cannot cover the moment you read.

For how this works in a notes app, and exactly what the server can see, read end-to-end encrypted notes: what the server can and can't see.

What does end-to-end encryption not protect against?

Here is the whole picture in one table. The sections below explain each row.

Malware, keyloggers and browser extensions

Anything running on your device sees what you see. A keylogger records the master password as you type it. Malware can read the screen or the browser's memory. A browser extension that has permission to "read and change data on all websites" can read the text of any page you open, including your unlocked notes.

None of this breaks the encryption. It simply waits until your notes are decrypted for you and reads them then. Cappa's own security model says it plainly: malware, a browser extension, a screenshot, the clipboard or a person with access to the unlocked device bypass the protection of stored data.

What helps: turn on automatic updates for your operating system and browser, since updates close the holes malware uses (CISA and CERT Polska both put this near the top of their advice). Install apps from official stores, and review your extensions: remove any you don't use, and be wary of those that ask to read every website.

Someone using your unlocked device

If your vault (Cappa's name for the encrypted collection of your notes) is open and you walk away, anyone who sits down can read it. The same is true of a laptop left unlocked on a café table or a phone handed to a child.

Two habits cover most of this. Lock your device screen with a short timeout, and lock the vault when you step away. Cappa also locks an open vault automatically after a period without activity. On a device where you haven't chosen anything, that period is 1 hour. You can change it for each device under Settings → Security → Vault expiration, from 5 minutes to 30 days, or Never.

Remembered unlock

Typing a long master password every time can be tiring, so Cappa offers an option you have to tick yourself when you unlock: "Reopen without the password on this device." The browser then stores a key handle that the app can use to reopen the vault without your password. The key is kept in a form that page code cannot copy out as raw bytes, but any code running as the app in that browser can still use it.

How long it lasts follows the same per-device setting as auto-lock, but counted from the moment the remembered unlock was created. Unless you have changed that setting, it expires 1 hour after creation. With Never, it stays until you lock the vault or sign out; locking or signing out always removes it.

Phishing and fake login pages

Phishing means a fake message or page that imitates a real service to get your password. It is a very common way accounts are taken over, because it skips the math entirely: you hand over the secret yourself.

This matters more in Cappa than in some apps, for a simple reason. One master password both signs you in and unlocks your vault. Anyone who captures it on a fake page could sign in on the real site and open everything. Cappa does not yet offer a second sign-in factor. The protection is a long, unique password and not typing it into the wrong page.

The best defense is a password manager that fills in passwords automatically. It links each saved password to the real web address and will not fill it on a lookalike domain. CERT Polska makes the same point: if autofill suddenly doesn't work on a page where it always did, treat that as a warning. Check the address bar before you type a password anywhere. For your other accounts, especially email, use passkeys where they are offered: the FIDO Alliance describes them as phishing-resistant, because each passkey is tied to the site it was created for, so a fake page cannot collect it. We explain how they work in What are passkeys?

If someone does get in, you have a chance to notice. When Cappa's email delivery is set up, it sends you a short plain-text email, with no links and no secrets, when your master password is changed, your recovery code is replaced, a new browser is added to your account, an administrator opens a recovery window, or a recovery is completed. An email you didn't expect is a reason to act at once. These emails help you detect a takeover; they do not prevent one. Someone who controls your inbox can delete them, and a missing email does not prove nothing happened, which is one more reason to protect your email account well.

A compromised server delivering malicious code

This is the central limit of every end-to-end encrypted app that runs in a web browser, and it deserves a plain sentence: the app's code comes from the server. If an attacker takes over that server, or a code library it depends on, or sits at the point where the encrypted connection ends, they can deliver modified code. That code runs in your browser with the same access as the real app, so it can capture your master password as you type it and read your notes after they are decrypted.

Encryption cannot defend against the program that does the encrypting. Cappa's security documentation lists this scenario with the answer "nothing": code running as the app sees the password, the vault key and the content. What still holds is the stored data: a server breach alone does not reveal notes already sitting in the database. The danger is the next time you open the app.

As a user, there is little you can check yourself. It is the operator's job to keep the server, its dependencies and its deployment secure. If your stakes are very high (for example, protecting sources as a journalist), factor this in when choosing any web-based tool.

Metadata

Encryption hides what a note says, not the facts around it. The server still knows your account's email and name, how many records you have, roughly how large each one is, and when and how often you change them. Login sessions record an IP address and browser information. The email provider that delivers security notifications learns the kind and time of those account events. The EFF explains why metadata matters: patterns of activity can reveal a lot about a life even when no content is visible.

Your own exports and downloads

When you export notes as Markdown or text files, or download a backup, those files are plaintext. The same goes for an attachment you download from a note. They sit outside the vault on your disk, in your Downloads folder, maybe in a cloud sync folder. Keep them on an encrypted disk (FileVault on a Mac, BitLocker or Device Encryption on Windows), and delete copies you no longer need.

A weak master password

If someone steals encrypted data, they can try guessing your password offline, on their own hardware, with no login limit to slow them down. Cappa makes every guess expensive: each one has to run Argon2id with 64 MiB of memory. That cost multiplies the time an attacker needs, but it cannot rescue a short or common password. That is why Cappa checks a new master password in your browser before using it. The password must be 16 to 256 characters long, contain at least 5 different characters and get the top score from a strength estimator called zxcvbn-ts. The estimator compares it with bundled lists of common and leaked passwords, words and names, and looks for patterns such as keyboard rows and dates. The check never sends your password anywhere, so it only knows the passwords on those lists, not every password ever leaked. A password that passes can still be one you reused elsewhere; random and unique is what counts. See how long a master password should be.

Losing both your password and your recovery code

End-to-end encryption means nobody else holds your key. That includes Cappa. If you lose both your master password and your recovery code, no one, including the administrator, can decrypt your notes. There is no reset link, because a reset would require someone else to have the key. Why no one can reset your master password explains how the recovery code works and where to keep it.

Build a threat model in five questions

"Threat model" sounds technical, but it is just a structured way of asking what could go wrong and what is worth doing about it. The questions below are adapted from the Electronic Frontier Foundation's guide Your Security Plan (which adds a sixth: who are your allies?).

1. What do I want to protect? Be specific: a private journal, client notes, medical records, passwords you should not be keeping in notes at all.
2. Who do I want to protect it from? A curious family member, a thief, an ex-partner, an online criminal, a company, a government.
3. How likely is it? A stranger stealing your laptop is more likely than a targeted attack on a notes server. Be honest about your situation.
4. How bad would it be? Embarrassing, expensive, dangerous? Worse consequences justify more effort.
5. What am I willing to do about it? Every protection has a cost in time or convenience. Pick the ones that match the answers above.

Two quick examples show how different the answers can be. Maya keeps a personal journal on a laptop she shares with her family. Her likeliest risk is someone reading over her shoulder or opening an unlocked vault, so a short auto-lock, a screen lock and no remembered unlock matter most for her. Tom stores notes about his clients. His biggest risks are a phishing email and a breach somewhere online, so a password manager, passkeys on his email and end-to-end encryption do the heavy lifting.

A practical checklist

You don't need all of these, but most people benefit from most of them:

• Turn on automatic updates for your operating system and browser.
• Set a screen lock with a short timeout on every device.
• Use a password manager, and let it generate a long, unique master password.
• Let the password manager fill in logins. If it refuses, stop and check the address bar.
• Turn on passkeys or two-factor authentication for your email account.
• Remove browser extensions you don't use.
• Lock your vault when you step away, and choose an auto-lock time that fits the device.
• Use remembered unlock only on devices that only you use.
• Store your recovery code offline, somewhere you will find it in five years.
• Treat exported and downloaded files as readable by anyone who can open them.

FAQ

Is end-to-end encryption safe?

For what it is designed to do, yes: it is the strongest protection against breaches of the server, its backups and the network. It is not a shield for your device. Malware, phishing and an unlocked screen get around it, so it works best together with good device habits.

If the server is hacked, can the attacker read my notes?

Not from the stored data alone: the database holds ciphertext, and guessing a strong master password is impractical. The risk is what happens next. An attacker in control of a web app's server could change the code your browser loads and capture your password the next time you unlock.

Does end-to-end encryption protect me from phishing?

No. If you type your password into a fake page, the attacker has what they need to sign in as you. A password manager that autofills only on the correct address, and passkeys where available, are the practical defenses.

What is a threat model?

It is a short, personal risk assessment: what you want to protect, from whom, how likely and how serious the danger is, and what you are willing to do. The EFF's Surveillance Self-Defense guide is a good free starting point.

Can the company behind my notes app read my notes?

With end-to-end encryption, not from the stored data: they hold ciphertext, not your key. They can still see metadata, and because they deliver the app's code, you are trusting them (and their security) every time you open it.