The record around the file is also the file
It is intuitive to think of a photo as its pixels, so encryption is often described as protecting the image. But a stored item carries a name, a timestamp, a size, an album title, and often a generated preview — and each of those can disclose the thing the encryption was meant to hide.
A filename can name a person. A timestamp can place an event. A collection title can reveal a relationship. None of that requires decrypting a single byte of the image itself.
Thumbnails can expose a readable copy
Generated previews can be overlooked because they are created for legitimate performance reasons and then cached somewhere convenient. A cached thumbnail is a readable copy of the protected image, at lower resolution and potentially outside the vault's own storage.
A vault that encrypts file bodies but caches decrypted thumbnails indefinitely has moved the problem rather than solved it.
What remains observable regardless
Some metadata belongs to the operating system rather than the app, and cannot be encrypted away. Total application storage size, installation date, and access timing are visible to the platform whatever the vault does internally.
An honest design says so. The useful distinction is between metadata the app creates and controls, which should be protected, and metadata the filesystem and platform require, which should be documented rather than denied.
Audit what is visible before unlock
- List every field that appears before the vault is opened.
- Inspect thumbnails, notification text, recent-app previews, and share-sheet entries.
- Check what an export writes into the exported file's own metadata.
- Separate storage metadata the platform requires from private metadata you created.
- Document what remains observable, such as total app size or access timing.
Where the leaks usually appear
- Encrypting files but leaving descriptive album or note titles in plaintext.
- Caching decrypted thumbnails indefinitely instead of tying them to the session.
- Showing filenames in notifications or the app switcher preview.
- Claiming metadata protection hides all device activity from the platform.
What to verify in a vendor's documentation
Documentation should state whether filenames, previews, notification text, and recent-app views are protected, and what remains observable to the platform.
Those concrete details are more useful than inferring unseen security properties from a visible metadata control. Ask how the product verifies each claimed boundary.
A fictional example
Amara starts with a non-sensitive test: “List every field visible before the vault unlocks.” Next, Amara follows the second check: “Inspect thumbnails, notification text, recent-app previews, and exports.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Encrypting files but leaving descriptive titles in plaintext
- Caching decrypted thumbnails indefinitely
- Claiming metadata protection hides all device activity
What this workflow does not change
- Encrypting files but leaving descriptive titles in plaintext
- Caching decrypted thumbnails indefinitely
- Claiming metadata protection hides all device activity
Questions people ask
Can encryption hide total storage size?
Not necessarily. Device storage may still reveal how much space the app consumes.
Does NullVault claim filename protection?
Its Android value proposition includes encrypted filenames, metadata, and file contents.