Dropbox encrypts files in transit and at rest, and holds the keys that open them. files.vualet is being built so that it cannot. This sets out the architectural difference, separates what is true today from what is intended, and gives the reader the three questions that settle it for any service.
The only question that separates them
Beneath the interfaces and the sync speeds, one architectural decision decides what a storage service can and cannot do with your files: who holds the key.
This piece keeps what is true today and what is merely intended strictly apart, and marks every statement as one or the other. A reader is entitled to that separation from anyone selling them storage. That includes me.
What Dropbox does, on its own account
True today. According to Dropbox's own published security documentation, the service encrypts files in transit and encrypts files at rest, and it holds the keys that open them. That custody is what allows it to restore a user's files after a password reset.
Holding the key buys real things, and it is worth being straightforward about them rather than skipping past. It permits server-side search of file contents, so a document can be found by keyword without downloading it. It permits previews generated by the server. It makes sharing by link straightforward, since the server manages access on the recipient's behalf. And it means a forgotten password is an inconvenience rather than a loss.
These are legitimate engineering choices, and a service that gives them up is giving up something users genuinely want. Any honest comparison has to concede that before it says anything else.
What files.vualet does today
True today, and short, because there is not much to claim.
files.vualet encrypts data in transit and stores it server-side, like most services of its kind. There is one piece of cryptography in the product now that is worth naming precisely because it is so often overstated: the TOTP seed used for multi-factor authentication is encrypted with AES-GCM before storage. That is authentication material, not file content. It protects the account. It does nothing for your documents.
The product's own documentation states that it will not claim end-to-end encryption unless and until a source file demonstrates it. That is a discipline it holds itself to, and it is the reason this article can be trusted on its own subject: the standard applies here too.
What it is being built to do
Intended, not yet shipped. Everything in this section describes a design, not behaviour you can observe in the product today.
The intended arrangement is that encryption will happen in the browser. A key will be derived from a passphrase only the user knows, and it will never be transmitted. The server will hold ciphertext it has no means of opening.
The consequences follow immediately and cannot be engineered away, so they are stated here rather than discovered later. There will be no server-side search of file contents. There will be no server-generated previews. And if a user loses the passphrase, the files will not be recoverable — not by support, not by appeal, not by anyone.
That last one is not a defect in the design. It is the proof that the design is real. A service able to return your files after you have forgotten everything necessarily kept a route to your key, and a service that kept a route to your key can walk it whenever it is asked to.
The three questions
Three questions settle this for any service, including ones neither of us has heard of.
- Where is the key derived? Dropbox holds the keys to its users' files, which is what makes reset possible. The intended files.vualet design derives the key in the browser from user knowledge alone.
- What does the server store? Dropbox stores ciphertext it can decrypt. files.vualet, as intended, will store ciphertext it cannot.
- What happens when the password is forgotten? Dropbox restores the files. The intended files.vualet answer is that they are gone.
The third question is the one worth asking first, because it can be answered from a help page in a minute, and the answer cannot be dressed up. Recovery and key custody are the same fact stated two ways.
Why publish this before it ships
Because an intention stated publicly is harder to quietly abandon than one held privately, and because labelling it as an intention is what gives the reader standing to hold me to it.
It is easy to claim a security property and hard to build one. It is harder still to write down, in advance, what your own product will not be able to do for the people paying for it. files.vualet will not be able to recover your files. I would rather that sentence appear here, under my name, before the feature exists, than appear in a support ticket afterwards.