Most cloud storage providers encrypt your files. They list AES-256 on their security page. They mention TLS for data in transit. These statements are true and, at the same time, nearly meaningless.
The question that matters is simple: who holds the keys?
If the provider encrypts your files on their servers with keys they generate and store, then encryption protects you from outside attackers but not from the provider itself. A rogue employee, a court order, a compromised server, any of these can expose your data in plaintext. The encryption is a locked door, and the landlord has a copy of the key.
The decision we made in 2019
When Mart and I designed the first version of Fileson, we had one constraint that preceded all others: the server must never see plaintext. Not during upload, not during processing, not during search. This ruled out many features that other providers offer, like server-side file previews and full-text search across documents. We accepted those trade-offs.
The architecture works like this. When you create a Fileson account, we derive a master key from your password using Argon2id with parameters tuned to take about 500 milliseconds on a mid-range laptop. This master key never leaves your device. It encrypts a randomly generated account key, which in turn encrypts individual file keys. Each file is encrypted with AES-256-GCM using its own unique key.
When you share a file with another Fileson user, we use X25519 key exchange to create a shared secret. The file key is re-encrypted under that shared secret and stored on the server alongside the ciphertext. The server facilitates the exchange but cannot derive the shared secret from the public components.
What we gave up
Zero-knowledge encryption is not free. It costs functionality.
We cannot index file contents for search. Fileson's search works on file names and metadata, not on the text inside documents. Customers who need full-text search must handle that on their own devices.
We cannot generate thumbnails or previews on the server. When you browse your files in the web app, thumbnails are generated in the browser after decryption. This is slower than server-side rendering, particularly on large image libraries.
Password recovery is impossible. If you lose your password and have not saved your recovery key, your data is gone. We cannot reset it for you because we do not have the keys. This is the hardest conversation we have with new users, and we have it often.
Why we would make the same choice again
Five years of running Fileson have only reinforced the original decision. We have had zero data breach incidents, not because our infrastructure is invulnerable, but because a breach of our servers would yield nothing of value. Encrypted blobs with no keys attached are, for practical purposes, random noise.
We have received law enforcement requests. In each case, we explained the architecture, provided the ciphertext as required, and confirmed that we hold no decryption keys. The requesting parties accepted this. The architecture did exactly what it was designed to do.
Most of our competitors have moved toward server-side AI features: automatic categorization, smart search, document summaries. These features require the provider to read your files. We are not opposed to AI in principle, but we will not build features that require breaking the encryption model. If we find ways to run those features client-side in the future, we will. Until then, they stay off the roadmap.
The technical details of our encryption protocol are documented in full in our security whitepaper. If you find a flaw, report it to security@fileson.cloud. We pay bounties for valid findings.