What never leaves your device cannot leak
Every privacy promise you have ever read says roughly the same thing: we take your privacy seriously. It is a sentence about intentions. It tells you nothing about what happens when a server is breached, a vendor is careless, a log file is kept too long, or a company is sold.
This week a team called the National Design Studio published a paper about a small tool named Rampart. It removes names, addresses, card numbers and similar details from text before the text leaves your browser. The tool is interesting. The sentence at the heart of the paper is more interesting, because it is not about intentions at all:
Data the server never receives cannot be leaked, by a model provider, a logging system, an analytics pipeline, a third-party SDK, or a future compromise of the application's own backend.
That is a claim about architecture, not trust. It says: we did not build a way for this to go wrong. We think it is the only kind of privacy promise worth making, and it is the one Cluzy is built on. So this first post is about that idea, why it is harder than it sounds, and what it looks like inside Cluzy.
The trust boundary
Every product has a line. On one side is your device. On the other side is everybody else: the company's servers, its cloud provider, the AI model it calls, the analytics vendor, the person who will one day misconfigure a database.
Most products draw that line as close to you as they can get away with. Your data crosses it the moment you type, and from then on your privacy depends on every party on the far side behaving well, forever.
Rampart's authors call moving that line "shifting the trust boundary." Put the sensitive work on your side of it, and the far side never has anything to lose. It is a modest engineering idea with an immodest consequence: the worst case is bounded by what the device failed to protect, not by everything you ever shared.
What this looks like in Cluzy
Cluzy exists to show you what data brokers are selling about you, and to help you take it back. That means Cluzy, of all products, handles exactly the information brokers trade in. If we stored it the ordinary way, we would simply be one more copy.
So we don't. When Cluzy gathers records about you, they go into a private Vault that only you can open. The Vault is locked with a key that lives on your own device and in a private folder of your Google Drive. Cluzy's servers hold the locked box, never the key. We cannot read your Vault: not on our servers, not in a backup, not if someone asked us to.
That is the same trust boundary Rampart describes, drawn around your data rather than around a chat message. And it has the same consequence. If our systems were breached tomorrow, the attacker would get sealed boxes.
The part most people skip: what you keep
There is a subtler idea in the paper, and it is the one we would most like people to understand about Cluzy.
Rampart does not blank out everything. It removes the precise street line but keeps the city, state and ZIP, because an assistant "can reason about coarse geography and eligibility" without knowing exactly who you are. The authors call this a keep-set: the small amount of context that is useful without being identifying.
That distinction, between what identifies you and what is merely true about you, is the whole difference between a data broker and what Cluzy is trying to build.
A broker sells the identifying part: your name, your address, your phone, attached to everything else. The name is the product. Take it away and the rest is nearly worthless to them, which is why they will never take it away.
Cluzy's view is that the useful part and the identifying part can be separated, and that the choice of whether anything is shared at all belongs to you. Today that means reviewing what was found, correcting what is wrong, and asking sites to remove your listings. Nothing in your Vault is released for any other purpose unless you make a separate, explicit choice to release it.
Harm reduction, not magic
The other thing we admire about the Rampart paper is its honesty. Its first design goal is "local-first privacy as harm reduction," and it says plainly: "No client-side redactor at this size will catch every leak, and we do not claim otherwise." Then it publishes a limitations section.
We want to hold ourselves to the same standard, so here is ours.
- Cluzy cannot read your Vault, but Cluzy has to fetch records before they are sealed. For that moment they pass through our systems, and we treat that as a liability, not a feature. We log counts, never content.
- Data brokers do not need our permission to keep selling what they already have. Removal is a request, one broker at a time, and a broker can list you again next month. We show you the status honestly rather than declaring victory.
- Deleting your Cluzy account deletes your Vault and your login. It does not un-sell anything a broker sold before you arrived.
None of that is a reason not to start. It is the reason to start with a product that, by construction, cannot become the next place your data leaks from.
What comes next
This is the first post on this blog. We will use it to explain what we find in broker data, what is and is not working in removal, and the design decisions behind Cluzy, including the ones we get wrong. Cluzy is in early access. If you would like to see what brokers hold about you, you can ask to join.
The Rampart whitepaper is published by the National Design Studio. We cite its ideas; we have not independently reproduced its numbers.