After finishing a long investigation into Git deletion, I thought the difficult part was over. The repository had been the experiment; the broader lesson seemed to be that deletion has several observable states. Then a more uncomfortable question appeared. If a system says that something is deleted, what exactly is it claiming, who defines the scope of that claim, and who gets to decide when the process is truly finished?
I documented the original technical investigation in Deleting in Git and Rethinking (Philosophically) Deletion as a System Design Question. I will not repeat its command sequence, checksums, history reconstruction or remote tests here. That article supplies the concrete case study. This essay begins where it ended and follows the questions that emerged afterwards: deletion as a promise, deletion as a division of power, the limits of legal erasure, the possibility of user-triggered irreversible deletion, and the way end-to-end encryption changes the problem entirely.
The command was no longer the interesting part
The question that survived the successful experiment
The first conceptual shift was simple. A deletion command and a deletion claim are different things. A command is an event: a user presses a button, an API receives a request, or a service begins a workflow. The claim comes afterwards: “the data are deleted.” That sentence requires an object, a scope, a time, an authority model and some evidence. A successful command can establish that a process ran without establishing the final condition the user has in mind. Once I noticed this difference, the title of the new argument became almost unavoidable: deletion is a claim, not a command.
This was the first place where the discussion with AI materially changed my framing. I had begun with a technical result and was still asking what operation should follow it. The better question was grammatical before it was architectural: what is the subject of the statement, which data does its object denote, and what predicate has actually become true? The AI could readily produce another command sequence, but that would have answered the question I had just completed. What I needed was an account of the sentence the interface presents to the user. In other words, the experiment had succeeded while its vocabulary had become unstable.
I also had to resist a tempting exaggeration. Discovering residual representations does not prove that every ordinary deletion interface is deceptive, nor does it prove that users always want physical annihilation. In the earlier Git work, stable identifiers and remote tests made a deeper state visible. The new essay had to preserve that evidence without promoting it into a universal accusation. The defensible conclusion was narrower and, I think, stronger: the word deleted can name several postconditions, and a system should not rely on the user’s inability to distinguish them.
One verb compresses an entire lifecycle
“Delete” is perhaps one of the most semantically overloaded verbs in computing. One interface label can stand for removal from a screen, a namespace change, reference invalidation, logical marking, cache expiry, garbage collection, backup rotation, cryptographic key destruction or a mixture of these. The interface presents a single verb because users need a usable action, but the verb also makes an epistemic promise. When the system later displays “Deleted,” it is no longer merely reporting that code executed. It is telling the user something about reality. That is quite a workload for one small button.
DELETE
may mean
remove from visible account
stop normal retrieval
remove live references
schedule garbage collection
retain a recovery copy
wait for backup expiry
destroy a decryption key
notify other data holders
This semantic compression is usually harmless. If I delete a downloaded document because my folder is untidy, I normally want it out of my working environment. I do not care whether a short-lived backup or an SSD remapping layer still contains a representation. Likewise, ordinary application data can often be considered successfully deleted once they stop participating in the user’s intended workflow. A full ontology of disappearance would be wildly disproportionate. The Delete button may be the most optimistic member of the interface, but most days its optimism causes no real trouble.
The ambiguity becomes consequential when the difference between postconditions changes security, privacy, recovery, legal responsibility or operational behaviour. A removed credential may remain dangerous in history or a clone. A closed account may leave personal information in other internal systems. A database row may disappear while a cache or search index continues to expose it. A backup may faithfully restore information that the live system had correctly erased. A private manuscript, source repository or photograph may remain recoverable by a provider even after its owner has chosen deletion. Usually the ambiguity does not stop a person accomplishing the immediate task. It still affects what the interface is entitled to claim.
That qualification became important during the AI exchange because I kept returning to a practical objection: if deletion works for perhaps 99 percent of ordinary intentions, am I turning a marginal edge case into a philosophy of everything? The answer depends on the cost of the mismatch. Removing an old download from a folder and erasing a compromised secret are visually similar actions with very different failure consequences. A recoverable grace period can be kindness after an accidental click and a liability after a deliberate security decision. A single label is acceptable only if the surrounding context tells the user which contract applies. Otherwise an implementation detail quietly becomes a risk allocation.
I therefore stopped asking whether the word delete has one correct technical definition. It plainly does not. The useful design question is whether the system has selected a definition appropriate to the user’s objective and exposed enough of that definition to support an informed choice. The first ACM article helped confirm that the vocabulary across research and practice is genuinely fragmented; the second helped organise the user-facing stakes as control, scope, completeness and transparency. Those papers gave names to the terrain. The route through it—claim, universe, terminal-state control and cryptographic agency—came from the iterative dialogue and the concrete repository case.
Reading two recent research contributions sharpened this point. The Many Faces of Data Deletion surveys the fragmented vocabulary and mechanisms collected under the word deletion. From Objects to Influences identifies four persistent user expectations—control, scope, completeness and transparency—and asks what happens when learning systems transform discrete data into distributed influence. I am deliberately leaving machine-unlearning algorithms outside this essay because I want to study them properly before making technical claims. Their conceptual challenge still helped me recognise that even in traditional systems a deletion interface carries assumptions about agency, boundary, finality and proof.
How the thesis changed through the dialogue
From a Git operation to a system claim
The sequence of revisions matters because the final thesis was not present at the beginning in polished form. The first version was essentially operational: a user can remove ordinary references, yet the host may retain objects and can perform a deeper cleanup unavailable through the normal interface. The next version became epistemic: a successful interface action does not establish every condition implied by the word deleted. Then it became architectural: the provider owns the mechanisms that create the terminal state. Finally it became normative: which part of that terminal-state decision should belong to the user, which part properly remains with the provider, and what evidence should connect the two?
AI was useful here because it could rapidly propose distinctions and test them against examples. It was also quite willing to make the argument sound finished too early—a talent shared by software demos and some committee reports. Each time the language became too smooth, I pushed it against a harder case. If I said “complete deletion,” the next question was complete within which systems. If I said “user control,” the next question was whether I meant root access, a legal entitlement or an outcome. If I said “proof,” the next question was who could observe the relevant layer. The method was a repeated cycle of proposition, counterexample, narrower formulation and another counterexample.
The questions that forced corrections
Several questions did more work than any abstract definition. What if the repository is private, has one owner, no forks, no collaborators, no external clones and no legal hold? If the provider can perform deeper reclamation for a support case, why can the authorised owner not select the same terminal state as a product capability? Does ownership of the content imply control of storage? If not, does rejecting infrastructure control also require rejecting outcome control? If a legal right lets a person request erasure, what can that person actually observe? If encrypted ciphertext remains in backups after the last key is destroyed, is the repository gone, inaccessible, meaningless, or all three under different definitions?
None of these questions was solved by replacing the old answer with its opposite. The private single-owner case does not prove that every repository can be erased without affecting anyone else. Provider-side reclamation does not prove physical annihilation. Content ownership does not confer ownership of a disk, and a legal claim does not itself implement a storage transition. The iterations instead separated concepts that my opening language had conflated. This was honestly the most productive part of the work: every apparent objection became a request for a better type system.
What remained mine in an AI-assisted method
The division of labour is worth stating because the article is partly about human–computer collaboration. The AI generated candidate distinctions, alternative phrasings, legal and architectural hypotheses, and lists of questions I might have missed. Deterministic tools and primary documentation established narrower facts: which remote states were observable in the earlier experiment, what the provider currently documents, and what the legal text actually says. The real environment decided which technical claims survived. I decided the scope of the essay, rejected claims I could not defend, chose the normative direction, and kept asking whether an attractive sentence had outrun its evidence.
This also explains why I postponed a technical treatment of machine unlearning. The AI could summarize algorithms and produce fluent comparisons, but fluency would not give me the understanding needed to make original claims about them. The learning-systems paper was valuable as a conceptual provocation: it shows how deletion becomes influence mitigation when no stable removable object corresponds to the original input. I use that contrast cautiously. A Git object identified by a known hash is an unusually strong epistemic handle; a learned influence distributed through parameters is not an object with an equivalent OLD_SHA. Pretending otherwise would make the comparison vivid and the analysis wrong.
The methodology that emerged is therefore reusable. Begin with a concrete discrepancy. Ask what proposition the interface appears to assert. Enumerate the layers over which that proposition could vary. Separate observations from inferences and desired rights from existing mechanisms. Search primary sources for claims that may have changed. Let AI generate counterexamples, but make the environment, documents and threat model arbitrate factual questions. The goal is not to remove judgment from the process; it is to make judgment easier to inspect.
Deleting an object is different from deleting its consequences
Presence, propagation and influence
The next step was to distinguish the source object from everything that has happened because of it. Consider an ordinary, non-learning system. A customer record may feed a search index, a cached profile, a monthly report, a fraud score and a backup. Removing the primary record does not necessarily remove every copied or derived representation, and it certainly does not reverse a decision already made from the information. The data may cease to be present as an object while remaining causally effective as an influence. Machine learning makes this problem more difficult, but it does not invent it.
source record
|
+-- exact copy
+-- cached representation
+-- search index
+-- derived score
+-- aggregate report
+-- backup
+-- human decision
This produces three increasingly demanding meanings of deletion. Object deletion asks whether the identified source remains represented or retrievable. Propagation deletion asks whether copies, indexes and derived personal representations have also been handled. Causal reversal asks whether the system has returned to the state it would occupy had the information never entered it. The third is a counterfactual demand, not an ordinary storage operation. Deleting an incorrect record does not cause a person to unmake a decision taken yesterday, just as destroying a letter does not make its reader forget what it said.
I found the state-based and counterfactual formulations especially useful:
State-based deletion
Is X present or recoverable now?
Counterfactual deletion
Is the system equivalent to the system
that would have existed if X had never entered it?
These should never be promised as though they were the same. A system may be able to remove exact objects and derived indexes while being unable to undo independent human knowledge, external copies or prior consequences. That limitation does not make object deletion meaningless. It makes the boundary of the claim essential. The system should say what it can erase, what it can prevent from returning, and what lies outside its causal or technical authority.
One revision in the dialogue was especially helpful: distinguish deleting a representation, deleting access to it and deleting its meaning. These targets can coincide, but they need not. Physical destruction targets the representation. Access revocation targets a capability or policy path. Cryptographic erasure targets the ability to recover intelligible plaintext. Removing a search result may reduce discoverability without destroying the source. Deleting a source record can stop future processing while leaving a past aggregate unchanged. The word deletion often moves between these targets mid-argument unless they are named.
This is also why I would not describe every residual consequence as undeleted data. A report that contains an exact personal field is different from an aggregate whose value was once affected by that person, and both differ from a human decision informed by the report. The further the effect moves from identifiable representation toward causal history, the less ordinary object-erasure language can do. A requirement may still demand correction, recomputation, notification or mitigation, but those are distinct operations. Treating them all as deletion hides the work that must actually occur.
Why forgetting may be the wrong metaphor
The language of “forgetting” initially appealed to me because it captures the human desire to make information stop mattering. Yet human forgetting and machine deletion are poor equivalents. A person who burns a letter can destroy the object and still remember its contents; another reader may preserve a photograph; a decision already made does not automatically reverse. That analogy usefully reveals the causal limit, but it should not be pushed into an excuse for systems to retain everything. Computers can often enumerate, isolate and destroy representations far more systematically than people can erase memories.
The more precise aspiration is controlled non-persistence. For object-like data, the system should prevent the information from remaining available, recoverable or reintroduced within a declared scope. For derived effects, it should state whether they will be recomputed, quarantined, corrected or left unchanged. For independent human knowledge and outside copies, it should acknowledge the boundary. “As if it had never happened” may express the user’s moral wish, but an engineering contract needs individually testable postconditions.
A complete-deletion claim needs a declared universe
Complete according to whom and inside what boundary
The phrase I initially used was “delete it completely from the universe.” It expressed the desired outcome honestly, but it was technically unbounded. Which universe? The active account, every live provider system, all provider backups, every storage device ever involved, every processor, every external clone, every screenshot, or the memory of every person who saw the information? Without a defined universe, complete absence is not a proposition that an ordinary observer can test.
I therefore began writing the claim as a relation between an object and a declared universe:
CompleteDeletion(x, U) x = an identified object or body of information U = the declared universe of relevant representations CompleteDeletion(x, U) holds when no recoverable representation of x remains inside U, subject only to explicitly identified and justified exceptions.
Different actors may choose different values for U. A user interface may implicitly use the active namespace. A provider’s deletion policy may include live storage and caches but place backups on a retention schedule. A regulator may consider every system controlled by the controller or its processors. A forensic investigator may care about physical remnants. The disagreement is often less about whether a deletion command ran and more about who gets to define U.
At first I treated this as a measurement problem: define enough checks and eventually the answer should become complete. The dialogue exposed the prior governance question. The provider decides how systems are partitioned, which processors receive data, what counts as a cache, when a snapshot expires and which internal stores appear in the official inventory. If it can define the universe narrowly and then attest to deletion inside that universe, the receipt may be accurate while the promise remains weak. Scope selection is therefore part of the substantive right, not a harmless preface to verification.
This is why the phrase under effective control matters in my proposed default. It ties scope to operational power instead of product labels. A database managed by a contracted processor should not fall outside merely because the provider calls it “external.” A backup that the provider can restore but claims it cannot selectively edit remains within the lifecycle that must be accounted for. Conversely, a clone independently created by another authorised person may genuinely lie outside the provider’s power to destroy. A useful boundary follows authority and responsibility, then declares the exceptions, rather than following whichever diagram makes the deletion report shortest.
My proposed default is demanding but bounded: where no independent third-party interest or lawful retention obligation applies, the relevant universe should presumptively include every representation under the service provider’s effective control. That includes active copies, internal references, caches and recovery systems, together with processors the provider can instruct. It does not include an independent person’s local copy, because the provider has no power to destroy it. A private repository with one owner, no collaborator, no fork, no outside clone and no legal hold is the clearest thought experiment precisely because it removes those competing boundaries.
This also refined two propositions from the earlier investigation:
Deletion is relative to an abstraction boundary. A claim of complete deletion is also relative to a universe of observation.
The second sentence adds an epistemic limit. A provider may control systems that the user cannot inspect. A user may know a stable identifier that exposes one residual state without having authority to change it. A regulator may be entitled to demand records and audits that the user cannot obtain directly. There is no single observer with automatic access to every relevant layer.
How can anyone prove absence
The question “how do you prove a negative?” kept returning, but it needed refinement. In a finite technical universe, absence is not inherently mystical. If a repository service declares a complete set of live references, caches, backups, processors and keys, it can test postconditions for those components. The problem is that the user rarely knows whether the set is complete and cannot usually inspect all its members. Verification therefore has two layers: evidence that each declared component reached its required state, and evidence that the declaration itself covers the relevant system.
The earlier Git investigation was unusually favourable because a known object identifier offered a repeatable query. A failed lookup after deeper reclamation was meaningful evidence about direct addressability through that interface. It did not reveal cold backups or disk sectors, but it let me falsify an earlier assumption while the object still resolved. The identifier functioned as an epistemic handle: it made a hidden difference observable without granting me control over the server. Many deletion disputes are harder precisely because the user lacks such a stable probe.
Learning systems expose the limit from the other direction. There may be no bounded object corresponding to one training contribution that can be queried like a historical commit. Effects can be distributed and behaviour can vary across prompts and model versions. I am not treating that as a technical account of unlearning, only as a warning about proof structure. A finite reference graph and an open-ended space of possible model behaviours do not support the same absence test. The second ACM paper’s move from objects to influences makes that mismatch explicit and helped me see why a universal deletion verifier would be a category error.
The observability ladder is useful but reality is a graph
That led me to a deletion observability ladder. It is not a universal state machine, because real systems can branch, but it helps prevent evidence from being stretched upward:
- Interface disappearance means the user no longer sees the object.
- Namespace disappearance means ordinary retrieval no longer locates it.
- Reference disappearance means declared live references no longer lead to it.
- Direct non-addressability means even a known identifier no longer retrieves it through the tested interface.
- User non-recoverability means the user-facing restore process cannot bring it back.
- Provider-attested erasure means the provider asserts that its declared lifecycle is complete.
- Cryptographic irrecoverability means surviving encrypted representations cannot feasibly yield plaintext within the threat model.
- Physical irrecoverability means no relevant physical representation can reconstruct the information.
The higher the claim climbs, the less direct the ordinary user’s observation tends to become. A visible disappearance can be checked with one’s own eyes. Backup expiry and storage-media destruction may depend on provider records, audits or cryptographic design. If I cannot inspect the provider’s physical storage, I should not silently upgrade an interface observation into a physical-erasure claim. The tool should model observable predicates, not declare metaphysical victory.
I call this a ladder because the claims often feel progressively stronger, but the metaphor has limits. Cryptographic irrecoverability does not necessarily come after physical reclamation; it can occur first, while encrypted copies remain. User non-recoverability can coexist with provider recoverability. A source object may be gone while an index remains, or an exact copy may remain inaccessible while a derived effect continues to influence a decision. The real model is a graph of predicates, authorities and dependencies. The ladder is a teaching aid for refusing unjustified upward inference, not a claim that every system passes through eight neat stages in order.
A practical deletion report should therefore avoid a single scalar “deletion level.” It should state a vector of properties: visibility, addressability, live references, recovery paths, backup behaviour, key availability, derived representations and external boundaries. This is less elegant than a green checkmark, but elegance is not always the friend of truth. A dashboard can still summarise the outcome; the underlying receipt must preserve the distinctions on which the summary depends.
Deletion is the inverse problem of durability
The same mechanism can be protection or persistence
Another thread became clearer once I stopped treating deletion as an isolated CRUD operation. Modern systems are designed to prevent loss. Replication, snapshots, immutable logs, version histories, caches, redundant object stores and disaster-recovery backups all answer the requirement “do not lose this information.” Then the user asks the same architecture to lose it deliberately, completely and sometimes immediately. Every reliability mechanism becomes part of the erasure-coordination problem.
Reliability asks how information can survive failures. Deletion asks how information can fail to survive on purpose. A system that remembers well has to work harder to forget. That is not evidence of bad engineering; it exposes competing objectives. The same recovery window that saves a project after an accidental click also prevents immediate irreversibility. Backups are heroes until the requirement is forgetting, at which point their admirable memory becomes the problem under examination.
This is why soft deletion is often the correct default. People make mistakes, accounts are compromised and destructive operations can be abused. A recovery period has genuine value. Yet the safety argument supports offering a reversible default; it does not necessarily justify withholding an irreversible option from an informed, authorised user. Trash and Empty Trash already embody two different postconditions. Cloud services could make the distinction equally explicit.
The conflict can be stated simply:
recoverability increases protection from accidental loss irreversibility increases protection from unwanted persistence
Neither objective is universally superior. For an ordinary project, recovery may matter more. For a sensitive private repository, an unpublished manuscript or information subject to a valid erasure requirement, continued recoverability may be the risk. System design should let the authorised person choose which failure is unacceptable, with appropriate safeguards and clear consequences.
Deletion debt begins at architecture time
The AI discussion also shifted my attention from deletion procedures to deletion-aware architecture. If a service replicates data widely, mixes tenants through deduplication, builds immutable provenance, copies content into analytics systems and adds backups without a corresponding erasure path, it accumulates what I would call deletion debt. The feature works today because persistence is easy; later, a terminal-state request must reconstruct a map that the architecture never maintained. At that point deletion becomes an expensive expedition through systems whose owners may not even agree on vocabulary.
This does not mean every record should be easily destroyable. Audit logs, scientific provenance, financial records and legal evidence can have justified retention requirements. It means the conflict should be designed explicitly. A system should know which data are authoritative, which are derived, which retention rule applies, which keys protect which scope, how a restore replays prior erasure decisions, and which actor owns the final check. Immutability without an erasure model is still a design choice; calling it a platform constraint later does not make the original choice disappear.
The restore path deserves particular attention. A live deletion can be technically correct and still fail operationally if disaster recovery resurrects an older copy. The robust pattern is to preserve the erasure instruction or tombstone long enough to reapply it after restoration, while preventing that metadata from becoming an indefinite duplicate of the content being erased. Well, backups have discovered time travel, so deletion has to write instructions for its future self. This is one reason verification should include restore testing and not stop at the production database.
Who controls the terminal state
The clean private-repository thought experiment
The most important turn in my reasoning concerned power. At first the question sounded like a demand for lower-level infrastructure access: if the repository is mine, why can I not run the provider’s garbage collector? That formulation invited a correct but incomplete answer. Users should not receive administrator access to shared storage. A hosted object may participate in internal references, deduplication, security processes, legal holds or another person’s legitimate state. Content ownership is not ownership of a physical disk block.
But I did not actually want the provider’s root password. I wanted control over the outcome. Infrastructure control means choosing storage devices, GC algorithms, queues and backup implementations. Outcome control means being able to say, after informed confirmation, “make this data irrecoverable throughout every system under your effective control.” A person need not control the architecture in order to have meaningful control over the terminal state of their data. Root access would be an exciting solution only until the first typo.
GitHub makes the distinction concrete without requiring me to repeat the earlier Git experiment. Its current documentation says that fully removing qualifying sensitive data can require GitHub Support to dereference pull-request references, run server-side garbage collection, remove cached views and purge orphaned LFS objects. The same procedure is not offered for ordinary non-sensitive data and may be refused where credential rotation mitigates the risk. GitHub also documents that some deleted repositories can be restored within 90 days. See Removing sensitive data from a repository and Restoring a deleted repository.
The significant boundary is not simply possible versus impossible. GitHub possesses provider-side operations that the ordinary repository owner cannot directly trigger as a normal lifecycle choice. Deeper cleanup is mediated through a provider-defined support category. That is partly a security and implementation boundary, but it is also a product and governance decision. The legitimate question is therefore not “why can I not administer GitHub?” It is “why is irreversible erasure a provider-mediated exception rather than a user-selectable terminal state in the clean private case?”
The clean case became my way to isolate the disagreement. Assume one verified owner; a private repository; no fork, collaborator, pull request belonging to another party, external clone known to the provider, legal hold or statutory retention duty. Assume the user understands that restoration will be impossible. Under those conditions, the familiar justifications for refusing a definitive choice become much thinner. Shared infrastructure still makes the implementation complex, but shared infrastructure alone does not answer who should choose the authorised outcome.
This hypothetical is not a prediction that providers can always know whether an outside copy exists. It deliberately limits the requested universe to provider-controlled representations and declared processors. Nor does it say that a provider must erase bits synchronously while the user watches a progress bar. It asks for a committed terminal state with a defined deadline and no retained provider recovery path. The service may choose queues, cryptographic erasure, media rotation or another sound method. The user’s decision concerns continued provider-controlled recoverability.
Ownership was the wrong shortcut
Server-side Git garbage collection would not by itself answer the entire question. It operates at the Git-object layer; cached views, pull-request references, LFS objects, snapshots, backups and underlying storage can have separate lifecycles. Even if a provider exposed a “run GC now” action and the old object stopped resolving, the result would not prove that every physical representation had disappeared. GC is a deeper abstraction than branch deletion, but it is not the physical bottom of the provider’s system. This is why the desired right must concern the terminal outcome across a declared universe, not one favoured implementation command.
There are practical answers. The service must authenticate authority, detect shared references, protect other users, check legal holds, coordinate distributed storage and prevent account takeover from becoming instant permanent destruction. Those reasons justify validation, high-friction confirmation, delays and internal implementation. They do not logically require the final decision to remain discretionary once every condition has been satisfied. Complex infrastructure can be hidden behind a safe operation, just as payment systems expose a transfer without giving customers access to settlement databases.
I initially used ownership language too casually: “my repository” seemed to imply “my right to destroy every stored copy.” The dialogue corrected that shortcut. The repository can contain my intellectual work while the storage medium, service database and operational logs belong to another entity. Personal data law may apply to some content and not to other content. Contract, copyright, privacy, organisational policy and third-party rights can allocate different powers. Ownership is too blunt to derive root access or an absolute deletion result.
The argument survived because it did not actually require that shortcut. What I wanted was a product capability and, perhaps eventually, a broader right to choose an irreversible provider-controlled terminal state for material I am authorised to govern. That is closer to informational self-determination and exit than to physical property. It can be bounded by other people’s rights and lawful retention without reducing the user to a petitioner whose preferred outcome is merely advisory.
Authority and observability form a matrix
I eventually separated four powers that deletion interfaces often collapse:
| Power | Question | Typical cloud allocation |
|---|---|---|
| Claim-right | Can I require another actor to erase the data? | The user may possess it under law or contract. |
| Trigger authority | Can I directly initiate the definitive lifecycle? | Often partial, mediated or absent. |
| Implementation authority | Who chooses and operates the technical mechanism? | The provider or its processor. |
| Verification power | Who can obtain evidence that the promised state was reached? | Provider high, user limited, regulator potentially higher. |
My argument asks for stronger claim, trigger and verification powers while leaving implementation authority with the service. It also clarifies the difference between a right to deletion and a right of deletion. The first lets me require someone else to produce an outcome. The second would give me a safe capability to initiate that outcome myself, within the provider’s system and subject to legitimate checks. Cloud computing turns direct technical agency into institutionally mediated agency; the question is how much agency the mediation should preserve.
Authority and observability also vary independently. I may observe that a historical identifier still resolves while lacking authority over provider-side reclamation. In many privacy systems the relation is reversed: the user can request erasure but cannot inspect the production databases, processors, backups and internal queues. A provider can be transparent by telling me what it claims to have done, observable by exposing relevant state, and verifiable by giving me evidence that can test the postcondition. These are progressively stronger properties. Transparency without observability may be little more than a well-written assertion.
| Low observability | High observability | |
|---|---|---|
| Low authority | The user can neither initiate the terminal state nor inspect it. This is dependence without useful evidence. | The user can detect residual state but cannot remove it, as when a known identifier still resolves. |
| High authority | The user can issue a binding request but must trust hidden implementation and reporting. | The user can initiate the process and examine evidence about its declared postconditions. |
The lower-right condition is the design target, but even it has degrees. An interface can be transparent by describing policy in readable language. It becomes observable when the user can see state transitions, deadlines, exceptions and relevant inventories. It becomes verifiable when the evidence is sufficiently independent or mechanically testable to challenge the provider’s assertion. These words are often used as pleasant synonyms; keeping them separate prevents a detailed help page from being mistaken for proof.
The refined claim that came out of this part of the discussion is one sentence I would keep: You do not need to give me control of the infrastructure. Give me meaningful control over the terminal state. That sentence leaves room for provider expertise and shared-system safety while refusing the idea that implementation complexity automatically settles the allocation of agency.
The GDPR is a starting point and not the final answer
The law says erase but at what technical layer
The General Data Protection Regulation is highly relevant because it turns erasure into a legal entitlement in defined circumstances, but I do not want to treat it as an absolute philosophical definition. Article 17 gives a data subject a right to obtain erasure of qualifying personal data when one of its grounds applies, subject to explicit exceptions. Article 19 requires communication of erasure to recipients in applicable cases and lets the data subject request information about those recipients. Articles 24 and 25 place responsibility for appropriate technical and organisational measures, and for demonstrating compliance, on the controller. The official consolidated text is available through EUR-Lex.
The Regulation deliberately speaks at a technology-neutral legal layer. It does not prescribe disk sectors, Git object collection, database commands or backup formats. That is sensible because infrastructures change. A data subject normally receives a claim against the controller, while the controller selects and operates the means. Supervisory authorities and courts can assess whether those means comply. The law may therefore entitle me to the outcome called erasure without giving me direct observational access to every technical state by which that outcome is implemented.
During the dialogue, I initially treated the absence of storage-layer language as a missing answer. I then revised that interpretation. Technology-neutrality is a feature of the Regulation, not an accidental silence. A law written around one filesystem operation would age badly and could encourage formal compliance at the wrong layer. The unresolved difficulty is operational translation: if the legal word is erasure, a controller still needs to decide whether deactivation, de-indexing, logical deletion, backup suppression, key destruction or physical reclamation satisfies the right in the particular context.
Article 17 is also conditional, not a universal incantation that makes all competing duties vanish. It states grounds for erasure and exceptions that include freedom of expression and information, legal obligations, public interest, certain archiving and research purposes, and legal claims. The careful argument is therefore not that every user request must destroy every bit. It is that a valid request, after applicable scope and exceptions are determined, cannot be answered merely by pointing to the limitations of an ordinary product workflow.
Legal observability is real but indirect
This is not a model in which the provider simply gives itself the final word. Article 5 requires accountability, Article 24 requires the controller to implement and demonstrate compliant measures, and Article 58 gives supervisory authorities investigative and corrective powers, including powers relevant to ordering compliance and erasure. The controller initially chooses the means; law, regulators and courts can judge their sufficiency. The user still depends on institutional rather than direct technical observation for much of that review.
There is no obvious general GDPR right to inspect every disk block, cache, replica and backup, or to operate the controller’s deletion machinery personally. Article 15 provides substantial access rights concerning processing, categories, recipients and retention periods, and Article 19 provides a form of propagation visibility concerning recipients. I think it is useful to call this legal observability: another actor is obliged to disclose information even though the data subject cannot inspect the underlying systems. That is my analytical term, not a formal term used by the Regulation.
Layer-specific erasure is already visible in European law. In Google Spain v AEPD and Costeja González, the issue concerned links returned by a search engine for a person’s name. De-referencing at the search layer could be legally meaningful while the original newspaper material remained available at its source. “Gone from a named search result” and “the source no longer exists” are different claims, yet the first can still protect a real interest.
Backups show the same issue from another direction. The European Data Protection Board’s coordinated enforcement report on the right to erasure found that some controllers confused deleting an account or profile with fulfilling an erasure request while retaining further personal data internally. It recommended mapping data and storage locations, highlighted automatically generated records as a useful proof-of-deletion practice, and addressed the difficulty of modifying backups. Where backups cannot sensibly be edited record by record, controllers still need procedures that track erasure, prevent restored data from returning to ordinary processing, verify the outcome and demonstrate it. See the EDPB 2025 coordinated enforcement report.
Article 19 struck me as especially interesting because it adds a propagation dimension: where applicable, the controller communicates erasure to recipients and provides information about those recipients on request. It does not grant the data subject a map of every sector or a live console into every processor. It does recognise that deletion has edges, not only a source node. My phrase legal observability captures this indirect structure: duties of disclosure, documentation and accountability let an individual or regulator know more than the interface alone reveals.
The controller–processor distinction also prevents an easy slogan. A hosting platform may be a controller for some account and service operations while acting as a processor for customer-directed content in another context. Roles depend on purposes and means, not only on which company owns the servers. The practical lesson for this essay is modest: product documentation cannot by itself settle the legal analysis, and a legal entitlement does not automatically specify a particular garbage-collection command. Both layers must be mapped before a strong conclusion is justified.
These rules matter, but they do not settle my broader question. First, a private repository containing code, a novel, mathematical notes or an unpublished photograph may not consist of personal data as the GDPR defines them. The desire to destroy one’s hosted intellectual work can still be a serious autonomy and contractual interest. It points towards a broader idea of digital informational self-determination over user-controlled hosted objects. Second, the GDPR is primarily an accountability model. It requires the controller to comply and to demonstrate compliance, but it does not generally turn definitive erasure into a user-operated technical primitive or give the individual all the internal evidence available to the controller and regulator.
This is where a constructive criticism becomes possible. The GDPR protects control in law more clearly than control over the terminal outcome as a directly triggerable system capability. Its technology-neutrality is necessary, yet the user may possess the underlying right while having the least technical observability of its fulfilment. A next generation of digital rights could distinguish the right to request erasure, the right to trigger a definitive process, the right to observe its progress and the right to receive evidence describing the postcondition actually achieved.
I would add a fourth distinction that emerged only after several iterations: a right to execute the mechanism is not required for a right to determine the outcome. The controller can retain implementation authority while the user holds a binding claim, a direct trigger and an evidence right. This is less dramatic than handing everyone a storage-administration console and much more useful. It converts “please consider deleting this” into a governed lifecycle whose alternative outcomes are completion or a reasoned, reviewable exception.
I would still avoid declaring GitHub’s lack of a user-facing server-GC control unlawful. There is no general rule requiring that particular interface, and GitHub’s controller or processor role can vary with the account and processing context. A different claim would be more serious: if a valid Article 17 request covered personal data under a provider’s control, no exception justified retention, and the provider refused erasure solely because its ordinary product process did not offer deeper cleanup, the product policy would not decide the legal outcome. Product eligibility for support is not the same thing as a data-protection obligation.
Hard delete should be an explicit system primitive
A terminal state needs policy as well as code
The design proposal that emerged from this reasoning is a user-triggerable definitive-erasure operation. It would not promise deletion from an undefined universe and it would not expose raw infrastructure. It would let an authorised user select an irreversible terminal state covering every representation under the provider’s declared effective control, except for precisely identified legal or third-party constraints.
SOFT DELETE remove from ordinary visibility and use retain a disclosed recovery window permit restoration HARD DELETE validate authority and shared interests identify any lawful retention constraint purge live objects and provider-controlled references invalidate provider caches and recovery functions make backups incapable of restoring the object to active use complete physical or cryptographic reclamation under policy provide evidence and disclose any residual state
The normal safe path can remain soft deletion. Hard deletion should require strong reauthentication, explicit explanation, perhaps a waiting period, and extra approval for shared organisational resources. The user should be told that recovery will be impossible. Those protections respect both safety and autonomy. They should culminate in a genuine point of no return; otherwise hard delete is merely soft delete wearing a stern hat.
The provider would need to evaluate a policy object before starting destructive work. That policy should bind the authenticated principal, the target, the declared universe, the recovery choice, known shared interests, retention constraints and a completion deadline. The point is not that every service should copy one schema; it is that “permanent” should be represented as a first-class, inspectable request rather than inferred from a generic delete call.
{
"operation": "hard-delete",
"target": "repository/example-project",
"requestedUniverse": "provider-controlled",
"recovery": "none",
"confirmSharedInterests": true,
"completionDeadline": "policy-defined",
"acknowledgeIrreversibility": true
}
The operation should also have typed alternative outcomes. If the service cannot comply because of a legal hold, statutory retention rule or independent third-party right, it should return PARTIAL_WITH_DECLARED_EXCEPTION or REJECTED_WITH_REASON, not quietly keep a recoverable copy while displaying “permanently deleted.” An exception should identify its scope, authority, access restrictions and expected review or expiry condition. Theoretical possibilities should not become blanket excuses for indefinite retention.
There is an important timing correction here. Immediate interface disappearance and immediate physical completion need not be the same promise. A provider may need a bounded period to propagate tombstones, rotate backup media or confirm processor action. Honesty requires a state such as PENDING_IRREVERSIBLE_ERASURE until the deadline, together with a statement about whether the user, provider or support staff can still recover the data during that interval. “Scheduled” is a respectable result. “Complete” is a different one.
A receipt reports evidence rather than omniscience
I would model the provider’s workflow as a state machine whose progression is visible to the authorised user:
REQUESTED -> AUTHORITY_VALIDATED -> SHARED_INTERESTS_CHECKED -> RETENTION_RULES_CHECKED -> LIVE_STATE_PURGED -> REFERENCES_AND_CACHES_PURGED -> RECOVERY_DISABLED -> BACKUP_RULE_APPLIED -> VERIFIED -> COMPLETE Possible bounded outcomes PARTIAL_WITH_DECLARED_EXCEPTION REJECTED_WITH_REASON
Completion should produce a deletion receipt. The receipt would not be a magical proof that no forgotten electron exists. It would be a signed, versioned statement of scope, state and evidence: what object was covered, which systems formed the declared universe, which postconditions passed, when recovery became impossible, how backups behave, whether processors were included, which exceptions remain and what lies outside the provider’s authority.
{
"request": "irreversible-erasure",
"scope": "all-representations-under-provider-control",
"liveState": "purged",
"historicalReferences": "purged",
"providerCaches": "purged",
"userRecovery": "disabled",
"providerRecovery": "disabled",
"backupState": {
"activeRestore": "erasure-replayed",
"residualExpiry": "declared-date"
},
"processors": "confirmed",
"legalRetention": "none",
"externalCopies": "outside-provider-authority",
"evidence": "provider-signed-attestation"
}
Such a receipt improves transparency and observability. Whether it provides strong independent verifiability depends on the trust model. Provider-signed evidence is still produced by the provider. Tamper-evident logs, independent audits, secure hardware attestations and verifiable-deletion protocols could strengthen it, but every mechanism still proves a bounded property. The honest output might contain PASS, PENDING, EXCEPTION and UNKNOWN. That is more informative than DELETED = true and more respectful of the user’s intelligence.
A receipt also gives support teams, auditors and regulators a common artifact. The user can compare the promised universe with the systems listed; an auditor can test whether controls actually implement those transitions; a restored backup can be checked for replay of the erasure decision. The receipt should avoid retaining the erased content itself, of course. A deletion proof that quietly becomes the most durable copy would be an impressive administrative own goal.
End-to-end encryption changes the question
Private and provider-blind are different promises
At this point I asked whether an end-to-end encrypted Git system would solve the problem. The answer is both more interesting and more precise than yes or no. Deletion asks whether the provider still possesses a representation. Provider-blind encryption asks whether the provider ever possessed the ability to understand that representation. It moves part of the problem from storage control to key control.
The distinction corrected another assumption in my original language. A private repository generally means that access is restricted by identity, policy and platform controls. The provider still operates the service and may retain technical capability to process plaintext for authorised features. Provider-blind encryption makes a different architectural statement: the provider does not possess the key required to interpret content. Private says, in simplified form, “the provider is not normally allowed to read this.” Provider-blind says “the provider is cryptographically unable to read this within the design and threat model.”
user device
plaintext repository
|
| encrypt locally with key K
v
provider boundary
ciphertext only
|
+-- live storage
+-- replicas
+-- snapshots
+-- backups
provider never receives K
If the provider stores only authenticated ciphertext and never holds a decryption or recovery key, it can retain multiple copies without being able to reconstruct the repository. Destroying the final valid copy of K can make the plaintext computationally irrecoverable even while ciphertext remains. Research on self-revocable encryption develops this general idea for cloud storage using locally held keys, while also showing that indexes and metadata require separate treatment.
This produces two meanings of complete deletion. Ontological or representational deletion means that the bits or objects no longer exist. Effective or cryptographic deletion means that surviving representations can no longer be transformed into the protected information by any actor within the stated threat model. They are not literally identical. The ciphertext does not disappear in a mathematically certified puff of smoke. For the goal “nobody else can ever recover my private source code,” however, strong cryptographic irrecoverability may be operationally equivalent to physical deletion and may provide a better assurance model than trusting an opaque provider-wide garbage-collection process.
The qualification “within the threat model” matters. Absolute claims such as “inaccessible by any means forever” must account for endpoint malware, memory exposure, weak implementations, copied keys, screenshots, collaborators, provider recovery keys and future cryptanalysis. An adversary can retain ciphertext now in the hope that later techniques will decrypt it, so long-lived secrets require crypto agility as well as strong present-day algorithms. NIST’s current post-quantum guidance distinguishes the serious migration problem for vulnerable public-key systems from the outlook for strong symmetric encryption, noting that AES-192 and AES-256 are expected to remain safe for a very long time under current knowledge. See the NIST post-quantum cryptography FAQ. Even cryptographic deletion is a claim with assumptions, scope and evidence.
Encryption does not eliminate the deletion problem. It compresses it. Instead of locating a large repository across many provider systems, I need to account for a small cryptographic capability. Where does K exist? It may be in a device keychain, a hardware token, a password manager, another computer, an offline recovery copy or a backup. Deleting a 32-byte capability everywhere is far more tractable than deleting gigabytes across an opaque cloud, but the key still has a lifecycle. The deletion question has moved to a smaller and more user-observable object.
The full key-state question is therefore more exact than “did I delete the key?” It asks whether a valid key remains in process memory, local secure storage, synced credentials, recovery material, collaborator devices, exported archives or provider escrow; whether old key versions can still decrypt historical snapshots; and whether rotation truly retired the prior capability. In a sovereign mode, the final user-controlled recovery copy is the terminal object. Destroying it is powerful precisely because the provider cannot undo the choice. That power should be optional, explicit and accompanied by very clear warnings.
The ciphertext paradox
If the provider retains ciphertext after every valid key has been destroyed, does the repository still exist? Physically, a representation remains. Semantically, no actor in the declared threat model can recover the source tree. Operationally, the user’s confidentiality objective may be satisfied even though an ontologist would refuse to call the bytes nonexistent. This apparent paradox disappears once the deletion target is stated: destroy the representation, destroy access, or destroy intelligibility. Cryptographic erasure primarily targets the third by eliminating the capability that connects ciphertext to meaning.
That is why I resist both easy conclusions. It is too strong to say key destruction literally deletes every copy, and too weak to say it changes nothing because ciphertext remains. For many cloud threat models, computational irrecoverability is the relevant terminal state. For other purposes—storage minimisation, metadata privacy, ecological cost, or a requirement concerning physical media—the remaining representation still matters. The architecture must say which goal it satisfies.
A provider-held recovery key changes the guarantee. If the service can recover the repository when I lose my key, the provider still possesses ultimate intelligibility. That may be a reasonable convenience option, but it is not the strongest provider-blind model. The user should be allowed to choose among provider recovery, a trusted third-party or personal recovery method, and no recovery at all. Recovery should be an informed option, not a capability silently retained against the user’s selected threat model.
Encryption therefore added another dimension to the deletion model: intelligibility. I now want to ask four separate questions. Who has rights over the object? Who can cause it to be deleted? Who can observe whether it remains? Who can understand it while it remains? In a provider-blind architecture, the service may have storage authority and deep knowledge of the ciphertext’s physical lifecycle while having no authority over its meaning. The user may know less about the storage yet retain the only capability that makes the content intelligible.
Encrypted Git remotes are not purely hypothetical. git-remote-gcrypt aims to provide confidential and authenticated Git storage over untrusted hosts by encrypting the remote representation for designated participants. It demonstrates feasibility while also illustrating tradeoffs. A full provider-blind Git platform could not straightforwardly render plaintext source on the web, index code, compute ordinary server-side diffs, scan secrets, run conventional CI, analyse dependencies or offer every collaboration feature without moving trusted processing to clients or explicitly authorised agents.
That tradeoff suggests a choice instead of a universal mandate. An ordinary private repository can preserve provider-managed recovery and rich server-side features. A provider-blind repository can sacrifice some convenience so that the host cannot interpret its contents. A sovereign mode can go further by denying the provider any recovery key and making loss of the final user-controlled key permanent. The architecture should describe these as different trust models, not hide them all behind the word “private.”
Is cryptographic agency a basic digital right
A right to choose who can make information intelligible
I do not think current law establishes a general right to end-to-end encrypted Git hosting. The stronger question is normative: should users have a right to choose an architecture in which an infrastructure provider is cryptographically incapable of reading private content? I would call this a right to cryptographic agency. It would include choosing who holds keys, whether the provider can decrypt, whether recovery exists, who can perform recovery, and when the final recovery capability is destroyed.
This proposed right should not be confused with a guarantee that every service can perform every feature over encrypted content, or with a denial that lawful investigations present difficult public questions. It is first a claim about meaningful choice. If a service offers provider-readable convenience, user-held confidentiality and a no-recovery sovereign mode, people can select the distribution of capability appropriate to their work. A right to cryptographic agency would protect the availability and intelligibility of those choices, not make the operational costs vanish.
This is broader than confidentiality. It redistributes operational and epistemic power. In an ordinary private cloud service, the provider may promise “we will not read this except under stated conditions.” In a genuine provider-blind system, the architecture can say “we cannot read this because we do not possess the capability.” Policy says “we will not.” Cryptography can make the statement “we cannot.” Those assurances respond differently to employee access, compromise, commercial pressure and state demands.
It would be too simple to say that users want E2EE while every company and government opposes it. Many services deploy end-to-end encryption. WhatsApp states that personal messages and calls remain between the participants and cannot be read by WhatsApp. Telegram offers ordinary cloud chats for multi-device convenience and separate device-specific Secret Chats using end-to-end encryption. These services differ substantially, but together they demonstrate that recoverability, cloud functionality and provider-blind confidentiality can be exposed as architectural choices.
Apple provides an especially revealing current example. Apple states that users in the United Kingdom who had not already enabled Advanced Data Protection no longer have the option to activate it for the additional iCloud categories covered by that feature, while also stating that it has never built a backdoor or master key. See Apple’s guidance on Advanced Data Protection in the United Kingdom. The technical ability to offer stronger user-held encryption therefore intersects with provider policy and state authority. Whether a user may choose provider-blindness is no longer a purely technical setting.
The 2021 Proton case involving a French climate activist shows why E2EE does not mean total invisibility. Proton reported that a binding Swiss order could require the collection of account-related information such as an IP address, while the encrypted message content itself could not be surrendered as decrypted plaintext. See Proton’s account of the case. Content and metadata occupy different protection layers. A provider-blind Git service might still know an account identity, repository size, access times, IP information, collaborator relationships and payment data even if it cannot understand the source code.
State authorities and law-enforcement organisations argue that systems which make content inaccessible even under lawful authority can obstruct investigations of serious crime and the protection of vulnerable people. A published international statement on end-to-end encryption and public safety asks providers to facilitate lawful access under authorisation and safeguards. Privacy and security advocates respond that a decryption capability deliberately available to someone other than the intended keyholders changes the security architecture for everyone and may become a target for misuse or compromise.
This conflict cannot be solved by pretending one side has no legitimate concern. Serious investigations and public safety matter. Personal confidentiality, cybersecurity, professional secrecy, political freedom and protection from abusive power also matter. The architectural question remains sharp: who should possess the ultimate capability to reveal private information—the individual, the platform or the state? “Who holds the key?” is political as well as cryptographic.
My own position grew more careful during the conversation. Companies are not uniformly enemies of encryption, governments are not a single actor, and users do not all prefer irrecoverability. A person may rationally choose provider recovery for family photographs and refuse it for confidential research. The design principle is plural but not vague: disclose who can decrypt, separate content from metadata claims, make recovery capabilities visible, and do not call a provider-held master capability “end-to-end” merely because encryption occurs somewhere in the pipeline.
For my deletion argument, the most important consequence is that provider-blind encryption reduces dependence on the provider’s willingness or ability to remove every physical copy. The provider may control the continued physical existence of ciphertext while the user controls the continued existence of its meaning. End-to-end encryption therefore does not abolish the deletion problem. It changes who has the power to make deletion meaningful.
A future interface should expose the choice honestly
Two decisions should not be hidden inside one privacy label
The final design I arrived at combines two decisions that cloud interfaces usually keep hidden: who may understand the data while they exist, and what terminal state should apply when the user is finished with them. A repository-creation interface could distinguish standard private hosting from provider-blind and sovereign modes. The deletion interface could separately distinguish recoverable removal, definitive provider-side erasure and cryptographic destruction.
Privacy model Standard Private provider manages access and recovery full server-side features Provider-Blind content is end-to-end encrypted provider cannot read repository plaintext selected server-side features are unavailable Sovereign provider-blind encryption no provider recovery key user controls every declared recovery capability Deletion mode Remove Repository recoverable for a disclosed period Permanent Provider Erasure purge every representation under provider control disclose exceptions and residual deadlines Cryptographic Destruction destroy every declared decryption capability surviving ciphertext becomes irrecoverable
No option should be described with a stronger promise than its architecture supports. Standard Private may offer excellent confidentiality by policy and access control without being provider-blind. Provider-Blind may protect content while exposing metadata. Permanent Provider Erasure may cover every declared internal representation without reaching an independent external copy. Cryptographic Destruction may make plaintext infeasible to recover while leaving ciphertext physically present. Precise language is part of the security model.
The interface should also show the cost of each choice in human terms. Stronger irreversibility removes rescue. Provider-blindness can remove server-side search, scanning and web collaboration. Sharing creates new keyholders and new copies. A recovery delegate reintroduces another capability that must be accounted for. These are genuine tradeoffs, but users can understand them when they are presented as choices instead of being silently resolved by the provider.
This approach changes the meaning of user responsibility. Autonomy does not mean one careless click should destroy years of work. It means a properly authenticated adult can review the consequences, accept them and choose an irreversible state when continued existence is the greater risk. A safe default and a sovereign option can coexist.
I would also separate configuration time from deletion time. At creation, the user chooses the confidentiality and recovery architecture: provider-readable private, provider-blind with recovery, or sovereign without provider recovery. At deletion, the user chooses the desired terminal state: remove from normal use, begin definitive provider erasure, destroy declared keys, or combine the latter two. The confirmation screen then shows the effects on content, metadata, collaborators, backups and recovery. This sequencing prevents an irreversible decision from being disguised as an ordinary privacy toggle.
After submission, the interface should remain useful. It should show the current lifecycle state, the declared completion deadline, which processors have acknowledged the request, whether a legal or third-party exception applies, and when the receipt becomes available. If the answer is uncertain, uncertainty should appear as data, not disappear behind an animation. A spinner can represent pending work; it cannot transubstantiate pending work into completion.
What remains unresolved
What I would test next
No design can promise deletion from an undefined universe. Another person’s independent copy, a screenshot, human memory or a consequence already produced may remain outside the original provider’s control. Exact byte copies are easier to identify than transformed or aggregated information. Legal obligations and third-party rights can sometimes justify retention. A forgotten internal system can undermine a provider’s declared inventory. Cryptographic deletion can fail through endpoint compromise, residual key copies or flawed implementation. Metadata can survive even when content becomes unreadable.
Deletion receipts do not remove institutional trust; they make its content more explicit. Independent audit and technical attestation can improve assurance, but they also operate within declared architectures and threat models. Physical non-existence is a stronger claim than non-addressability, user non-recoverability or cryptographic irrecoverability. Sometimes the latter properties fully satisfy the user’s real goal. The system should identify which one it provides.
The next technical work should turn the conceptual model into falsifiable prototypes. I would test a provider-side hard-delete state machine against shared references, delayed processors, backup restoration and cancellation boundaries; define receipt fields that disclose useful evidence without retaining sensitive content; and model key destruction across multiple devices and recovery modes. I would also test the interface with users, because a technically precise receipt can still fail if nobody can understand the choice before committing to it.
A separate research track belongs to learning systems. It should begin with the actual guarantees and verification limits of machine-unlearning methods, not with an analogy imported from Git. The object-versus-influence distinction is already enough to show why the questions are connected, while the technical answers may differ radically. Postponing that section was not an omission I wanted to hide; it was a boundary set by current understanding.
The collaboration lesson is methodological
The AI did not supply one decisive answer. Its value was iterative pressure: generate a formulation, expose an ambiguity, compare another domain, locate a source, then invite me to accept or reject the revision. The danger was equally clear. A model can make an unresolved idea sound inevitable, merge legal entitlement with technical capability, or fill an evidential gap with a plausible mechanism. The safest collaboration combined generative breadth with deterministic checks, primary documents and explicit statements of uncertainty.
That experience mirrors the article’s argument. A fluent answer, like a Delete confirmation, is a claim about an underlying process. Confidence in the interface is not the same as evidence of the postcondition. In both cases, human agency improves when the system exposes scope, state, assumptions and limits, leaving consequential judgment with the person who bears the result.
The law also remains an incomplete framework for the broader autonomy claim. Personal-data protection addresses important interests, yet people may want definitive control over private code, research, writing, photographs or other hosted objects that do not fit neatly into Article 17. Whether a broader right to user-triggerable irreversible erasure or cryptographic agency should exist is a question for system design, contracts, policy and democratic debate.
My conclusion is therefore more demanding than “providers should explain deletion better,” but narrower than “users must control every disk.” The user does not need control of the infrastructure. The user needs meaningful control over the terminal state, a declared universe for the promise, and evidence proportionate to the claim. Where provider-blind encryption is technically viable, the user should also be able to decide whether the infrastructure ever receives the power to understand the data.
A deletion system should not merely expose a Delete operation. It should expose the postcondition it claims to have achieved and the evidence available for that claim.
The Delete button is making a promise. The next step in deletion design is to stop hiding the promise inside one word.