"Client-side encryption" shows up on landing pages, security whitepapers, and Reddit arguments. It sounds like a guarantee. It is really a scope statement, and the scope is often narrower than the badge implies.
This post is about threat models: who you are defending against, at which moment, with which keys held where. It complements the security page. It does not replace it.
Three questions to ask first
Before evaluating any product, write down honest answers to these:
- Who should not be able to read my content? Hackers who breach the vendor? Insiders at the vendor? A subpoena to the vendor? A thief with my unlocked laptop?
- When should it stay unreadable? Only on disk at rest, or also while the service is running and operators have privileged access?
- Who needs to read it later, and how do they get keys without me? This is where most "zero-knowledge" marketing gets quiet.
Different products optimize for different answers. None optimize for all of them at once.
Threat model: the breached server
Scenario: Attackers copy the production database.
What encrypted-at-rest protects: Data at rest on disks, often including backups. Good against a stolen drive, insufficient alone against a live application breach.
What client-side encryption protects: If keys never leave your device in usable form, the database should contain ciphertext only. Attackers get blobs, filenames maybe, timestamps, billing metadata. They do not get a button that decrypts everyone's vault.
What it does not protect: Weak passwords still fall to offline guessing given ciphertext. Metadata leaks can tell a story even when content does not. If the product also stores escrowed handoff keys for assisted delivery, those rows are a separate custody question, not covered by live-vault claims.
HeirVault's live vault is protected by end-to-end encryption and encrypts in your browser before upload. That means HeirVault stores ciphertext and cannot decrypt your live vault. That is the breached-server story we design for.
Threat model: the curious operator
Scenario: No external attacker. An employee with database access, a misconfigured log pipeline, or a support tool that was never meant to see content.
This is the gap between "we encrypt" and "we cannot read it."
If encryption happens on the server, or keys live in a vault the application can reach, operators may have technical access even when policy says they should not. Policy is not cryptography.
Client-side encryption, done seriously, means plaintext exists briefly in your browser during edit and unlock, not on the vendor's API as a routine step. The vendor's honest claim becomes: we host what we cannot interpret.
That claim has limits. Assisted handoff for beneficiaries who stay silent until release requires storing a protected handoff key and transferring it after claim. That path is not end-to-end to the beneficiary alone. Direct account enrollment and owner-shared beneficiary passwords avoid that custody. See delivery modes for the split.
Threat model: the compromised account
Scenario: Phishing, malware, or a stolen session cookie while you are signed in.
Client-side encryption does not help much here. You decrypted the vault. The attacker rides your session or watches you type.
Defenses live elsewhere: passkeys, short idle timeouts, device trust, login alerts, and not unlocking on machines you do not control. This is why "one master password" and "client-side encryption" address different parts of the stack. That objection deserves its own post.
Threat model: the coerced owner
Scenario: Someone forces you to unlock.
Cryptography assumes you will not enter your password under duress. Products that care about this edge ship duress passwords or decoy vaults. Rare need, high stakes for the people who need it.
Threat model: the lost password
Scenario: You forget the secret and lose recovery material.
Strong client-side designs cannot recover your data. That is not a bug. Any "we can reset your password and keep your files" flow implies the vendor could have read your files all along.
Encrypted-at-rest vs zero-knowledge vs end-to-end
These terms overlap in marketing and diverge in engineering.
| Claim | Rough meaning | Typical limit |
|---|---|---|
| Encrypted at rest | Data encrypted on storage media | Provider may still hold keys |
| Client-side encryption | Encryption runs on your device before upload | Must specify what is covered (live vault vs handoff vs attachments) |
| Zero-knowledge (scoped) | Provider cannot decrypt the covered scope | Often scoped to the live vault only |
| End-to-end encryption | Only participants with keys can read content | Handoffs may use different key paths |
HeirVault leads with end-to-end encryption for the live vault, then proves it: encrypts in your browser before upload, ciphertext on the server. Zero-knowledge language applies to that scope, not as a blanket badge across every delivery mode.
What still has to happen in the browser
Client-side encryption is not magic transport. It is a workflow constraint.
When you unlock, your device derives keys from your password (Argon2id in our case), decrypts a data encryption key, and uses it locally. When you save, the process reverses. Plaintext crosses the wire only if the design is wrong.
Authentication can be separate from storage encryption. HeirVault uses OPAQUE for sign-in so your password is not sent to the server for hashing. One unified secret still unlocks the vault client-side. That coupling is a product choice, not a mathematical requirement.
Where handoff breaks the simple picture
Your live vault and your beneficiary handoffs are different objects.
The live vault uses your owner keys. Each beneficiary handoff is a separate encrypted snapshot under its own handoff key, never the live vault key. That separation is deliberate: releasing one person's bundle should not expose everyone else's assignment or your ongoing workspace.
Who holds each handoff key is a product decision with real security properties:
- Invite now: beneficiary enrolls; handoff wrapped to their account key; end-to-end for that handoff.
- Shared beneficiary password: you share a unique password out of band; end-to-end for that handoff.
- HeirVault-assisted: silent until release; we store a protected handoff key and transfer after claim; not end-to-end to the beneficiary alone.
Client-side encryption of the live vault does not automatically make every handoff path zero-knowledge. Read the mode before you assume.
How to evaluate any vendor's claim
Ask for specifics, not adjectives.
- Show me the decrypt path on your servers. If they cannot describe why plaintext never appears in application memory during normal operation, assume it can.
- What metadata stays visible? Titles, sizes, recipient lists, and check-in schedules may be plaintext even when files are not.
- What happens on password reset? Recovery that preserves files without user-held secrets implies vendor access.
- What happens on beneficiary release? Escrowed keys, emailed passwords, and account enrollment are different trust models.
- What does a server breach actually expose? Honest vendors answer in ciphertext terms, not vibes.
The honest summary
Client-side encryption protects your content from a vendor who should store but not read: across breaches, insider access, and many legal requests for plaintext they do not possess.
It does not protect you from weak secrets, unlocked devices, phishing, coercion, or a handoff mode you chose that deliberately puts a key within reach before release.
Use it when the threat you care about is custody of your files on someone else's infrastructure. Pair it with good password hygiene and a delivery mode that matches who you trust, and when.
For HeirVault's full stack, cryptography choices, and mode comparison, read the security page. For the timing and false-positive side of release, read how a dead man's switch actually works.
This is general information, not legal advice. Rules differ by country and state. Talk to a qualified professional about your own situation.
