The answer, step by step
- 01Lost phone
Daily local access should require password and Face ID; synced ciphertext can be recovered on another device with the phrase.
- 02Cloud ciphertext exposure
Content should remain unreadable without the correct key, while metadata exposure must be described separately.
- 03Lost phrase
If every authorized device is also unavailable, the developer cannot recover the vault.
- 04Ciphertext and phrase together
The attacker now has the conditions for decryption, so the content cannot still be described as protected.
- 05Intentional plaintext export
Encryption cannot retract exported plaintext; the recipient's storage becomes a new risk.
How to check this claim
Create repeatable tests for every threat: an incorrect phrase must fail authentication; changed Face ID enrollment invalidates old authorization; altered ciphertext fails authentication; and a revoked recipient cannot continue reading new sharedCloudDatabase records.
See the full verification protocol →What this answer does not claim
Direct answers
Does AES-256 mean absolute security?
No. Key custody, randomness, derivation parameters, implementation flaws, device state, and user exports all affect outcomes.
Can the developer really not decrypt it?
That requires evidence from the actual key flow, cloud records, and repeatable tests—not a marketing sentence alone.
Why publish failure conditions?
Security outcomes depend on what an attacker obtains. Clear failure conditions let users configure and protect recovery material correctly.