You Can Withdraw Anytime. The System Won't.

Every privacy screen you have ever used carries the same sentence: you can withdraw consent at any time. It is the most repeated promise in software. It is also, as engineering, almost entirely fiction.

Here is what actually happens when you press the button. The company you withdrew from — the first one, the one whose interface you were staring at — stops. Token dead. Emails stop. That part is real. Everything the consent ever touched downstream keeps going: the partner who ingested your data two years ago, the analytics house that enriched it, the model that absorbed it. Your withdrawal is a local event with global ambitions. It ends at the first hop, and the first hop is the only hop anyone ever shows you.

The law wrote the promise. Nobody wrote the protocol.

GDPR made it explicit in 2016: withdrawing must be as easy as giving. A decade later, that sentence is honored in exactly one sense — the button exists, the button works, the button is one tap. What the law never specified, and what no vendor ever built, is what happens after the tap. No wire format for the withdrawal. No list of what it covers. No delivery guarantee. No receipt. No way for you, a regulator, or anyone else to tell "deleted" from "ignored."

A law without a protocol is a promise without a postal service. The intent was mailed a decade ago. It is still being mailed.

We already know how this movie ends — certificates showed us

The web spent fifteen years trying to propagate bad news — revoking compromised certificates — and mostly failed, for boring economic reasons: revocation lists got big, revocation checks added latency, and browsers quietly chose availability over rigor. Then the industry found the answer, and the answer was not better propagation. It was Let's Encrypt: short-lived certificates. Don't spread the bad news. Make the good news expire on schedule, so trust is re-earned every ninety days instead of remembered forever.

That is the single most important design decision in our new paper, P-017. Consent should work the same way. Every grant of consent should carry a half-life. Processors who want to keep using your data must come back and ask again — the way your SSL certificate comes back and asks again. Revocation then stops being a message that has to survive a journey across an uncooperative economy. It becomes a schedule collapse: the next renewal simply never arrives.

Make silence evidence

The paper's other half is honesty about incentives. The party holding your data profits from the residue. No protocol survives contact with that incentive by asking nicely. So the specification makes non-compliance visible: signed receipts for every revocation, canary records planted at consent time that surface later as evidence if data leaked after withdrawal, and a liability ladder where silence past a deadline flips the burden of proof onto the holder.

You cannot prove a byte was deleted. Nothing can — copies are physics. But you can make ignoring the request expensive, observable, and presumptively noncompliant. Priced silence, not perfect enforcement.

The near-miss that proves it works

India's account-aggregator fabric runs purpose-bound, expiring, revocable consent artifacts across an entire financial-data economy, with regulators watching. The machinery works at national scale. What it has never been is general — one regulated domain, one closed architecture. The mechanics are proven. The missing thing is the fabric for everything else: your fitness app, the school form, the retailer.

That is the gap P-017 specifies: grant objects with lineage, withdrawal with coverage semantics, receipts, re-attestation cycles, canary audits. The world does not lack consent. It lacks the keeping. Read the paper for the whole protocol — and the next time a privacy screen tells you that you can withdraw anytime, notice that it never says what happens next. Now you know why.