Why Google Photos is not private (and what to use instead)

The claim, stated fairly Google Photos is an excellent product and Google documents its security model openly. Photos are encrypted in transit and encrypted at rest. What is *not* claimed anywhere is end-to-end encryption of your library: the keys are managed by the service, which is precisely why the service can generate thumbnails, group faces, search "beach 2019", detect duplicates, and surface memories.

So the sentence "Google Photos is not private" is not an accusation. It is a restatement of the published architecture: the provider can decrypt your photos, because the product's core features require it.

Why people only notice this with certain photos Most of a photo library is unremarkable. The awkwardness starts with the rest: private albums, medical images, photos of documents and IDs, pictures of children, images shared inside a relationship. For that subset, "the provider can technically read this" changes from an abstract fact into a real preference.

Four consequences of provider-held keys - **Automated analysis.** Content classification and abuse-detection systems operate on decrypted images. This is standard across mainstream clouds and is usually disclosed. - **Account actions.** If an automated system flags content, access to the account — and everything in it — can be suspended pending review. - **Legal process.** A valid request served on a provider that holds the keys can be answered with readable content. - **Insider and breach surface.** Any system able to decrypt is a system that must be perfectly defended, forever.

None of these require bad faith from anyone. They are properties of key custody.

What zero-knowledge changes, concretely In a zero-knowledge design, encryption happens on your device before upload:

• Your passphrase is stretched locally with Argon2id into a master key.
• Each item gets a fresh symmetric key; the payload is sealed with XChaCha20-Poly1305.
• Item keys are wrapped for the recipients who should hold them using X25519.
• The server receives ciphertext and wrapped keys. There is no decryption path on its side.

The practical difference: no server-side classifier can look at your images, no support tool can open them, and a legal request returns ciphertext.

What you give up Be honest with yourself before switching:

• No cloud-side face grouping or "search your photos by what is in them" unless it runs locally.
• No password reset that magically restores your library — you keep a recovery kit instead.
• First-load previews are decrypted on the device, so cold loads are marginally slower.

For a holiday album, that trade is not worth it. For sensitive personal photos, it is the entire point.

A practical migration that does not take a weekend 1. Keep Google Photos for everyday snapshots and shared family albums. 2. Create a private vault and move the categories that matter: private albums, document scans, medical and financial images, anything under a personal NDA of trust. 3. Delete the originals from the mainstream service — and remember to empty its trash, where items typically remain recoverable for a period. 4. Store a recovery kit offline, on paper or in a safe.

Where DRIVUNO fits DRIVUNO Photos stores personal media inside the same zero-knowledge workspace as your files, mail and team drives, so there is one key model rather than several. File names and album names are encrypted with the content, thumbnails are generated on the device, and public links carry the key in the URL fragment, are passphrase-gated and expire within 24 hours at most.

We can see that an account exists and how large its ciphertext is. We cannot see a single image.