← Blog
Private photos8 min read

iCloud vs Google Photos vs encrypted storage: a privacy comparison

A factual comparison of key custody across iCloud Photos, Google Photos and zero-knowledge storage — what each can technically access and what that means for private albums.

Try it in one click.

Three private surfaces. Same zero-knowledge architecture.

Compare custody, not feature lists All three options encrypt data in transit and at rest. The meaningful difference is who can decrypt, and under what conditions. That single variable determines what is technically possible for the provider, for an attacker who breaches it, and for anyone serving legal process.

The table | Dimension | iCloud Photos (standard) | Google Photos | Zero-knowledge storage | | --- | --- | --- | --- | | Key custody | Apple-managed for standard protection; Apple documents an optional advanced mode that moves more categories to end-to-end | Google-managed | Derived on your device | | Provider can decrypt content | Yes under standard protection | Yes | No | | Server-side content features | Some on-device, some server-side | Extensive server-side | On-device only | | Response to legal request | Can include readable content for provider-decryptable categories | Can include readable content | Ciphertext only | | Password reset restores library | Yes | Yes | No — recovery kit only | | File names and EXIF | Handled as service metadata | Handled as service metadata | Encrypted as content |

Read the first two columns as descriptions of well-engineered mainstream products, not as failures. Both companies publish their models; neither claims end-to-end encryption for everything by default.

Apple's advanced option, fairly stated Apple documents an optional setting that extends end-to-end encryption to additional iCloud categories, including photos. Where a user enables it, Apple states it cannot access the data, and account recovery shifts to user-held mechanisms. That is a genuine improvement in custody, and it is opt-in, Apple-ecosystem-bound, and it changes the recovery model in the same way any zero-knowledge design does.

Google's model, fairly stated Google Photos is built around server-side understanding of image content. Search by object, face grouping, memories, and storage-saving recompression all require plaintext access. Google documents strict internal controls, but the capability is inherent to the product.

Where a dedicated zero-knowledge vault differs It is not trying to be your everyday gallery for every photo you take. It is trying to be the place where a defined subset lives: private albums, document scans, medical images, anything you would not want an automated system to classify. Because it does no server-side content processing, it can encrypt file names and metadata as aggressively as pixels.

How to combine all three sensibly 1. Keep the platform gallery for everyday photos and family sharing. 2. If you are Apple-only, enable the advanced protection option; it is a meaningful upgrade with a recovery trade. 3. Put the genuinely sensitive subset in a cross-platform zero-knowledge vault, so the guarantee does not depend on staying inside one ecosystem. 4. Keep one offline copy of the irreplaceable images. Encryption is not backup.

The question to keep asking Not "is this company trustworthy?" — most are — but "if it stopped being trustworthy tomorrow, what would change for my photos?" With provider-held keys, everything. With keys on your device, nothing.

The honest comparison
iCloud Drive

End-to-end only when Advanced Data Protection is enabled. Default keeps some keys server-side.

Zero-knowledge
Client-side encryption
Provider cannot decrypt
No plaintext analysis
User-controlled keys
DRIVUNOYou

Encrypted on your device before upload (Argon2id + X25519 + XChaCha20-Poly1305).

Zero-knowledge
Client-side encryption
Provider cannot decrypt
No plaintext analysis
User-controlled keys
The honest comparison
Google Drive

Provider-managed encryption. Content accessible to provider-side systems.

Zero-knowledge
Client-side encryption
Provider cannot decrypt
No plaintext analysis
User-controlled keys
DRIVUNOYou

Encrypted on your device before upload (Argon2id + X25519 + XChaCha20-Poly1305).

Zero-knowledge
Client-side encryption
Provider cannot decrypt
No plaintext analysis
User-controlled keys

Try it in one click.

Three private surfaces. Same zero-knowledge architecture.

Encrypted on your device · upload in 1 click
Upload