Most collaboration platforms claim to be secure. 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: can the platform provider read your team's work?
If the provider encrypts your workspace content 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 documents 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 workspace content. Not during creation, not during collaboration, not during search. This ruled out many features that other platforms offer, like server-side document previews and full-text search across workspace content. We accepted those trade-offs.
The architecture works like this. When you create a Fileson workspace, we derive a master key from your credentials 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 workspace key, which in turn encrypts individual document keys. Each document is protected with AES-256-GCM using its own unique key.
When you collaborate with another team member, we use X25519 key exchange to create a shared secret. The document key is re-encrypted under that shared secret and stored on the server alongside the encrypted content. The server facilitates the exchange but cannot derive the shared secret from the public components.
What we gave up
Security-first architecture is not free. It costs functionality.
We cannot index document contents for search on the server. Fileson's search works on document titles and metadata, not on the text inside documents. Teams who need full-text search use our client-side indexing, which runs locally on each device.
We cannot generate previews on the server. When you browse your workspace in the web app, previews are generated in the browser after decryption. This is slower than server-side rendering, particularly for image-heavy projects.
Password recovery is impossible. If you lose your credentials and have not saved your recovery key, your workspace content is gone. We cannot reset it for you because we do not have the keys. This is the hardest conversation we have with new teams, 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 content with no keys attached is, for practical purposes, random noise.
We have received law enforcement requests. In each case, we explained the architecture, provided the encrypted data 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 competing platforms have moved toward server-side AI features: automatic categorisation, smart search, document summaries. These features require the provider to read your workspace content. We are not opposed to AI in principle, but we will not build features that require breaking the security 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 security 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.