The problem with standard cloud photo backups
Automatic photo backup is convenient and works well — but it also uploads your most sensitive images into a system that can read them. Here is the failure mode and the fix.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
Convenience without a decision Standard photo backup is switched on once, usually during phone setup, and then never thought about again. Every image the camera produces is uploaded automatically: holiday photos, and also the photo of a prescription, the picture of a passport taken for a booking, the screenshot of a bank transfer, and the private album.
The system did exactly what it was told. The user never made a decision about the sensitive subset, because the product is designed not to require one.
Four structural issues **1. Undifferentiated upload.** Backup treats every image identically. The 3% that matters most goes to the same place as the rest.
2. Provider-readable storage. Mainstream backups use service-managed keys, so content features and safety systems can operate. Readable is the default.
3. Automated judgement. Automated content review is standard practice across mainstream clouds. Detection systems are imperfect in both directions, and an incorrect flag on a personal photo can lead to account restriction — potentially taking mail, documents and contacts with it.
4. Permanence. Deletion often means "hidden for 30 to 60 days". Copies may persist in a sync folder, a shared album, or another family member's device.
The failure people actually experience It is rarely a dramatic breach. It is:
- an account suspended by automated review, with years of memories inaccessible
- a shared album link that stayed live long after it was needed
- a family member's device showing an album that was never meant to be shared
- a photo surfacing in an automated "memories" notification at an unfortunate moment
What a better setup looks like - **Two destinations, not one.** Everyday photos to the mainstream service; sensitive personal media to a zero-knowledge vault. - **Encryption before upload.** Sealed on the device with a locally derived key, so no server-side system can act on the content. - **Encrypted metadata.** File names, album names and EXIF sealed alongside the pixels. - **Expiring shares.** Links with a passphrase and a hard cap — 24 hours at most — instead of permanent URLs. - **A real backup.** One offline encrypted copy, off-site. Cloud sync is not backup: a deletion propagates.
Reliability details that matter more than they sound For a vault to replace backup for the sensitive subset, it has to be dependable on a phone:
- resumable uploads that survive a crash, a lost signal or a closed app
- deduplication that does not require the server to read content
- integrity verification after upload, so a truncated file is caught immediately
- large-video handling through streaming rather than full download
DRIVUNO implements each of these client-side, because a vault you do not trust to finish an upload is a vault you stop using.
The one-line summary Automatic backup optimised for never losing a photo. It did not optimise for never exposing one. Use both destinations, and decide which images go where.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.