"You Own Your Data" Is a Property of the Server or It Is Nothing

Our own data-store product is compatible with the protocol it is built on rather than conformant to it, and the difference is most of this page.

The least checkable sentence in software

Every privacy policy contains a version of you own your data. Almost none of them means the thing a reader hears.

What it usually means is that the company holds your data, has written down some rules about what it will do with it, and will let you export a copy on request. That is a policy commitment. It survives exactly as long as the company's intentions, its ownership and its solvency do.

Ownership that depends on a promise is not ownership. It is custody with good manners.

What would make the sentence structurally true

The data has to live somewhere the person controls, and applications have to request access to it rather than hold copies of it.

That inversion is the whole idea. Under it, an application is a lens over your store rather than a silo containing a duplicate of you. Revoking an application's access removes its access, instead of leaving it with a copy it already took.

The Solid protocol specifies exactly this: a personal data store, applications that ask, and permissions the person grants and withdraws. It is not our design, it comes from Tim Berners-Lee's project and the community around it, and the specification is public.

Why a buyer should care about that specific word

Compatible means today's applications mostly work against it. Useful, and it is a statement about the present.

Conformant means an application written for any pod works against yours, and your data can move to any other provider without a migration project. That is the portability property, and it is the reason the model is interesting at all.

Without conformance, a personal data store is a private silo with better manners than the usual one. The manners are worth something. They are not the structural guarantee.

This is the same shape as our identifier problem, written up separately: the format is open and the plumbing that would let somebody else serve it is not finished. Two different components, one recurring gap, and naming it twice is more useful than naming it once.

What is checkable without asking us

The store is live and answers. An unknown path returns an authentication challenge rather than a soft not-found, which tells you the routing is real rather than a placeholder.

And the comparison is available to anyone: public Solid providers let a stranger create a pod for free in a couple of minutes. Create one, look at what it does, and compare. We are not the reference implementation and we would rather you measure us against one than against our own description.

The part where this connects to identity

A credential and a data store answer different questions. A credential proves a claim about you to somebody who needs it. A store holds the material your applications work with day to day.

The connection is control: both are attempts to move the default from the institution holds it and promises to the person holds it and grants. Our store is anchored to the same identifier the credentials use, which is what makes it one system rather than two products sharing a brand.

That is the design. The conformance gap above is what stands between the design and the property.

What to ask any personal-data-store vendor

"Conformant or compatible?" Ask for the word, then ask what fails. A vendor who has not made the distinction internally will not have an answer ready.

"Can I move my pod to another provider, and has anyone done it?" Portability that has never been exercised is a design intention.

"When I revoke an application, what happens to what it already read?" Nothing, in every system, and a vendor who implies otherwise is describing something impossible.

"What is between me and my files if you disappear?" For a conformant store the answer is a standard interface. For anything else it is a support ticket.

Where this leaves a decision

If you need the portability property, we do not have it yet, the missing piece is protocol conformance, and it is work rather than a wait.

If what you need is a data store anchored to a portable identifier, where applications request rather than copy, that is live and you can inspect it today, alongside a conformant pod from somebody else for comparison. Running both is the cheapest way to hold us to the distinction this page is built on.

Keep reading

"You Own Your Data" Is a Property of the Server or It Is Nothing · Solidus