Why most "private" photo apps are not actually private
Hidden albums, PIN-locked galleries and "secure folders" often protect against a curious guest, not against the provider. Here is how to tell the difference.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
Two very different threat models "Private photo app" usually means one of two things:
- Hidden from someone holding your unlocked phone. A PIN screen, an album excluded from the main gallery.
- Unreadable by the service storing the images. Client-side encryption with keys you control.
Most apps in the category deliver the first and are marketed in language that sounds like the second. Both are legitimate; only one survives a breach, a subpoena or an automated classifier.
Five patterns that look private and are not **A PIN in front of a normal folder.** The lock is a UI state. The files sit unencrypted on disk, readable by any file browser or backup process.
"Hidden" albums in the platform gallery. Excluded from the main view, still stored and processed normally, still uploaded to the provider-readable cloud.
"Encrypted" without a stated key model. If the documentation never says where the key is derived, assume the provider holds it.
Server-side thumbnails. If the service generates previews on its side, it decrypted the image. That single detail settles the question.
Password reset that restores your library. If support can get your photos back without your passphrase, the provider can read your photos.
The one-question test *"If I forget my password, can you restore my photos?"*
- "Yes" → the provider holds a decryption path. Not zero-knowledge.
- "No, but you can use your recovery kit" → keys are on your side. Investigate further and check whether metadata is encrypted too.
The metadata trap Even genuinely encrypting apps sometimes leave file names, album names, timestamps and EXIF in clear text — sometimes to make server-side sorting easy. `IMG_2031.jpg` reveals little; `ultrasound-week-12.jpg` in an album called "Clinic" reveals a great deal. Ask explicitly.
The client integrity question nobody asks Client-side encryption depends on the client doing what it claims, every time it loads. For a web application, the code is delivered fresh on each visit. Ask whether the vendor publishes integrity information for the shipped client, so a modified build can be detected rather than trusted.
DRIVUNO ships an integrity manifest covering the client bundle and pins it locally after first use, so a substituted build is a detectable event rather than an invisible one.
What honest marketing sounds like - "The keys are derived on your device; we store ciphertext." - "We cannot recover your photos if you lose your passphrase and recovery kit." - "File names and EXIF are encrypted." - "We can see object sizes and timestamps." - "Public links expire within 24 hours at most."
Precise, slightly inconvenient statements are the signal. Unqualified superlatives are not.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.