This page describes what Verden actually does with your data, in enough detail to be checked rather than believed. It is written against the shipping code and is kept in step with it. Where a protection stops, that is said.
1. What the encryption is
Every record is encrypted on your device with AES-256-GCM, using your Vault Encryption Key. Only Apple's CryptoKit primitives are used; nothing cryptographic is written by hand. Every seal uses a fresh random nonce.
The Vault Encryption Key is generated once, on the device, at 256 bits. It is never written to disk in the clear, never placed in `UserDefaults`, never sent to iCloud, and never logged. It lives in memory only while your vault is unlocked. It is stored only wrapped, inside key envelopes.
2. The three ways in
A key envelope is your vault key encrypted under a wrapping key. There are three, and they are independent.
The device envelope — ordinary unlocking. A random 256-bit device key is held in the Keychain as when unlocked, this device only, so it is never included in a backup and never restored onto another device. Reading it requires Face ID, Touch ID or your passcode. Because that protection rests entirely on the device credential, Verden refuses to create a vault on a device with no passcode and says why, rather than quietly falling back to something weaker.
The recovery envelope — a new device. A 240-bit Master Recovery Phrase is generated with the system random source and shown to you as twelve groups of four characters. The wrapping key is derived from it with HKDF-SHA256 and a random salt. The phrase itself is stored nowhere. Regenerating it deletes the previous envelope everywhere, so the old phrase then opens nothing.
Backup codes — single use. Eight independent 100-bit codes, each with its own salt and its own envelope. Redeeming one marks it consumed locally and in iCloud, and the envelope is deleted, so a used code stops working on every device.
3. What iCloud holds
If sync is on, iCloud holds ciphertext, opaque identifiers, record kinds, versions and timestamps — in your own private database, under your Apple ID. Apple cannot read the content. Neither can we; we have no access to that database at all.
We will not describe this as "zero knowledge", because that would be inaccurate: an observer of the iCloud zone can see how many records exist and when they changed, even though they cannot see what any of them says. That is metadata, and it is the honest limit of the design.
4. Recovery Capsules
A Recovery Capsule is a file you can hand to someone or store away from your device. It is sealed with its own 200-bit key, shown once, stored nowhere by Verden, and unrelated to your vault key.
Nothing readable sits outside the sealed payload — no service name, no address, no note, no file name. The header is bound as authenticated data, so editing it breaks the seal rather than changing what opens. A capsule file on its own is inert.
What goes into a capsule is chosen per capsule. Recovery addresses and phone numbers are off by default; including live secret material requires a separate confirmation and a fresh authentication.
5. Password AutoFill
The autofill extension runs inside whatever app asked for a password, and that app is not trusted. The design assumes the extension can be attacked, and bounds what sits behind it.
It is given a separate store, not the vault: one record per account that has a password, five fields each. Its key is derived from the vault key with HKDF — reading it does not yield the vault key — and is held behind a user-presence check, so every fill needs Face ID, Touch ID or the passcode. A silent background read returns nothing.
Out of reach of the extension, by construction: the vault key, the recovery map, the Master Recovery Phrase, backup codes, seed phrases, private keys, documents, notes, attachments, device passports, plans, contacts, and every account with no password stored.
The feature is off until you turn it on, and turning it off deletes both halves.
Where this stops: if you are shown a look-alike domain and pick a credential for it anyway, autofill will fill it. The system reports the requesting domain and Verden shows it; recognising it is a judgement you make.
6. On the screen
The app relocks on a timeout you choose and always after launch. Secrets stay concealed even inside an unlocked session; revealing, copying, exporting or deleting each require a fresh check. A revealed value re-conceals itself after 30 seconds, and the clipboard is cleared on the interval you choose — thirty seconds, a minute, two minutes, or never, if you decide that is what you want.
While the app is not in the foreground it is covered, so the app-switcher snapshot holds nothing — a setting that is on unless you turn it off. While iOS reports active screen recording, views carrying secrets hide themselves.
Where this stops: iOS gives an app no way to prevent a screenshot, and no way at all to stop a camera pointed at the screen. Verden does not claim otherwise.
7. What leaves the device
Two things, and only if you allow them.
iCloud, when sync is on: ciphertext, opaque identifiers and timestamps, over Apple's own transport. Even a successful attack on that transport yields ciphertext, because the payload was already encrypted before it was handed over.
A logo request, when Load service logos is on: one domain, to a cache we run — and, if that cache has nothing, to DuckDuckGo's favicon service. No account data, no identifier, no vault content. It does tell whichever host answers which service a record of yours concerns, which is why the switch exists and why the Privacy Policy says so rather than burying it.
Nothing else. There is no telemetry, no crash reporter, no attribution and no advertising identifier — and no third-party SDK of any kind is linked into the app, so there is no vendor who could add one in an update we did not read. The whole dependency list is Apple's own frameworks.
8. What this design does not survive
A device with malware running as root, or an unlocked device in someone else's hands with your face or passcode. Once the vault is unlocked, its contents are readable by definition — that is what unlocking means. Verden shortens the window with a relock timeout, concealed values and a fresh check before each reveal, but it cannot defend a device that is already lost while open.
9. What Verden will not claim
- It cannot read Apple Passwords, list your passkeys, scan your device for accounts, or check with a service whether two-factor is on. Everything in the Readiness score comes from what you entered or confirmed.
- It cannot prevent screenshots.
- It cannot detect that something has happened to you. The digital legacy plan is handed over deliberately; nothing releases on a timer.
- Travel Mode hides categories on the device it was switched on. It deletes nothing and changes nothing on your other devices.
- It cannot recover a lost Master Recovery Phrase. There is no escrow, no backdoor and no support procedure that can substitute for it.
- It holds seed phrases and private keys — behind an explicit tap, never in a form that opens by default. It is not a hardware wallet: a phrase kept on a phone is only as safe as the phone.
10. Reporting something
If you believe you have found a vulnerability, write to alexblessingx@gmail.com with enough detail to reproduce it. Please give us a reasonable period to fix it before publishing. There is no bounty programme; there is a developer who will read it and answer.