Share the slice, not the file
Suppose a researcher needs one number from you: your latest cholesterol reading. To give it to them, most systems hand over the file that number lives in. The file also holds your address, your other test results and whatever else was stored beside it. You wanted to share a sentence and you shared the book.
A paper published this year in ACM Transactions on the Web measures how much that costs, and shows a way out. It is called You Shall Not Pass (Without Consent): Enforcing Data Sovereignty with Solid Pods, by Tobias Hajszan, Moritz Staudinger and Tomasz Miksa of TU Wien. It was not written about Cluzy, and its authors have nothing to do with us. But it describes, carefully and with numbers, an idea Cluzy is built on. So this post is about that idea.
The problem: a vault with only one size of door
The paper works with Solid, the open standard started by Tim Berners-Lee. In Solid, your data lives in a personal store called a pod. You own it. An app or a person can read something in it only if you say so.
Cluzy uses Solid for the same reason the authors do. If the data lives with you, a company does not have to be trusted to give it back.
But the authors point at a real weakness:
[D]ata retrieval in Solid is currently implemented in such a way that entire files are transferred, which can result in the exposure of more personal data than necessary.
Permission in a pod is granted file by file. That is a door with one size. Open it for one fact and everything in the file walks out.
The fix: make the slice, then share the slice
Their answer is simple enough to explain in a sentence. When you agree to a request, software on your side writes a new, small file containing only what was asked for. Permission is granted on that file and nothing else. The original never moves.
They call this the granular strategy, and they tested it against the ordinary way with 500 simulated contributors holding health records. With whole-file sharing, between 91 and 95 percent of everything transferred was irrelevant to the question. With the granular strategy, none of it was.
Two other parts of their design are worth knowing:
- Consent is a record you hold. Each time you agree, a consent file is written in your own pod, in a standard vocabulary, saying what you agreed to and when.
- Withdrawal is checked, not assumed. Before data is fetched, the system reads that consent record again. If you have withdrawn it, nothing is fetched, even if the old permission is still technically in place.
That second point is the difference between consent as a form you once signed and consent as a switch you still have your hand on.
What this looks like in Cluzy
Cluzy shows you what data brokers hold about you, helps you delete your listings from people-finder sites, and lets you build a corrected profile that belongs to you. The next question is what you can do with that profile. Our answer is a room.
A room is a private place you create for one purpose: your family, your lawyer, a single company. In the version of Cluzy we are testing now, a room has a short list of switches. One switch per kind of information, such as identity, contact details or work history, and one per file you have added.
Switching one on does what the paper describes. Cluzy writes a small document holding only that kind of information, and only what you have confirmed is true. That document, and nothing else, is what the room can read. A consent record is written in your own pod. Switching it off withdraws the consent and removes the document from the room.
We did not get this from the paper. We arrived at it the same way its authors did, by starting from the question "what is the least this person needs to share?" It is reassuring to see the same answer reached independently, measured, and peer reviewed.
Where we are going
The paper stops at research. Its contributors donate data to studies, and the researcher receives statistics, never the records.
Cluzy's aim is for that same boundary to work in your favor commercially. If a company wants to learn something from people like you, it should be able to get an answer without getting your data, and without learning who you are. You decide which room, if any, is open to that. You can close it again.
We have not turned that on, and we will say so plainly when we do. What exists today is the foundation it needs: data that lives with you, sharing by the slice, and consent you can withdraw.
What this does not solve
The paper is honest about its limits, and we should be about ours.
- The paper's numbers come from a prototype. Its data was synthetic and its test ran on one server. The authors write that the result "should be interpreted as a proof of concept rather than as a definitive performance metric." We agree, and we cite it as evidence for the design, not as a measurement of Cluzy.
- A slice is a copy made at a moment. If you later correct a fact, a room that already shares it has to be updated. Cluzy does that the next time you open the room, not instantly.
- Sharing is still sharing. Once someone you invited has read a document, withdrawing consent stops future reading. It does not make them forget.
- Rooms are still being tested. What we describe here is running in our test version, not yet for everyone.
None of that changes the main point. The safest amount of data to share is the smallest amount that answers the question, and a system should make that the easy thing to do.
The paper is published under a Creative Commons Attribution 4.0 license. We cite its ideas and its reported results; we have not independently reproduced its numbers.
Reference
Tobias Hajszan, Moritz Staudinger and Tomasz Miksa. "You Shall Not Pass (Without Consent): Enforcing Data Sovereignty with Solid Pods." ACM Transactions on the Web 20, no. 1, Article 12 (February 2026). doi.org/10.1145/3771554