Your files are encrypted. That's not the same as controlling who can read them
Encryption answers one question: can the server read this. Access control answers a different one: which agent may read, write, append to, or control this particular resource. Both are worth having. Neither substitutes for the other, and a product can be excellent at one while offering nothing on the other.
The products that do the encryption half well
Several encrypted-storage services are genuinely good applied cryptography: end-to-end encryption with zero server access, modern ciphers, and in one case a research pedigree going back fifteen years. Their briefs rate them competent and this page agrees.
If your threat model is "I do not want the operator reading my files", they answer it, and a pod does not.
What they do not answer
Encryption is all-or-nothing at the granularity of a key. Hand someone the key and they can read everything that key opens, for as long as they keep a copy. Take it back and you have changed nothing about the copy they already made.
That is fine for storage. It is not an authorization system. There is no way to express, in a key alone:
- this agent may append to my inbox but may not read it
- this agent may read this one resource and nothing else in the container
- this grant is revocable and the server will enforce the revocation on the next request
Those are the four permission modes, and they are a separate layer with its own page.
Where the two actually sit
Think of them as different axes rather than competing answers.
| encrypted storage | access control | |
|---|---|---|
| Answers | can the operator read this | which agent may do what to this resource |
| Enforced by | mathematics | a server |
| Survives an untrusted operator | yes | no |
| Granularity | per key | per resource, per agent, per mode |
| Revocation | re-encrypt and redistribute | change a rule, effective next request |
The two useful readings of that table are that encryption is stronger where the operator is the adversary, and access control is more expressive where the operator is not.
The row that goes against us
Access control is enforced by a server. If you do not trust the server, it is worth nothing.
An encrypted file stays unreadable whether or not the operator behaves. A permission rule is a request the operator agrees to honour, and on our deployment the operator is us. That is the same concession the tamper-evidence comparison makes, and it is not one we can engineer around while we are the only party running anything.
And we do not have the encryption half either
Pod content is not end-to-end encrypted. We searched our own frontend and backend and there is no encryption or decryption of user content anywhere. The cryptographic code that does exist, in four files, signs sessions and hashes passwords. It does not touch your files.
So the honest position is that the server can read what you store, and we operate that server.
Scope that claim properly: it is about the application layer. Whether the host disk is encrypted is an infrastructure property, and this page will not assert one either way about something it did not check.
One defect found while checking, recorded here because a reader following the same path will hit it. The file browser has an "Encrypted" badge, and the function that assigns file types can never return that value. The branch is unreachable. It is filed for removal.
What to use when
If the operator is your adversary, use encrypted storage. That is what it is for, the products above do it well, and nothing on this surface competes with them on it.
If you need to let three different applications touch three different parts of your data under rules you can change, that is an authorization problem, and encryption alone will not express it.
If you need both, you need both. Nobody in this field is currently offering the pair with fine granularity, and we would rather write that sentence than imply we are.