\"Provider-independent security\": the idea underneath every data pod, named in 2007
The intuition that you should not have to trust whoever stores your data is older than Solid, older than Inrupt, and much older than us. A volunteer project named it, defined it precisely, and shipped it, starting in 2007.
Nothing on this page is a claim about anything we built.
Their definition, in their words
Provider-independent security means that the integrity and confidentiality of your files is guaranteed by mathematics computed on the client side, and is independent of the servers, which may be owned and operated by someone else.
Read the second half carefully. Not "the servers are trustworthy". Not "we vet our operators". The servers may be owned and operated by someone else, and it does not matter.
How they get there
Files are encrypted on the client with AES, then split with erasure coding and spread across many servers. The defaults put shares on ten servers and need any three to reconstruct the file.
Two properties fall out of that, and both are unusual:
- A server operator holds ciphertext and a fraction of it. Reading your file is not something they can decline to do, because it is not something they can do.
- Seven of the ten can vanish and you still have your data. Availability stops depending on any single party's continued existence or goodwill.
The project is named for the principle of least authority, and the design is a fairly literal reading of it: give every component the smallest capability that lets it do its job.
Why this is worth a page on a pod site
Because a pod inherits the intuition and not the mechanism, and the difference is easy to blur.
A Solid pod's answer to "why trust the provider" is that you do not have to keep them. The data is in open formats over HTTP, so you can move it. That is portability, and it is a real property.
Tahoe's answer is that the question does not arise. The maths already excludes the operator.
Which is stronger, said plainly
Theirs, against a hostile or compromised operator.
Portability is a remedy you exercise after you decide something is wrong. Client-side encryption is a condition that holds whether or not you ever notice. If your threat model is an operator who reads your files, a pod's permissions do not answer it on their own, because the server you are asking about is the thing enforcing them. What answers it, for the files you choose, is per-file encryption: client-side and opt-in, so the bytes the server holds are ciphertext. The cost is real and belongs next to the offer, because an encrypted resource is opaque to every other Solid client, to pod's own preview and search, and to us. What a pod does not have is blanket end-to-end encryption, and that is a deliberate refusal rather than a gap: encrypting a whole pod would break WAC and interoperability with other Solid apps, which is the property a pod exists to provide.
What a pod offers instead is granularity: per-resource, per-agent permissions with four modes, which a K-of-N encrypted store does not attempt. Those are different jobs. Saying so is not a consolation prize, but it is also not a rebuttal.
What we do differently, and it is not an improvement
Our content sits on one server, in one place, which we operate, unencrypted at the application layer. Against the standard this page is about, that is worse on every axis: no client-side mathematics, no spread across independent operators, no threshold reconstruction.
We are not going to present portability as equivalent to it.
The part that deserves saying out loud
This was built by volunteers, on donations and summer-of-code grants, with a small commercial arm offering support. It has been maintained for close to two decades and shipped a release in December 2024.
A great deal of what this industry now sells as a novel architecture was specified and running, in public, before the companies selling it existed. Our own brief on the project spent most of its words scoring its website. That was the wrong thing to look at, and the rating table it came from is not reproduced here.