∞LifetimeCloud

The question nobody asks

Encrypted doesn't mean they can't read it

Everyone encrypts. The real question is who holds the key.

“Your files are encrypted” is written on everybody's website. And it is true: Google, Dropbox and Apple really do encrypt, both while files travel and while they sit on their disks. Anyone telling you otherwise is wrong, or has not read.

The question that matters is a different one, and almost nobody asks it: who holds the key?

A safe with the combination inside

Encrypting a file without saying who keeps the key is like saying your documents are in a safe, without mentioning that the caretaker has the combination too. The safe is real. But whoever knows the combination can open it whenever they like.

Who holds the key, service by service

Google Drive. Files are encrypted in transit and at rest with AES-256. Google's own documentation also states that Google owns and manages the keys used in default encryption at rest. There is an option where the customer holds the keys — client-side encryption — but it is a feature for Workspace organisations, not for ordinary accounts.

Dropbox. 256-bit AES on files at rest, TLS while they travel. Their help page carries a sentence worth more than any commentary: “Dropbox doesn't support the creation of your own private keys”. They manage the keys.

iCloud. Here it is more nuanced, and it is only fair to say so. In the normal configuration — what Apple calls standard data protection, and which is the default setting — the keys are secured in Apple data centres, so that Apple can help you recover your data if you lose access. But Apple also offers Advanced Data Protection, which is genuine end-to-end encryption: switch it on and the number of data categories protected that way goes from 14 to 23, with the keys staying on your devices alone.

It is a serious feature and it deserves credit. But it is off until you turn it on, and most people do not know it exists.

What this changes, in practice

If the provider holds the key, your files can be opened. We are not talking about conspiracies: these are ordinary, openly documented things — automated content scanning, indexing so you can search inside your documents, and responses to requests from the authorities. It is not a question of trust: it is a question of possibility. Whoever holds the key can; whoever does not, cannot — not even if they wanted to, not even if ordered to.

Here, the key does not exist on our servers

The key that opens your files is born from your password, inside your browser, and it never leaves. What reaches our server is already-encrypted files: blocks of bytes that mean nothing.

This is not a promise we are making. It is a consequence of how the system is built, and it has a price we pay gladly but that you deserve to know: if you forget your password and have no recovery key, we cannot open your files. Nobody can. A service that can let you back in after you have lost everything is telling you, without saying it, that it can open your things.

The proof, not the slogan. On our disks there are files that not even we can read. It is checkable: if someone broke into our servers tomorrow and took everything, they would carry away unreadable blocks. The reason we cannot open them is not that we decided not to — it is that we do not have the key.

How to check for yourself

Do not take this page's word for it. The sources are below, they are each company's official pages, and they say exactly what we have written. If you find we have reported something wrongly, tell us and we will fix it.

Sources