Lesson 3 of 4 · 9 min
Data in the cloud: encryption, key holders, and sharing links
Almost every cloud provider encrypts your data. The question that actually matters is who holds the key that unlocks it — and who a sharing link trusts.
A cloud provider will almost always tell you your data is encrypted, and this is usually true. It is also, on its own, a fairly weak claim, because it leaves out the detail that decides who can actually read that data if compelled, breached, or simply curious: who holds the key.
Encryption at rest and in transit, by default
Google Cloud’s documentation describes what most major providers do by default: “All data that is stored by Google is encrypted at the storage layer using the Advanced Encryption Standard (AES) algorithm, AES-256”, applied automatically, with no configuration required from the customer. Data in transit between your device and the provider is separately protected by TLS, covered in the cryptography course in this university. This baseline is genuinely useful — it protects against, for example, someone physically stealing a hard drive from a data centre — but it answers only part of the question.
Who holds the key changes what the protection is for
By default, Google Cloud states plainly: “we own and manage the keys used in default encryption at rest.” That is standard practice across the industry, and it is exactly why this default protects you against physical theft or an outside attacker, but not against the provider itself: if the provider holds the key, it can technically access the data, and so can anyone who legally compels the provider to. Providers do also offer customer-managed key options for organisations that need to hold their own keys, though this adds real operational complexity — losing your own key with no provider fallback can mean losing the data permanently.
End-to-end encrypted options: the customer holds the only key
A smaller number of consumer-facing features go further than provider-managed encryption at rest, extending true end-to-end encryption (the guarantee explored in the cryptography course) into cloud storage itself. Apple’s Advanced Data Protection for iCloud is a documented example: when enabled, it extends end-to-end encryption to iCloud Backup, Photos, Notes, iCloud Drive and more, and Apple states that “your trusted devices retain sole access to the encryption keys for the majority of your iCloud data” — meaning Apple itself cannot decrypt it, even under legal compulsion, and states it plainly: “No one else can access your end-to-end encrypted data — not even Apple.” The trade-off Apple documents alongside this is real: because Apple holds no key, it also cannot help recover that data if you lose access and have not set up a recovery contact or recovery key in advance. Strong protection and easy account recovery pull in opposite directions, and Advanced Data Protection asks you to choose.
| Encryption model | Who holds the key | Protects against | Does not protect against |
|---|---|---|---|
| Provider-managed encryption at rest (the common default) | The cloud provider | Physical theft of storage hardware; many outside attackers | The provider itself, or anyone who can legally compel it |
| Customer-managed keys | You (with real operational responsibility) | The provider accessing data without your key | Losing the key yourself, with no provider fallback |
| End-to-end encrypted options (e.g. Apple Advanced Data Protection) | You alone, on your trusted devices | The provider and most legal compulsion directed at the provider | Losing your own account access without a pre-set recovery method |
Sharing links: the quiet way data leaves the model above
All of the above can be undone by a single careless share. A “anyone with the link can view” setting on a cloud document turns strong encryption at rest into something closer to a public webpage: the link itself becomes the only thing standing between your data and anyone who receives, forwards, or guesses it. This matters more than it might seem, because such links are trivially forwarded beyond the intended recipient, often end up indexed or cached in unexpected places, and rarely expire on their own. Before sharing anything sensitive, it is worth checking whether the link can be restricted to specific people who must already be signed in, given an expiry date, and revoked once it is no longer needed — options most major providers offer but do not turn on by default.
Key takeaways
- Most cloud providers encrypt data at rest and in transit by default; this protects against physical theft and many outside attackers.
- By default the provider usually holds the encryption key, meaning the provider itself (or anyone who legally compels it) can still access the data.
- Customer-managed keys shift that control to you, at the cost of real operational responsibility — losing the key can mean losing the data.
- End-to-end encrypted options such as Apple Advanced Data Protection give you sole access to the key, but you must set up account recovery in advance since the provider cannot help recover it.
- A broadly shared link can undo all of the above; restrict sharing links to specific people, add expiry where possible, and revoke access once it is no longer needed.
Check yourself
1. By default, who typically holds the encryption key for data stored in a mainstream cloud service?
- The end user, always
- The cloud provider — Right.
- No one; the data is unencrypted by default
- A government agency
Providers commonly manage encryption keys themselves by default, which protects against outside theft but means the provider can still technically access the data.
2. What does Apple state about data protected by Advanced Data Protection for iCloud?
- Apple can always recover it if you lose access
- No one else can access it, not even Apple, since trusted devices hold the keys — Right.
- It only applies to email, not files or photos
- It requires no recovery setup at all
Apple documents that trusted devices retain sole access to the keys, so Apple cannot decrypt the data — which also means Apple cannot help recover it without a pre-set recovery method.
3. Why can an "anyone with the link can view" sharing setting undermine strong encryption at rest?
- It automatically deletes the encryption
- The link itself becomes the only protection, and it can be forwarded, cached, or guessed beyond the intended recipient — Right.
- Such links always expire within an hour
- Cloud providers block this setting for sensitive files automatically
A broadly shared link bypasses the need for the recipient to be signed in or verified, so anyone who obtains the link gets the same access as an authorised viewer.
Do it with FireAI
Put this lesson into practice on your own Mac.
- Find out where an app sends data, on the World map — See exactly which company and country one app is quietly talking to.
- Rules: app, website, domain, IP or a range, forever or until you restart — Write a rule as precise as one address or as broad as an entire domain.
- The Threats page: what looks wrong, and why — See the handful of connections worth your attention, instead of scrolling through thousands.
Sources
Put it into practice on your Mac
Try every feature free for 17 days, no card needed.