Permissions Are Only Real If Something Refuses, and We Did Not Write the Thing That Refuses

The enforcement described here runs inside a component we did not write, and we have not independently tested it.

The claim every product makes

You control who sees your data. There is a permissions screen, there are toggles, and the toggles reflect your intent.

What makes that true or false is not the screen. It is whether something refuses a request that the screen says should be refused, every time, including on paths the vendor did not think about.

A permission model is a claim about denial. Products get built and marketed around the granting side, which is the easy half.

Why access control is harder than it looks

The number of paths grows faster than the interface. A permission is enforced correctly on the main read path, then a search index, an export job, a cache, an admin tool or a backup restores a way to the same bytes without passing through the check.

Inheritance surprises people. Permissions on a container flowing to what it contains is convenient and produces situations where a person grants access to one thing and has granted it to more.

Revocation is not retrieval. Withdrawing access stops future reads. It does not recall what was already read, and any product implying otherwise is describing something impossible.

And defaults decide outcomes. Most people never open the permissions screen, so whatever the default is, that is the system's actual privacy posture.

Why we would rather say that than claim the strong version

Because the strong claim is checkable and we would eventually be checked.

An access-control claim is exactly the kind a serious buyer tests: create two accounts, grant a narrow permission, and try to reach the data another way. A vendor asserting rigour it has not tested is one afternoon away from being contradicted by its own product.

What is already done is that access is governed by an explicit permission model rather than by an application's good behaviour, the store is anchored to the same identifier the credentials use, and the enforcement component is real software with a community behind it. What is not done is our own independent verification of it.

What a buyer should test rather than ask

This is one of the few areas where you can settle the question yourself in an afternoon.

Create two identities. Grant one narrow access. Then try every other route to the same data: search, export, a shared link, an older cached reference, an admin view. Whatever you can reach without a matching permission is the actual model.

Do that to us and to anyone else you are evaluating. It is a better answer than any documentation, including ours.

What to ask any vendor about permissions

"Who wrote the enforcement, and have you tested it under your configuration?" For us: the protocol community wrote it, and no, not independently.

"Which paths bypass the check today?" Every system has had one. A vendor who says none has not looked.

"What is the default for a new resource?" The default is the posture, because most users never change it.

"What happens to data already read when I revoke?" The only honest answer is nothing, and it should be said rather than implied away.

Where this leaves a decision

If you need demonstrated access-control assurance, we cannot offer it, because the demonstration is exactly what we have not done.

If you want a store where permissions are explicit and enforced by a real implementation rather than by convention, that runs today, the enforcement is somebody else's well-regarded work, and the honest gap is that we have not proven our own use of it.