A file storage platform encrypts data at rest and in transit. A customer asks whether the provider can read their files. What does the honest answer depend on, and what would change it?
Show the full answer Hide the answer
The honest answer
Yes, if the provider holds the keys — which is the case for essentially all storage services offering server-side features. Encryption at rest protects against a specific threat: someone obtaining the physical media or the raw storage. It does not protect against the provider itself, or against an attacker who compromises the provider's key management.
Being precise about which threat each control addresses is the whole point, and vagueness here is how customers form incorrect expectations.
What each layer actually protects against
| Control | Protects against | Does not protect against |
|---|---|---|
| TLS in transit | Network eavesdropping and tampering | Anything at either endpoint |
| Encryption at rest (provider keys) | Stolen disks, discarded media, raw storage access | Provider access, compromised key service |
| Customer-managed keys | Provider using data without customer cooperation | Provider compromise while the key is in use |
| End-to-end encryption | Provider reading content at all | Metadata exposure, endpoint compromise |
What would change the answer
End-to-end encryption, where keys are derived on the client and the provider never holds them. It gives the strongest guarantee and costs almost every server-side feature:
- No server-side search over content, because the server cannot read it. Search must move to the client, which changes what is possible on constrained devices.
- No server-side deduplication across users, because identical files encrypt differently. For a storage platform this is a substantial cost increase.
- No previews, thumbnails or content indexing generated server-side.
- Key recovery becomes the product's hardest problem. If a user loses their key, the data is gone. Every recovery mechanism — escrow, social recovery, a recovery code — reintroduces a path that weakens the guarantee, and this trade must be made explicit rather than papered over.
- Sharing becomes key distribution, which is genuinely hard to make usable.
What does not change
Metadata. File names, sizes, timestamps, folder structure, sharing relationships and access patterns are usually still visible, and metadata is frequently more revealing than content. A platform claiming end-to-end encryption while exposing full metadata is making a narrower promise than customers hear.
The architectural guidance
Offer tiers, and be explicit about each: provider-managed keys with full features; customer-managed keys for regulatory control; end-to-end for the subset who need it and accept the feature loss.
The failure to avoid is implying a stronger guarantee than the architecture provides. "Encrypted" is not a security property — the property is who holds the keys and under what conditions they can use them, and that is what a customer's question is actually about.