A practical safety checklist
Assess the app on the platform you will use. A useful comparison covers stored files and previews, who can unlock them, permissions, remaining source copies, and recovery after device loss. A store approval or an encryption label alone does not answer all of those questions.
For NullVault, start with the security architecture, security limitations and encrypted backup design. These are NullVault Team’s product disclosures, not an independent security audit. For other apps, use the same questions and their own documentation.
What “safe” has to mean before the question is answerable
“Safe” collapses several different promises into one word. A vault app can be safe in the sense that it encrypts stored files, and unsafe in the sense that it keeps a readable thumbnail cache, or leaks filenames, or has no recovery path when you forget the credential.
Split the question before answering it. Ask what is encrypted, what authorises decryption, what remains readable while the vault is open, and what happens to your data if the app is deleted or the company disappears. Those four answers describe most of the real risk.
What a cipher name does not tell you
Seeing “AES-256” in a store listing establishes very little. The same algorithm protects everything from a well-designed vault to one that reuses a nonce, derives a key from an unsalted PIN, or stores that key beside the ciphertext it protects.
The design questions that matter sit around the cipher rather than in it: how the key is derived from what you type, where the derived key lives while the app is closed, whether filenames and previews are encrypted alongside the file, and whether altered data is detected rather than silently decrypted.
The risk moves when the vault is open
Encryption at rest describes stored vault records while the vault is locked. While you are viewing a photo, displayed or decrypted copies can exist in memory, on screen, in a screenshot, a recording, or an operating-system preview; assess those session risks separately.
This is why automatic locking and short sessions matter more than they look, and why a compromised device defeats a vault regardless of the algorithm. A vault narrows the window; it does not remove it.
Test the whole lifecycle, not the lock screen
Most evaluations stop at whether the app opens with the right credential. The failures that lose data happen elsewhere — at import, export, backup, and restore.
- Read the technical documentation and the stated limitations before installing.
- Import a non-sensitive test file, lock the app fully, and reopen it from a cold start.
- Export that file and confirm it opens intact outside the vault.
- Create a backup, restore it on a second device or after a reinstall, and open real content — not just a thumbnail.
- Review the store privacy disclosure and the permissions the app actually requests.
Permissions and disclosures are evidence you can check
A vault that requests contacts, location, or broad network access deserves an explanation. Compare what the app asks for against what its stated function needs, and treat a gap as a question rather than a verdict.
Store privacy disclosures are self-reported, so they are a starting point rather than proof. They are still useful: a declared “no data collected” label is a public commitment that can be checked against observed network behaviour.
Signals that should lower your confidence
- Marketing language like “military-grade” standing in for a documented design.
- No published limitations page, or a claim that the app protects against everything.
- No recovery documentation, or recovery that depends entirely on the vendor.
- An app ranked highly by a review that shows no evidence of hands-on testing.
- Long gaps in update history on a platform that has since changed its storage or permission model.
What no vault app can promise
No vault protects a photo that already exists somewhere else. Copies in a cloud library, a message thread, a downloads folder, or a system backup are outside its boundary and have to be handled separately.
No vault protects a device that is already compromised, and none can promise that data written to flash storage has been physically erased. An app that claims otherwise is describing marketing, not engineering.
A fictional example
Eli starts with a non-sensitive test: “Read technical documentation and limitations.” Next, Eli follows the second check: “Test import, lock, export, backup, and restore with samples.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Trusting 'military-grade' without a design
- Ranking apps without current hands-on testing
What this workflow does not change
- Encryption at rest does not protect content visible in an unlocked session.
- A vault does not control originals, exports or backups held by other apps.
- Product disclosures and a successful sample import do not replace an independent security audit.
Questions people ask
Does a calculator disguise prove security?
No. Camouflage and encryption are separate properties.