I am angry.

I quite like the phrase “we made rocks think”, even though it is not really true. It compresses generations of work into four words. People dug materials out of the ground, learnt their properties, built machines precise enough to shape them and kept teaching the next person what they had learnt. The result now sits on desks and in pockets almost everywhere. I think that is incredible. A person with an ordinary computer can learn a subject their school never offered. They can make music, investigate a claim or build something with people they have never met. Computers give ordinary people a reach that once belonged mostly to wealthy institutions. I am not angry about that. I am angry about the systems we keep building around it.

Someone buys a machine that still works then discovers that repairing it is forbidden, illegal or deliberately impractical. A maintainer spends evenings keeping software they once built for colleagues, friends or simply themselves alive while faceless institutions build immensely profitable products on top of it without returning material value. An institution tells a person that its database is right and expects them to disprove a system they cannot inspect. These decisions affect whether people keep their work, money, access and time.

Some limits are real. No provider can guarantee active support forever. Security can justify restrictions and a service may genuinely need to refuse a request. I do not expect every system to serve every person indefinitely. I expect the people exercising power to state the limit honestly, take responsibility for its consequences and provide a workable route when they are wrong. Too often they do not. One organisation keeps the authority while somebody else carries the risk. A test proves one narrow property and gets advertised as proof of the whole system. Responsibility lands on the person closest to the failure even when they could not change the decision that caused it. The cost does not disappear. Somebody loses access, replaces a working product or spends months trying to get an answer. That gap is what this essay is about. It appears in software, public administration, education, employment and commercial contracts. The details differ but the same questions keep returning. Who had the power to make the decision? Who had to live with it? What happened when it was wrong? I do not want to force every case into one theory. Some of the evidence complicates positions I would otherwise prefer. That is part of the point. This anger of mine is useful only when it can survive contact with the facts and narrow itself when the facts demand it.

I should also be honest about geography. Most of the detailed cases in this essay come from Australia, the United Kingdom, the United States and Europe. Those are the places whose institutions, laws and English-language records I can examine most readily. They are not a map of where these problems matter and they do not show that one region’s remedies will transfer cleanly to another. The experiences and institutions of much of Africa, Asia, Latin America, the Middle East and the Pacific are underrepresented here, as are Indigenous perspectives within and beyond the countries I discuss. That limit belongs to this essay, not to the people and places it has failed to cover. Where I make a wider claim, it should remain open to evidence from contexts I do not yet understand.

These questions also sit inside existing human rights rather than a private theory of good software. Equality, privacy, expression, education, work, participation and effective remedy do not cease to matter when an institution exercises power through a database or an interface. A badly labelled button is not automatically a human-rights abuse and a reference to dignity does not decide every design dispute. Human rights provide a floor for asking what the system does to people, what interests are at stake and what remedy exists when those interests are harmed. The United Nations’ digital compact ties digital governance to international human rights while the UN Guiding Principles on Business and Human Rights distinguish state duties, business responsibility and access to remedy.¹

Some systems deserve criticism even when they work exactly as designed. A system built to censor lawful dissent, manipulate a person, exploit a dependency or inflict unjustified harm does not become acceptable because its implementation is reliable. Better engineering can make a bad purpose more effective. This essay cannot turn every moral question into a defect waiting for a test. The purpose has to be examined before the implementation: who benefits, who is acted upon, what authority permits it, which rights it limits and whether the people affected can refuse or challenge it. Some public functions legitimately require observation or coercive power. That makes the purpose, limits and review more important rather than making technical correctness a complete defence.

I want the anger to lead somewhere. That means naming the decision, finding the person or institution that could have made it differently and asking what should happen now. “Technology should be better” is too vague to help anyone. I refuse to sit on the side-lines for even a moment longer.

I. The signs we ignored
II. The terms we never chose
III. The work behind the promise
IV. Who gets to become capable
V. What survives us
VI. What counts as progress

I. The signs we ignored

1. When the record is believed

I have learnt to distrust the peculiar authority of a computer record. It appears precise. It can be repeated instantly. It arrives through a system an organisation has paid for, integrated and trained its staff to use. The person disputing it may have only a recollection, an unexplained discrepancy and the increasingly desperate conviction that something is wrong. Neither side is always right. People misremember and sometimes lie. Records can be accurate even when their implications are unwelcome. But the two sides do not enter the dispute as equals. One controls the system, its logs, its supplier and the process for challenging the result. The other has to explain an output from machinery they are not allowed to examine.

The 2019 Horizon Issues judgment in Bates v Post Office found that Fujitsu could alter branch accounts remotely without the subpostmaster’s knowledge or consent. The court distinguished branch information from audit records and found that an earlier Post Office statement about remote access was false.² The point is narrower than saying remote access caused every discrepancy. A subpostmaster’s apparent control of an account was not the whole story of who could change it. Establishing even that required access and resources unavailable to someone ordered to account for a shortfall.

The Horizon Inquiry’s July 2025 report describes the wrongful accusations and serious harm caused by the scandal. It treats redress and independent legal help as part of the response. The Inquiry’s separate In Your Own Words project records experiences shared by subpostmasters, family members, employees and communities affected by the scandal. Those accounts concern human impact rather than the technical cause of each discrepancy. Correcting a record cannot restore years of a person’s life.³ I find the asymmetry unbearable. The organisation controls the system and the evidence needed to challenge it. A person disputing the result should not have to reverse-engineer a system they cannot access to show that the organisation might be wrong.

People disputing a record can still be wrong or dishonest. The answer is a process that does not let the organisation’s machine win every uncertainty by default. Somebody has to decide who carries the uncertainty while the facts are checked. An investigation should separate the record from the conclusion drawn from it. What does this entry show? Which processes can generate or alter it? Which identities represent a human being and which represent a service acting on someone’s behalf? What happened between the original event, the stored value and the report now being used? Which parts can be checked independently? Those questions are technical. The organisation still decides whether they can interrupt enforcement. Both parts matter. Beautiful logging offers little protection if a person cannot obtain the relevant records, the organisation cannot interpret them or the people handling the dispute must accept the original result anyway.

Robodebt supplies a different Australian case. The Royal Commission called for understandable explanations, clear review routes and independent scrutiny of automated decision rules. Its recommendations also addressed hardship and debts under dispute.⁴ People could not shop around for another welfare system. The protections had to exist inside the public service itself. Take two short income histories. In the first, the person receives nothing in one period and 2,000 in the next. In the second, they receive 1,000 in each. Both add up to 2,000 but they are not the same history. A total tells us how much there was overall. It does not tell us when the income arrived.

A transformation can therefore be computationally correct and still support a conclusion its inputs cannot justify. The machine does not need a programming error. It can execute the calculation exactly as instructed. The error occurs when somebody treats a convenient summary as evidence of something it cannot show. That is why a technical audit cannot stop at whether the implementation matches the specification. Somebody must ask whether the specification should be allowed to produce the decision being made. When a rule affects a person’s rights or life, successful execution is not enough.

There were people who objected. In September 2024, the Australian Public Service Commissioner announced findings of 97 Code of Conduct breaches involving twelve people in the centralised Robodebt inquiry. The statement contrasted senior failures with frontline and junior staff whose concerns were not heard.⁵ Some people did notice the signs. They tried to make the organisation notice too. A history that remembers only the final official acknowledgement risks erasing the work, risk and frustration of the people who were right earlier. It is not enough to hope for braver or more conscientious staff. A worker needs somewhere to take a concern and somebody with the authority to act on it. Another acknowledgement means little if the organisation continues treating the disputed evidence in the same way.

The balance is difficult. Public bodies have to administer large systems, protect public resources and reject unfounded claims. They cannot stop every decision indefinitely whenever somebody objects. They can still pause collection, sample decisions independently, disclose relevant records or review a case before serious harm becomes difficult to reverse. The need to decide does not make the current burden of proof fair. The design should start with the consequences of being wrong in each direction. What happens if a disputed demand is enforced and later withdrawn? What happens if it is paused and later upheld? Which losses are reversible? Who can bear them? An institution should not calculate only the cost of delay to itself while treating the cost of an incorrect decision to the affected person as somebody else’s concern.

A record may contain several different kinds of statement. A sensor produced a reading. Software transformed the reading. An application associated it with an account. A rule treated the transformed value as evidence of an event. An institution decided the event created an obligation. Each step needs its own justification. A sensor reading alone does not mean that a person owes money. This problem becomes especially important when a supplier describes data as an audit trail. An audit trail can show what a system recorded without proving that the recorded event occurred as represented. It can preserve an erroneous calculation perfectly. It can also omit relevant actions performed outside the component being logged. Immutability protects against certain changes to a record; it does not make the original entry correct.

The engineering task is to retain the information needed to distinguish these possibilities. An important transaction should identify its origin, the rule applied and any major change to the information. The account should preserve which version of the rule operated at the time. Manual changes should remain distinct from the original observation. A correction should not make an earlier decision appear as though it had always relied on accurate information. That need not mean publishing the entire database. Records can contain other people’s private information and details that would expose a system to attack. A disclosure process can separate evidence about the disputed decision from unrelated records, with independent inspection where necessary. The institution cannot demand proof of an error while withholding every way to examine it.

Uncertainty also has to be allocated. Suppose a system produces a discrepancy and the cause remains unknown. The institution might continue an investigation, pause a collection process, place a temporary limit on an account or impose a penalty. These responses do different things to the person concerned. The apparent neutrality of an unresolved investigation does not extend to its consequences. Someone has decided what will happen while the uncertainty remains. That decision needs an express basis. A temporary restriction might be justified to prevent serious immediate harm. It should have a defined purpose, an appropriate review point and a route to provide missing evidence. If the action depends on treating the disputed record as already proven, calling the process provisional achieves little.

A human reviewer is useful only if the review can change the conclusion. A person who reads the same screen and confirms that the system produced the same result has repeated the output, not examined it independently. The reviewer needs the reasoning and authority to question the rule, the data or their use. Where the reviewer cannot do that, whoever decides what happens next should know the limit. This also explains why an institution’s error rate cannot dispose of an individual complaint. A system can be accurate for most people and wrong about this person. A low rate can still produce many important errors at scale. The individual case needs evidence about the individual decision. Aggregate performance helps decide whether the system should be used; it cannot substitute for investigating a specific contradiction. A system exercising serious authority should distinguish an allegation, a conclusion and a finding. Its interface should not collapse them into one status merely because the organisation wants a simple queue. That status determines how staff speak to the person, which actions are available and what explanation can be given. The data model is part of how the organisation exercises power.

The difficulty is not resolved by assuming that people are always right about themselves. Accounts can be incomplete or false. The requirement is a process in which neither a person’s assertion nor a supplier’s record becomes immune to examination. That is a higher standard than choosing one side to trust automatically. An ordinary person should be able to say, “Your record does not describe what happened,” and reach a process capable of discovering whether they are right. They should not need public attention, exceptional persistence or a major lawsuit before the organisation regards that possibility as real.

The danger arises when an institution gives its records more authority than their production, interpretation and correction can justify. Neither a machine nor a person should receive unconditional credibility because investigating the alternative would be difficult. The system should have to earn the consequences attached to its output.

2. The failure without an attacker

The cybersecurity story I hear most often begins with somebody malicious finding a way in. An attacker stole a credential, exploited a defect or manipulated a person. The defensive work then seems straightforward in outline, even when technically difficult. Find the route, close it and keep the next attacker out. Dependability has to survive a less reassuring story too. The approved people used the approved process. The change reached exactly the machines it was meant to reach. The consequences were still disastrous.

On 1 August 2012, Knight Capital’s trading system malfunctioned. The US Securities and Exchange Commission (SEC) later described failures in deployment and safeguards, losses exceeding US$460 million and ninety-seven automated error-related emails sent before the market opened. Those emails were not designed as system alerts. Receiving them did not produce an effective intervention. Knight settled the SEC’s enforcement action for US$12 million without admitting or denying the findings. The underlying order identifies a specific deployment failure: new code reached seven of eight servers while an eighth retained old code. A repurposed flag on that server activated obsolete functionality. Nobody had to perform a second-person review and no reliable process confirmed that every server received the update. The firm’s safeguards then failed to contain the resulting orders.⁶ This case complicates an explanation I find tempting. It is easy to say that bad systems persist because organisations keep the benefits while everybody else bears the costs. Here the organisation had an enormous financial interest in preventing the outcome. That interest did not make it competent at preventing it.

Accountability needs capability. A person can have every reason to avoid a mistake and still operate within a process that makes the mistake difficult to detect, understand or stop. An organisation can know, abstractly, that reliability matters while failing to translate that knowledge into a deployment procedure, a tested constraint or an escalation path somebody can use under pressure. A message and a warning are different. A message exists when information is emitted. A warning exists when the right person or control can recognise the condition, understand its importance and act appropriately in time. More messages can make that harder rather than easier if nobody has decided which ones require interruption. The same applies to dashboards. A red indicator may be accurate but operationally useless. Who sees it? Do they have authority to stop the process? What would stopping it interrupt? Has anyone practised the decision? Did the change itself cause a false alarm? Adding a notification after the event cannot supply the preparation needed for a sensible response.

In July 2024, an authorised CrowdStrike Windows-sensor content update caused a widespread outage. CrowdStrike’s later account acknowledged the update as the initiating event. This was a supplier’s explanation of its own incident, not an independent demonstration that every later corrective measure would work.⁷ The example gives a different angle on concentration. A trusted channel is powerful precisely because organisations allow it to distribute changes efficiently. The capacity that makes protection scalable can also make a defect scalable. It is not enough to establish that an update came from the right organisation. We also need to understand how much damage an incorrect authorised update can cause before the process stops. That does not make centralised updating inherently wrong. Delayed or inconsistent deployment can leave people exposed to known attacks. A small organisation may obtain better protection from a specialist provider than it could build itself. The comparison is between complete systems including their update controls and recovery paths, rather than between an imperfect central service and an imaginary collection of flawless independent operators.

The better questions concern implementation. Can teams stage a change across genuinely different environments? Can an independent control halt the rollout? What observations cause an automatic stop? Can a damaged machine recover without the remote-management facility that has stopped working? Have people other than the designers tested that recovery? Redundancy needs the same scrutiny. Two providers can depend on the same underlying network. A backup account can require the failed identity service. A recovery procedure can be stored behind the system it is intended to recover. Buying another component gives no protection when both components share the same point of failure.

The technical restoration date is also not the end of the human account. In November 2024, the Australian Communications and Media Authority (ACMA) announced penalties exceeding A$12 million concerning Optus’s November 2023 outage. Its findings included failed emergency-call access affecting 2,145 people and failures to conduct 369 welfare checks. These figures concern that particular outage and the regulator’s investigation.⁸ The network returning does not complete a duty towards someone who could not reach emergency assistance while it was unavailable. Recovery may require finding people, following up, correcting records, compensating losses or explaining what they should do next. Those tasks do not become optional because a service-availability metric has turned green. Organisations should rehearse that distinction before the next major incident. Who owns the response after the infrastructure team declares service restored? What information must be retained to identify those still affected? How can a person whose failed attempt left no complete record establish that they need help? What interim route exists if the promised follow-up never arrives?

Some failures will be genuinely difficult to foresee. That should affect blame without removing the duty to plan for failure. Perfect prediction is unavailable. An important system should still have a workable way to limit damage, recover and deal with people afterwards. Operating conditions mattered long before cloud infrastructure. The US Government Accountability Office (GAO) found that an inaccurate time calculation in the Patriot system at Dhahran became more important as continuous operation increased. The battery had operated for over 100 hours before the attack on 25 February 1991. GAO also recorded an earlier warning about extended operation that did not state what duration counted as too long. Modified software arrived the next day. The report connected the resulting tracking failure with the battery’s failure to engage the incoming missile, which struck a barracks and killed 28 soldiers.⁹ The lesson here is specific. The calculation was accurate enough only while the equipment operated within an assumed time limit. The equipment then ran beyond that limit. Improving the calculation was one response. Communicating a usable limit, delivering the update and deciding what could safely happen in the meantime were also necessary. A correct fix at the development site did not yet protect the deployed system.

Nobody can now show that every proposed correction would have prevented the deaths. The case still shows why an operating assumption belongs in the safety account. A system cannot rely on a limit that its operators have no practical way to recognise or manage. Similar questions arise without military equipment. A service may assume that a queue never grows beyond a particular size, that a clock is sufficiently accurate, that a certificate can be renewed while the issuing service is available or that an administrator can log in through a functioning identity provider. The assumption becomes dangerous when the recovery procedure requires the component that has failed.

A real recovery exercise should begin from a specified damaged state. Restore the database without the usual management interface. Recover access when the primary identity service is unavailable. Establish which credentials, documentation and people remain reachable. Record what could not be completed. A demonstration with every dependency healthy answers a different question. Redundancy has limits. Two systems can share a power supply, a deployment process, a person or a supplier. Buying a second instance does not make those dependencies independent. Conversely, eliminating every shared element can make an operation too complicated to maintain safely. The design needs a stated failure model and enough independence to address it, rather than a count of duplicate components.

A staged update provides another example. Deploying first to a small group can contain some defects but only if that group exercises the conditions under which the failure occurs. A quiet test environment might not expose behaviour triggered by a particular device, workload or sequence of events. Monitoring also needs to detect the relevant harm before the update reaches everybody else. A successful installation is not sufficient evidence that the service still performs its function.

The release decision should name the observations that justify continuing. It should also identify the conditions for stopping, who may stop and whether a halt can take effect quickly enough. An automatic gate based on the wrong measurement can distribute failure more efficiently than a manual process. A manual gate operated by someone without enough information is no better merely because a person clicked it.

Recovery has several completion states. A machine can boot before the application works. An application can answer requests before records are reconciled. A service can resume while people affected during the outage still need help. Treating all three as restored service makes the remaining work difficult to fund because the incident has already been described as over. Recovery records should retain those distinctions. Which functions have returned? Which transactions require checking? Who remains unable to use the service? What additional harm could occur if the organisation resumes ordinary processing too soon? The same precision needed during an incident is needed when deciding that it has ended. I therefore object to a narrow defence based on the absence of an attacker. The people depending on a system need protection from authorised mistakes too. Signing a release, authenticating the operator and approving a change show where the action came from and who approved it. They say nothing about whether it is safe. Nor does punishment automatically produce learning. If the organisation’s response is to find one operator who clicked the wrong thing and preserve everything that made the action likely, it has converted an investigation into a ritual. If nobody can ever be responsible because the process was complicated, it has made the opposite error. Individual conduct and organisational design need to be examined together.

A productive review asks what somebody could reasonably have known at the time, which safeguards were feasible and which decisions increased the exposure. It distinguishes a person violating a clear, workable rule from a person following a procedure whose hidden assumptions were wrong. It also asks whether the supposedly clear rule could actually be followed within the staffing, time and tools provided. The dangerous part of an engineering decision should be visible without delaying every routine change. A small, reversible change within a tested boundary should be easier to make than an unbounded deployment whose recovery depends on luck. That is a useful form of agility: freedom created by knowing what failure would mean and having the means to contain it.

3. What we knew how to prevent

I see a moral difference between discovering a new kind of failure and continuing to introduce a familiar one whose practical defences are well understood. That difference does not make migration free or answer every question of liability. It changes what the designer should be prepared to answer. Why does the ordinary way of using this system still permit this mistake? What would prevent it? What would that prevention cost and who bears the cost of its absence?

In March 2024, the US Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI) urged manufacturers to eliminate SQL injection vulnerabilities, invoking the long history of the problem and available mitigations. OWASP’s related guidance centres prepared statements and parameterised queries, alongside appropriate handling of query elements that cannot be supplied as bound values.¹⁰¹¹ The engineering principle is simple enough to explain without making the problem trivial. Information supplied as a value should not accidentally become part of the instruction determining what the database does. A design that preserves that boundary by default asks less of every developer than one requiring them to reconstruct the boundary correctly whenever they build a query.

The difference is not whether programmers should be careful. Of course they should. The difference is how much safety the system can provide without depending on a person’s uninterrupted vigilance. Care is a scarce human resource. Spending it repeatedly on a preventable syntactic trap leaves less available for questions the machine cannot settle. We can examine that distinction with two illustrative interfaces. In one, the normal operation accepts a query and separate values; unsafe construction requires an explicit escape from the ordinary path. In another, the normal operation accepts one assembled string and every caller must remember how to prevent untrusted fragments changing its meaning. Both can be used correctly. They do not impose identical burdens on the people maintaining a large application over time.

Memory safety raises a related issue. CISA and the FBI’s Product Security Bad Practices guidance urges a deliberate move towards memory-safe development in the product contexts it addresses. That is guidance with a stated scope, rather than a legal ban on every use of C or C++.¹² The justified criticism is of avoidable exposure, not of everyone who works in a particular language. A new component written within a sound memory-safe environment can exclude important classes of defects that would otherwise require continuing discipline. That benefit survives the observation that logic errors, authorisation failures and insecure dependencies remain. Preventing one category of harm is useful even when other work remains.

Switching languages alone cannot make the complete system safer. A rushed rewrite can reproduce old assumptions and introduce new errors. Foreign interfaces, unsafe components, operating-system interactions and deployment conditions matter. The comparison needs to include the code and people that exist, not only the language feature that looks best in isolation. The most practical demand is incremental. Stop reproducing a known hazard where a safer path meets the real requirements. Identify the boundaries where migration is difficult. Fund the training and assurance needed to move them. State what remains exposed and why. An institution can make a reasoned exception without turning that exception into permanent permission never to reconsider. I am particularly tired of “everything has bugs” as a universal defence. It contributes almost nothing. It does not compare the kinds of mistakes made, their frequency, their consequences or the cost of detecting them. It is a true sentence used to avoid the decision that matters. The same impatience applies to hardware that reaches into physical processes. CERT-FR’s October 2026 alert identified compromises of remote refrigeration controllers and warned against exposing management interfaces to the internet. Its product scope included Danfoss controllers and was later broadened to Copeland and Dixell XWEB systems.¹³

That official warning is enough to ask serious questions about remote management. It is insufficient to assign responsibility for every installation or claim that a particular previously disclosed vulnerability caused every compromise. Incident evidence must establish the precise path. A list of potentially affected products does not complete a causal investigation. The design questions nevertheless exist before the investigation. Which identities can alter operating parameters? Are their permissions limited to the maintenance actually required? What protects against a compromised account or an erroneous command? Can an independent safety control recognise a harmful state? Who receives the signal and what can they do before a physical loss occurs?

The US National Institute of Standards and Technology (NIST) explicitly treats reliability, performance and safety constraints as part of operational-technology security.¹⁴ The physical process changes the meaning of a successful intervention. Abruptly disconnecting or updating equipment can create danger of its own. A critic who ignores that is offering a different form of carelessness. But difficult maintenance needs to be designed and funded. If an operator cannot safely update a system, its lifetime plan should explain how defects will be mitigated, tested and ultimately corrected. “We cannot stop it” is a description of dependence. It cannot be the permanent security strategy for a product sold into that dependence.

An apparently narrow technical choice acquires human meaning here. The person exposed to a failure may never have chosen the controller, the network design or the maintenance contractor. Their safety cannot reasonably depend on each supplier defining its responsibility so narrowly that the complete system belongs to nobody. The language of prevention creates another danger. After an incident, it is often possible to identify some step that would have stopped that particular chain. Hindsight cannot tell us whether that step was the best use of resources beforehand. We should compare what was reasonably foreseeable, what the measure cost and which competing hazards would have remained.

The SQL distinction can be demonstrated without a production system. Suppose a database contains one ordinary account name. Supplying hostile input as a bound value keeps it separate from the query. Inserting the same input into the query string can instead change the query itself. The example is deliberately small; it tests the boundary between instructions and data, not the security of a complete application.¹¹

The value of the safer operation is that the ordinary call preserves that boundary. A reviewer still has work to do without rediscovering whether every quote and delimiter was handled correctly. The developer can express the intended relationship directly. Language and interface design can make a class of mistakes harder to express and easier to notice before release. The guarantee has a scope. Binding a value does not permit arbitrary table or column names to be inserted safely. A query builder can expose an escape hatch that restores the original risk. An application can use parameterised queries and still allow a user to retrieve another person’s records. The protection deserves credit for the mistake it prevents. It should not be advertised as resolving the separate authorisation decision. The same reasoning applies to memory safety. A useful language guarantee removes certain operations from ordinary code or requires their justification at an explicit boundary. That changes the work of review. Instead of checking every expression for the same low-level hazard, attention can be concentrated on the interfaces where the guarantee depends on additional assumptions. Whether that choice is worthwhile still depends on the whole system including foreign libraries, device interfaces and the competence needed to maintain the boundary.

There are cases in which a safer abstraction is itself difficult to use. The response should be to examine the difficulty. Does it represent a genuine constraint the program must satisfy or complexity introduced by the chosen design? A compiler can reveal a real ownership conflict. It can also issue a poor diagnostic that makes the conflict unnecessarily hard to understand. Treating every complaint as resistance to safety prevents improvements to the tool. Treating every rejected program as proof that safety is impractical makes the opposite mistake.

Hardware protections and real-world limits remain relevant. A language does not decide how much authority a process has, what information it can transmit or whether a dangerous physical action is permitted. Stronger guarantees at one layer should make the remaining duties clearer. They should not disappear behind a claim that the code uses the right language. Therac-25 provides a historical reason to examine the complete control system. Leveson and Turner’s investigation documented lethal radiation overdoses and examined interacting software, hardware and organisational failures. One of their comparisons concerned an error that produced less serious consequences in a predecessor whose hardware interlocks provided protection. The authors also warned against treating reused software as safe merely because it had operated in a different system.¹⁵

The broader design question is what prevents a dangerous output when an ordinary assumption fails. A warning helps when the recipient can recognise its importance and intervene. An independent interlock may constrain the action before intervention is possible. A second check adds little when it relies on the same wrong value and reaches the same conclusion. Counting controls without examining their dependence can create a misleading safety argument.

Some proposals reduce one risk by increasing another. Preventing every invalid state at compile time may make a system difficult to adapt. An automatic shutdown can be the right response for one physical process and dangerous for another. The engineer needs to explain the consequence of the chosen failure mode. Terms such as fail-safe cannot determine which state is safe in an unspecified environment. What should change is the burden placed on routine care. Requiring a tired person to remember an undocumented exception every time is a poor permanent defence where the system can enforce the distinction. Choose the control for the hazard, whether it belongs in code, hardware or procedure. Designers should remove repeated opportunities for predictable error where a practical improvement exists. Perfection is not the standard. Hindsight still requires an honest account of what people could reasonably foresee and prevent. Sometimes they knew enough and declined to act. Sometimes a safer default could have prevented an ordinary mistake for little cost. Those cases should be named precisely.

I do not expect the end of error. I expect a profession that learns to make well-understood errors harder to repeat and institutions willing to pay for that learning. A bug is not a moral failure merely because it exists. Continuing to defend an avoidable pattern without examining the alternatives is a choice.

4. Nobody owns the whole network

The internet is where this becomes harder for me. A useful system can depend on cooperation among organisations that do not share a manager, budget or goal. BGP, the Border Gateway Protocol, allows independently administered networks to exchange reachability information and apply routing policy. That independence is central to its function. A proposal to replace it must preserve or deliberately reconsider the distribution of power, as well as improve the technical behaviour.¹⁶

In February 2008, a more-specific announcement originating from Pakistan Telecom propagated through an upstream provider and diverted traffic intended for YouTube. RIPE NCC’s case study describes the event through the measurements its routing infrastructure could observe.¹⁷ A decision inside one network had consequences for people far beyond that network’s intended scope. There have been serious attempts to improve routing security. Route Origin Validation using the Resource Public Key Infrastructure (RPKI) can check whether an autonomous system is authorised to originate a prefix. It does not check the entire path or stop every route leak. BGPsec addresses path validation. RFC 9234 specifies BGP Roles and the Only-to-Customer attribute to help prevent and detect particular leaks.¹⁸¹⁹²⁰ Those distinctions are important because “BGP is insecure” does not identify which guarantee is missing. Origin, path and propagation policy are different questions. The relevant intervention depends on the failure being considered.

Cloudflare’s August 2026 account supplies a contemporary implementation example. It reported that GTT and Arelion were stripping the Only-to-Customer attribute in observed paths. The operators attributed that behaviour to precautions adopted after older error-handling incidents. Cloudflare subsequently observed Arelion preserving the attribute, while reporting continued stripping by GTT at publication. These were one operator’s measurements and attributed explanations, not a census of every route or a permanent description of either network.²¹

The case is revealing because the older defensive action could interfere with a newer defence elsewhere. Nobody has to intend the combined bad result. A policy can be locally understandable and still create an external effect its owner needs to address. The problem is technical and organisational. The new attribute is useful partly because it can survive networks that do not yet implement the associated defence. Intermediaries removing it change what another participant can know. The consequence crosses an organisational boundary, while the decision may have been justified against a narrower history of failures.

Calling every operator negligent would conceal that behaviour. Calling the configuration understandable and ending the discussion would leave it uncorrected. A useful account asks whether the assumption is still necessary, what evidence would justify changing it and how the affected networks can discover the behaviour in the first place. Standards deployment supplies a broader lesson. Publishing a protection does not deploy it. Implementing it in one product does not configure it on a network. Configuring it on one network says nothing about what intermediate networks will preserve. Each step needs different evidence. This should alter what purchasers and operators ask. “Do you support the standard?” may be too weak a question. Which operations are enabled? Which paths preserve the information? What happens when an object expires or a validation service is unavailable? How is a mistaken authorisation corrected? What observations would reveal that the protection was being bypassed or undermined?

Validation also creates dependencies. Resource authorisations can be wrong. Objects expire. Software interpreting them can fail. An incorrect security decision can disrupt legitimate reachability. Those risks require staging, monitoring and recovery. They do not make unauthenticated announcements safer. The choice is rarely between a dangerous decentralised system and a perfectly governed centre. A central authority can simplify coordination while concentrating the power to make a damaging mistake or impose an objectionable policy. A federation can preserve independence while making collective improvements slower. The design has to say which powers belong where and how each can be challenged.

We should be able to demand better behaviour across organisational boundaries without demanding one owner for the whole internet. Shared infrastructure can have shared duties, public measurements and agreed escalation. The rules need to be specific enough that each participant can tell whether it is doing its part. They also need a way to revise old precautions. Security controls are responses to a model of the world. When the world changes, preserving the control unchanged can preserve the wrong assumption. Retirement of a protective rule deserves the same discipline as its introduction: evidence of its current purpose, the consequences of removal and a plan for the cases it still protects. I object to treating “best practice” as a permanent conclusion. It should point towards an understood body of evidence and experience. It should not freeze a decision in place after its rationale has changed.

The routing case shows how demanding real interoperability is. Messages have to remain meaningful across versions, policies and institutions. A specification can be necessary to that work while leaving much of it unfinished. It also shows improvement. The reported change in one operator’s behaviour matters. Measurement and direct engagement produced a correction. An essay that only notices the original defect cannot tell the reader what useful action looks like.

Correction should depend less on somebody having unusual resources, access or persistence. Other participants should be able to discover the relevant behaviour and obtain an answer before a major failure forces the issue. A routing announcement carries information between organisations whose interests overlap without being identical. An origin authorisation can show that a network may originate an address prefix. It says nothing about whether every later export decision is appropriate. A path signature proves another property without deciding whether the path fits a customer’s service needs. Operators need to know exactly what each protection tells them.

Procurement needs the same precision. Asking whether a provider supports routing security can produce an answer too broad to guide a decision. Which records does it publish? Which incoming routes does it validate? What happens to an invalid announcement? How are authorisations changed during a migration? What does the provider preserve when forwarding somebody else’s protection? Those operations are different commitments and their relevant evidence differs too.

Deployment can also create a new route to failure. An incorrect authorisation may make a legitimate route appear invalid. A validator may be stale. An operator can enable rejection before checking whether its own intended announcements fit the records. The lesson is to stage and monitor the deployment, with a documented response to these conditions. It is not to reject validation because implementing it requires care.

The conflict is partly temporal. Compatibility permits a new protection to pass through equipment that does not yet understand it. That allows incremental adoption. A middle system that discards the unfamiliar information can make the protection ineffective elsewhere. A local policy adopted for an earlier threat may remain long after the original circumstances have changed. The people affected by that policy might be unable to identify which network made the decision. This requires more than telling operators to collaborate. They need a way to observe the effect, describe it precisely, reach someone able to change it and check whether the change worked. Public measurement can help. So can agreements between networks that specify the relevant behaviour. Neither replaces the engineering needed to distinguish a defect from an intended policy.

A customer cannot independently reconstruct every inter-network relationship carrying its traffic. It can still ask a supplier to describe the measures under its control and the limits of the assurance. The supplier should not promise end-to-end certainty it cannot provide. It should also not use the absence of end-to-end control to avoid the checks it can perform locally. The governance of the supporting registries needs the same attention. A system that helps establish legitimate origins has to allocate authority over those statements. Errors, disputes, expiry and changes of ownership need procedures. Improving cryptographic assurance can increase dependence on the correctness and availability of that administrative machinery. The improvement should therefore include how the new dependency is governed. This does not make the old trust model preferable. It prevents a false comparison between an imperfect decentralised system and an imagined replacement with no risks from central control. Each option needs a complete account of who may make an important statement, who checks it and what happens when the statement is wrong.

Protocol design has a related problem. The Internet Architecture Board’s (IAB) Maintaining Robust Protocols discusses the costs of silently tolerating ambiguous or defective behaviour and argues for active maintenance. It is an informational architectural statement, not a new universal requirement to reject every unfamiliar input. Its concern is that apparent short-term compatibility can leave defects and incompatible interpretations embedded in the ecosystem.²² A system can withstand unexpected input while making the discrepancy visible. It can record which peer supplied a malformed object, preserve enough information to reproduce the problem and provide a route to correction. Silently inventing meaning is a different choice. That choice needs justification when it affects security or service operation.

No single actor controls enough of the path to repair the public internet alone. Participants can still improve it by making each important boundary explicit and each harmful interaction easier to find. Distributed responsibility makes this work necessary; it does not make responsibility disappear. The first movement of this essay has therefore produced several different problems. Institutions can give records more authority than they deserve. An organisation can fail despite bearing enormous costs. Teams can leave a safer default unused. Independently reasonable policies can interact badly. Saying that technology is hard or people are greedy explains none of them adequately.

We have to follow the decision far enough to identify the actual failure. Then we have to ask what the person on the receiving end was ever permitted to do about it.

II. The terms we never chose

5. The contract inside the machine

A feature can exist in the software while being unavailable to the person using it. The restriction may be a key, an account, a contract or a combination of all three. To understand the product, we have to understand that control. Buying an object, obtaining a copy of software, receiving a licence and subscribing to a service can create different rights. An interface may make the transactions feel similar even when the conditions for continued use differ greatly.

Valve’s Steam Subscriber Agreement, for example, describes its content and services as licensed rather than sold and connects the licence to the agreement and relevant subscription. That describes the legal relationship Valve offers. It does not tell us whether a particular game works offline, which terms a court would enforce or whether a particular termination is justified.²³ A person needs to understand the relationship before building a life around the purchase. Will the product continue to work offline? Which functions require a remote service? Can a copy be transferred? What happens to records, creative work or access if the account is closed? What will remain if the supplier disappears? Those questions do not all have to receive the same answer. A service requiring continuous operation is different from a downloaded document. A collaborative platform has other participants’ privacy to protect. A seller cannot guarantee the existence of a business indefinitely. But the important differences should be clear at the point where a person is invited to rely on the product. I object to the gap between the promise a transaction encourages and the limitations a customer discovers only when something goes wrong. A legal document should clarify that relationship. It should not function as a concealed reversal of the ordinary description through which the product was sold.

There are limits to what people can read and negotiate. An individual cannot reasonably perform a full legal and technical review of every tool needed for work, communication or study. Even someone capable of understanding all the terms may have no practical ability to change them. Reading becomes a ritual when every provider imposes the same terms and acceptance is the only available action. Consent still matters and standard contracts still have a place. Common terms can reduce costs, make a service affordable and establish predictable responsibilities. Negotiating every detail with every customer could exclude the small providers we want to make viable.

Some terms can reasonably remain available on a take-it-or-leave-it basis. Others should be conspicuous or restricted because the bargaining process cannot adequately protect the affected person. Australian unfair-contract-term rules already recognise part of this problem. The Australian Competition and Consumer Commission (ACCC) describes protections for consumers and qualifying small businesses in standard-form contracts, with tests concerning significant imbalance, legitimate interests and detriment. It identifies transparency and the agreement as a whole as relevant to assessment. That is a defined legal regime, not a conclusion that any clause I dislike is unlawful.²⁴ Its existence nevertheless challenges a simplistic defence: “They agreed.” Agreement matters. It is not the only thing that matters.

Consider an illustrative maintenance contract. The supplier controls every update, can change the service substantially and disclaims much of the loss if it fails. The customer bears the cost of migration, must continue paying during a dispute and cannot obtain the documentation needed to operate independently. Each clause may have an explanation. Taken together, they can create a relationship in which the party with the least control bears much of the practical risk.

The explanation needs to address the whole relationship. A supplier might reasonably limit liability for a customer’s unauthorised modifications. That does not justify excluding responsibility for its own hidden limitation. It might need to suspend an account being used to harm others. That does not justify making innocent users’ important records inaccessible without a fair recovery route. A good contract can make responsibility clearer. It can specify support, reporting channels, escalation, migration assistance, evidence retention and what happens if a supplier cannot continue. It can also expose the real cost of promises that marketing would otherwise make casually.

A bad contract can do the opposite. It can distribute obligations so that no party has accepted the complete task the customer thought they were buying. A manufacturer points to an integrator, the integrator to a service provider, the provider to a component and the component’s maintainer to the absence of any service agreement. The customer is left tracing a supply chain after the product fails.

We should not solve that by imposing every downstream obligation on the earliest author. The commercial actor supplying a complete product should understand what it is promising and arrange the dependencies needed to keep that promise. Its own agreements with suppliers are part of that work. A volunteer’s disclaimer cannot become a universal shield for a manufacturer selling dependable equipment. Contracts also shape the working lives of the people who produce technology. A person can be asked to accept responsibility for a deliverable while the client controls the environment, changes acceptance criteria or holds the information necessary to resolve a dispute. Intellectual-property terms can reach beyond the work actually commissioned. Confidentiality can protect legitimate secrets while also making it difficult to demonstrate experience elsewhere. These are questions to examine in particular agreements, not allegations about a named employer or platform. The same principle applies: relate an obligation to the person’s actual work, control and ability to manage the risk. A broad clause is not more reasonable because a lawyer found a way to express it.

The strongest defence of expansive terms is sometimes uncertainty. The supplier cannot predict every use, the client cannot anticipate every dispute and the employer needs to protect genuine business interests. But uncertainty should be allocated deliberately. Automatically giving the stronger party discretion and the weaker party exposure is a choice about power, not an inevitable feature of drafting. The contractual account should not end with the supplier’s preferred wording. In April 2018, Australia’s High Court refused Valve special leave to appeal, leaving standing the Full Federal Court decision concerning misleading representations about consumer guarantees and a penalty of A$3 million. The ACCC’s account says that Australian Consumer Law bound Valve in its dealings with Australian customers despite the company’s overseas base.²⁵

A user can read a restriction accurately and still receive an incomplete account of the applicable rights. The existence of a term does not settle its enforceability. A private agreement operates within a legal system that can limit what the parties may exclude. Which limits apply depends on the jurisdiction and transaction; the historical Valve result does not make every disputed term unenforceable. Even where the law is clear, an information problem remains. A supplier can organise its support interface around the contractual description rather than the rights that remain. The person seeking a remedy then has to know enough to challenge the first answer. Excessive effort can weaken a formal protection in practice. Staff training, accurate notices and a usable dispute path therefore affect whether the legal right has practical value. The same analysis should distinguish promises from disclaimers. A company may describe a product as suitable for an important purpose, encourage dependence and then place a broad limitation elsewhere in the terms. The ethical question concerns the complete representation. A limitation disclosed prominently before adoption carries different weight from one discovered only after the failure it was meant to excuse.

Disclosure does not make every set of terms reasonable. A person needing an essential service may have little bargaining power. A business may face high switching costs after years of integration. An employee may be required to accept the chosen platform to do their job. Those conditions weaken the claim that the affected person freely chose the risk. A fair contract should connect responsibility to control. A supplier managing the service can accept defined duties for availability and correction including security incidents. A customer can accept duties for its credentials and configuration. Problems arise when the customer must cover outcomes it cannot inspect or prevent while the supplier retains broad control over the facts on which payment or access depends. Standard-form contracts are not inherently abusive. Standardisation reduces costs and can make a service available at a useful price. Individually negotiating every clause would favour large customers and exclude ordinary ones. What matters is having acceptable defaults and a workable way to challenge an excessive term.

A particular concern is unilateral change after reliance. Consider a service that is convenient to join because data can be imported easily then changes price, functionality or collection practices after the customer has reorganised their work around it. The customer may retain a formal right to cancel. The effect of the change depends on whether leaving remains practically possible and what disruption the supplier knew it would cause.

Not every alteration is opportunistic. Operating costs change, laws change and a product can need a safer architecture. A useful change process distinguishes the required adjustment from unrelated commercial additions. It provides notice appropriate to the dependence and preserves enough time and information for the customer to respond. A short cancellation window does little when the migration itself takes months. The contract should also say what happens to work already completed. Ending a relationship need not erase lawful rights in existing material or prevent a person retrieving their own records. At the same time, access to someone else’s confidential information cannot continue merely because exporting it would be convenient. A fair exit identifies the relevant rights and information rather than granting either party unlimited possession.

The terms need to be clear before commitment and applied consistently afterwards. A person should know which duties they are accepting, which protections remain and how disputes are resolved. An institution benefiting from the relationship should not make the less-resourced party carry the whole cost of understanding it. A technological system is therefore partly made of promises. Some are expressed in code, some in documentation, some in a sales conversation and some in a contract. Their consistency matters. A feature list that says yes, a manual that says perhaps and an agreement that says nothing is guaranteed do not add up to an honest account merely because all three documents can be located. I want the relationship to be understandable before a person needs a remedy. I want its important limits to survive the sales process. And I want the party designing it to remain answerable for the dependence it deliberately invites.

6. An interface with an interest

I dislike the way we usually discuss a bad interface. We assume the designer wanted the user to succeed and merely failed to help them. Sometimes that is the wrong starting point. An interface can perform its intended function exceptionally well while serving a goal the user would not have chosen. It can make an action easy when the supplier benefits and difficult when the person wants to stop. It can record an input accurately while leaving the person surprised by what that input authorised.

In March 2023, the US Federal Trade Commission (FTC) finalised an order requiring Epic Games to pay US$245 million to settle charges concerning unwanted purchases and associated practices. The agency’s account described confusing purchase controls and restrictions imposed on accounts whose owners disputed unauthorised charges. The order required affirmative consent and prohibited blocking access because a consumer disputed such charges. That amount and proceeding are distinct from the separate children’s-privacy settlement.²⁶

The relevant issue is not whether a button generated the correct event. It is whether the person had a meaningful opportunity to understand and intend the consequence. Engineering correctness at the level of input handling cannot answer that question alone. It is tempting to respond that people should read more carefully. Sometimes they should. A payment confirmation should be examined. Users can make errors that no practical interface could eliminate. But the designer controls where information appears, how an action is interpreted and how hard it is to proceed or reverse. That control matters when evaluating foreseeable mistakes.

Friction can protect people. A delay before deleting important work may prevent a mistake. A confirmation before transferring money can make the consequence clear. A well-chosen default can help someone who does not want to configure a complicated product. The better test is what the friction does. Does it give the person time and information to make the decision they came to make? Or does it make the supplier’s preferred outcome easier to obtain regardless of that intention? Why is enrolment immediate while cancellation requires a different channel, several explanations and another attempt later? Which of those steps protects the person cancelling? That is a question about the system’s purpose. A service can be fast, available and free of memory corruption while still being designed around an objectionable relationship.

The Avast case exposes a related problem at the level of representations. In June 2024, the FTC finalised an order settling charges that Avast sold browsing information after promising protection against online tracking. The order prohibited specified advertising-data sales and required US$16.5 million. The underlying descriptions of collection and sale are the agency’s allegations resolved by the settlement, rather than findings from a contested trial.²⁷

The case invites scrutiny of a simple contradiction: a person seeking protection can become the source of the information being commercially exploited. More accurate collection would not resolve it. Better uptime would not resolve it. The purpose and terms of the collection have to be examined. Security products and fraud-prevention systems may need data to operate and diagnose failures. The objection cannot be that all collection is forbidden. It should concern necessity, representation, secondary use, retention and the practical controls available to the person described.

Start with the particular service. What information is needed to perform it? What is merely desirable for a separate commercial purpose? How long does the original purpose justify retention? Can the person obtain the protection without accepting the secondary use? Is refusal as understandable as acceptance? The people affected may include others who never installed the product. A browsing history, contact list or uploaded document can describe relationships. One person’s agreement cannot settle every other person’s interest in the resulting collection. Treating data as though it belonged only to the account holder can erase those relationships.

“You can opt out” is incomplete when the person cannot see the system they must leave or does not control the relevant account. Even where a real option exists, repeatedly discovering and reversing defaults consumes time. We should count that work even when no invoice records it. The comparison must still include the cost of alternatives. A subscription may be unaffordable. A service with less data may be less useful. Strong privacy controls can create legitimate safety or abuse-detection problems. There is no universally correct business model hidden in the word privacy. Institutions should state those trade-offs plainly and let people examine the real proposal. A person may choose an advertising-supported service. They should not have to discover that a supposedly protective product was financed through a relationship unlike the one presented.

The interface should also help people stop. A task has an end: the bill is paid, the setting changed, the message sent or the lesson completed. Continued engagement is the product’s goal, not necessarily the user’s. Good design should sometimes end with the person closing the application and doing something else. That ambition is technically demanding. It requires understanding the task beyond the metrics a supplier finds convenient. A shorter session might indicate success. A person declining a notification may be expressing a useful boundary. An account that is rarely used may be exactly right for a service needed only occasionally.

We should be suspicious of measures that define every refusal, departure or reduction in use as a defect to be corrected. The system is there to serve a human purpose. The person is allowed to have purposes beyond feeding the system. An interface records events: a button was pressed, a box was ticked, a screen was displayed. The conclusion that a person made an informed choice requires more. What did the screen communicate? Which action did the label describe? Was an important change presented before the commitment? Could the person correct an accidental input? What happened if they declined?

A log of acceptance records an interaction, not the person’s full understanding or freedom to refuse. A user cannot invalidate every inconvenient agreement by claiming not to have read it. The institution should still retain enough information about the design and version to examine a serious complaint. Defaults deserve particular attention. A default can help a person choose a safe configuration without expert knowledge. It can also exploit the fact that many people will not change it. The same feature can protect or exploit, depending on its purpose and consequences. Counting how often users keep it tells us little by itself.

Consider a hypothetical enrolment form that asks for a mailing preference beside a necessary service acknowledgement. A single acceptance control combines two decisions. The institution can later report consent to both, although the user may have understood the action as necessary to obtain the service. Separating the controls would make the choice clearer but could reduce the number of people consenting to the optional use. That reduction could be evidence of a better-informed choice rather than a failure of the redesign.

Commercial success and user success can diverge. A test optimising completion or revenue may select an interface that increases mistakes, unwanted commitments or later disputes. The test can be statistically sound while measuring the wrong thing. A wider assessment would consider reversals, complaints, understanding and whether people can achieve the task they intended. Such measures can also be gamed. Low complaint numbers might reflect satisfaction, an inaccessible complaint route or users deciding that recovering a small loss is not worth the effort. The service should not rely on the absence of reports as proof that the choice was understood. Sampling actual task completion and examining the circumstances of failures can supply information the dashboard lacks.

Every ordinary purchase need not become a lecture. Excessive notices can make a simple task harder and hide the few facts that matter. The interface should place important information at the point of decision, use language appropriate to the audience and keep further detail available. A serious action may deserve more friction than a reversible preference. Reversibility can reduce the cost of honest mistakes. A short delay, cancellation route or preview may permit correction before an action becomes difficult to undo. Yet an apparent undo is misleading if downstream recipients have already received the information or the underlying transaction cannot be reversed. The design should distinguish cancelling a queued action from compensating for an executed one. The same care applies to confirmation prompts. Requiring a person to confirm every routine operation can teach them to confirm without reading. The useful question is what information or authority changes at this step. A prompt that merely repeats the existence of a button adds little. A prompt showing the actual recipient, amount or scope can give the person a meaningful opportunity to stop.

The aim should be to make the important decision understandable. Convenience does not make a user interface morally neutral and guidance does not make it inherently objectionable. The task should justify that guidance and the interface should remain answerable to the person whose action it records. An ordinary security checklist cannot satisfy the anger behind this essay. Some systems I oppose could pass it. Their harm depends on what they persuade people to do, which burdens they conceal and how they use the authority obtained through an apparently routine interaction.

Did the interface help the person act or merely make them easier to act upon?

7. Who controls the route to the user

I do not think the legal freedom to create something means much when there is no practical way to offer it to the people who might benefit.

Software reaches users through devices, operating systems, stores, search, networks, payment services and other intermediaries. Any particular intermediary may provide a valuable service. The complete route can still place an independent creator under rules they have little power to negotiate. The ACCC’s final Digital Platform Services Inquiry report, released in June 2025, brought together concerns across app marketplaces, mobile ecosystems, messaging, search, advertising and retail marketplaces. It recommended targeted competition and consumer-protection measures including stronger dispute resolution. Those recommendations show what the regulator believes should change; their effects still need to be tested.²⁸

The issue is wider than whether a particular company is too large. A platform can be useful because it coordinates many participants, gives consumers a trusted place to look and handles difficult tasks at scale. Its size can enable protections smaller providers struggle to supply. The power becomes more demanding when the intermediary also determines which competing products may reach the same users, which payment methods they may use or which features can interoperate. A rule framed as general platform maintenance can have unequal commercial consequences. The evidence should establish those consequences rather than infer them from the company’s size alone.

The route also determines which information people encounter. Search ranking, recommendations, moderation, advertising and account enforcement do not merely carry speech from one place to another. They shape visibility, reward some behaviour and can make other speech practically disappear. No feed is neutral merely because its choices are automated. Chronological order is still a choice. Engagement is a goal chosen by somebody. A moderation rule can protect people from targeted abuse and can also be applied without enough local knowledge or a usable appeal. The platform remains responsible for that power even when no editor selected each item by hand.

There is no honest solution in which one institution simply decides what everyone is permitted to know. Measures against manipulation can become censorship, surveillance or a way to disadvantage political opponents. Refusing every intervention can leave harassment, deception and well-funded manipulation to determine who can participate safely. Freedom of expression, privacy, public safety and access to reliable information can pull in different directions. The system should state which harm it is addressing, which actions it takes, who can challenge them and what evidence will show whether the intervention helped.

The United Nations’ Global Digital Compact treats information integrity, independent media, multilingual information, platform transparency and privacy-protected researcher access as connected concerns. It also calls for measures against manipulation to remain consistent with international law.²⁹ Those commitments are not evidence that any platform or government has fulfilled them. They identify useful questions for a real service. Can researchers examine important effects without receiving everybody’s private data? Can a person learn why a recommendation or restriction occurred? Are local languages and political conditions understood? Does an appeal reach someone able to change the result? Which groups bear the errors? A platform that influences public debate should not be judged only by whether its servers delivered the selected content correctly.

A good criticism asks what the rule protects, whether it is applied consistently, whether less restrictive alternatives exist and whether an affected participant can obtain reasons and review. A store does not have to distribute malware in the name of openness. It should not be able to hide every commercial restriction beneath the word safety. Security and competition are not always enemies. An interoperable design can make it possible to leave an unsafe provider. A closed distribution channel can reduce some attacks while concentrating the harm from a mistaken exclusion. The effect depends on the threat, the alternative and the people holding the decisions.

Cloud services reveal a related problem after adoption. In its July 2025 investigation, the UK’s Competition and Markets Authority found significant market power held by Amazon and Microsoft and identified barriers involving egress charges, interoperability and software licensing. Its March 2026 announcement described steps by the firms and further work the regulator considered necessary. The response was still developing and switching was not suddenly effortless.³⁰³¹

A supplier can truthfully say that a customer is free to leave while leaving the customer with a substantial engineering project. Some of that work is real. Applications acquire dependencies because specialised services solve problems. A different provider may have different semantics, operating limits or security guarantees. Universal interchangeability is not a free feature somebody has perversely refused to add. The relevant distinction is between necessary migration work and obstacles created to preserve a supplier’s power. Both may be present in the same relationship. An honest comparison includes integration cost, data movement, retraining, compatibility and the risk of running two systems during transition. This also limits an easy remedy: require every organisation to use several clouds. Maintaining a second environment can add complexity and dilute expertise. It can leave a small team responsible for more failure modes than it can manage. A single well-understood provider may be the better current choice for a particular service. That does not make exit planning pointless. A smaller plan may be enough: preserve data in an understandable format, separate a critical business rule from a proprietary integration, document reconstruction steps, retain independent backups or negotiate assistance if the service changes significantly. Portability can be selective and still valuable.

The decision should be made before the alternative becomes urgent. A migration discovered during a dispute is different from a migration that has been rehearsed. A theoretical export button is different from evidence that a receiving system can interpret the exported work. The user who never selected the provider is also affected. An institution chooses a platform, builds its workflows around it and then tells employees, students or customers that using it is necessary. The original buyer may have accepted a trade-off. People later required to participate may never have had the same alternatives or understood the same consequences.

Procurement should therefore account for the people over whom the selection acquires practical authority. Can they use it on the equipment they have? Does it impose unrelated data collection? What happens when an account is suspended? Can the institution resolve a failure itself or can it only submit a ticket to a supplier and wait? The responsibility cannot disappear at the vendor boundary. An institution that imposes the dependency should know how it will respond when the vendor’s standard process is inadequate for the people being served.

A more competitive market can help without providing the whole remedy. Several providers can offer similarly poor terms. A network of other users can create as much lock-in as a file format. A person may lack the money, time or authority to exercise an available choice. Conversely, public ownership is not a guarantee of answerability. A publicly funded platform can still be inaccessible, badly governed or difficult to challenge. The relevant properties are its actual decision rights, purposes, controls, resources and routes to correction. I do not want to exchange a commercial monopoly for an institution whose public label excuses the same practical powerlessness.

Interoperability is often described as though a published endpoint settles the matter. A developer can connect, therefore the market is open. The relevant question is what the connection allows them to do on workable terms. An interface may expose only part of the information needed to reproduce a service. It may permit reading but not changing a relationship. Its rate limits may suit a small integration while preventing a serious migration. A competitor may receive delayed information where the platform’s own application receives it immediately. The existence of an API does not make the two services equal.

There are legitimate reasons for some differences. An interface serving external callers needs protection against abuse. A provider may lack permission to transfer another user’s information. Internal systems can change more quickly than a public contract. Preserving every internal feature for outside use may be expensive or unsafe. The assessment should identify the specific capability withheld, its importance to participation and the reason for the restriction.

The boundary matters. A user may need to move a calendar, retrieve a record or change a payment provider without receiving all of the host company’s technology. A narrowly specified interface can preserve meaningful choice while leaving substantial room for product differentiation. The migration also has to preserve meaning. An exported permission attached to a document may have no direct equivalent in the new system. An account identifier may refer to a person who has not joined the receiving service. A retained timestamp may use a different time basis. A migration that silently replaces these uncertainties with convenient defaults can appear successful while changing the relationship the user expected to preserve.

Migration reports should identify transferred material, omitted material and fields whose meaning changed. They should distinguish a deliberate exclusion from a failed transfer and retain enough information to correct errors. Some discrepancies require the user’s judgement. Others should stop the operation because continuing would produce an unsafe result. Those are decisions to design before selling portability as a feature. Switching costs also influence negotiations before departure. A supplier can know that the customer will tolerate a price increase smaller than the cost of migration. That does not make every increase unreasonable. It does explain why a list of competitors may matter less than it appears. The customer needs to assess the cost of leaving while choosing the relationship, when the necessary information may be hardest to obtain.

A public purchaser can ask for evidence of export and recovery instead of accepting a promise alone. A trial migration can reveal missing fields and undocumented dependencies while there is still time to choose differently. The requirement should match the service: a small provider does not need an elaborate multi-cloud architecture to supply a documented copy of its records. Portability can become the customer’s second infrastructure project. If obtaining a usable exit requires maintaining two complete implementations continuously, only well-resourced organisations may be able to exercise it. An alternative can be a maintained export format, a tested migration procedure and obligations that survive termination long enough to complete the transfer. The design should match the scale and consequence of the dependence.

Markets need ways for useful alternatives to reach people. That includes the right to build and practical access to distribution. A product may also need payment services and compatible relationships with other systems. Permission granted at an incumbent’s discretion can leave innovation technically possible and commercially precarious. Any remedy should still preserve fraud prevention, privacy and security. The route to a user is part of the ecosystem’s distribution of opportunity. We should be able to examine the rules governing it without pretending either that intermediaries add no value or that their value entitles them to decide every surrounding term.

A gatekeeper’s protective function should be demonstrable. Its commercial interests should be visible. Its important mistakes should be correctable. Those expectations become stronger as the alternative routes become less usable.

8. The decision you cannot walk away from

I reject “accept the service or leave” as a fair description of many of the most important systems in a person’s life. You may be required to use a public portal to establish an entitlement. Your workplace may select the application through which you receive assignments. Your educational institution may determine the evidence required to progress. Another organisation may hold a record about you that shapes a decision even though you never became its customer.

The route out can be too costly, irrelevant or nonexistent. A person needs protections within the relationship. This changes what a reasonable appeal should do. Customer retention is incidental. The appeal exists to keep the institution’s power tied to a sound account of the facts and rules. It must be able to find a mistake, stop the wrong consequences and authorise a remedy. A hypothetical process makes the problem clear. A person receives an adverse decision. The appeal form asks for a document they cannot access. A helpdesk repeats the requirement. The deadline continues. An escalation is forwarded to the team that made the original decision, where it waits behind new work. Every individual response complies with a local procedure. The person still has no workable way to be heard.

The failure is not solved by adding another form. It needs authority to reconsider the requirement, a route to the missing evidence and a decision about what happens while the issue remains unresolved. A process can be procedurally elaborate and practically empty. The timing matters. An institution may consider thirty days a modest administrative interval. For the affected person it can mean missing a course, a payment, work or access to important records. A final correction does not retroactively make the waiting period harmless.

Temporary protection should follow the consequences. Sometimes it will be right to pause enforcement, preserve access, provide another route or protect somebody from a deadline missed because the institution was late. Sometimes protecting others requires immediate action and access cannot continue unchanged. The institution should explain why and provide the quickest fair review that safety permits. The goal is a fair process capable of rejecting a claim as well as accepting it. A person should not obtain a service by being more persistent or aggressive than everyone else. Staff also deserve protection against harassment and repetitive bad-faith demands. An unlimited right to consume another person’s time is not a plausible account of recourse. That makes well-designed boundaries important. Define the issue, request evidence relevant to it, provide a decision with reasons and identify the next review route. Distinguish a new factual concern from a repetition of one already answered. Give the person a way to correct a misunderstanding before treating it as non-cooperation.

A meaningful explanation does more than recite the policy. It connects the policy to the accepted facts and the conclusion reached. “You do not meet our criteria” cannot settle a dispute about which criteria apply, whether the evidence was considered or whether the policy’s own exception was ignored. Technical design can help or obstruct every part of this. Versioned decision rules make it possible to establish which rule was applied. Provenance can show where information came from. A record of corrections can prevent the same false claim being reintroduced. Accessible interfaces can let people submit evidence without needing a particular device or a helper who must see private information.

But those features need an institution willing to use them. Exposing a record is not the same as allowing it to affect the decision. A human reviewer who has no discretion and no route to the person who does is not meaningful human oversight merely because a human has entered the loop. An explanation also differs from disclosure of everything. Some records contain other people’s private information and revealing detailed fraud-detection logic can make a service easier to attack. An investigation may have good reasons to withhold particular evidence for a time. It can redact that evidence, give it to an independent reviewer or explain it another way. It cannot use secrecy as blanket permission to assert a conclusion that nobody outside the original team can examine.

Where an institution creates the information asymmetry, it should help make scrutiny feasible. A person should not have to guess the exact internal document title before their request can reach relevant evidence. The institution knows how its system works; the affected person often knows only what it did to them. The right to assistance matters too. Someone may need a representative, advocate, translator or independent specialist. Giving them that option can be more useful than expecting them to master every technical and legal detail. Real agency includes the ability to rely on another person under appropriate limits. This is an account of dependence I can defend. We do not become free by abolishing every relationship in which someone else knows more. We become more capable when those relationships are trustworthy, their powers limited and their errors challengeable.

A supplier, employer or public body can make a legitimate decision the affected person dislikes. Universal satisfaction is not the test. The decision needs a sound basis, the process must consider the person’s circumstances and mistakes must be correctable without extraordinary effort. That standard is demanding. It will require staff, records and judgement. It will sometimes cost more than a system designed around the convenience of the institution alone. The cost already exists on the other side: hours spent chasing an answer, opportunity lost during delay and private resources consumed by trying to prove what the institution could have checked itself.

A public service can become easier to access at its first screen while retaining the same delays and uncertainty behind it. A completed online form may still be printed, re-entered, passed between teams or reconciled against incompatible records. The citizen experiences one service. The organisation may account for several separate processes, none of whose owners can resolve the complete case. The UK Public Accounts Committee’s 2023 report on digital transformation described this problem directly. It found that improvements to online interaction had outpaced modernisation of the underlying systems and data. Its recommendations included a senior owner for each end-to-end service and better visibility of costs and performance. The report also recognised progress by the central digital function. This was a dated assessment of the British government, not a finding about every public digital service.³²

The proposed owner should not be interpreted as a person who must solve every technical problem alone. The value lies in having authority to coordinate the boundaries: who requests information, who assesses it, what happens when records disagree and which team must communicate the result. Assigning one person’s name without the necessary budget or decision rights changes little. This changes how administrative efficiency should be judged. A department can reduce its internal handling time by requiring applicants to perform more preparation, obtain additional evidence or chase another institution. The service has become cheaper within one account while its total work remains unchanged or increases. That might occasionally be justified but it should be described honestly. A saving cannot be evaluated without identifying the person now doing the task. The same applies to channel changes. A digital route can save time for most people and create a substantial barrier for a smaller group. The appropriate response may be to retain an assisted route with different operating costs. The existence of the average saving does not explain why the excluded group should lose access. Nor does the cost of a fallback mean that the digital route should be abandoned for everyone.

A service needs to decide what equivalence means. The alternative can omit nonessential features. It should still allow the legitimate task to be completed within an appropriate timeframe and without disproportionate loss of privacy. An accessible form followed by an inaccessible verification step is incomplete. The problem deepens when the same institution sets the requirement and judges whether its alternative is good enough. Independent evaluation can include people who could not use the preferred route, not only successful applicants. Otherwise the service may learn mainly from people it already accommodated.

Correctability should be designed into the ordinary service rather than reserved for a scandal. A person should be able to identify a discrepancy, receive an explanation and supply relevant evidence without knowing the institution’s internal structure. The institution can reasonably reject a request outside its role but should say which decision it can make and where the unresolved matter belongs. Repeatedly forwarding a case without an accountable handover is not a remedy.

A public authority also has duties beyond customer satisfaction. It may need to refuse an entitlement, enforce an obligation or protect another person’s information. The applicant need not receive the answer they prefer. The answer should come from a lawful, understandable and reviewable process, and the consequences should match what the authority has actually established. Those expectations are compatible with automation. A limited automatic check can reduce arbitrary variation and free staff to examine difficult cases. Failure begins when the automatic result carries more authority than its evidence or nobody with enough access can correct it. The service needs to identify which decisions are routine, which require judgement and which should stop when an essential fact is missing.

The choice is not between an expensive humane process and a costless existing one. It is about who performs the work, whether it is necessary and which party has the best ability to do it properly. We should stop calling a right meaningful before we have examined the ordinary person’s route to exercising it.

9. Identity, privacy and the recovery route

I dislike the way systems ask for identity as though identity were a single fact. Often the service needs something narrower. It may need to know that the person controls an account, meets an eligibility condition, may act for an organisation or has authorised a particular transaction. Those questions do not all require a legal name and a legal name does not answer all of them.

Collecting identity information creates another dependency and another risk. A service acquiring a copy of a document now has to protect it, decide who may inspect it and explain what happens when the information changes. The collection can make fraud harder in one place while giving an impersonator useful information if it is mishandled. Its value depends on the decision it actually supports. NIST’s 2025 authentication guidance separates control of authenticators from the wider identity process. Its assurance levels concern confidence that a claimant controls an authenticator bound to an account and the resulting identifier can be pseudonymous. The guidance also treats recovery as a separate process and recognises that the ordinary authenticator may no longer be available.³³ That distinction matters. Control of a key proves control of the key, not that every proposed action is legitimate. A legal identity does not prove professional authority. A person can authenticate successfully and still be denied access because the operation is outside their role. The interface and its records should keep those boundaries clear.

A reliable identity service can make life easier. Repeatedly proving the same fact to different institutions can be expensive, inaccessible and risky. Reuse can reduce unnecessary document collection. But it also creates a question about the consequences of an error or suspension in the shared service. If one provider mediates many relationships, losing access can have effects far beyond the account in which the problem began.

The architecture should therefore distinguish a convenient shared credential from an irreplaceable authority over ordinary participation. Which services can still be used during a dispute? Can another valid route establish the necessary fact? Does the relying institution know why authentication failed or only that the provider returned an error? An ambiguous failure should not silently become evidence that the person is ineligible. Data minimisation is a practical constraint on this expansion of authority. The Australian privacy regulator’s guidance on APP 3 distinguishes information reasonably necessary for an organisation’s activities from information that would merely be useful or convenient. It also distinguishes the relevant requirements for agencies, sensitive information and ordinary personal information. The guidance gives examples in which collecting a whole identity document exceeds what is needed to establish a narrower fact.³⁴ Those are requirements within the law’s scope. The wider design principle is useful even before a legal dispute arises: state the decision then identify the minimum evidence that can support it. Do not collect everything because the form could later be used for another purpose.

For example, a service checking age might need a trustworthy statement that a threshold is met rather than a retained copy of an identity document containing unrelated information. That is possible. Not every age-assurance product achieves it. The method still needs to address fraudulent reuse, errors, accessibility and the power of whoever makes the assertion. A privacy claim should state what each participant learns and retains. The same applies to professional eligibility. A verifier may need to know whether a qualification remains valid without seeing the applicant’s full educational history. An employer may need evidence that a task was performed competently without receiving confidential incident material from a former employer. The record should answer the relevant question without building a richer personal dossier.

Children cannot be treated merely as accounts for which an adult clicked accept. Parents and guardians have important responsibilities but a child also has privacy, safety, access and participation interests of their own. Those interests change as the child develops. The UN Committee on the Rights of the Child’s guidance for the digital environment treats access and protection together and asks institutions to consider non-discrimination, the child’s best interests, participation and evolving capacity.³⁵ A service should not respond to every risk by excluding children from useful participation or collecting a permanent identity record about them. It should explain what is age-dependent, use only the evidence needed for that decision and provide a route when the assumed family, document or device does not exist. Protecting a child can require limits. It also requires asking whether the limit preserves their ability to learn, communicate and be heard.

There are costs to narrower proofs. An intermediary must issue them accurately, relying parties must interpret them consistently and people need a way to challenge a mistaken result. Reducing the data disclosed to one party can increase dependence on another. The improvement should be evaluated across that relationship, rather than stop at the amount of information visible on the final screen. The account-recovery process exposes the practical limits of an authentication design. A person loses a device, a phone number is reassigned or the only recovery address becomes unavailable. The normal login was secure under the conditions for which it was built. The person now needs a route back without giving an attacker a simpler route in. These objectives can conflict. An immediate, convenient recovery based on information that many people know can undermine the ordinary authentication. A rigid requirement to present the lost authenticator makes recovery impossible. A manual decision can accommodate exceptional circumstances but introduce inconsistent judgement and opportunities for social engineering.

The design has to decide how that conflict is handled. Options include additional credentials established in advance, offline recovery information, a trusted contact or repeated identity proofing where that was part of the original relationship. The right combination depends on the risk and on what the service actually knows about the account holder. A pseudonymous service cannot fairly promise recovery through a legal identity it never established.³³

Recovery planning should also account for interim needs. A person unable to change an address may still need to read an urgent notice. Someone disputing an account suspension may need to preserve records before an automated deletion takes effect. Allowing limited access can create risk but denying every function also has consequences. The relevant permissions should be considered separately rather than made to rise and fall with one account status.

The service should explain recovery before the loss occurs. A procedure buried in support documentation is unlikely to help someone who discovers that every route requires the device they no longer have. A backup option matters only if the user can understand, establish and retain it. The provider should test whether ordinary people can complete the process under realistic conditions. Accessibility creates another constraint. A method can work for most people and remain unavailable to someone without the required document, physical ability, private device or stable address. An alternative route should maintain the necessary assurance through another means. The institution has to allocate resources to that route if it expects the public to depend on it.

Future disputes and fraud investigations create an understandable temptation to retain more information. Sometimes retention is justified. But a service should distinguish the evidence needed to establish an event from every detail it could record about a person’s activity. A log can record that someone used a permission without retaining every private document involved. A verification record can identify which requirement was checked without copying all the underlying evidence into a new database. Whether that is enough depends on the task, the threat and the law. Accountability and collecting everything are not the same goal.

Access to those records also needs boundaries. Staff investigating a disputed transaction may need detailed information. A marketing team has a different purpose. Joining data is technically easy; that does not make every combined use acceptable. Consent alone cannot do all the work. A notice can explain a service; it cannot create an alternative for someone required to use it for employment, education or an essential entitlement. The provider should be able to explain why the collection is necessary and appropriate instead of relying only on a log saying the person agreed.

Privacy does not have to stop a legitimate investigation. A reviewer with limited authority can inspect evidence that should not be public. The reviewer needs clear powers, confidentiality and rules about what can appear in the outcome. A person challenging the decision should still receive enough explanation to understand the result. I want security that protects people’s ability to act including their ability to recover from ordinary losses. A system that protects an account by making it permanently inaccessible to its legitimate holder has solved only part of its problem. A system that offers easy recovery by collecting an unnecessary permanent identity dossier may have moved the risk elsewhere.

The right question is which facts must be established, how reliably they can be established and what happens to a person when the preferred method fails. That is more precise than asking for more identity or less security.

III. The work behind the promise

10. What the tools make easy to get wrong

I have little patience for treating an established tool as beyond criticism merely because people have learned to survive its awkwardness. Familiarity can conceal a continuing cost. It can also make a critic impatient with a distinction the tool genuinely needs to represent. I want an actual example before accepting either conclusion. A difficult tool can still be well designed because some problems contain real complexity. Concurrent changes can conflict. A network request can succeed at the remote end while its acknowledgement is lost. A transaction can be incomplete. A resource can have several legitimate owners with different lifetimes. Hiding those distinctions may make the first demonstration easier while making recovery much harder.

The design question is where the complexity goes. Does the system represent the distinction explicitly or leave each user to reconstruct it? Does the ordinary operation preserve an important invariant? Can a person recognise the consequences before committing to them? How much of the difficulty comes from the problem and how much comes from the history of the interface? Consider a state model that deliberately permits exactly one of four states: waiting, running, completed or failed. Representing it with independent Boolean flags can permit combinations excluded by that model, such as running and completed at the same time. A more constrained representation could exclude those combinations. It would not decide whether the process should have been launched, whether its output is correct or whether the user has permission to see it. It would remove one avoidable source of ambiguity. That is the scale at which language and API design become substantive. The design should distinguish mistakes it can make impossible, mistakes it can make conspicuous and questions that require continuing human judgement.

A language that represents every failure as a special value can be straightforward until callers forget to check it. A language with explicit error types can force attention to the possibility while still allowing careless handling. A powerful type system can encode a useful protocol and become so elaborate that maintainers cannot tell whether the protocol is correct. Each choice moves work between the compiler, the original author and the next person trying to change the program.

Calling a language small does not answer where its complexity went. If omitted features are recreated through application-specific conventions, the language specification may be simple while the resulting ecosystem is not. Calling a language expressive is equally incomplete. A compact abstraction can still be miserable for a colleague to debug under pressure. I want to judge designs through the complete working environment. What information can the tool retain about intent? Does it distinguish a missing value from an empty value, a denied operation from an unavailable service or a partial success from a complete one? Can developers test the failure path without constructing a production disaster? Can a reviewer see which assumption is being relied on?

Rust provides a useful example of a deliberately enforced boundary. Its safe facilities constrain memory use, while specific operations require unsafe and additional reasoning. The official documentation also explains that unsafe does not disable every other compiler check. Safe interfaces over unsafe internals must actually uphold the invariants on which callers rely.³⁶ That architecture is valuable without becoming a complete safety certificate. A memory-safe program can send a private record to the wrong person. It can enforce an unjustified policy accurately. A dependency exposing a supposedly safe operation can contain an unsound implementation. We need to preserve the scope of the guarantee, because inflated claims make users less informed about the risks that remain.

The opposing argument is equally weak when it points to those remaining risks as though they cancel the benefit. Preventing a category of memory corruption matters. It does not have to settle every other engineering problem before it deserves adoption where it fits. My frustration with programming languages is therefore not a demand for one perfect language. It is a demand that their choices remain open to evaluation, especially where a design repeatedly asks humans to supply a property the system could enforce. There can be justified escape hatches. They should be recognisable escape hatches, not the unremarked path through every application.

Git gives a smaller, directly inspectable example. Its official documentation describes checkout as serving both branch-related and path-restoration functions and points to the more specialised switch and restore commands. Restoring a path from the index can replace unstaged working-tree changes, while git restore --source=HEAD explicitly selects the committed version. The underlying object and reference model is a separate subject from whether the interface makes a person’s intended operation clear. This is documented behaviour, not an internal Git defect or a measure of how often people lose work. An editor, backup or stored object may still recover an overwritten edit. My concern is whether an operation that discards work is clear to the person invoking it.

A strong defence is that this is an explicit instruction to restore a path. Non-interactive tools need predictable behaviour for scripts. Adding confirmations everywhere would break established use and train people to dismiss prompts. That defence matters. It suggests that an improved design must distinguish human-facing assistance from stable automation, rather than make every primitive stop and ask. There are several possible improvements to examine: clearer commands, a preview in an interactive wrapper, an explicit discard operation, automatically retained local snapshots or better teaching of the index. Each has costs. Snapshots consume storage and can retain secrets. Wrappers can obscure the underlying operation. Changing vocabulary can confuse experienced users and existing documentation. No alternative wins merely because it sounds friendlier.

The narrow conclusion remains worthwhile: a user should understand which version will replace their work and what protection exists before an operation discards it. A version-control tool’s purpose makes that expectation especially reasonable. We can criticise the interface without pretending to have audited every line of the implementation. The same restraint should apply to claims of correctness. A test exercises particular conditions. A proof establishes a property under assumptions. A reproducible build connects specified inputs to an output. These achievements answer different questions. A reproducible malicious program remains malicious. A proof of a policy can faithfully prove the wrong policy. A passing test suite can leave the important deployment condition untested. A modest claim backed by a useful procedure is stronger than a grand claim protected by vague language. “Production-ready” ought to say which workload, maintenance, recovery and support the product can sustain. Without that context it is advertising.

A tool also has a social interface. Its vocabulary, error messages and documentation determine who can participate without already knowing the hidden conventions. The author who finds an interface obvious may be remembering years of exceptions no longer noticed as exceptions. Expertise is valuable; it should help identify unnecessary burdens rather than turn them into entrance requirements for the next person. Selecting a generally safer language cannot remove errors that first require a decision about meaning. A calculation can be arithmetically correct and still implement the wrong rule.

Consider three amounts of 0.005 in a currency accounted for to two decimal places. Under an explicitly chosen half-up rule, rounding each amount before addition produces 0.03. Adding first and rounding the total produces 0.02. The difference is not a defect in floating-point representation. It follows from choosing where rounding occurs. A type named Money does not choose that policy automatically. It can record the currency and prevent some invalid operations. The application still needs to establish the precision, rounding point, treatment of refunds and relationship between displayed and settled values. Replacing arithmetic with a library helps only when the library’s contract matches the intended rule.

A time value exposes the same problem. It needs a clear meaning and level of precision. A missing reading differs from a measured zero. A status that has not been assessed differs from a failed assessment. A system that compresses these states into one convenient field may force downstream code to invent distinctions that the record no longer contains. The representation should make the required differences visible. A small tagged value or explicit status may be enough. The choice should reduce ambiguity for everyone writing and maintaining the code.

Excessive abstraction creates a related risk. A generic framework can conceal a domain rule behind so many layers that the person checking the result cannot find where the rule is applied. A sophisticated type can be used inconsistently at the boundary. A helper that silently converts an unknown value into a default can undo the care taken elsewhere. The relevant measure is the complete path from meaning to action. Can a reviewer identify the source of the value, the transformations applied and the conditions under which the operation is permitted? Can a maintainer change the rule without guessing which other components rely on it? Can a test distinguish the old interpretation from the new one?

Data exchange has the same problem. RFC 8259 says JSON object names should be unique and warns that receivers behave unpredictably when they are not.³⁷ A document can contain the same permission field twice, once false and once true. One receiver may keep the later value, another may report every value and another may reject the document. A system cannot assume that every participant will derive the same meaning from an ambiguous representation. If one component approves an operation using one interpretation and another executes a different interpretation, syntactically valid JSON is not enough.

A high-consequence application can specify a stricter profile: reject duplicate names, define number limits, distinguish absent fields from explicit nulls and make unsupported values fail visibly. The profile should be checked at the relevant boundaries. It should not rely on an undocumented assumption that every library happens to choose the same behaviour. Strictness has costs. A newly rejected document may expose a long-standing producer defect and interrupt a service. An incremental rollout can measure those failures before enforcement and give producers a path to correction. Silently accepting the ambiguity indefinitely is also a choice, with consequences the service should understand.

Programming tools deserve this kind of criticism. Declaring one language good and another bad says little. Show which distinctions the tool preserves, which operations it makes dangerous and which obligations it pushes into application conventions. Then compare a feasible alternative under the same conditions. No universal winner exists. An embedded controller, a research script and a public financial service have different constraints. Those differences should produce explicit design decisions. Every chosen environment still deserves scrutiny for the mistakes it makes easy. This is one place where technical criticism can become genuinely humane. A safer operation saves attention. An understandable error saves a person’s time. A clear state model saves a future maintainer from reconstructing the original author’s intentions. Those benefits do not need to be dramatic to matter.

But the criticism must reach beyond irritation. Show the behaviour. Explain the burden. Distinguish necessary complexity from incidental complexity. Compare a plausible improvement against the costs it introduces. Then make the judgement directly.

11. The record is not the defence

Security work is full of records that are useful until somebody mistakes them for protection. A Common Vulnerabilities and Exposures (CVE) identifier lets people refer to the same publicly disclosed vulnerability. A Common Vulnerability Scoring System (CVSS) score describes selected technical characteristics. An advisory gives a supplier’s current account. A patch changes software. None of them can tell an operator by itself whether attackers have already reached the system, whether every vulnerable installation can obtain the fix or whether the public explanation is complete. The vulnerabilities branded PHP2Shell provide one unusually public and easy-to-examine example. Their chronology exposes decisions from the first recognition of the underlying problem through private reports, patch preparation, broken disclosure and observed exploitation. The case is not unique. It makes several recurring failures visible within one documented sequence.

The first signs of the memory problem behind CVE-2026-109618 appeared during a PHP security audit in 2024. A possible exploit was considered but no concrete route was found. The security team developed competing fixes with serious costs: compatibility breaks, new denial-of-service risks or changes across extensions it could not realistically coordinate. Work stalled and restarted. The PHP Foundation later called the delay a structural failure caused by its decision process and lack of resources. On 11 August 2026 Calif reported unconditional remote code execution with the same root cause. OpenAI independently reported it and further attack paths followed from OpenAI and Wiz. The defect had moved from a difficult unresolved concern to an urgent remote-execution problem yet the people running PHP still could not act on information they did not have.³⁸

The eventual advisories describe two critical vulnerabilities allowing unauthenticated remote code execution. CVE-2026-109618 concerns invalid state left by an out-of-memory exit. CVE-2026-109619 concerns request-owned state surviving into another request. The confirmed paths differ across Apache mod_php, PHP-FPM, application behaviour and configuration. Both advisories score the vulnerabilities at 9.2. Both make the essential remedy clear: install a patched release. Configuration changes can remove particular routes but none provides a complete general fix.³⁹

The nickname is part of the mess. PHP2Shell is memorable and almost useless as a technical description. It does not identify the two PHP core defects, affected versions, server interface, preconditions or confirmed routes. The fashionable “something2Shell” formula invites people to infer a universal route from the named technology to a remote shell. A nickname can help somebody find the discussion. It cannot replace an identifier and a precise account. The security industry keeps turning engineering failures into brands then acts surprised when public discussion becomes inaccurate.

I have a complete remote exploit against pinned vulnerable PHP and Apache environments on my own machine. It reaches benign command execution over HTTP. I am not publishing its mechanics here. Its scope matters. It proves that remote execution is concrete in those environments, not that every PHP deployment is exploitable through the same path. That is the level of precision public discussion repeatedly lost. Claims circulated that exploitation required an explicit session_start() call, that PHP-FPM was unaffected or that disabling one setting solved the problem. The official advisories say otherwise. Session upload progress is enabled by default and does not require an application call to start a session. PHP-FPM has different preconditions but confirmed application-level paths exist. Disabling session upload progress removes one demonstrated path, not the wider stale-state problem. An operator needed those distinctions more than another confident summary of the score.

The disclosure then became its own incident. AWS found an exploitation attempt dated 17 October, four days before public disclosure. On 20 October the CVE identifiers began circulating with the wrong release time and a score of 10.0 rather than 9.2. PHP moved its preannouncement forward and brought the release from 22 October to 21 October. A researcher then mistakenly published a video of a working proof of concept. Copies spread and speculative exploits followed. At 07:41 UTC on 21 October, more than six hours before the coordinated release, Chainguard published fixed images. Anybody could compare those images while most users were still waiting for an official update. AWS observed several different attempts between 02:00 and 08:00 UTC that morning before the embargo lifted at 14:00 UTC.⁴⁰

This chronology does not support one convenient villain. The 17 October attempt predates the circulating CVE details, accidental video and Chainguard images. The early image release did not create the first observed attacker. It still gave attackers another route to study the correction while other distributors honoured an embargo and their users had no general release to install. PHP’s original delay, the weakly resourced decision process, the leaked identifiers, the mistaken video, the unilateral image publication, public speculation and uneven package availability all affected the same outcome. Calling that process coordinated does not make it coordinated.

PHP’s unusually complete public chronology makes it easy to see why security milestones need separate names and dates. The underlying problem was recognised, exploitability was suspected, remote execution was privately demonstrated, a patch was written, distributors received it, fixed packages became available, the public advisory appeared, exploitation was observed and individual systems were eventually updated. “Known”, “fixed”, “released”, “disclosed” and “protected” describe different states. When a supplier says a vulnerability is fixed while an operator cannot obtain the package, the operator is not protected. When a scanner reports a vulnerable version after a distributor backports the change, the matching record is not enough. When an update succeeds after earlier exploitation, the vulnerable code is gone but stolen credentials and persistence do not disappear with it. The record must preserve enough of the route from defect to deployment for someone to establish which state is real.

Cisco has chosen to weaken that identity deliberately. Since July 2026 its disclosure model has grouped vulnerabilities that share a Common Weakness Enumeration category under an “umbrella” CVE identifier. The umbrella receives the highest CVSS score of any vulnerability in the group. Cisco says this streamlines disclosure and helps customers patch. Its September 2026 Secure Email hardening advisory shows what the policy means. One identifier for improper neutralisation covers command injection, SQL injection, code injection and cross-site scripting. Another for improper access control covers authentication, authorisation, privilege and bypass failures. A third covers uncontrolled resource consumption, algorithmic complexity, recursion, deserialisation and improper resource initialisation. Two underlying vulnerabilities were already being exploited.⁴¹

This is a bad use of CVE. A CWE describes a class of weakness. It is not the identity of one vulnerability. A release can reasonably fix several defects together and an advisory can reasonably tell customers to install one hardening update. Neither fact requires collapsing those defects into one identifier. Under Cisco’s model the score attached to the umbrella is the maximum severity of its worst member. That number does not describe every vulnerability carrying the identifier. A later exploit can target one member while a mitigation blocks another. A backport can fix some members. A researcher can discover that one reported defect is not exploitable without disproving the rest. Downstream tools cannot represent those differences cleanly because the supplier discarded them at assignment.

The CVE Program’s own rules say that numbering authorities should assign different identifiers to separate and independently fixable vulnerabilities. They also say a record should contain enough information to identify the vulnerability and distinguish it from similar vulnerabilities. Those are “should” rules and numbering authorities retain judgement. Cisco can argue that its approach remains within that discretion. The result is still worse for defenders. A category is not an incident, a patch bundle is not an identity and supplier convenience does not justify making independent flaws harder to trace.⁴²

CVE-2026-102764 exposes a different failure. A suspected state-backed actor exploited a zero-day in BeyondTrust Remote Support on 29 August 2026 against one hosted appliance and one self-hosted appliance. BeyondTrust says its sensors fired in real time when the actor escalated privileges. A third-party automated triage system closed those alerts as false positives. The activity was not recognised until 28 September after a separate edge-device campaign prompted a hunt through older telemetry. BeyondTrust contained the hosted instance within 27 minutes of that discovery, reproduced the entry route about seven hours later, validated a fix by 30 September, distributed the patch on 8 October and published the advisory on 15 October. That is 40 days from the exploitation to patch availability and 47 days to the public advisory. The vendor reports only those two affected customers and no further activity after August.⁴³

Once BeyondTrust understood the event, it investigated quickly, released the patch before public technical detail and used off-appliance evidence that survived the attacker’s deletion of local logs. None of that excuses the earlier failure. The system saw high-severity behaviour while it happened then allowed an automated verdict to erase it from human attention. No additional scoring standard would have repaired that decision. The evidence existed. The disposition was wrong. Retaining closed alerts for later hunting helped recover from the mistake. Preventing a third-party triage system from closing a high-severity signal on its own would have been better.

These are three visible examples of failures at different points, not the boundary of the problem. The PHP vulnerabilities joined an unresolved technical problem to inadequate maintenance capacity and a disclosure process that broke apart under pressure. Cisco made the coordinating identifier less exact by design. BeyondTrust had useful telemetry and accepted a false conclusion about it. They share one lesson: producing the expected record is not the same as protecting the people who depend on the system.

A better system should not wait for complete proof before giving defenders a shared public identifier. That would turn evidence discipline into another delay. The useful function of CVE is rapid coordination around a publicly disclosed vulnerability. The identifier should begin the investigation rather than become its conclusion. It should not decide by implication whether several reports share one root cause, how many vulnerabilities exist, which products are affected, how severe each condition is, whether attackers can exploit it or whether the correction works.

The fuller record should retain the original source and exact source claim then distinguish the falsifiable technical claim, coordination decision, aliases, product-specific affectedness, verification evidence, severity assessments, observed exploitation, remediation and correction history. A CVE, GHSA, OSV or vendor identifier and any memorable nickname would remain a source-attributed alias. An umbrella identifier remains a disclosure bundle until evidence establishes its members. A CWE remains a weakness classification. A patch remains a remediation artefact. Sharing a classification, score, component or patch does not make two vulnerabilities identical.

There should be no universal vulnerability or risk score. Technical severity, exploit likelihood, observed exploitation, affectedness, environmental consequence, fix availability and operational priority answer different questions. CVSS can remain one technical severity method when its vector identifies the applicable product, version, deployment and systems whose impact it measures. An operator can combine the separate dimensions through an explicit local policy. That priority belongs to the operator’s context. It must not be written back into the public record as universal vulnerability truth.

Every conclusion also needs an evidence state and a history. Confirmed, contradicted, not reproduced, insufficient evidence, environment dependent and disputed are materially different results. A failed reproduction must not become “safe”. Missing evidence must not become “unaffected”. A later correction should append a new conclusion, name the evidence that changed and identify the assessments, feeds and operational decisions which inherited the earlier claim. A correction that stops at the source record leaves the downstream failure in place.

I am not interested in congratulating an ecosystem because every participant produced the document its process required. Attackers do not care that the CVE was syntactically valid, the score correctly calculated, the advisory eventually published or the patch technically available somewhere. Defenders need enough truth early enough to act. The record should identify the exact defect, preserve where a claim came from, state when exploitation was observed, distinguish a source fix from an obtainable package and distinguish installation from recovery after compromise. A correction should reach every decision that relied on the earlier claim. If a standard makes those facts harder to express, the standard is part of the failure. If an organisation has the facts and withholds, flattens or discards them, the organisation owns that decision.

This is not administrative tidiness. Machines are compromised, credentials are stolen, services are interrupted and people carry the consequences. The record is useful only when it serves the defence. The defence is the point.

12. From the repository to the running system

I do not treat published source code as proof of what a person is running. Between the source and the machine are build instructions, tools, dependencies, packaging, distribution and installation. Each can affect the result. An assurance about one stage should not be presented as assurance about the whole path. The XZ Utils backdoor made that distinction visible. The project’s current account identifies malicious release tarballs for versions 5.6.0 and 5.6.1 while Red Hat’s investigation explains that the triggering build material was absent from the Git distribution and that its affected packages had reached Fedora 41 and Rawhide rather than Red Hat Enterprise Linux.⁴⁴ These records support a criticism of the release chain without making open development uniquely vulnerable to deception. Discovery and staged distribution also constrained the attack. A fair account needs both the failed boundary and the controls that limited the harm.

Shai-Hulud removed any excuse for treating package installation as a passive download. GitHub says the September 2025 attack entered npm through compromised maintainer accounts, injected malicious post-install scripts into popular packages, stole several kinds of secrets and used those secrets to replicate. GitHub removed more than 500 compromised packages. Later waves targeted continuous-integration environments, registered self-hosted runners and added destructive behaviour. The dramatic name adds little. The operational facts matter: installing a package executed publisher-controlled code, the process could read valuable credentials and one stolen publication identity could turn downstream trust into distribution for the next compromise.⁴⁵

The platform response added stronger authentication, shorter-lived publication tokens, trusted publishing and staged releases. Those controls can break important links in the attack. They do not make the chain safe by declaration. A project has to adopt them, scope its credentials, control what installation can execute and retain enough evidence to recognise a poisoned release after the registry removes it. A lockfile can identify the malicious version but cannot undo code already executed during installation. Removing a package from the registry can stop new downloads but cannot revoke secrets already copied from a developer machine or build system.

LiteLLM suffered two supply-chain compromises in 2026. Its March account says versions 1.82.7 and 1.82.8 were poisoned after an unpinned Trivy dependency ran in a shared continuous-integration environment beside static publication credentials. LiteLLM responded by separating build stages, moving towards ephemeral credentials and trusted publishing, signing images and adding release auditing. Those were sensible corrections to the route it had found.⁴⁶

Seven months later another route produced a malicious official release. On 21 October LiteLLM’s version 1.107.0 wheels and container images contained compiled malware that stole credentials and loaded remote code execution tools. The matching GitHub source tag did not contain the malicious files. The PyPI release remained live for about two hours and several moving container tags pointed to compromised images for longer. Somebody inspecting the public source tag could therefore examine clean source while users received malware through official distribution channels.⁴⁷

The compromise began months before publication. LiteLLM’s own investigation says a master key was committed to a public repository in May then removed by force-pushing the history. The key was identified for revocation but was not revoked. In October an attacker used it to obtain an organisation owner’s GitHub token, extracted more credentials, changed the release workflow, approved the production gate with a stolen token, deleted workflow runs and force-pushed the visible history clean. The release system did not fail to recognise an authorised credential. It accepted authority which should never have been available in that form. A clean tag, successful signature, generated inventory or green workflow would each have described one part of the event while missing the decisive compromise.

These incidents identify what a release path should refuse. Installing a package is code execution, not passive retrieval. A build should declare and isolate any dependency code it permits to run instead of giving every installation script access to developer, cloud and publication credentials. A security scanner needs authority to inspect source, not authority to publish a release. Release jobs should use short-lived purpose-bound identities which cannot administer the complete project. An exposed secret must be revoked rather than removed from visible history. Publication from an unexpected source or an unapproved workflow should fail. Moving tags can help discovery but an exact artefact digest and retained release decision should govern deployment. Once a malicious package has run, installing the next version is not recovery. The affected environment and every credential it could reach need examination, rotation or reconstruction.

The more general question is what a consumer can verify about the artefact received. A repository can be public while a release archive contains additional material. A build can fetch dependencies that were not present during review. A packaging step can alter an executable. The final signed output may therefore require a different evidentiary record from the source revision that originally attracted trust. A valid digital signature shows that the supplied bytes verify against a specified public key. Under the scheme’s assumptions, this is evidence that the related private key was used to sign them. The verifier still needs a reason to trust that key, an account of what its holder was authorised to approve and a way to respond if the key is compromised. A signature does not determine whether the approved material contains a defect.

The familiar advice to install only signed software needs a defined scope. It can protect against unauthorised changes within a known distribution system. It cannot replace evaluation of the publisher, the build process or the permissions granted after installation. A harmful release signed by an authorised publisher remains harmful. An attestation has similar limits. It records a claim by an issuer about an artefact or process. Its usefulness depends on the issuer’s access, method and authority. A consumer should know whether the attestation came from an independent build service, the project’s own release script or a manually maintained statement. The format can be standardised without making those evidentiary differences disappear.

The eMudhra incident should end any habit of treating a ceremony, certified device or audit as the result itself. On 30 April 2025 eMudhra generated intermediate certificate authority keys during a formal key generation ceremony. eMudhra says it used FIPS 140-2 Level 3 certified hardware security modules. Its account says an approved wrap and unwrap deviation created a second weak set of keys then the weak set was used for the certificates. All eight affected P-384 private values were between 1 and 255. One was 4. Mozilla and Scott Helme independently recovered the keys from the public certificates. Six certificates could issue trusted TLS certificates and two were for code signing. Sectigo had also cross-signed the affected keys.⁴⁸

The hierarchy entered browser trust stores and eMudhra says it passed two independent audit cycles. A related 2025 incident had already exposed invalid certificate revocation list signatures for the same intermediates. Mozilla’s public incident record now asks why the key mismatch did not cause eMudhra to stop and investigate the existence of two key sets. That question remains open. The affected intermediates issued no end-entity certificates and there is no public evidence that an attacker abused them before disclosure. Chrome and Mozilla moved quickly to block them after the report. Those facts limit the observed harm. They do not rescue the ceremony. The process performed formal steps around keys whose essential property had not been established. Compliance evidence that did not catch a private key of 4 is evidence about the ceremony, not evidence that the resulting keys could be trusted.

A competent key ceremony ends only after the final output has been independently checked. The public key and certificate request should be matched to the intended hardware key object, algorithm, parameters, purpose and authorised hierarchy. Algorithm-specific validation should reject trivially weak material. A deviation from the witnessed procedure creates a new procedure which needs its own review rather than inheriting the old ceremony’s assurance. Witnesses should bind their approval to the exact script, device configuration, authorised deviation, generated key identities and final requests. A cross-signing authority should perform its own validation before extending trust. Recovery must then reach every trust store that accepted the key. A rapid browser block does not update an operating system, language runtime, container image, appliance or abandoned embedded device automatically. Ceremony, audit, revocation and deployed distrust are separate states.

Supply-chain Levels for Software Artifacts (SLSA) version 1.2 separates responsibilities between the producer and the build platform and defines requirements concerning provenance and isolation. Its Build Level 3 requirements concern protection of the build process; they do not require the platform to prevent a producer choosing a risky or insecure build.⁴⁹ That distinction is concrete in the LiteLLM incident. Provenance could have exposed that the published artefacts came from an unexpected source. Provenance issued through the compromised workflow under stolen authority could also have recorded the attacker’s build faithfully. The record helps only when the consumer can establish which source, builder and authority it is prepared to trust.

The Reproducible Builds project defines reproducibility through obtaining bit-for-bit identical specified outputs from the same source, environment and instructions.⁵⁰ Rebuilding LiteLLM 1.107.0 from its public tag should have exposed that the official wheels and containers came from somewhere else. That is valuable. Rebuilding the attacker’s source perfectly would only reproduce the malware. Changing the compiler version, build path or timestamp can also alter an honest output unless the process controls them. A reproducibility claim therefore needs to identify the artefact and every material input rather than say only that the project builds.

Independent reproduction can detect a mismatch between the published recipe and the distributed result. It cannot tell us whether the recipe itself is safe. Two builders faithfully compiling malicious source can produce the same malicious artefact. Builders sharing one compromised input can agree for the wrong reason. Confidence grows when the builders are genuinely independent and their dependencies are understood. That limitation does not make reproducibility pointless. It narrows the uncertainty and provides another route to inspection. Source review, reproducible builds, protected release credentials and deployment controls address different parts of the chain. The useful design explains how they work together and which assumptions remain.

A smaller project might not be able to operate elaborate independent infrastructure. Shared build and verification services can reduce the burden but also concentrate trust. Their governance, access controls and continuity become part of the dependency. An institution adopting the output for an important purpose should examine those services instead of demanding a badge the maintainer has no resources to earn. A software bill of materials generated from LiteLLM’s clean public tag would not have described the malicious official wheels. One extracted from a compromised image might list ordinary components while saying nothing about the hidden payload’s origin or behaviour. Source dependencies, build inputs, a distributed package and a deployed system are different inventories. A useful record states what it observed, how it was produced, which exact artefact it covers and what remains unknown. Without that information an SBOM is formatted reassurance.

The inventory also needs an owner. Someone must be able to use it when a serious defect is disclosed, identify the affected deployment and decide what to do. A directory full of perfectly formatted inventories still fails if nobody knows which one describes the service in use. The same problem affects attestations about exploitability. A supplier may state that a vulnerability does not affect a product because a particular code path is unavailable. The consumer needs the basis, relevant version and conditions. A configuration change may invalidate the statement. Retaining only the conclusion can make the old assessment appear to authorise a deployment it never examined.

A supply chain is also a chain of delegated authority. Somebody can merge source, alter a build job, upload a package, change a dependency or rotate a signing key. These powers should not all be inferred from a person’s public reputation. A long record of useful contributions can justify increased trust without exempting every future action from review. A legal name can improve some forms of accountability while saying little about whether a patch is correct. Requiring public identity can also exclude people with legitimate privacy needs. The controls should follow the power granted and the harm its misuse could cause.

A release process may require a second person to inspect an important change. That control is useful only if the second person has enough time, information and independence to do so. Approval by someone who cannot reproduce the build or understand its effect may create a record of review without supplying much additional assurance. There should also be a route to reduce scope when review capacity is unavailable. A project can postpone a release, restrict changes or decline a feature. A commercial adopter should not respond by pressuring a volunteer to remove the control so that the adopter’s deadline can be met. The adopter can fund capacity, accept a delay or take responsibility for its own maintained version.

Security and labour meet here. The system cannot claim careful stewardship while relying on exhaustion to complete it. A process should remain workable when a trusted contributor is ill, absent or no longer interested. Succession planning can remain light for a hobby project. Organisations depending on that project still need to know what continuity plans exist. A compromise can require more than releasing a clean version. Consumers need to know which artefacts were affected, how to recognise them and what the exposure might have permitted. Keys or credentials may need replacement. Records may need review. An ordinary update can remove vulnerable code without reversing an action already performed through it. The response should preserve those distinctions. Correcting the source does not update every package mirror. Publishing a package does not upgrade every installation. A successful upgrade cannot tell us whether a secret was exposed beforehand.

An incident account should connect the source, build, distribution and deployment records. Operators need clear instructions, investigators need enough technical evidence and everyone needs to know what remains uncertain. Reassurance alone leaves important decisions unsupported, while publishing every sensitive detail immediately can create new risks. Disclosure should focus on what affected people can use to protect themselves. The lesson is that trust has specific objects. Trust in a maintainer, a source revision, a build service, a release key and an installed system are related claims. They should be supported separately and connected through evidence. Calling the software open, signed or certified cannot make those connections on its own.

13. The people doing the invisible work

I can add a dependency to a project in one line. That line says nothing about the work that makes the dependency worth using. Someone reviews changes, understands old assumptions, maintains tests, explains failures, handles releases and responds when a security report interrupts everything else. Someone decides whether a plausible contribution belongs in the architecture. Someone remembers why the obvious simplification was tried before and removed. That knowledge does not reproduce itself when the package is downloaded.

Some maintainers are paid well. Some volunteer. Some combine employment, sponsorship and personal interest. Treating them all as exploited victims would erase their agency and the diversity of the work. Treating the absence of a bill as proof that no resources are required is equally absurd. An organisation adopting a dependency for an important purpose should know what sustains it and what happens if current support ends. It can purchase support, contribute staff, fund upstream work, maintain a suitable version or reduce the dependence. It cannot assume that publishing code made one person permanently responsible for every commercial use.

The licence does not employ the maintainer. Product abandonment requires an important boundary. A manufacturer selling a maintained product has accepted one relationship. A person sharing a tool without a service commitment has accepted another. The manufacturer cannot use a volunteer dependency to make its own promises disappear. Nor should regulation turn that volunteer into the unpaid guarantor of an industry. A company that depends on someone’s work can hire them, fund the project, purchase support, maintain its own version or reduce the dependence. Calling the relationship a community does not pay for any of those choices.

Payment can support a commons. Employment can give somebody time to maintain work they value. A commercial service can help preserve useful public infrastructure. The moral question is what was represented, what participants agreed to and which powers accompany the resources. A company should not use ownership language when asserting control and community language when another duty arrives. Contributors deserve to know whether they are building a shared institution, improving a company’s asset or joining a deliberate mixture of both. Clear terms make informed participation possible; their fairness still needs examination.

The economics of incoming work matter too. In June 2026, Ladybird announced that it would stop accepting public pull requests and permit only project maintainers to introduce code changes. Its explanation concerned responsibility for a security-sensitive browser and the reduced value of a substantial patch as evidence of a contributor’s effort. It acknowledged the team’s own use of AI and preserved other forms of participation.⁵¹ The project can reasonably protect its review capacity. A public licence does not give a stranger an entitlement to merge a contribution or demand an alternative review queue. Maintainers are accountable for what they accept and they have limited time.

The restriction also has a wider cost. An unknown contributor may previously have become trusted through a small useful patch, followed by another. Restricting that route can make it harder to enter. The local decision may be justified while the ecosystem loses an opportunity for learning and belonging. That tension should lead us towards resources and alternative pathways, rather than demanding that the project sacrifice itself. Employers and educational institutions that benefit from experienced contributors can fund supervised work and review. Platforms can make requirements clearer and abuse harder. Newcomer opportunities can be limited to what a project can genuinely sustain.

curl’s 2026 reporting history adds an important complication. In January, Daniel Stenberg announced the closure of its bug bounty, describing poor-quality and generated reports as a severe burden. The bounty had also funded genuine discoveries; his account did not deny that earlier value. By April, he described a different problem. Report quality had improved and the immediate slop problem had receded while the volume of valid or otherwise useful findings had become difficult to manage. He inferred widespread AI assistance but reporters generally did not identify the tools they used.⁵² That change matters. Discovering more real defects is useful. It can also generate more work than the existing team can perform. The problem is no longer merely filtering rubbish. It is providing the people, tests, judgement and release capacity needed to turn good information into a safer product.

In June, Stenberg announced a July pause in vulnerability-report intake and handling. Ordinary issues and pull requests remained open and paid-support commitments continued. His August retrospective described relief and renewed attention to neglected review and documentation.⁵² The pause limits a service; it does not mean that the project stopped caring about security. A person cannot respond continuously to an expanding queue merely because each request is individually worthwhile. Somebody has to decide which work fits the available capacity and which commitments have actually been accepted.

The hard objection is that attackers do not take a holiday because maintainers need one. Correct. Users relying on continuous support still have a problem to solve. Demanding that one volunteer never rest will not solve it. Commercial users requiring uninterrupted support should arrange it and broader funding should address genuinely shared needs without conscripting an individual’s life. A sustainable disclosure system funds the whole path from discovery to deployment. Funding only discovery can leave an apparently successful programme creating an ever-growing obligation elsewhere. A count of reports is not a count of people protected. This does not excuse poor reports. A serious submission should contain enough detail to reproduce and scope the problem, avoid inflated severity and make the next useful step easier. The submitter remains responsible whether the report was written manually or with assistance.

Documentation and teaching belong in this account. A clear explanation of an old decision can prevent a damaging regression. An accessible test fixture can preserve knowledge after an author leaves. A translation can allow a person to use the system safely. These contributions may produce no dramatic announcement but they change the amount of uncertainty everybody else must absorb. A report can be valuable and still be expensive to receive. Someone must determine whether the behaviour is reproducible, whether it violates a security boundary, which versions are affected and whether the proposed correction creates another problem. Disclosure may require coordination with downstream users. A fix needs tests, review and a release path. Finding the defect begins that work.

An organisation funding discovery should therefore consider the next stage. A research grant, bounty programme or automated scanning effort can generate a queue whose maintenance cost falls on another organisation. That does not make discovery undesirable. It means the funding model should include triage and remediation where these are necessary to realise its claimed benefit. The funding needs safeguards. Paying a project for every vulnerability report could reward poor quality or create pressure to classify ordinary defects as severe. Paying only for spectacular fixes can neglect preventive work. A contract might instead fund a defined maintenance capability, agree the expected work and permit independent review of the results. The exact form should follow the project.

Maintainers should also be able to decline unsuitable funding. Some money comes with reporting burdens, restrictions or a scope that displaces the work the project actually needs. A grant that pays for a new feature while leaving the release process unsupported can make the long-term position worse. Scarcity does not make every sponsor’s offer beneficial. A project needs an honest account of what it can promise. That can include limited response hours, supported versions, a queue policy and a clear statement that a public repository is not a commercial service. Institutions relying on stronger guarantees should arrange them. They should not reinterpret a volunteer’s helpful response as a standing obligation to provide the same service indefinitely. This also affects the meaning of urgency. A commercial user may face a genuine emergency. The emergency does not create more hours in the maintainer’s day or make that user the only party with a serious need. Priorities should reflect harm and agreed commitments. A process rewarding the loudest request can divert scarce capacity from less visible but more important work.

The maintenance relationship should preserve information needed for such decisions. A report should explain the affected environment and observed behaviour without inflating the claim. A request for a feature should identify the problem it solves. A proposed patch should state what was tested and what remains uncertain. These are ordinary ways of respecting the recipient’s time. Automation can help perform some of that work. It can also make it cheap to create the appearance of a complete submission. The standard should concern the evidence and the responsibility retained by the submitter. A human-written report containing no reproduction is not inherently more useful than a well-checked assisted report. An assisted report that invents a reproduction is unacceptable however plausible its language.

A community should not have to choose between accepting everything and closing every route for a newcomer. Limited tasks, clear review requirements and queues matched to available capacity can provide a middle path. The maintainer is entitled to set the project’s scope and contributors are entitled to an honest explanation of what participation is available. The contribution pathway is part of sustaining expertise. Someone learns why a proposed change was rejected, how a compatibility requirement arose and what evidence would justify a different result. That knowledge is difficult to preserve when all review becomes a private exchange among an unchanged group. Yet preserving the pathway requires resources. The organisation benefiting from future contributors should consider that cost before treating a public issue tracker as an unlimited training service.

Praising an indispensable maintainer is easy. Reducing their involuntary indispensability takes work. It means another person can understand the release. Someone can cover an absence and important decisions do not exist only in one exhausted person’s memory. I want the people doing this work to have lives. That is not a sentimental addition to resilience. It is part of a realistic account of the humans on whom the infrastructure depends.

14. Who can afford to say no

Responsibility sounds admirable until it is assigned to somebody who cannot control the conditions required to fulfil it.

A developer is accountable for quality but cannot change the deadline. An operations team is accountable for availability but cannot fund replacement capacity. A tutor is accountable for learning but has more students than can receive meaningful feedback. A support worker is accountable for resolving complaints but cannot alter the rule that caused them. These examples expose a question that the language of personal professionalism can conceal: what power accompanies the obligation? A person should exercise judgement within their role. They should also be able to identify when the role is being asked to promise something the organisation has not made feasible. Otherwise “take ownership” can become a request to absorb the contradiction privately and keep working until it is no longer visible to management.

The burden is especially difficult when refusal carries serious risk. A person may need the income, a reference, continued access to a profession or the cooperation of the institution assessing them. The formal ability to resign does not tell us how freely they can challenge the disputed decision. That does not make management authority illegitimate. Work requires coordination. An employer can set priorities, protect confidential information and expect agreed duties to be performed. A client can reject work that does not meet a clear specification. A project lead cannot put every ordinary choice to an indefinite vote.

Authority needs to remain connected to a defensible purpose and a workable division of responsibility. A worker asked to endorse a safety claim needs access to the evidence. A reviewer accountable for a change needs time to review it. A person whose output will be judged against a criterion should be able to understand it before the work is rejected. Monitoring provides a concrete setting. The UK’s ICO guidance recognises the power imbalance in employment and explains why consent is often an unsuitable basis for worker monitoring. It asks employers to establish purpose, necessity and proportionality. Those are requirements within that legal context, not a statement of Australian law.⁵³

Ask what a measurement represents. A record of keyboard activity can show activity. It cannot, without further justification, establish useful work, understanding, care or the quality of a difficult decision. A person thinking through a failure may generate less visible activity than someone producing unnecessary changes. The temptation to measure what is easy is understandable. Managers need to assess performance, identify problems and distribute work. Pure intuition can conceal favouritism. A system with no records can leave workers unable to prove what they contributed. The objection should target the conclusions drawn, who can see the records and what happens next, not measurement itself.

Can a worker inspect the information used about them? Can they correct an obvious error? Does the process account for work that does not leave the preferred trace? Are sensitive details collected because they are necessary or because the tool makes collection easy? Who can use the records for a different purpose later? The same questions apply to contracting. A high advertised rate does not settle the value of the work. Paid and unpaid time, task availability, acceptance criteria, correction requests, payment disputes and ownership all matter. A flexible project can be genuinely valuable. A contractor should be able to judge it through its actual terms rather than its prestige or headline rate. Independent contracting is not inherently precarious exploitation. Some people value autonomy, variable commitments and the ability to work across projects. That preference does not justify placing every risk on someone who cannot inspect or prevent it. Clear information and enforceable terms improve choice. Pretending all participants have equal leverage does not.

The International Labour Organization’s 2021 report on digital labour platforms examined web-based and location-based work through surveys and interviews with workers and businesses.⁵⁴ Those forms of work differ and not every technical contractor faces the same conditions. A further boundary concerns the person’s intellectual life. Employment should protect the work commissioned, legitimate confidential information and genuine conflicts. It should not casually absorb every idea, experiment or creative activity merely because the person has relevant skills. The fair boundary depends on actual duties, resources and agreements, which need to be explicit enough that both sides can rely on them. The general question is what an institution is entitled to purchase when it purchases labour. A person’s expertise develops through a life larger than a particular role. The institution can protect its investment without claiming to be the source of every capability the person will ever exercise.

Rest belongs in the same discussion. Emergency response sometimes requires exceptional effort. A system that depends on exception after exception has a capacity problem. Praising commitment does not create a second shift of rested people and telling someone to manage their wellbeing does little when the work remains assigned without relief. A serious continuity plan should identify coverage, escalation, recovery time and the point at which scope must be reduced. Otherwise the institution is borrowing against a person’s future health and attention without properly recording the debt.

Workers should be able to raise a concern without becoming heroic. Institutions should have ordinary channels through which a person can say that a requirement is unclear, a schedule is unsafe or a proposed claim is unsupported. The channel needs someone able to act and a record of the response. It should not rely on the worker’s willingness to incur unlimited professional risk. That right has boundaries. Disagreement alone is not misconduct. Confidential information and bystanders need protection. Public accusation can cause harm when evidence is incomplete. A good process makes internal challenge effective enough that the person is not immediately forced to choose between silence and a damaging public confrontation. A person can understand a risk and lack permission to change the system producing it. Another can hold the authority to approve the change without possessing the technical knowledge needed to evaluate it alone. A workable organisation connects those roles. It does not pretend that either role eliminates the need for the other.

Individual courage is not the only available counterweight. Workers can share information and negotiate through trade unions, works councils, professional associations or another representative body suited to the workplace. The ILO treats freedom of association and effective recognition of collective bargaining as fundamental rights at work.⁵⁵ Collective representation can make a shared problem visible before each person has to risk a private confrontation. It can address monitoring, staffing, on-call work, training and safety as working conditions rather than personal inconveniences. Representation is not automatically fair. A body can become remote, reproduce existing exclusions or favour a majority whose circumstances differ from others. Collective processes need accountable representatives and individual routes for matters they do not resolve. The mistake is to discuss unequal bargaining power as though one worker negotiating alone were the only possible arrangement.

When an incident is explained as an engineer’s failure to act, ask what authority the engineer actually held. What access did they have? Could they stop the release? Had they been instructed to preserve a service whose shutdown would cause another harm? Which decision was reserved for management? A review that ignores these questions can assign blame to the person nearest the software while leaving the governing decision untouched. It matters in the other direction too. Limited authority does not exempt a practitioner from reporting a serious concern or staying within the permissions actually granted. Someone who cannot safely complete an assignment should identify the obstacle. The organisation then needs a route for that information to reach someone who can change the conditions, accept a defined risk or stop the work.

A risk register should support that route. Merely attaching a person’s name to a risk does not give them the authority to fund a remedy. A recorded acceptance should identify who accepted what, on which evidence and for how long. Where the decision relies on an interim control somebody should check that the control exists and continues to operate. Time spent reviewing, teaching and responding to interruptions can disappear from a performance measure focused on completed tickets. The organisation may then reward the person whose work looks fastest while relying on someone else to maintain the conditions that made it possible. This monitoring practice deserves examination in each workplace without assuming every manager misuses metrics. Recording every minute of a person’s life would not solve it. The organisation needs to understand the work required and allow for it before judging output. A mentor’s responsibilities should reduce the work expected elsewhere. An on-call duty should affect staffing and recovery plans. A release reviewer should have enough time for genuine review.

An emergency can require unusual effort. If unusual effort is required repeatedly, the operating model needs examination. The organisation might have insufficient staffing, an overly broad service promise or a process generating avoidable interruptions. Praising the people who compensate does not resolve the underlying mismatch. A person should also be able to develop competence without turning every spare hour into work. Independent study can be valuable and enjoyable. It should not become an unspoken substitute for the training needed to perform assigned duties. An employer asking for a new capability needs to consider the time, support and supervised practice required to acquire it.

Employment does not consume a person’s entire intellectual life. At the same time, a person cannot treat an outside activity as independent while using confidential information, employer resources or authority entrusted for another purpose. Both boundaries matter. A reasonable contract should identify the work actually commissioned, relevant conflicts and the treatment of work created independently. It should distinguish general knowledge from confidential information and an industry overlap from actual competition or misuse of a relationship. This is an ethical negotiating principle, not legal advice about a particular contract.

People who write, research or contribute to software outside employment need an explicit boundary. A broad statement of ownership can create uncertainty long before a dispute reaches a court. The boundary lets both parties understand what is protected and what remains the person’s own work. It should not require the person to assume that every future idea belongs to an institution because its subject happens to be technical.

Conflicts should be assessed with enough information to make a decision but not used to demand unnecessary disclosure of another party’s confidential material. A narrowly scoped approval, a restricted engagement or an agreed separation of resources may resolve the concern. Where it cannot, the person should receive a clear decision rather than an indefinite warning that any activity might someday be considered problematic. The broader expectation is that professional responsibility and personal autonomy can coexist. A person should perform their duties, protect entrusted information and honour legitimate commitments. The organisation should state those commitments explicitly and avoid treating uncertainty itself as a source of control.

The stronger party’s obligations should reflect what it can organise. It can staff the service, define acceptance, fund review, separate duties and change incentives. The individual can perform their role carefully, raise relevant concerns and avoid making promises they know cannot be kept. Neither responsibility should be used to erase the other. I want professionalism to include the ability to say, with evidence, “We cannot responsibly promise this under the conditions provided.” An organisation that cannot hear that sentence has made responsible work harder than it needs to be.

15. The business that can sustain the thing

Criticising extraction is easy if the alternative never has to pay salaries. Products need people and continuing resources when their assumptions change. Public services do too. A commons is not relieved of that need by being shared. Funding is part of the human argument, not an embarrassing distraction from it. I want more useful software whose success does not depend on perpetual expansion. A modest tool can solve a stable problem and improve in quality without accumulating features forever. That ambition requires funding suited to the work.

A one-off sale can be reasonable where continuing obligations are limited and understood. It can become unsustainable if users expect indefinite compatibility and security work without another source of support. A subscription can fund continuing service. It can also turn a previously durable capability into something that disappears when payments stop. The model’s name does not justify it. The relationship should be explicit. What continuing work is being funded? Which rights survive cancellation? Does the product require a remote service for a real functional reason? What happens when the number of customers falls? Which promises have been funded and which are being left for a future maintainer to absorb?

Selling expertise around public software can be entirely legitimate. Some users want to operate it independently; others want a reliable supplier to take responsibility. Paid support can make that choice more meaningful. The vendor earns income by performing work the customer does not want to perform while the customer keeps a workable alternative if the relationship becomes unacceptable. Supplier incentives create a tension. A company can make money from complexity that an improved design would remove. It can benefit from dependencies that make exit difficult. Those incentives should be tested against its actual products and terms instead of assumed away. The same scrutiny should apply to public and charitable funding. A grant can support work markets neglect. It can also require the maintainer to spend substantial time repeatedly explaining a project to people who do not understand its continuity needs. A short funding cycle can favour a new feature over unglamorous recurring work. A foundation can become skilled at sustaining itself while weak at demonstrating benefits for the people it invokes.

Calling the activity public-interest work should begin the evaluation, not end it. What capability is being maintained? Who uses it? What would fail without it? Does the funding reduce dependence on a single person? Are its administrative demands reasonable for the amount and purpose of the support? The answer will not always be a new organisation. Sometimes a direct support contract, shared engineering time or an existing programme can do the job. Institution-building has costs of its own: governance, reporting, money management, disputes and the possibility that the new institution becomes another gatekeeper.

Commercial funding can sustain valuable work and distort it. Ask what power accompanies the money. A donor who funds maintenance without dictating direction is different from a sponsor holding authority over the project’s identity, release process or priorities. Mozilla’s 2025 report describes about US$1.4 billion in reserves, US$658.5 million in Firefox-related income for 2024 and about US$650 million in anticipated portfolio expenditure during 2026. It allocates approximately 80% of that expenditure to core products and 20% to expanding trustworthy open-source AI.⁵⁶ Publishing that allocation makes a consequential priority inspectable. It does not establish that the priority is correct. Mozilla’s users, donors and staff can judge the decision against the mission used to justify it.

The mission question is unavoidable. How are prospective sources of income tested against the purpose? Which activities would the organisation refuse even if profitable? Who can challenge the judgement? What evidence would demonstrate that a commercial strategy served users as well as the institution’s continued existence? Financial survival matters. An organisation that rejects every workable source of income may disappear and leave people with worse options. But survival cannot justify any activity indefinitely. If every deviation is necessary to fund the mission, the mission becomes difficult to distinguish from continued existence. That is why I prefer commitments that constrain decisions rather than language attached afterwards. A privacy commitment should exclude some forms of collection. An openness commitment should preserve permissions that would be commercially convenient to withdraw. A public-service commitment should require an acceptable service even for people who are unprofitable to serve.

The exact constraints can be contested. They need to be stated. Otherwise an attractive mission functions as an asset from which the institution can extract trust without accepting a related limit on its behaviour. Shared benefits create the question of who pays. A critical library may create value for many organisations, each with an incentive to leave funding to the others. Individual generosity can help but it is an unstable answer to a recurring collective need. Shared support, procurement contributions, public provision or direct employment can make the relationship more deliberate. Those methods need safeguards of their own. A compulsory fund could distribute money badly or reward politically connected projects. A large corporate contribution could distort priorities. Public support could make a maintainer dependent on changing government preferences. Several workable funding sources, clear governance and the ability to leave may be safer than one supposedly benevolent patron.

The goal is not to abolish economic constraints. It is to stop treating the least visible person’s unpaid adjustment as the default way to satisfy them. A project may need to reduce scope. A supplier may need to charge more. A service may need to retire. Those can be honest decisions. They become harder to defend when the institution has encouraged greater dependence, concealed the continuing cost or prevented other people from taking over. I am willing to defend useful work that is commercially viable. I am also willing to defend public spending where the benefits and responsibilities justify it. Willingness to pay does not capture all value and public money does not guarantee value.

Different funding models pay for different things. A grant may fund an initial development. A subscription can fund continuing access. A support contract pays for defined assistance. A consultancy can earn money adapting a common tool to particular needs. A public institution can employ people to maintain infrastructure whose benefits are widely shared. None automatically covers every part of the lifecycle. That mismatch should be examined before choosing a model. A one-off grant can produce a useful release without financing the work needed to keep it usable. A subscription can create recurring revenue while encouraging the supplier to retain dependencies that make cancellation costly. A support business can sustain expertise but prioritise the customers who pay for access. Public funding can serve neglected needs while creating dependence on changing administrative priorities.

The choice is more specific than commercial or non-commercial. What work needs continuing support? Which users can pay? Which benefits fall on people outside the transaction? What control does the funder gain? How can the funding end without destroying the capability it was meant to support? A product serving a stable need can be successful without continually expanding its scope. The engineering may become quieter as the system matures. Fewer releases can reflect stability or neglect; the difference depends on whether necessary maintenance, support and compatibility work continues. A funding model that recognises only new features may struggle to distinguish them.

The price of a copy differs from the price of a commitment. A digital file can be cheap to reproduce. Providing a reliable service, reviewing defects and remaining available to answer important questions require continuing resources. A licence permitting copies does not determine which party should pay for those commitments. A company can charge for convenience and assurance while leaving users able to operate an alternative. The details still matter: what happens to user data, how does migration work and which capabilities remain exclusive? Revenue does not make the model wrong and published code does not make it right.

Public or philanthropic support should identify the capability it intends to preserve. Funding a named organisation is not the same as sustaining the underlying work. The organisation may be an effective vehicle but its continued existence should not become the only measure of success. A serious proposal would identify the people doing the work, who benefits, which tasks would otherwise be neglected and how the funding is expected to help. It also needs an exit or transfer plan. If one organisation can no longer provide the work, can another take over without losing the necessary knowledge and rights?

Evaluation should match the funding and risk. Requiring a small maintainer to produce extensive reports can consume the capacity the grant was meant to increase. Accepting every claim without inspection can fund ineffective or misleading work. Evidence may include a release record, maintained compatibility tests, documented response capacity or an independent assessment of a defined improvement. It need not become theatre through endless activity counts.

Some benefits are hard to attribute. A maintained dependency can prevent disruptions that never become visible. A clear specification can save many implementers time without producing a direct invoice. The benefit is still real. Evaluation should combine the best available measurements with an honest account of what remains uncertain. Almost every project can tell a convincing story about its importance. Scarce resources require choices. A funder should compare alternatives, ask whether the work already has enough support and consider what would happen without the award. Audience size can matter. It should not decide every funding choice.

A shared resource needs decisions about access, contribution, maintenance and conflict. Calling it a commons does not remove those decisions. The governance should fit the resource and the people whose work sustains it. A freely downloadable program and an irrigation system do not have the same scarcity. Copying the program does not deprive another person of a copy. Reviewing changes, operating infrastructure and answering questions still consume finite time. A useful governance account should identify which resource is actually scarce rather than import an analogy wholesale.

Broad permission to use code can coexist with limited access to a maintainer’s attention. A public archive can permit reading while limiting write access. A project can welcome ideas without undertaking to implement them. The commitments should be stated explicitly so that freedom over an artefact does not become an involuntary service obligation for a person. Judge the business sustaining the work by what it enables and constrains. Does it fund competent maintenance? Does it retain useful exit rights? Can a legitimate concern change a decision? Does it survive ordinary changes in personnel? The answers are more informative than a claim that one financing model is inherently virtuous.

The business has to sustain the thing people were promised. When it cannot, the transition belongs in the business’s account of responsibility. A funding problem does not disappear when it reaches the customer, the volunteer or the next generation of staff. That is the economic question behind the promise: who will keep doing the necessary work, under what terms and what happens when they reasonably decide to stop?

IV. Who gets to become capable

16. The opportunity that exists on paper

An opportunity is often described from the institution’s side. A course is available. Financial assistance exists. An application process is published. A position is advertised. The institution has opened a door and can point to the people who walked through it. That description leaves out the approach to the door. A person has to know that the opportunity exists, understand what is being offered, decide whether the conditions apply to them and establish whether they can survive the transition. They may need an answer before leaving a job, arranging accommodation or committing to care responsibilities. An eventual entitlement can be difficult to use when nobody can confirm it at the moment the decision has to be made.

Motivation and ability are not the problem here. An institution can select for the capacity to navigate its uncertainty while believing it has selected for the capacity to learn. The HAIL scholarship experiment at the University of Michigan gives this distinction substance. High-achieving students from low-income families received an early guarantee of tuition support without an increase in the grant aid they would otherwise have expected after admission. The original study reported application rates of 68% among those offered the intervention against 26% in the comparison group and enrolment rates of 27% against 12%.⁵⁷ The lesson is narrower than “free university solves educational inequality”. This was a particular intervention involving a particular population and institution. It changed the timing and certainty of an offer as well as its presentation. It also shows that an apparently similar financial opportunity can produce different participation when people receive a commitment early enough to act on it.

The follow-up is equally important. A July 2026 working paper reports that the programme largely shifted students between colleges. The authors found an improvement in four-year completion but no detected improvement in six-year degree attainment.⁵⁸ Those findings should not be hidden because they complicate a good story. They tell us what changed and what did not. Applications, where students enrolled, timely completion, learning and eventual income are different outcomes. A policy can improve one without improving them all. I draw one practical conclusion: usable certainty matters. When an institution controls information that a person needs before committing, the timing and clarity of that information are part of the service. Generous support revealed too late can be less useful than modest support someone can actually rely on. Educational access should be examined from that position. What must the applicant know? Which answer remains conditional? What expense must they incur before finding out? Who will help if the ordinary route does not fit? What does a person without family experience of the institution need explained? I am not asking institutions to abolish every form or admit everyone who applies. They have to assess eligibility and allocate scarce places. Some uncertainty is unavoidable because decisions depend on information that arrives at different times. The obligation is to avoid creating unnecessary uncertainty, explain the uncertainty that remains and recognise the costs of asking another person to wait.

Time creates a similar barrier. An apparently affordable course may require attendance that cannot be combined with the work paying for the student’s housing. An online course may assume a reliable computer, private space and hours free from interruption. A scholarship may pay tuition while leaving the person unable to afford participation. Calling these matters personal circumstances does not make them external to access. They determine whether the offered education can be used. I believe worthwhile public education should be free at the point of access. That commitment extends to vocational learning and opportunities to return later in life. People should be able to study more than the subjects for which they can make an immediate earnings case. History, mathematics, literature, science, politics and philosophy help people understand a world in which they are expected to make important decisions.

Australia already subsidises Commonwealth supported places and offers eligible students income-contingent HECS-HELP loans for their student contribution. Fee-Free TAFE provides funded places subject to programme and eligibility conditions. Those forms of support matter. They are not a universal tuition-free public pathway. Nor does every student pay an unsubsidised price upfront.⁵⁹⁶⁰ My preference does not answer every funding question. Under a limited budget, removing a fee from someone who can already participate may achieve less than providing living support, transport or accessible teaching to someone who cannot. A policy that mainly benefits people already well placed to enter university can leave other forms of learning neglected. That is a reason to design the public commitment broadly. It should include vocational and adult education, practical participation support and funding that reflects capacity to contribute. It should also be judged against what the same resources could achieve elsewhere. The fact that education is valuable does not make every educational expenditure the best use of public money.

There will still be limits. Some programmes need expensive equipment or supervised placements. Teaching capacity cannot appear merely because a government announces more places. Fair admission and enough teaching support remain necessary. A free place in an overcrowded course with little feedback is not the outcome I am defending. Nor do I expect teachers to make the aspiration affordable through unpaid labour. Public access requires public provision: educators, support staff, facilities, equipment and time. Shifting the bill from the student to an exhausted lecturer would repeat the same mistake in another account.

The moral position is that personal wealth should not decide whether someone can obtain worthwhile public education. The proposal must explain what is funded, who benefits, which limits remain and how results will be evaluated. This essay defends that principle without pretending to contain a completed national budget. Free at the point of access still costs money. The difference is where the price appears and which decisions occur before someone can participate. A serious proposal must identify who pays, which activities receive support and how places and resources are distributed.

There are at least three separable aims. One is to prevent an immediate fee from excluding a person who could benefit. Another is to distribute the cost fairly across a lifetime and across society. A third is to ensure that the education provided is worth the resources committed. A policy can improve one aim while performing poorly against another. Income-contingent lending addresses a different part of this problem from an upfront fee. It can reduce the cash required to begin. It still leaves questions about debt, uncertainty, participation expenses and whether people understand the loan well enough to rely on it. Criticism should address how the loan works rather than describe it as ordinary commercial debt.

Universal tuition funding raises another question about who benefits. People who already have the preparation and support to enter higher education may receive a large share. That should shape investment in school preparation, vocational routes, accessible teaching and living support. Tuition is only one possible way to distribute the cost. Targeting assistance can direct more resources towards need but requires eligibility rules. Those rules can exclude people near a threshold, create uncertainty or demand repeated evidence. Universal provision avoids some of that administration while supporting people who could afford to contribute. The comparison needs both the distribution of money and the cost of determining eligibility.

My preference for a broad public pathway rests on the value of education beyond private earnings and on the importance of access that people can understand. It does not settle every funding instrument. Progressive taxation, targeted participation support and capacity planning need separate justification. A political commitment should be clear about which parts remain proposals rather than presented as a completed economic result. A place is usable only if the institution can provide the required teaching, facilities and assessment. Expanding admissions faster than those resources can be supplied can create access in the enrolment statistics while reducing the education available to each student.

Expansion has to mean actual provision. A laboratory needs equipment, maintenance and supervision. An online course needs accessible materials, support and a way to assess understanding. A placement requires people with time and authority to supervise. A funded seat without these conditions is a partial promise. Rationing remains necessary where capacity is limited. The criteria should relate to the programme’s purpose and the support available. Prior achievement can provide useful evidence but it also reflects opportunities previously supplied. A selection process should consider whether another route, foundation programme or supported entry can distinguish an unmet prerequisite from a person who never had the opportunity to demonstrate it. The same question arises later in life. Someone returning to study may possess relevant knowledge but lack recent formal records. A person with caring responsibilities may need a different schedule. Recognising those circumstances does not require reducing the performance standard. It requires distinguishing the intended learning outcome from the institution’s most convenient route to it.

Earnings after graduation should not be the sole measure of public education. Employment matters, particularly to people making substantial sacrifices to study. So do the ability to examine evidence, participate in public decisions and pursue work whose value is not captured by a wage. Institutions should debate the resource conflicts between those purposes openly. Measuring only the outcome most easily connected to a tax receipt erases the others.

Honest provision requires a fair account of access. A student should know what the course offers, what support is available, which outcomes are assessed and what costs remain. The institution should be able to explain who cannot participate and what would change that result. The more immediate expectation is easier to state. An institution should be able to explain the path it offers well enough that a person can decide whether to take it. It should not reward only those able to tolerate ambiguity, chase missing information and absorb delays without consequence.

A system that congratulates itself on available opportunity should examine who could not use it including people whose absence never appeared as a complaint.

17. Being enrolled and being taught

My experience of trying to turn Technical and Further Education (TAFE) enrolment and recognition of prior learning into a workable assessment path is one reason this subject matters to me. I spent too much effort trying to make the process function. Eventually I stopped. Whatever value the qualification still held was no longer worth the time, uncertainty and stress required to keep the process moving. That was one course and one process, not a verdict on every teacher, course or campus. It is why I reject successful enrolment as proof that education was properly provided. I wanted to learn what I did not know and demonstrate what I already understood. Those are reasonable purposes for an educational process. Administrative work should help make them possible. When the administration becomes the main task, the institution should ask what it is actually providing.

Staff shortages can explain a delay. They do not explain why the student should continually discover the delay by chasing an answer. If a deadline is no longer achievable somebody needs to communicate the change, identify the next step and consider whether the student is being disadvantaged. A recurring shortage is a fact to govern, not an excuse to repeat indefinitely. A student also has responsibilities. Evidence for prior learning must demonstrate the relevant competence. A public portfolio does not exempt its owner from assessment. An institution can reasonably require supervised work, ask further questions or conclude that an important gap remains. Its obligation is to make the requirement understandable and the judgement defensible.

Entitlement to a functioning process differs from entitlement to the desired result. I want the first. A fair process must remain able to say no. But the educational question goes beyond administration. What does it mean to be taught well? Information being available is insufficient. A person may need an explanation that connects a new concept to what they already understand, a task that exposes a misconception, a chance to practise and feedback that arrives while it can still change their work. Those are forms of skilled labour. They are part of why a course can be valuable even when its reading material is available elsewhere.

Instructional design matters. Freeman and colleagues’ 2014 meta-analysis of 225 undergraduate STEM studies found higher average assessment performance and lower failure rates under active-learning approaches than under conventional lecturing. The interventions varied and the authors questioned how readily the results would transfer to universal implementation.⁶¹ This does not supply a script for every subject. It does establish that “we delivered the content” is a weak stopping point for evaluating teaching. A provider should ask what students can understand and do after the teaching, which methods help and which assumptions about learning have become habit rather than evidence.

The term active learning can itself become misleading. Giving students an unexplained task and leaving them to struggle is not vindicated by research into deliberately structured participation. A teacher still needs to know what the exercise is meant to reveal, which support it requires and how the result will inform further instruction. An exercise can also be engaging without producing the intended understanding. Students may enjoy collaboration while retaining the same misconception. They may complete a sequence by copying a procedure without recognising when it applies. Attendance, activity and satisfaction are useful observations but none is identical to learning.

The 2025 Student Experience Survey from Quality Indicators for Learning and Teaching (QILT) found that 76.5% of undergraduate respondents rated their overall educational experience positively. That is meaningful evidence about reported experience and a reason to reject a blanket claim that almost nobody benefits from university. It is not an independent measure of mastery, the value of a particular course or the experience of every student.⁶² A serious assessment should be connected to the capability the course claims to develop. If students are meant to reason about a system, they should encounter a problem in which memorising its preferred description is insufficient. If they are meant to operate equipment safely, the assessment needs evidence of that practice. If they are studying history, the quality of their interpretation and handling of sources matters more than imitation of a template.

Good assessment costs money. Open-ended work can be expensive to mark consistently. Practical work requires supervision and equipment. A larger class can make individual feedback difficult. Those limits should affect course size, staffing, design and the promises made to students. They do not make an easy proxy good enough. Consistency matters too. An assessor’s intuition can be biased or opaque. Rubrics and standardised tasks can protect students against arbitrary judgement. The question is whether they describe the competence or merely the preferred way of displaying it. A process that is highly consistent at rewarding superficial compliance has not solved the educational problem.

There should also be room for failure that teaches. A student needs opportunities to discover a mistaken assumption before the final assessment makes it costly. Feedback that says only “incorrect” may record the outcome without helping the person understand the error. Feedback that supplies the entire answer without explanation can conceal the same gap. Good teaching asks what the learner is thinking, not merely which answer appeared. It gives enough support to permit progress while preserving the work through which understanding develops. That balance will differ between beginners and experienced learners. One slogan about independence cannot settle it. I value independent learning. I do not accept it as an all-purpose defence of absent teaching. Someone enrolled for structured instruction should not be told, whenever the structure fails, that successful people teach themselves. That rewards people who could already compensate for the missing provision and leaves the institution free to claim their success as its own.

At the same time, a course should not promise to remove all difficulty. Some ideas are hard. Some practice is repetitive. Some understanding arrives only after sustained effort. A student dissatisfied because learning takes work is presenting a different complaint from a student unable to obtain a clear requirement or useful feedback. Examine the course, the work and the support provided. The institution’s authority does not guarantee sound teaching and frustration alone does not show that teaching was poor.

Education has a larger purpose. It should help people become capable of questioning an authority including the authority teaching them. A learner who can repeat a standard but cannot examine its scope has acquired a fragile kind of competence. A learner who can reject every standard but cannot explain an alternative has a different problem. A student can experience fluent instruction as clear and still retain little ability to use it. Conversely, effortful practice can feel less successful while producing better performance on a later task. These possibilities make satisfaction an incomplete measure of teaching without making the student’s experience irrelevant.

In a 2019 study of large introductory college physics classes, Deslauriers and colleagues compared active and passive instruction using the same materials. Students in the active condition learned more on the study’s measures while reporting less feeling of learning. The authors examined the role of cognitive effort in that difference.⁶³ This is evidence from a particular instructional comparison, not permission to disregard students whenever they find a course confusing.

Measure the intended learning and investigate the experience. A difficult exercise might expose a productive gap in understanding. It might also be badly explained, inaccessible or unrelated to the assessment. The teacher needs evidence that discriminates between those possibilities. Calling every frustration desirable difficulty is as weak as treating every comfortable lesson as effective teaching. Feedback should identify the decision that needs to change. A score can tell someone that their result was inadequate. It might not explain why. An annotated example, a discussion of alternatives or a changed scenario can show which assumption failed. The learner should then have an opportunity to apply the explanation, rather than receive it only after the final grade makes further practice irrelevant to the course.

Individual attention has practical limits. The response can include well-designed peer review, reusable examples and formative tasks that expose common errors. Those methods still need supervision and evaluation. Asking students to grade one another without criteria does not guarantee accurate feedback or reduce the teacher’s responsibility for the assessment. A capability judgement should identify what the person did and under which conditions. Was reference material available? Was the task completed alone or with review? Which parts were the person’s contribution? What happened when the information changed? These details can matter more than whether the evidence came from a classroom or a workplace.

In my CyberPath submission, I argued against treating simulation, workplace performance, repetition and validation as positions on one evidentiary ladder. They describe different properties. A simulation can be repeated and independently observed. A workplace document can be authentic while saying little about the applicant’s contribution. The evidence should be assessed against the claim it actually supports.⁶⁴ Keeping those properties separate avoids two unfair outcomes. It prevents an institution dismissing relevant capability merely because it developed outside the preferred route. It also prevents an applicant claiming broad competence from a narrow achievement. A public contribution, a medal, a qualification or a job title can supply evidence without establishing readiness for every duty in a role.

A confidential-evidence route is necessary for the same reason. Someone whose work cannot be published should not have to choose between breaching confidence and appearing to have done nothing. Authorised attestations, controlled review or alternative demonstrations may establish the required result. The verifier should state what they actually observed rather than rely on seniority as a substitute for evidence. The assessment should also distinguish a demonstrated failure from a requirement that could not be assessed. If an essential data source was deliberately unavailable, recognising the limitation and declining an unsupported conclusion may be the competent response. A confident answer obtained by luck should not receive the same recognition as sound reasoning under the information available. This makes the assessment more accurate without lowering its requirements. The practitioner needs to understand the limits, act within authority and communicate what remains unresolved. The organisation remains responsible for the conditions it supplies. Assigning the individual a low score because the institution withheld a necessary resource confuses those responsibilities.

A framework can contain carefully worded levels and still produce inconsistent decisions. Its usefulness needs examination through actual assessment cases. Independent assessors should apply the requirements to comparable evidence, explain disagreements and revise ambiguous descriptors. The process should also record the time and cost required from candidates and assessors. Agreement alone is insufficient. Assessors can agree on an irrelevant proxy. A stronger evaluation asks whether the judgement predicts performance on other relevant tasks, distinguishes genuinely different capability and remains the same when equivalent evidence comes through another learning route.

The limits of such validation should remain visible. A pilot can test particular descriptions and tasks. It cannot by itself show that a framework improves national security or resolves a labour shortage. Those outcomes require other evidence and longer observation. Education and professional recognition should become demanding at this level. Preserve high standards but know what the standard measures. Let assessment recognise supported practice without pretending it is unrestricted independence. Let technical depth be recognised without requiring management authority that the task does not involve. A person should leave the process knowing what has been demonstrated, what remains uncertain and which further work would resolve the gap. A label that cannot explain those things is a poor substitute for an assessment. I want people to leave with knowledge, judgement and a more accurate understanding of what they do not yet know. I also want them to retain curiosity including curiosity that will never become a job requirement. An institution should be able to show how its teaching serves those purposes. The student should not have to be unusually persistent, unusually connected or unusually impressive before that expectation counts.

18. Where experience is supposed to come from

The next contradiction appears when education ends. An applicant is told that knowledge alone is insufficient; they need experience. That is often true. Professional work requires judgement about systems, organisations and consequences that a course cannot fully reproduce. The applicant then discovers that the work through which they might acquire that judgement is reserved for people who already possess it. A particular vacancy may genuinely require an experienced practitioner. A beginner should not receive independent responsibility for a dangerous process merely because the industry needs more entry points. Some teams lack the supervision capacity to hire a junior safely. Pretending otherwise can leave the newcomer unsupported and the existing staff overwhelmed.

The collective question remains: who will provide the experience everyone intends to hire later? Training creates an awkward economic relationship. The current employer pays much of the immediate cost, while a future employer may receive some of the benefit. An organisation can therefore have a reason to wait for somebody else to provide development. If many organisations follow that reasoning, the system can underprovide the competence each depends on. That is an incentive problem, not a finding that every employer is behaving this way. It is also a reason not to mistake a temporary improvement in vacancies for a complete answer. An industry can be hiring and still provide poor routes into responsibility for people outside its preferred backgrounds.

Indeed’s Australian analysis of April 2026 reported that graduate job advertisements fell 14.7% in 2025, remained above 2019 levels and rose year-on-year in the March quarter of 2026. Its methodology identifies advertisements containing the word ‘graduate’. That is a specific series, not a census of every junior opportunity.⁶⁵ Contemporary evidence needs careful denominators. Australian graduate job advertisements are not the same thing as completed junior hires. Young workers are not all beginners and a career changer is not represented merely by counting people under twenty-five. US payroll research concerning highly AI-exposed occupations raises a serious concern about younger workers’ employment but it does not measure every cause of hiring change or establish the position of Australian entry-level engineers.⁶⁶

The argument does not need a declaration that junior work has vanished. It needs a defensible expectation that employers, educators and public institutions take the development of competence seriously enough to provide workable routes. A genuine route has stages. Someone begins with work whose consequences are limited. They learn to inspect the relevant context, propose a change, explain their reasoning and respond to review. They see what happens after deployment. They learn how to recognise an incident and when to ask for help. Over time, the range of decisions they can make independently grows. That progression requires supervision. It also requires the supervisor to have time. Adding a junior to a team while measuring the mentor as though their only responsibility were personal output is a way of making training compete invisibly with the work through which performance is judged. The organisation may then conclude that juniors are unproductive. In reality, it has attempted to obtain both a fully productive senior and a trained newcomer without paying for the relationship between them.

Mentoring requires more than occasional availability. A beginner often does not yet know which question matters. Someone needs to choose appropriate work, review the evidence, explain the consequences and distinguish a useful struggle from an avoidable obstacle. That is professional work and should be recognised as such. The opposite direction carries its own risk. A programme can keep people in nominal training while relying on them as permanently cheap labour. Workshops and online modules can create an appearance of development without increasing responsibility or opportunity. A serious programme needs a path the participant can understand and evidence that progress is occurring.

Automation makes this more urgent without supplying the answer. If a tool removes a routine task that previously gave beginners useful practice, preserving the task solely for tradition may be wasteful. But the organisation still needs to decide how the underlying judgement will develop. A generated explanation can help someone learn. It cannot show that the person will recognise when the explanation is wrong. That ability requires enough knowledge and experience to examine the work. An employer cannot outsource all beginner practice to a tool and assume that future practitioners will somehow acquire independent judgement elsewhere.

There are possible alternatives: supervised simulations, limited production assignments, paid placements, structured review and deliberate rotations through different responsibilities. Each needs evaluation. A simulation that rewards the intended answer without exposing realistic ambiguity may produce confident but brittle performance. The goal is to increase competence while protecting the learner and the people affected by the work. The choice is not between unsupervised autonomy and indefinite exclusion.

Independent projects and public contributions can provide valuable evidence. I value them. But a portfolio cannot become the universal answer to every entry barrier. A person with caring responsibilities, an illness, insecure housing or several paid jobs may have little time for an elaborate public record. Another may have done substantial work under confidentiality obligations. Treating visible unpaid output as the natural measure of dedication rewards circumstances as well as ability.

Informal selection can also favour existing networks. Removing a qualification requirement does not create a fairer process when a manager replaces it by choosing people who resemble colleagues they already trust. Standardised credentials sometimes protect applicants against exactly that discretion. The sensible question is which evidence is relevant to the work and how people with different circumstances can provide it. A practical assessment can help if it is limited, accessible and genuinely evaluates the required capability. A lengthy unpaid assignment that produces useful commercial work for the employer raises a different concern.

Volunteer communities should not be assigned responsibility for repairing the labour market. An open repository is not a publicly funded training institution. Its maintainers can provide opportunities they have capacity to support. Companies benefiting from those opportunities should consider how to sustain them rather than assume they will remain freely available. Shared provision may help where individual employers cannot carry the whole burden. Industry-funded placements, public support, cooperation with educational institutions and paid mentoring can spread the cost. Those schemes also need safeguards against capture, poor certification and obligations that trap participants in one job.

People should be able to leave an employer without being treated as having stolen the training that made them useful. An organisation can invest in development because doing so sustains a workforce and creates value during employment. The person may later work elsewhere; that does not make the investment a moral waste. No single obligation requires every business to hire a beginner into every vacancy. The industry still has a substantial collective interest in making sure enough beginners can become experienced. An industry that cannot explain how it reproduces competence is depending on an inheritance while treating its renewal as optional.

Designing an entry-level role takes more than lowering the salary on a senior role. The scope should identify what the newcomer can safely do, what must be reviewed and how responsibility will increase. The supervisor needs to know which decisions are delegated and which remain theirs. Consider a limited software change. The newcomer can inspect an issue, reproduce the behaviour and propose a test. Review can examine whether the test distinguishes the defect from the intended result. A later change can be checked against that test and its surrounding requirements. Following the release then exposes real-world concerns absent from a local demonstration. The sequence teaches more than assigning a ticket and waiting for a completed patch. I propose this training pattern without requiring every workplace to use the same exercise. A laboratory, incident-response team and public service have different risks. The person should receive feedback on real decisions while the possible harm remains appropriate to their experience.

The evidence of progress should be specific. Can the person recognise when the task exceeds their authority? Can they identify missing information? Can they explain why a familiar method is unsuitable in a changed case? Can they perform the work consistently without the supervisor silently repairing essential parts? Completion time can matter where the task genuinely requires speed. It should not compensate for a serious failure to protect data, seek approval or report uncertainty. A training programme that rewards fast confident answers regardless of those boundaries teaches precisely the judgement it should later have to correct.

Employers also need practical ways to decide who can enter such a route. A relevant work sample can provide stronger evidence than a generic impression. It can also become an excessive burden or a source of unpaid commercial output. The sample should be limited, explain its purpose and avoid demanding confidential information. The amount of work should match the hiring stage and the decision being made. A candidate should not have to produce a complete product before learning whether the employer can offer a suitable role.

Assessment design needs to account for assistance. An applicant may use documentation or ordinary tools because those would be available in the work. Where unaided performance is essential, state why. Where tool-assisted performance is acceptable, examine the person’s contribution and ability to check the result. Neither a blanket tool ban nor unquestioned acceptance of polished output answers the capability question. A structured assessment can also provide a route for people without conventional credentials. Applicants will not all be equally prepared. The assessment should specify the prerequisite and accept sound evidence instead of using one familiar background as an automatic proxy.

The employer has legitimate constraints. Screening thousands of applicants is costly and a more detailed assessment cannot be offered indiscriminately at the first stage. The process can still test whether its inexpensive filters exclude people whose evidence would satisfy the actual requirement. Sampling rejected applications and reviewing the reasons can reveal problems that a success-only account conceals. Where employers fear losing their training investment, an industry-wide programme may spread costs more sensibly than leaving each organisation to wait. Paid placements, shared facilities and contributions tied to real training are possible approaches. Judge them through completion, competence, employment and the experience of participants.

The scheme should not make the learner the residual insurer of every cost. A large repayment obligation can make it difficult to leave a poor workplace even where the training was ordinary induction rather than a transferable qualification. Legitimate recovery of a specific optional investment needs a different argument from making mobility generally punitive. The applicable law varies; the ethical distinction concerns the nature of the benefit and the control retained.

Public support can also subsidise hires an employer would have made anyway. Evaluation should identify additional opportunities and examine whether the work offers real progression. Counting participants or training hours alone can reward programmes whose paperwork is complete while the learning is weak. The goal is a sustainable route into competence. It should benefit the learner, protect people affected by their work and give employers a reason to participate. A programme that makes any one of those groups absorb unlimited risk will eventually fail the others too. I am angry at the circularity because it is so easy to recognise. Nobody arrives fully formed. Someone explained, corrected, supervised and trusted each experienced person before the title became true.

The people coming next deserve a route into that process. They should not have to be exceptional before anyone is willing to help them become capable.

19. The knowledge behind the gate

I find it absurd that a person can be told to demonstrate competence while being denied practical access to the material against which their competence will be judged. Sometimes the barrier is a publication charge. Sometimes it is a standard, a laboratory, a dataset, a library subscription or a piece of documentation restricted to approved customers. Sometimes the material is technically public but supplied in a form that cannot reasonably be searched, understood or reproduced.

Legal effects sharpen the issue. In March 2024, the Court of Justice of the European Union recognised an overriding public interest in disclosing four requested harmonised standards because of those effects. The judgment did not declare every standard public domain and did not resolve the separate copyright ground of the appeal.⁶⁷ That limited decision supports a larger question: what does it mean when a rule you cannot readily inspect governs you?

A manufacturer may need the rule to build a compliant product. A consumer may need it to understand a claim about safety. A researcher may need it to challenge whether a product meets its advertised standard. An affected person should not have to be a substantial commercial participant before the relevant requirements become clear. Providing access still leaves the cost of producing the work. Public funding, membership contributions and implementation services spread that cost differently. Some can undermine independence or exclude smaller contributors. The funding model matters as much as the access barrier.

“Someone must pay” does not answer who should pay or when. Charging the person who needs to understand an obligation is a choice. When a private document helps determine public legal consequences, that choice deserves close scrutiny. Research access raises related questions. A public-interest study may be difficult to read without a university or employer login. A freely accessible paper may still rely on data, equipment or methods unavailable outside the original team. Removing the article’s price helps without making the research independently checkable.

UNESCO’s open-science framework covers publications, research data, educational resources, software, hardware, infrastructure and participation.⁶⁸ It describes what open science should make possible. Each institution still has to show what it actually provides. That breadth should lead to more precise questions. Can somebody obtain the material? Can they understand the method? Can they test the important claim? If full reproduction is impractical, what narrower independent check is possible? What information must remain protected and why?

A demand for scrutiny should not become an excuse to publish other people’s private records. Medical, personal and community-held information can require controlled access, aggregation or an alternative verification procedure. The appropriate openness is related to the claim being tested and the people whose interests are implicated. Privacy should not become an excuse that prevents anybody outside the institution from questioning a result. A serious claim needs a workable route to independent review. Sometimes a trusted reviewer should inspect the evidence instead of publishing it to everyone. The reviewer needs enough access and independence to do the work.

Withholding data to protect people differs from withholding reasoning to protect an institution from criticism. The boundary can be difficult. That is why it should be explained rather than settled by attaching a reassuring label. Open access can also move costs rather than remove them. If authors must pay substantial fees to publish, the reader’s barrier might become the researcher’s barrier. A programme should ask who can contribute as well as who can consume. Otherwise unequal access to money can still shape the publicly available record.

Libraries, repositories, documentation teams and archivists matter here. They provide continuity and help that an isolated file cannot. People may need help finding the relevant work, checking its status or understanding how it relates to earlier work. Those services are worth funding. The authority attached to a publication also deserves scrutiny. The San Francisco Declaration on Research Assessment (DORA) rejects using journal-level metrics as substitutes for judging individual research and asks institutions to recognise outputs such as data and software.⁶⁹ It identifies a real assessment problem without telling us how often each institution repeats it.

The connection to this essay is direct. A recognised venue can be useful evidence about a process the work passed through. It cannot perform the reading, assess every method or prove that a particular conclusion is correct. A prestigious failure remains a failure. An unfashionable result can be valuable. That does not justify replacing all structured assessment with personal taste. Informal judgement can conceal patronage and bias. We need methods that make the grounds of assessment visible, recognise different contributions and remain open to correction. A metric can assist that work if its scope is understood.

Work that does not produce a dramatic positive result can still have great value. A replication, a maintained dataset, a negative finding or a careful explanation of a failed method can prevent somebody else wasting years. A system rewarding only novelty risks making the conditions of reliable knowledge less attractive to supply. The criticism should identify particular assessment practices instead of declaring academia uniformly corrupt. Researchers and institutions are already trying to improve them. Their work gives us alternatives to examine and a reason not to collapse everybody into one accusation.

Knowledge should help more people become capable of understanding and questioning the world. That includes people who are not enrolled, employed by a major institution or likely to publish in a prestigious venue. Public access can be made a condition of funding rather than left to each reader’s purchasing power. The 2024 Public Access Policy of the US National Institutes of Health (NIH), implemented for applicable manuscripts accepted from 1 July 2025, requires submission of the accepted manuscript to PubMed Central and public availability without an embargo on the official publication date.⁷⁰ The requirement concerns covered research articles. It does not make every underlying dataset public or remove the need to protect research participants.

The policy makes a concrete choice. The cost of public access becomes part of how research is funded and published. It also creates work: authors need to retain the right permissions, submit the correct version and comply with repository requirements. The policy succeeds only when the work becomes available in a usable form. A reader should be able to distinguish the accepted manuscript from the publisher’s version and locate later corrections. Persistent identifiers help but an identifier pointing to an inaccessible or withdrawn object still requires an explanation. The repository’s responsibilities include describing what is held, which version it represents and what happened when the underlying claim changed.

An article and its evidence are different things. A polished open-access paper may still be impossible to reproduce. Reproduction may require code, data-cleaning decisions, instrument settings and environmental information omitted from the paper. A sound research record should identify those dependencies and explain which can be supplied. Where sensitive data cannot be released, a structured verification route may still be possible. A trusted reviewer could test the analysis in a controlled environment. A carefully constructed public dataset could exercise the method without reproducing private observations. The result should state what was checked and which parts remain dependent on the original investigators. Replacing inaccessible evidence with an assurance from a famous institution would not answer the same question.

Access to the finished standard is different from access to the process that develops it. A small organisation may be able to obtain a document yet lack the staff time to attend meetings, prepare comments and follow revisions. People affected by the resulting system might not even know which committee is making the relevant choice. Representation creates a practical problem. Giving everyone a theoretical invitation does not ensure that the interests represented are broad. Equally, filling a committee with nominal representatives does not guarantee that they possess the technical knowledge or independence required to contribute effectively. The process needs to explain how expertise, affected interests and decision authority are brought together.

Consultation should identify which decisions remain open. It should supply enough explanation for a respondent to understand the consequences and enough time to prepare a substantive response. Afterwards, the institution should explain which objections changed the proposal and why others were rejected. Counting submissions is a poor measure of participation if none can affect the result. That expectation has limits. A standards body cannot accept every incompatible preference. Some decisions require specialised evidence. A person whose preferred design was rejected has not, by that fact, been excluded unfairly. The question is whether the objection was considered under understandable criteria and whether the decision can withstand the evidence presented against it. The same reasoning applies to publicly funded frameworks. A framework can invite comments while its examples already imply the implementation choices that users will adopt. Definitions, schemas, worked examples and eligibility fields deserve scrutiny together. The part most likely to be copied into software may matter more operationally than the careful qualification in the introductory prose.

A body of knowledge must contain more than the methods that produced attractive results. If a tested approach failed under specified conditions, documenting that failure can prevent somebody else repeating it. The record should distinguish a negative result from an unsuccessful experiment whose design could not answer the question. It also changes what institutions ought to preserve. Raw volume is not the aim. A small, understandable account of a tested method, conditions, result and limitations can be more useful than a large archive nobody can interpret. Data without enough context can encourage confident reuse under assumptions the original work did not support.

Publication and preservation are continuing responsibilities. A paper may remain cited after a correction. A dataset may be reused after consent conditions change. A benchmark may continue to shape procurement after its tasks cease to represent the work. Important changes need to remain visible to the next person relying on the record. Researchers are not solely responsible for every later misuse. They should still communicate what they know about the work they publish. Institutions claiming authority from that work should check its status and limits.

A student should be able to follow a question beyond the point at which their course stops. An engineer should be able to inspect the standard invoked to reject their work. A member of the public should have a practical route to the evidence behind an important public claim. Those capabilities take resources. They should be financed as capabilities, rather than described as already available because a citation exists.

20. The person outside the default

Before a system can give someone an opportunity, it has to recognise that they might be there. The assumed user is often remarkably convenient. They have current equipment, reliable connectivity, private space, an available telephone number and fluency in the language of the interface. They can read the screen, hear the instructions, complete the task quickly and produce the identification the designer expected. They are not interrupted, injured, frightened or sharing a device with somebody they do not entirely trust.

A specialist tool can legitimately have a narrow audience. An essential service cannot casually make the same assumptions about everyone who needs it. The International Telecommunication Union’s (ITU) 2025 estimates put 2.2 billion people offline and emphasised continuing differences in affordability and connection quality. That is a dated estimate, not a current headcount. It is sufficient to reject the idea that publishing a webpage by itself establishes universal practical access.⁷¹

Even being online is not a complete description of capability. An expensive or intermittent connection changes which operations are reasonable. A shared device changes the privacy of notifications, saved sessions and account recovery. A low-end device may load a page while making the actual task unusable. Access means being able to complete the task under the conditions in which people are expected to use it, not merely reaching its first screen.

A service should be evaluated at its difficult boundaries as well as its successful demonstration. A person does not become an irrelevant edge case because the circumstances causing failure are inconvenient to reproduce in a design meeting. Accessibility makes this point particularly clear. WebAIM’s 2026 automated assessment detected Web Content Accessibility Guidelines (WCAG) failures on 95.9% of the one million homepages sampled. The result concerns detectable failures on those pages, not the complete usability of the entire web. An automated pass would not establish that every user can complete every task either.⁷²

The measured failure rate is already serious without exaggeration. We have testable criteria for important aspects of access, yet a large majority of sampled pages failed at least one of the criteria the testing could detect. The response should be a development process, not a badge. Keyboard operation, understandable labels, appropriate contrast, useful error messages and the ability to use assistive technology need to be considered while the interaction is designed. Testing with people whose circumstances differ from the team’s can reveal failures a checklist misses. This work has costs. A small project might not be able to accommodate every combination of language, impairment and equipment immediately. It should describe its intended scope honestly, use the accessible features its platform makes available and avoid unnecessary barriers. An institution imposing an essential service has a stronger obligation and should fund it accordingly.

The comparison should include the cost of exclusion. If a person has to ask somebody else to read private correspondence or complete a financial transaction, the workaround can affect privacy and independence. The provider’s redesign cost is not the only cost in the decision. A fallback must be usable. Telling someone to telephone is insufficient if they cannot use that channel, cannot reach an authorised person or are sent back to the same form. A paper option that takes so long the person misses an important deadline may preserve formal choice while denying a comparable service. Test whether the alternative achieves the necessary outcome, not whether a sentence somewhere says an alternative exists.

Exclusion can be systematic without anybody writing an explicit rule against a group. A decision may use location, employment history, language, purchasing patterns or another field that acts as a proxy for circumstances the designer never examined. Historical records can carry the effects of earlier exclusion into a new model. One rule applied consistently can therefore burden people differently. The exact legal categories and duties vary between jurisdictions. The engineering question exists before that legal classification: whose errors are hidden by the average and who bears the consequence when the system is wrong?

Face recognition provides a well-measured example. NIST’s continuing evaluation reports differences in false-positive and false-negative rates across age, sex and race for submitted algorithms. It also identifies image quality and representation in training data as possible contributors to some differences. Face recognition is only one case. The Australian Human Rights Commission’s broader report examines algorithmic bias in government and private-sector decisions alongside accessibility, reasons and review.⁷³ Neither source makes every automated system equally inaccurate or proves unlawful discrimination in a particular deployment. They show why an overall accuracy number cannot establish equal performance or fair treatment. The deployment still has to consider the population, conditions, error rates and consequence of each kind of mistake.

Group analysis creates its own risks. Measuring unequal effects can require information about characteristics that a service should not otherwise collect. Inferring those characteristics can be intrusive and inaccurate. Small groups can be identifiable even in an aggregate report. A responsible evaluation should collect only what the question requires, protect it, involve people who understand the affected context and explain what remains unmeasured. Absence of subgroup data is not evidence of equal treatment. It is an evidence gap.

Individual review remains necessary because a sound group average cannot decide one person’s case. Group review remains necessary because an appeal process can correct a sequence of individual mistakes without revealing that the same people are repeatedly being burdened. People also belong to several groups at once. A service that reports acceptable results by age and by disability separately can still fail older disabled users under the conditions it actually imposes. The useful response is not to invent ever smaller categories until nobody can be measured. It is to test plausible concentrated harms, preserve routes for affected people to report what the measurement missed and give somebody authority to change the system.

Language belongs in this account. I prefer British English and want products to respect that choice. The same principle protects people who prefer other forms of English or use another language entirely. My preference cannot become the universal setting because I dislike somebody else’s. Internationalisation also extends beyond translating buttons. Names, addresses, dates, number formats, writing direction and the meaning of administrative categories vary. W3C’s guidance on personal names describes why assumptions about first names, family names and their order fail across different naming practices.⁷⁴

The design should begin with what the service actually needs to know. Does it require a legal name or merely a way to address someone? Must the name be divided into components? Does an address need to match one national postal model? Is the system rejecting valid information to preserve a convenient database assumption? Sometimes a shared technical identifier needs a stable spelling or format. That does not justify imposing the same rigidity on every human-facing field. The distinction between an internal identifier and the person’s own description should remain visible.

A translated interface can still leave the important explanation untranslated. Someone may reach the final stage of an application and discover that the legal notice, error message or support process requires fluency they do not possess. Translation quality itself matters; an inaccurate translation can create serious misunderstanding. Language support should be sustainable and meaningful. A long menu of poorly supported languages can be worse than a smaller set supported carefully, provided the institution acknowledges who remains excluded and offers another route.

Identity checks create a related tension. A service may need to establish eligibility or prevent impersonation. Requiring a particular document or device can be an effective method for some users and an impossible condition for others. The system should ask which fact it needs to establish and what alternative evidence can establish it without disproportionate risk. I do not want access achieved by making fraud easier against other people. I want the institution to distinguish its legitimate goal from its preferred implementation. “This is the only method our supplier supports” describes the current system; it does not justify excluding someone from an essential service.

The need for help should not be treated as a failure of adulthood. People should be able to authorise another person to assist them, with limits that preserve privacy and prevent abuse. Meaningful agency includes competent delegation. It does not require everyone to operate every system unaided. Circumstances also change. A previously accessible interface can become unusable after an injury, loss of equipment or change in housing. A person who usually completes tasks easily can still need a slower explanation during an emergency. Designing for such variation protects ordinary users across time, not merely a separate category of people described as exceptional. Access should not be organised as a charitable supplement to the real product. For an imposed or essential service, it is part of delivering the service to the people for whom it exists.

An accessibility review should follow the complete task. Can the person discover the service, understand what it requires, supply the necessary information, recognise an error, correct it and obtain help? A product can provide an accessible registration form and an inaccessible recovery process. The first success does not make the second failure irrelevant. Consider an account needed to receive important notices. The user completes registration with assistive technology. Later, a change in device triggers an additional verification step that the technology cannot operate. The provider may report that its main interface meets a standard while the person remains unable to read the notice. A route used infrequently can still determine whether the service is accessible at the moment it matters most.

The test should therefore include changes of circumstance. A device breaks. A person temporarily cannot use a hand. A connection becomes unreliable. A household shares equipment. Someone loses access to the telephone number used for recovery. Different interfaces can address these conditions. The organisation should know what provision remains available in each case. Alternative provision needs equivalent authority. A member of support staff who can explain the problem but cannot change the deadline may be unable to help. A telephone channel that accepts information but leaves it outside the system of record can create a new dispute. An alternative should complete the relevant task, preserve the evidence and produce a result recognised by the institution.

Every channel need not reproduce every feature. The essential outcome must still remain available under conditions appropriate to the people expected to use the service. An alternative route should not quietly provide weaker protection or a slower remedy because the preferred interface was inaccessible. A page that loads quickly on the developer’s equipment may make ordinary use expensive elsewhere. Images, scripts, repeated authentication and large downloads all have costs. The intended environment should therefore be specified and tested, rather than inferred from the equipment available inside the development team.

No universal minimum device suits every application. A specialised design tool can legitimately require powerful hardware. The demand becomes harder to justify when a basic public-service task requires a recent device primarily because the chosen software stack assumes one. The institution should distinguish the requirements of the task from the requirements introduced by its implementation. Offline provision has similar limits. Some decisions require current information and cached records can become misleading. A service can still identify which operations can safely continue without a live connection, how pending work is marked and what happens when connectivity returns. Saving a completed form locally may help someone even when the final submission must wait.

The design must also account for privacy on shared equipment. Persistent login and automatically saved documents can expose information to another household member. A convenient default for a personal laptop may be unsuitable in a library or an assisted-access setting. The user’s circumstances should affect the protection supplied without requiring them to understand every technical risk before receiving it.

A stable technical identifier can coexist with a display name chosen by its subject. The identifier should serve the system’s need to distinguish records. The name should serve the person’s need to be represented accurately. Reusing one field for both can make a legitimate name change look like a new identity or make an internal key become an inappropriate public label. Errors also need translation. A person who can navigate the ordinary screens but cannot understand the explanation of a rejected application has only partial access. Important notices, assistance and correction procedures should be included in the language plan. Where a language is unsupported, the limitation should be clear before someone invests substantial effort in the process.

The relevant principle is accuracy about the intended audience and honesty about remaining exclusions. A small voluntary project may serve a narrow language community. A widely imposed system has accepted a different responsibility. The difference should follow purpose and consequence rather than the prestige of the organisation providing it. Testing with affected users can expose assumptions that an internal checklist misses. It should be a supported activity with a clear task, appropriate privacy protection and a way for findings to change the product. Asking someone to repeatedly demonstrate that a known barrier exists, without allocating resources to remove it, transfers the institution’s work back to the person excluded.

No participant represents every person sharing a diagnosis, language or access need. The evidence should describe the conditions tested rather than certify universal accessibility. The outcome should be a maintained account of what works, what remains difficult and who owns the changes. A redesign, security measure or new dependency can undo a route that previously worked. Accessibility therefore remains an operating responsibility. The institution should know who cannot complete the task, how it learns that fact and who can change the result. Otherwise the people missing from its successful-completion statistics may be exactly those who most need its attention. A person should not have to become an accessibility campaigner, translator or technical investigator before their circumstances count. The system should meet them as a person with a legitimate purpose, not a defective version of the person its designers imagined.

V. What survives us

21. The right to keep using it

When I read a support announcement, I notice how completely it is written from the supplier’s perspective. The customer receives a date, a list of affected products and perhaps a recommended upgrade. The supplier has already made the decision and treats communication as the remaining task. From the customer’s perspective, the work may only be beginning. Ending support can require equipment replacement, software testing, staff retraining and data migration. The budget might not absorb the transition or the process may need availability beyond the supplier’s release schedule. The product can still perform its original function after the support that made it safe has been withdrawn. I do not think every support period should be infinite. I do think the relationship deserves a more complete account than the date alone provides.

What useful life was represented when the product was sold? What did the customer reasonably rely on? Which parts require the original supplier’s continuing involvement? Could another competent party maintain them? What has the supplier done to permit or prevent that possibility? What remedy remains if the product cannot be made safe? These questions distinguish several different demands. Continuing to add features is different from correcting a serious defect. Maintaining every old configuration is different from supplying a safe transition. Keeping a hosted service alive indefinitely is different from providing a documented export before it closes.

A sensible obligation should relate to the product and the dependence it creates. A small experimental utility is not a remotely administered device used in an essential service. A disclosed short-lived trial is not a machine marketed for years of dependable use. The distinction should be reflected in design, pricing, support and the promises made before adoption. The commercial decision should include the cost of keeping those promises. If the product cannot be maintained under its advertised economics, the problem is not solved by discovering that fact after customers have organised their lives around it.

Repair restrictions can make the relationship especially one-sided. The owner may possess the physical object while lacking access to diagnostic tools, parts, documentation or permissions needed to restore it. In its 2021 report on repair restrictions, the FTC identified such barriers and found scant evidence supporting several manufacturer justifications it examined. That was an assessment of the practices considered, not a ruling that every restriction on every device is illegitimate.⁷⁵

There are real protections to preserve. An unauthorised modification can harm other people or weaken a safety control. An update process needs to distinguish an authorised maintainer from an attacker. A repair right should not grant access to another person’s secrets on a shared device. Invoking security should begin a design discussion. Which risk does the restriction address? Can the owner authorise a qualified alternative? Can verification survive a transfer of maintenance? Is the restriction protecting people or retaining the service relationship?

Meaningful owner control and necessary safeguards often can coexist, although making them coexist requires engineering work: separate credentials, a documented maintenance mode, verifiable updates, clear responsibility for modifications or a procedure for handing over a discontinued product. The cost belongs in the comparison with continued exclusivity including the costs that exclusivity imposes on users. The same caution applies to legislation. The EU Cyber Resilience Act links support for covered products to expected use, generally with a five-year minimum unless expected use is shorter. Most substantive provisions apply from 11 December 2027; Article 14 reporting duties began on 11 September 2026. The regulation also distinguishes non-commercial free and open-source software and certain stewardship roles. Its existence is meaningful progress but it is not an October 2026 guarantee covering every installed product.⁷⁶

Australian consumer guarantees already address acceptable quality and, subject to conditions and exceptions, repairs and spare parts for a reasonable period. Those protections should not be ignored. They also should not be casually converted into a universal promise of perpetual software maintenance.⁷⁷ The ethical argument is wider than any one legal rule. A supplier can meet a minimum obligation and still make a decision worth questioning. Conversely, a complaint that nothing ever happens must recognise actual rights and enforcement when they exist.

There are difficult cases. A supplier can become insolvent. A hardware limitation can make a safe fix impractical. Continuing a service can cost far more than anticipated. Another maintainer may lack the necessary expertise. An operator may decline an available migration because it is disruptive. Those circumstances change the feasible remedy. They do not make the affected person’s interests vanish. The answer may involve a refund, replacement, reduced safe functionality, migration support or an authorised maintenance handover. In some cases continued operation must end. Then the responsibility is to manage that ending honestly and allocate its costs fairly. A rule should not make an individual engineer personally responsible forever for any defect in work they once touched. Such a rule ignores the organisation that commissioned, sold and controlled the product. It also confuses identifying a defect with determining whose conduct warrants sanction.

A volunteer should be able to stop maintaining a project. A commercial organisation depending on the project should plan for that possibility. The owner’s freedom to continue and the maintainer’s freedom to stop can coexist if the adopting institution accepts the work required to connect them. Durability allows change without extinguishing somebody else’s useful work. Apple’s Error 53 case shows a limit to a supplier’s account of repair. In June 2018, the ACCC reported an A$9 million penalty after Apple admitted making false or misleading statements to at least 275 customers about their consumer rights. Customers had been told that third-party repair prevented a remedy, although Australian consumer guarantees still applied.⁷⁸

The case concerns the automatic refusal, not damage actually caused by an unrelated repair. The cause of a fault and the presence of third-party work are different facts. A service process needs to distinguish them before refusing a remedy. Apply the same reasoning to technical restrictions. A manufacturer can identify a genuine safety requirement without proving that only its own commercial network can satisfy it. Ask what capability is required, how competence can be checked and which less restrictive options would preserve the protection.

Australia’s Motor Vehicle Service and Repair Information Sharing Scheme offers a concrete alternative to an all-or-nothing choice. It requires relevant service and repair information to be made available to eligible repair businesses and registered training organisations at no more than fair market value, with additional conditions for safety and security information.⁷⁹ The scheme has a defined scope and does not give hobbyist owners the same access entitlement as eligible repair businesses. It is neither a universal software-repair right nor a requirement that every diagnostic service be free. Its design nevertheless separates several questions that are often compressed. The information can be accessible without indiscriminate public disclosure. A fee can fund provision without granting an exclusive repair monopoly. Restricted information can have eligibility conditions without every ordinary repair being confined to the manufacturer.

An independent provider must be able to obtain the necessary material in time, at a workable cost and in a usable form. A formal entitlement supplied through broken tools or incomplete documentation would not provide the same capability. Evaluation must continue after the legal change. Before purchase, the supplier should state the expected support period, important remote dependencies and what happens when support ends. A purchaser should not need to infer a product’s usable life from a warranty written for a different purpose. A product sold for long-lived use needs support suited to that use.

During operation, the supplier and customer should preserve the means to maintain the product. This can include current documentation, supported backups, available parts, understandable update procedures and clear authority over changes. The product’s risks should decide how much is required. An industrial controller and an inexpensive personal utility do not justify identical spending. Before retirement, the parties need to establish which functions can continue safely, what data must move and what assistance the transition requires. A reduced but safe operating mode may be preferable to immediate replacement. In another case, continued use may be unacceptable and a replacement or compensation may be the appropriate remedy. The outcome should be based on the actual risk and reasonable expectations created at sale.

Planning cannot guarantee that every supplier survives. Insolvency, loss of essential staff or unavailable components can defeat an honest intention. Heavy reliance makes contingency plans worth examining. Writing an unlimited guarantee into a brochure cannot create one. Escrow illustrates the limits. Depositing source code somewhere may help if a supplier disappears. It may still omit the build environment, deployment keys, third-party rights or people needed to use it. Test escrow against the capability the customer expects to recover. A sealed archive that nobody can build is a weak continuity plan.

A security fix may require a behavioural change. A previously permitted operation may be unsafe. An old interface may need to be removed because it cannot preserve a necessary boundary. Users should receive an explanation that connects the change to the protection it supplies. That need does not justify bundling an unrelated account requirement, tracking feature or commercial restriction with the fix. A supplier should distinguish necessary changes from preferred ones. The customer’s need to remain reasonably secure should not become bargaining power over every other part of the product.

There are costs in maintaining separate branches and configurations. A supplier can reasonably limit the combinations it supports. The resulting decision should account for the reliance it created and the alternatives available to users. It should not be defended solely through the fact that a single package is easier for the supplier to distribute. Repair design and commercial responsibility meet here. A system designed with replaceable dependencies and documented interfaces may allow a narrower change. A tightly coupled product may make an unrelated migration unavoidable. That coupling was itself a design decision with future costs. Those costs should be considered before the supplier presents them as an unavoidable property of technology. The supplier should explain the continuing terms before asking for reliance, support them while they apply and provide a workable transition when they end. The customer should know which maintenance remains their responsibility and act when a workable remedy is available.

Nobody receives unlimited entitlement. Nobody should be able to erase an important obligation merely by redefining the product as old. A support date is a necessary part of some products. It is not a complete moral explanation for what happens afterwards.

22. Open to whom and for what

I do not accept that one institution’s definition settles the philosophy of openness. I also do not want my disagreement to make the actual permissions harder to understand.

Being able to read source code has value. Visibility can support scrutiny, education and discovery of behaviour a user would otherwise have to trust. But a public file gives no right by itself to copy, modify or redistribute it. Even a licence granting those rights may leave independent maintenance impractical. The legal permissions and the practical capabilities should both be described. A person may inspect a program but be unable to distribute a repaired version. They may have permission to build a modified version without any usable way to install it on the purchased hardware. They may fork the source while control over the project itself remains concentrated elsewhere.

The Open Source Definition is a recognisable framework for licensing and distribution permissions. It requires source availability, rights to modify and redistribute and no discrimination against fields of endeavour.⁸⁰ Those are serious conditions. The definition can do that job without certifying every other property of a project. Demanding more would repeat the same category error I object to elsewhere.

Meta’s description of Llama as open source gives the distinction a current example. The Llama 4 Community License permits substantial use, modification and distribution but incorporates an acceptable-use policy. It also says that an organisation whose products or services exceeded 700 million monthly active users at the release date must request another licence which Meta may grant at its sole discretion. Those conditions conflict with the Open Source Definition’s prohibitions on discriminating against people, groups and fields of endeavour. The Open Source Initiative made the same classification of corresponding restrictions in the Llama 3.x licences.⁸¹ Meta can choose custom terms and argue that its restrictions are responsible. It should not make those restrictions disappear inside a familiar classification. A useful description would state which source and model material is available, what people may use, modify and distribute, which uses are prohibited and where Meta retains discretion. Concluding that the licence is not open source under the Open Source Definition does not establish that Llama is worthless or that every restriction is unethical. It establishes that the rights differ materially from the rights the label ordinarily communicates.

My disagreement begins when the classification becomes the final moral account. I want to ask which freedoms it prioritises, which conflicts it leaves unresolved and what people can actually do. A licensing label cannot endorse the governance or social value of the whole project. GNU places the freedoms to run, study, modify and redistribute software within an explicit ethical account. It also recognises commercial development and paid support. It would be false to describe the movement as requiring all authors to work without payment.⁸²

The stronger disagreement concerns the moral status of developer control. GNU’s free-software definition describes a nonfree program as an instrument of unjust power. I do not think the legal category alone determines whether every particular relationship is unjust.⁸² A person can reasonably purchase a supported service or a specialised proprietary tool without being morally mistaken for valuing convenience, reliability or features they cannot obtain elsewhere. The seriousness of the control depends on the consequences, alternatives, representations and ability to obtain a remedy. A restricted optional tool and an unavoidable system governing someone’s livelihood should not be evaluated as though those circumstances make no difference.

The ability to sell a restriction does not make it acceptable. I need a fuller account of the relationship. Some forms of control are objectionable even when disclosed. Some permissions are valuable even when most users exercise them through somebody else. A practical choice can be defensible without becoming a universal ideal. Permissive and copyleft licensing pose another question: how should permissions continue downstream? A permissive licence can make integration easier. Copyleft attaches conditions intended to preserve certain freedoms when covered work is distributed. The detailed scope depends on the licence, not the label.⁸³

Both approaches can be chosen for serious reasons. Neither guarantees sustainable maintenance or a fair institution. Contributors deserve to understand the bargain and should not have it casually reinterpreted because a powerful participant would prefer different terms. The terms of distribution should therefore be stated directly. Can a recipient run the program for their purpose? Can they inspect and modify it? Can they distribute the changes? Does an obligation follow distribution or remote provision? What patent permissions are supplied? What remains under trademark or service control? The answers can be compared without treating one label as a complete verdict.

Approval by an established body can make a familiar model easier to recognise. That coordination benefit is real. A replacement vocabulary should explain how people will preserve comparability and avoid misunderstanding. Rejecting a convention has costs. The convention remains open to challenge. Exclusion from knowledge remains a political question and commercial control can survive through institutions, not merely through an individual’s refusal to share. The demanding question is how the proposed freedom would be maintained under changed conditions.

A creator can work without relying on an exclusive right to every copy. Those rights are not necessary for every act of creation. The harder question is which alternatives can support expensive research, unpopular subjects, long-term maintenance and creators without another income. Production has costs. The present system is not the only possible way to meet them. A serious proposal needs a transition. Which work is funded publicly? Which can be supported through services or voluntary association? How are priorities chosen? What protects people whose contribution is valuable but difficult to monetise? How does an institution lose funding if it no longer serves its purpose? A manifesto can identify a direction without supplying those answers. The missing answers remain necessary before the direction becomes a workable settlement.

Using an existing legal tool while advocating different long-term institutions is not inherently hypocritical. Copyleft uses copyright conditions to preserve permissions for recipients. A proponent can defend that strategy under current law while wanting a different system eventually. Judge the strategy by its effects and whether the proposed transition could work. The same consistency is required from proprietary publishers. A company can defend protection for its own work while valuing access to shared methods and knowledge. It should explain the distinction when it seeks broad access to other people’s material and narrow control over what it produces from that access. Whether the distinction is defensible depends on the actual rights, contributions and consequences. A rhetorical preference for innovation cannot decide it.

An author can reasonably object to a harmful use of their work. A use restriction may express that objection and sometimes give it a means of enforcement. It also transfers interpretive power to whoever decides whether a use falls within the prohibited category. That power can be exercised well or badly. A broadly worded restriction might obstruct legitimate investigation, preserve an incumbent’s advantage or give a hostile government a convenient reason to exclude criticism. A narrowly worded restriction might fail to reach the conduct that motivated it. The evaluation needs to consider enforceability, evasion and effects on legitimate uses.

Removing the restriction does not imply approval of the harmful conduct. A person can defend a general permission while opposing particular exercises of it through other institutions. Conversely, a restriction that fails an established open-source definition is not thereby proved unethical. Classification and moral judgement remain separate tasks. Authority over harmful conduct has to sit somewhere and the chosen intervention has to reduce the harm. Sometimes a generally applicable law is more legitimate than each software author defining their own categories. Sometimes law is unavailable, captured or too slow and an author may decide not to supply a capability. Neither possibility makes every case easy. I do not want this disagreement settled by declaring one movement the owner of freedom. I want people to understand the competing freedoms and the power held by the project they are joining.

The CARE principles developed by the Global Indigenous Data Alliance make that conflict explicit. They ask data governance to consider collective benefit, authority, responsibility and ethics alongside technical sharing.⁸⁴ They offer one important perspective; communities still differ. Giving access to one party can remove control from another. Publishing more does not benefit everyone affected. Collective authority also needs scrutiny: whose voice counts, how dissent is handled and which decisions may legitimately be made for an individual.

Privacy, public accountability and access to knowledge can genuinely conflict. Evidence can help us understand their consequences without producing one uncontested moral ranking. The writer still has to choose and explain which interests they consider decisive in a particular setting. AI training is one application of those questions, not a reason to suspend them. A person can defend access to knowledge while opposing a particular data-collection practice because of privacy or the conditions of acquisition. A company can make a useful model without automatically being entitled to every input it would find convenient. Human-learning analogies and accusations of theft cannot settle the actual permissions, copies, outputs and consequences by themselves. Nor is a maintainer refusing generated contributions necessarily contradicting a software licence. Permission to modify a program does not entitle a contributor to the original maintainer’s attention. A private choice, a project policy and a proposed prohibition on everyone are different claims with different burdens of justification. I want claims of openness to become more informative. Tell me what can be inspected, what can be done legally, what can be done in practice, who makes the important decisions and how the work will be sustained. State the limits without pretending the limit either destroys all value or is beneath criticism.

23. Who can change the rules

I do not think publishing every line of code answers who controls a project’s future. That power may sit in several places: the licence, a foundation’s constitution, a hosting account, a trademark registration, a funding agreement and the permissions held by the people who make releases.

Those powers deserve the same attention as the technical interfaces. They determine which changes can be made, who can make them and what remains available to people who disagree. The first question is the scope of each power. Reviewing a patch is different from changing the licence. Selecting a release is different from transferring the project’s name. Managing a budget is different from deciding which technical objections count. A title such as maintainer, sponsor or board member does not explain all those relationships.

The Apache Software Foundation separates its board’s management of the corporation from each Project Management Committee’s technical authority over its project. It also assigns project roles to people rather than their employers.⁸⁵ That is Apache’s published model; practice can still vary between projects. They are useful because they expose powers that can be examined separately. A reader can ask how a committee is appointed, what the board can change and which decisions require a recorded process. Funding can then be judged against those powers rather than a general promise that the project is community-led.

A distinction on paper needs practical support. If only one sponsor can afford the people doing most of the work, that sponsor may influence priorities without a formal veto. If only one person understands the release infrastructure, a committee’s theoretical authority may depend on that person’s cooperation. The institution should examine those dependencies rather than assume its constitution has removed them. The converse matters too. Concentrated expertise is not the same as improper control. Someone who has spent years maintaining a system may have sound reasons for rejecting a change. A newcomer should be able to ask for those reasons without gaining a right to overrule the person responsible for the result.

Legitimate technical authority needs a connection to the task. Experience in one component can justify influence over changes to that component. It does not show competence in handling complaints, distributing funding or deciding whether another person’s contribution should be recognised. Institutions should not turn technical credibility into unrestricted authority over unrelated decisions. A project can accept infrastructure or funding from a foundation without assuming that the foundation should own every trademark, account, domain or technical decision. Those transfers need their own reasons and terms.

The concrete issue is sufficient to justify scrutiny. Code can remain available while control of its public identity and operating infrastructure moves elsewhere. Contributors may retain permission to fork yet lose the name, release channels, community records and relationships through which the work is recognised. A fork can therefore be legal and still expensive in practice. That does not erase the licence freedom; it shows why legal permission is only part of governance. A project joining another institution should understand which assets it is transferring and what happens if the relationship ends.

A foundation may have legitimate reasons to hold assets centrally. It can protect continuity when an individual leaves, simplify contracting or prevent a project’s identity being appropriated. Those benefits need to be weighed against the powers reserved by the central institution and the community’s ability to challenge their use. The real test is whether the system serves the project during disagreement. A constitution that works only while everyone shares the same priorities has avoided the difficult question. It should explain how important changes are proposed, who has a voice and what protections remain for those who reject the new terms.

Financial contribution deserves recognition. It can provide infrastructure, staff time and stability that voluntary work alone cannot supply. It does not buy the right to decide every matter affecting people who contribute in other ways. The rights accompanying sponsorship should be explicit. A sponsor might receive a consultation forum, visibility or a defined seat in a governing body. The terms should state whether that role controls technical decisions, funding or changes to the rules themselves. Ambiguity becomes much harder to resolve after the project depends on the money. The same clarity should apply to non-financial standing. A community may recognise sustained review, documentation, mentoring or maintenance work. It should explain how those contributions matter instead of treating visible code volume as the only evidence of commitment. A group claiming broad participation should check whether influence is available only to people with substantial unpaid time.

No system removes disagreement. Elections can favour popularity or organised blocs. Appointment can reproduce existing networks. Consensus can give a determined minority an effective veto. Expert decisions can become opaque. The right structure depends on the decisions and people affected. Every structure still needs a way to explain its limits. The word merit is especially incomplete unless the institution says which contribution is being recognised and for which responsibility. A person can deserve recognition without being the right custodian of a signing key. Someone can be an excellent administrator without being the most prolific developer. Governance should preserve those distinctions.

Ordinary technical changes can use a lighter process than constitutional changes. A patch fixing a limited defect should not need the same procedure as transferring a trademark or changing membership rights. Calling a transfer of control routine administration should not shield it from scrutiny. A major change needs a clear proposal, reasons, affected interests and a record of the decision. People should know which rules apply before the vote and whether the proponents can alter those rules while seeking approval. Contributors may need time to decide whether they wish to continue under the new terms.

Reinterpreting the past is particularly damaging. A person may have contributed under one understanding of ownership or participation. The institution should not call that history consent to whatever future terms it prefers. Existing permissions and commitments should follow the terms that actually applied, with legal advice where rights are disputed. Emergency decisions also exist. An urgent security issue may require restricting access before a full discussion is possible. The response should go no further than necessary and leave a record for later review. Urgency can shorten the procedure; it should not remove the duty to explain it later.

An exit plan should identify what can move with a departing project or participant. Source code is one item. Documentation, issue history, domains, trademarks, funds, contributor records and signing material may have different owners and legal conditions. Some information should stay because it concerns other people’s privacy or an unrelated project. A workable separation needs enough continuity for users to know which releases they are receiving and who is responsible for them. Competing versions should not be allowed to impersonate one another. Preserving a distinction between the projects can protect users while allowing both to continue. An institution cannot promise that every departure will be painless. Shared assets may be indivisible. A community can split and some work may have to be duplicated. The obligation is to make the consequences understandable and avoid unnecessary restrictions whose main function is to punish departure. That expectation applies to the departing group too. It should not take private records, misrepresent authority or erase the contributions of people who remain. The right to continue independently does not transfer every relationship formed during the collaboration.

A public-interest institution should be evaluated against the work it undertakes. Does it maintain the relevant infrastructure? Are decisions recorded well enough to challenge? Can people discover conflicts of interest? Do its finances support the stated purpose? Is there a realistic succession plan for the responsibilities on which the project depends? Those questions require more than publication of a mission statement. They also require more than finding a single unpopular decision and declaring the institution corrupt. A poor judgement, an unresolved conflict and deliberate misuse of power are different claims. The evidence should identify which one is being made. The institution should be able to acknowledge a failure without presenting its own existence as the public interest. Sometimes the responsible decision will be to reduce scope, transfer a service or close an ineffective programme. A project can survive the organisation originally created to support it, provided the assets and obligations were arranged with that possibility in mind. The governance standard should make useful authority identifiable and limit it to its purpose. People should know how it can be challenged, changed or relinquished. A foundation, company, cooperative or voluntary group can meet that standard in different ways. Its label tells us little about whether it actually has.

24. The work we cannot read anymore

I care about more than whether a file survives. The ability to use it can disappear while every byte remains intact. The bytes may be intact. The backup may have completed successfully. The checksum may match. Yet the application no longer runs, an authentication server has closed or the documentation needed to interpret a field has gone missing. The record exists but a person cannot recover the work it was meant to preserve. That is a different failure from losing a disk. It is a failure to sustain the relationships that made the information meaningful.

The history of the BBC’s 1986 Domesday project gives this problem a concrete form. It placed a large community record of the United Kingdom on specialised LV-ROM discs used with BBC Micro hardware. A later preservation project recovered the material and recreated enough of the original environment to make it usable again.⁸⁶ The original work survived. Keeping it usable required technical work and human knowledge beyond the environment for which it was built.

Keeping the content and preserving the experience are also different tasks. An image can survive separately from the navigation through which a person originally encountered it. A collection of records can remain available while the program expressing their relationships disappears. Which aspects need to be preserved depends on the purpose of the collection. The Library of Congress evaluates digital formats through factors including disclosure, adoption, transparency, self-documentation, external dependencies, patents and technical protection mechanisms. Its framework gives weight to complete documentation and available tools rather than treating approval by a standards body as sufficient.⁸⁷ That is a practical account of continuity. Can the next custodian understand the material? Can they move it? What else must remain available? Which capabilities disappear if one organisation stops cooperating?

Ordinary lives face the same questions as national archives. Family photographs, correspondence, creative projects, business records and research environments can all outlast the software that produced them. An export that preserves text but discards structure may be enough for one purpose and devastating for another. A person should not need to predict every future use. Suppliers and institutions can still identify common long-term needs and offer documented formats, complete exports and a reasonable migration path. The more important the records, the less acceptable it becomes to make their interpretation depend on an undocumented commercial service indefinitely.

Preservation also involves decisions about authenticity. If a record is converted, what changed? Were fields dropped? Did a font or rendering rule alter meaning? Is the preserved version enough to understand a decision made from the original? A migration should describe important losses instead of implying that a successful import preserved everything. This connects directly to intelligence and public administration. A corrected assessment is easier to understand when the earlier version and reason for change can be identified. A disputed decision is harder to examine when its governing rules, relevant inputs or contemporaneous documentation no longer exist.

But the solution cannot be to retain every person’s data forever. Privacy, consent and legitimate deletion place real limits on preservation. Some records should expire. Some need restricted access. Some need a record of their existence and disposition without indefinite retention of their sensitive contents. A reasonable policy should identify what deserves preservation, why, for how long and under whose authority. It should also distinguish the public record from a permanent dossier on every person who interacted with the institution.

Deletion and accountability can be designed together. A system can record that an authorisation was withdrawn without retaining every underlying private record. It can keep enough explanation for a later audit. The exact solution depends on the law and the system. The conflict should be addressed before storage makes permanent retention the default. Software itself needs preservation. Source alone might not reproduce the behaviour that matters. Build instructions, dependencies, toolchain versions, configuration, test data and assumptions can all be necessary. A reproducible build connects known inputs to an output; it cannot recreate every external service or physical condition.

For scientific work, that difference affects what a later researcher can verify. For an important service, it affects whether another maintainer can take over. For a creative work, it can determine whether future people can experience it at all. We should be careful about promising perfect reconstruction. Some environments will be impractical to preserve in full. The task is to identify the important properties, retain enough to support them and state the losses. A documented limitation is more useful than an unexplained collection that invites false confidence. This work needs people. Archivists, librarians, maintainers and domain experts decide what material means, which dependencies matter and how to make it discoverable. A storage contract cannot replace that judgement. Nor can a one-off digitisation project necessarily fund decades of migration and access.

The continuity budget should therefore extend beyond acquisition. Who maintains the catalogue? Who checks that the format remains usable? Who handles a rights dispute? Who takes over if the institution holding the material closes? What remains possible when the original expert retires? These questions resemble product maintenance because both concern commitments across time. The beneficiary may be somebody who was not present when the work began. Their interests can be easy to omit from an immediate cost comparison.

SQLite’s published format policy and qualified support horizon towards 2050 show that continuity can be an explicit engineering goal. They do not promise that every old binary understands every new feature or that future requirements can be predicted. They do show a deliberate attempt to make age compatible with usefulness.⁸⁸⁸⁹ That deserves attention alongside stories of loss. A successful preservation practice is evidence about the conditions under which the future does not have to begin by reverse-engineering the past.

Preservation begins with a decision about the object. A document’s appearance may matter, as may its searchable text, annotations, embedded data or relationship to another record. Software may need its source, build environment and behaviour preserved for different purposes. Keeping one may still lose the others. Preservation planning should identify the intended future task. Someone may need to read a public decision, verify a scientific result, migrate a database or experience a cultural work. Each task requires different evidence and capabilities. Keeping every possible dependency indefinitely is usually impractical; selecting dependencies without naming the task risks preserving the wrong thing.

The plan should distinguish an original from a migrated representation. Migration can make a record more usable while changing a property that matters. A font may render differently. A formula may be recalculated under new rules. A timestamp may lose its zone. A field that once distinguished unknown from empty may be flattened during export. The migrated version needs a record of the transformation and any known loss.

Migration still matters. An unreadable original can be less useful than a documented conversion. Fidelity has dimensions so a claim that a conversion succeeded should identify which properties were preserved and how they were checked. A checksum can show that stored bytes match an earlier copy. It cannot tell us whether that copy was complete, whether the file can still be read or whether readers will understand it as intended. Integrity checks protect against particular risks; they do not preserve meaning by themselves.

A work can depend on a service rather than contain all the material it needs. A page may retrieve external scripts, an application may require an account and an archive may preserve a link while the linked object changes. The visible artefact can survive while its function disappears. The responsible response depends on what was promised and what can feasibly be preserved. An offline export may be enough for records. An executable environment may be necessary to examine historical software behaviour. Some networked experiences cannot be reproduced fully because they depended on other participants. The limits should be described rather than hidden behind a claim that the files were saved.

Licensing and access conditions matter alongside technical ability. An archive might possess the material but lack permission to make it available for a particular use. A private collection may preserve culturally important work while offering no succession plan. A funded repository may remain vulnerable to a single institution’s change of priorities. The continuity plan should identify custody, rights, access and resources. Preservation is work performed by people and institutions. An export button leaves later custodians with work to do. A supplier can still avoid making that work unnecessarily difficult.

Some records should retain a history of correction. Others should be deleted when their legitimate purpose ends. Those aims can conflict, especially where a record is evidence of a disputed decision about a person. A defensible system should identify what must remain to explain the decision without retaining unnecessary detail forever. The outcome, relevant version and reason for correction may be sufficient where a full copy of sensitive source material would add little. In another case, an authorised custodian may need the source to support legal or scientific review. Access should follow that purpose.

Deleting an erroneous record from the original database does not correct decisions made from earlier copies. The institution should know which important outputs relied on that record and reconsider them where necessary. Perfect recall of every downstream copy is impossible. The system should still preserve the relationships behind the decisions it directly controls. The person affected should also be told what a correction can and cannot fix. A notice can change a formal assessment while leaving damage to reputation or finances unresolved. The remedy needs to address those consequences separately. Correcting the database can finish the technical task while leaving the organisation’s work unfinished.

Organisational memory should not depend on someone remembering to explain everything during a final handover. Important decisions need enough explanation while the people involved can still examine them. Record the purpose, alternatives, important assumptions and conditions that would justify revisiting the decision. The record must remain selective. Recording every conversation creates work and can discourage honest exploration. A sound decision record captures the basis for an important commitment without pretending that every provisional thought belongs in a permanent archive.

The test is whether a successor can understand the system well enough to maintain or change it responsibly. They need to know which awkward feature protects compatibility and which exists only because nobody has removed it. Without that distinction, preservation can become permanent deference to an accidental past. Continuity should make change possible. It should not turn every old decision into an obligation that survives only because its reason has been lost. Institutions should treat their records, explanations and useful work as things they are passing on rather than material whose value expires when the current project ends. The person inheriting a system should receive more than the instruction that somebody once knew how it worked.

25. The physical bill

I refuse to pretend computers became weightless when their screens made the work look intangible. We still turned materials from the earth into every one of them. Manufacture, transport, energy, repair and disposal all belong in the account. People make components, maintain infrastructure and deal with what remains when a device is no longer wanted. A software decision can alter that chain by extending useful life, requiring new hardware or making repair uneconomic.

The Global E-waste Monitor 2024 estimated that the world generated 62 million tonnes of electronic waste in 2022 and formally collected and recycled 22.3% of it. Those figures describe that year and that accounting boundary. They do not tell us what proportion any particular software policy caused.⁹⁰ The number is a reason to investigate the lifecycle, not a substitute for doing so. Consider what must be compared when deciding whether to replace a working device. The new device may use less electricity, perform tasks faster or remove a serious safety limitation. Producing it also consumes resources and creates impacts before it reaches the user. Repairing the old device has its own costs. The answer depends on the workload, energy source, remaining life, necessary repair and what happens to both devices afterwards.

Carbon and waste do not complete the physical account. Material extraction and processing can affect water, land, air, biodiversity and people’s health in ways that one emissions figure does not preserve. UNEP’s Global Resources Outlook 2024 examines climate, biodiversity, pollution and distributional effects together across the global economy.⁹¹ It does not isolate the share caused by computers. It demonstrates why a technology comparison should state which physical effects it measures and which it omits. A lower-carbon option can still move toxic exposure or water stress elsewhere. A design that uses fewer materials can still depend on extraction whose local consequences are severe. The account needs more than one convenient environmental number.

A 2021 smartphone lifecycle study by Cordella, Alfieri and Sanfelix Forner modelled ways to use materials more efficiently in Europe. It found a lower annual carbon footprint under a longer replacement cycle in the scenarios examined. Including communication services changed the result substantially.⁹² Making a device and using it with connected services belong to different parts of the account. A comparison becomes misleading when one side omits a cost. The same applies to computing architecture. A local machine may use more resources than a shared service. A cloud service may waste resources once its whole operation is counted. Decentralisation can improve resilience while duplicating work. An apparently efficient central facility can still impose heavy burdens on one place.

We need a defined service and a realistic lifecycle. How much useful work is being provided? Which equipment exists already? What additional equipment is required? What will actually be displaced? Which assumptions dominate the result? It is tempting to prefer a simple moral label. Local, cloud, new, old, renewable, repairable. Each can describe something useful. None completes the accounting. Longevity also needs to remain safe. A device should not be kept operating in a dangerous state merely to avoid replacement. A repair can be worthwhile without being feasible in every case. Some designs genuinely make continued support difficult because of hardware limits. Those limits should become part of the product’s expected lifecycle and the customer’s information before purchase.

Avoidable retirement is more objectionable. A device may still work while a closed maintenance path, missing component or withdrawn service makes continued use impractical. Here the software, commercial and environmental arguments meet. The result is another purchase, more physical work and the loss of something that could have remained useful under a different system. That connection needs evidence in particular cases. We should not infer an environmental harm from every support announcement. We should ask what the announcement actually causes people to replace, what alternatives exist and whether the supplier evaluated them.

Regulation can make some lifecycle expectations explicit. The EU’s smartphone and slate-tablet framework applying from June 2025 addresses durability, repair, operating-system support and product information. The Commission describes requirements for relevant parts and access by professional repairers.⁹³ The rules now exist; their environmental effects still need to be measured. The intervention itself deserves evaluation. Do parts remain affordable? Can people obtain competent repair? Does the requirement reduce waste or merely change the timing of purchases? Do smaller suppliers face disproportionate burdens? Does a repairability score communicate something useful without hiding other limitations?

A rule can improve one property while creating another cost. Recognising that possibility should lead to measured revision, not a conclusion that no lifecycle requirement can ever be justified. Carbon accounting alone cannot answer who carries the burden. The people benefiting from the final product may live far from those affected by extraction, manufacturing, infrastructure or disposal. An overall environmental improvement can still leave one community with an unacceptable local cost.

Affected communities should be able to influence decisions and obtain remedies. Their position should not depend on becoming customers of the product whose supply chain affects them. Workers matter too. Repair and the rest of a product’s lifecycle are performed under conditions that matter, and an environmental policy relying on unsafe or poorly paid labour remains incomplete. Individuals should not be made to compensate forever for systems they cannot control. A person buying a device can make choices but cannot investigate its complete supply chain and disposal path. Institutions and suppliers should carry more of that work.

The aim is informed action at the level where the decision can actually change something. It is not to make ordinary ownership morally impossible until the buyer has audited a global supply chain. We can buy fewer unnecessary products, design more durable ones and repair them better while still making genuinely better technology. Judge improvement against the whole account including the cost of keeping the old system.

An environmental comparison needs a unit of useful work. The impact of manufacturing a device cannot be assessed against the electricity of an unrelated service without accounting for what each supplies and for how long. A device used intensively for years and one replaced after occasional use distribute their manufacturing costs differently. The boundary should include the physical stages relevant to the decision: manufacture, transport, operation, maintenance and end of life. It should state which are measured, estimated or omitted. A favourable result under one electricity mix or expected lifespan should not be advertised as a universal property of the product.

Consider a replacement that uses less electricity while operating. It still has to be manufactured and deployed. Its benefit depends on the energy saved over its lifetime, the cost of producing it and what happens to the displaced equipment. If the old device can serve a useful purpose elsewhere, that changes the comparison. If it cannot be made safe, continued operation is not a workable alternative. This reasoning does not yield one answer for every device. It identifies what the answer depends on. The supplier should not count only the stage at which its newest design performs well and the critic should not assume that longer use is always preferable regardless of operating costs or safety.

Software decisions belong in this account because they can change useful life. An unnecessary requirement for new hardware may bring forward replacement. A demanding application may increase the resources needed for an ordinary task. A well-designed update can also extend life, improve efficiency or remove the need for another device. The effect needs to be traced rather than inferred from whether the software is fashionable.

Reducing the resources used by an operation is useful. The total effect also depends on how many operations are then performed and what they replace. A cheaper service may enable valuable new uses. It may also increase low-value consumption. An efficiency percentage alone cannot settle that wider judgement. This should not become an argument that efficiency is pointless because demand could rise. It means product and policy claims need to distinguish the efficiency of a unit from total resource use. A claim that a system reduced emissions needs a defined comparison, not merely evidence that each request became cheaper.

The purpose of the activity remains relevant. Essential medical analysis and automatically generating disposable advertising should not be treated as morally identical because both consume a kilowatt-hour. Deciding between uses involves values and distribution, not only a technical performance measure. The institution allocating scarce infrastructure should be able to explain its priorities. Local effects also matter. A global aggregate can conceal a burden concentrated in one community. Decisions about land, water, electricity and waste should include the people living with those effects, even when most customers are elsewhere. The evidence must concern the actual site and alternatives. A general statement about an industry’s footprint cannot determine the merits of every proposed facility.

A purchaser can ask for evidence about repair, update support and replacement components before selecting equipment. It can also design its own operating practices to keep equipment useful. A manufacturer cannot deliver every benefit if the customer routinely discards serviceable devices but the customer cannot repair a product whose necessary tools are withheld. The plan should identify what each participant can change. A supplier can disclose support conditions and provide documentation. A purchaser can budget for maintenance and retain inventory information. A repair provider can record what changed. A recycler can explain which materials are recovered and which remain a disposal problem. The chain needs evidence at each handover.

A procurement score should not allow an impressive claim in one category to hide a failure in another. Recyclable packaging is not repairability. A long warranty is not security support. An efficient processor does not mean that the complete service uses fewer resources under its real workload. Nor should requirements become so elaborate that only the largest suppliers can afford to document them. A reasonable record should focus on the properties that matter and allow reliable shared evidence. The goal is a better purchase and a longer useful service, not a larger stack of certificates.

A lifecycle estimate can change when assumptions change. Product use may differ from forecasts. A component may prove less durable. A repair programme may exist but be too expensive or inaccessible for users to adopt. These findings should update the claim rather than remain outside the marketing account. The institution should state the consequences of uncertainty. A range can be more honest than an exact total based on weak inputs. Where the comparison cannot discriminate between options, the decision may rest on repairability, safety or other values that can be assessed more reliably. Uncertainty should not be hidden by supplying more decimal places.

The wider obligation is to make the physical consequences of computing part of ordinary technical judgement. They should be considered when selecting a design, planning support and deciding whether a replacement is necessary. Treating them as a separate reputational exercise leaves the decisions that produce them untouched. The physical bill is part of the technological decision. It does not vanish because it was paid elsewhere, earlier or by someone whose name is absent from the product’s marketing.

If we are going to celebrate what we made from the earth, we should be prepared to account for what making it required and what continuing to use it will leave behind.

VI. What counts as progress

26. The argument that became a metric

By this point the problem is larger than a collection of bad products. It concerns how we decide that a product, institution or policy is good enough and how easily a convenient indication can acquire authority beyond what it establishes. A record becomes proof of a debt. A severity score becomes a remediation decision. A publication venue becomes a judgement about an individual’s work. Enrolment becomes access, activity becomes learning, restoration becomes recovery and an export becomes the freedom to leave.

Each substitution begins with something potentially useful. Records are necessary. Scores can help people prioritise. Publications, qualifications and standards can make cooperation possible between strangers. The error is allowing the substitute to settle a question it can only help answer. Arguments that hide this movement especially frustrate me. A person defends the narrower property when somebody challenges it and returns to advertising the broader conclusion afterwards. The interface supplies a simple answer while the limitations remain in a document the decision-maker might never see.

A precise number can make this worse because precision looks like knowledge. The number may be calculated correctly from inputs that do not fit the situation. Two people can agree on the calculation while disagreeing about which outcome should matter. A change in methodology can alter the score without a related change in the object being scored. Purpose, measurement and action need to remain connected. What are we trying to improve? What does the measure actually observe? Which important consequences are missing? What action does a particular result justify? How do we discover that the measure has become a poor guide?

DORA’s objection to using journal metrics as substitutes for assessing individual research is one specific expression of this problem. The same logical distinction appears in vulnerability management and education, although the institutions and remedies differ.⁶⁹ Discarding measurement and trusting the wise person in the room would make matters worse. Unstructured judgement can be biased, inconsistent and impossible to contest. A transparent imperfect measure can sometimes protect people against arbitrary decisions. Its limits should guide how much authority it receives, not make it worthless.

Assessment often needs several forms of evidence. Numbers can show scale or change. Detailed investigation can explain why something happened. A technical test can show behaviour. A person’s account can reveal a burden the measured categories omitted. The question decides which evidence matters most. Ask what each piece of evidence contributes. A complaint identifies a possible failure without telling us how common it is. A successful test shows behaviour under its test conditions, not every deployment. A survey reports an experience without proving that the institution produced the competence it advertised.

The HAIL follow-up forces that discipline. Changes in applications or where students enrol do not prove a change in eventual attainment. Keeping the later limiting result makes the argument more informative even though it makes the initial story less convenient.⁵⁸ I want that willingness to revise an attractive interpretation throughout technology discourse. A proposition should not become immune to correction because it belongs to a worthy cause.

Openness, privacy, freedom, innovation and safety are valuable concerns. They are not conclusions. We still need to know which openness, whose privacy, what freedom, which innovation and safety against which risks. A word’s moral appeal cannot allocate the costs of pursuing it or decide when another person’s interest should prevail. Disagreement can remain after the facts are understood. One person may assign more weight to creator control; another may assign more weight to public access. That is different from misunderstanding copyright or inventing an empirical consequence. A serious argument should identify where the disagreement actually lies.

Calling every opposing conclusion irrational would protect my own values from scrutiny. Treating every value conflict as unresolvable would avoid the obligation to make a judgement. I need to state the interests I consider important, explain the consequences I expect and accept responsibility for the trade-off I defend. Analogies should receive the same treatment. Comparing software defects with car recalls can expose a neglected question about continuing obligations. It does not determine the exact duration or remedy. Comparing machine learning with human learning can suggest a question about access to knowledge. It cannot settle the copies made, rights involved or distribution of benefits.

An analogy earns its place when it makes the reader examine a distinction. It becomes an evasion when it allows the writer to skip the distinction. Another imbalance deserves resistance. Institutions may demand exhaustive evidence from a critic while promoting a new product through demonstrations and optimistic forecasts. Critics can make the reverse mistake by demanding certainty before accepting an intervention while treating the current system as costless.

Both sides need a feasible comparison. Continuing the present system is a decision with consequences. Changing it is another. The relevant question is which available path is justified under the uncertainty including whether the next step can be reversed and whether an interim precaution reduces serious exposure. A demanding standard of evidence should not require an affected person to build the replacement before establishing that something has gone wrong. Someone can show a defect, a false claim or an unfair process without possessing the resources to replace an industry. A proposed replacement carries its own additional burden.

People with less power especially need this distinction. Otherwise the incumbent acquires a rhetorical defence unavailable to the critic: nothing is wrong enough to object to until the objector has solved the entire institution’s problem. Three tasks should remain distinct. Establish what happened. Assess which obligations and decisions matter. Compare feasible remedies. The tasks inform one another but success at one is not permission to pretend the others are complete.

Positive evidence matters for the same reason. A correction that works, a durable design, a worthwhile course or a responsible supplier can show what conditions make improvement possible. They can also contradict an accusation of inevitability. An argument that absorbs every success into another reason for contempt has stopped learning. A classifier can appear accurate while producing a large burden of false alarms. Consider a deliberately constructed example: 10,000 cases, of which 100 genuinely belong to the class of interest. A system identifies 95 of those 100 and incorrectly flags 5% of the other 9,900. It produces 95 true positives and 495 false positives. Only about 16.1% of the 590 positive results are correct. These figures follow from the stated assumptions; they do not describe a deployed product. Their purpose is to show why sensitivity alone cannot tell a decision-maker what a positive result means. The prevalence of the condition and the false-positive rate also matter.

The appropriate action then depends on consequence and available review. A result might justify an inexpensive check while being wholly inadequate to justify a penalty. A system can therefore be useful for triage and unsuitable as an autonomous decision-maker without any contradiction. The interface should make the intended use and the required next step clear. False negatives matter too. Reducing the review queue by raising a threshold may leave serious cases undetected. Judge the trade-off against the real task and the harm caused by each error. A single accuracy percentage hides who bears that harm. The same issue appears in evaluation datasets. A benchmark can contain a balanced set of cases for experimental convenience while the real deployment has a different distribution. Performance on the benchmark tells us about those tasks. More work is needed before applying it to the real workload.

A time series can change because the underlying condition changes, because the population changes or because the measurement changes. Those explanations should be examined before a graph becomes evidence of improvement. A service might report fewer complaints after making its complaints route harder to use. A teaching programme might report higher completion after changing which students it admits. A security team might report more defects after improving detection. The number can be correct in each case while the simple interpretation is wrong.

A responsible comparison should preserve definitions, populations, observation periods and relevant changes in method. Where those changed, the report should explain the effect or state that the series is not directly comparable. More precise chart labels cannot repair an unexamined change in what is counted. Totals also need care because the same total can be distributed differently across time. The arithmetic is elementary; the policy question is whether the decision rule may discard that difference.

Averages across capabilities create a related problem. Excellent writing should not compensate numerically for failure to preserve evidence in a task where preservation is essential. A strong overall score should not conceal an untested safety requirement. The assessment should identify which conditions are mandatory and which can be traded off legitimately. An improvement after an intervention gives us a reason to investigate; it does not show causation by itself. Other changes, selection and the passage of time can matter. Use the strongest practical study design for the question and state the limits that affect the conclusion.

Randomised evaluation can help show that the tested intervention caused an effect. It does not make the population representative or reveal which part of a combined intervention produced the result. An observational study can still be valuable when it measures a real pattern and examines competing explanations carefully. The strength of the evidence follows the study design and the claim, not the prestige of the method’s name.

A policy argument also needs to distinguish an effect from a worthwhile effect. An intervention might change behaviour without improving the outcome people care about. It might improve one outcome at an unacceptable cost to another group. The evaluation should include distribution, burden and unintended consequences alongside its primary measure. Values remain unavoidable. Evidence can establish that a requirement reduces one risk and increases another. It cannot, by itself, decide whose interests should prevail. The decision-maker should state the judgement rather than present a calculation as though it had removed the conflict. An institution should be able to identify the evidence that would cause it to revise an important claim. If every successful result confirms a policy and every failure is interpreted as a reason to intensify it, the policy has become insulated from evaluation.

Review conditions might concern outcomes, cost, access or an assumption about the operating environment. They should be specific enough to act on and suited to the decision. A reversible experiment can tolerate more uncertainty than an irreversible commitment imposed on people who cannot refuse it. The critic needs the same discipline. A strong objection should identify what would defeat it. An institution correcting the problem should count as improvement, even if the correction is incomplete or comes from an organisation the critic dislikes. The point is to build something better, not preserve an accusation forever. I do not want a label to reassure me or my dissatisfaction to protect my argument. I want a more accurate account of what people can expect and what the system actually provides. That account may be less easily reduced to one number. It should still be clear enough to guide a decision and explicit enough to be challenged when the decision turns out to be wrong.

27. The people who establish that something is wrong

I cannot call a system accountable when it makes the evidence needed to challenge it practically unavailable. The person affected may receive an outcome without the rule, a score without the inputs or an assurance without permission to examine the underlying behaviour. That is a separate problem from whether the original decision was correct. A poor explanation can accompany a correct decision. Impressive documentation can surround an incorrect one. The challenge process needs enough access and authority to distinguish the two. The institution should identify what an affected person can obtain, how an independent reviewer can inspect protected evidence and what happens when essential records were never retained. It should not require the person to supply information that only the institution could possess then treat their inability to supply it as confirmation of the disputed conclusion.

Testimony and institutional records establish different things. A person can describe what happened to them, what they were told and what consequences followed. That account may identify a missing record or a question nobody inside the institution asked. It does not automatically establish the hidden technical cause or how often the same event occurred. An institutional dataset can measure a pattern while omitting the experience needed to understand its consequence. A fair investigation should connect these forms of evidence rather than treat either as inherently superior. Participation also has a cost. People should not have to recount a painful event repeatedly because every team wants its own consultation. Use existing testimony where consent and purpose allow, protect what was shared and show how participation changed the decision.

Security research provides a clear example of the tension. Independent testing can identify a defect the supplier missed. Testing can also expose private data, interrupt a service or affect people who did not consent to the experiment. A claim of public benefit does not remove those risks. The US Department of Justice’s May 2022 charging policy under the Computer Fraud and Abuse Act (CFAA) expressly addressed good-faith security research including conduct designed to avoid harm and promote security. The announcement also distinguished extortion and bad-faith conduct from protected research. This was a defined federal charging policy, not a universal immunity or permission to access any system.⁹⁴

Institutions need a reliable route for honest examination. A published policy should describe authorised scope, reporting channels and important conditions precisely enough that a researcher can stay within them. It should also explain how an urgent report is escalated and what response the reporter can expect. The reporter has responsibilities too. Use the least intrusive method capable of establishing the claim. Avoid obtaining more private information than necessary. Do not continue a disruptive experiment merely because the first result was interesting. Separate a demonstrated weakness from speculation about how much damage it could cause.

The scope must be treated seriously on both sides. A researcher should not reinterpret a narrow invitation as unrestricted authorisation. A supplier should not invite testing and then invent undisclosed conditions to avoid an inconvenient report. Where the boundary is genuinely uncertain, clarification or a controlled test may be preferable to a unilateral escalation of access. An allegation of a serious vulnerability should identify the affected versions, relevant conditions, reproduction method and observed result. It should distinguish what the researcher performed from what they infer an attacker might perform. A claim about possible access is different from proof of data extraction. A crash is different from a demonstrated ability to execute arbitrary code. This precision benefits the recipient and the people at risk. It makes triage more reliable and limits pressure to act on an inflated claim. It also allows the reporter to state uncertainty without weakening the part that has actually been established.

The recipient should preserve the same distinctions. An overstated impact claim can be wrong while the underlying defect remains real. Accepting the defect does not require accepting every severity estimate attached to it. A useful response can acknowledge the behaviour, explain the assessment and say what evidence would change it. The process should accommodate disagreement. Researchers can misunderstand a deployment; suppliers can underestimate harm. Independent review or a controlled shared reproduction may resolve the issue. A dispute should not become a contest over status or audience size.

Payment creates additional questions. A bounty can encourage useful investigation but its acceptance rules should be understandable. A programme should not use an opaque rejection to obtain substantial work without paying what it offered. Nor should a reporter treat participation as a right to payment for a result outside the stated scope. The terms and the actual decision need to be examined together. A report may contain information that would increase risk if immediately published. Delayed disclosure can give affected people time to obtain protection. Delay can also leave them unaware of a risk they could otherwise mitigate. The appropriate timing depends on the information already public, the availability of a remedy and the consequences of continued silence. The institution should be able to explain the delay. Waiting for a fix differs from waiting for a convenient announcement. Coordinating a downstream release differs from protecting a reputation. The public account might need to withhold technical detail while the response is active. The decision should still have an owner and a review date.

The October 2026 Tailscale disclosure shows what happens when reporting is treated as coordination. Cyberdione Labs tested Tailscale and headscale over three days then published eleven findings before a fix, CVE or vendor bulletin existed. The researcher told The Hacker News that Tailscale received the report and private proof-of-concept code shortly before publication. Tailscale acknowledged the report and said it was still validating the affected configurations. There was no public evidence of exploitation. The complete proof-of-concept source was reportedly withheld but the public report supplied affected components, prerequisites, commands, race mechanics, privileged targets, credential-capture paths and root-execution chains. That is not the same as releasing a self-propagating program. It still removes substantial work from exploiting unpatched systems. The report’s argument that the software carried no warranty, that open-source users were effectively developers and that a profitable sponsor could fix it quickly does not answer the disclosure question. A licence does not make every operator a maintainer or give them a patch. The name “Tailworm” also runs ahead of the evidence. The demonstrated laboratory chain required control of a policy-permitted device and a reachable Tailscale SSH target. It was not unauthenticated access to arbitrary Tailscale machines.⁹⁵

Publication needs distinct states. An initial public warning can identify the affected feature, prerequisites, consequence, available mitigations, fix status and uncertainty without supplying an operational chain. Complete reproduction evidence should first go to the supplier, coordinator and any qualified independent reviewers under exact custody. A public exploit artefact should normally wait until users can obtain a correction. That judgement can change when a supplier refuses to act, exploitation is already occurring, weaponising detail is independently public or an immediate technique is necessary for defenders to recognise compromise. Public attention and researcher impatience are not equivalent reasons. Behaviour also matters more than the label attached to code. A bounded reproducer using a benign effect against an owned target is not malware merely because it demonstrates exploitation. Code designed to propagate, persist, steal credentials, destroy data or execute payloads on systems without their owners’ authority remains malware when its author calls it research. Detailed instructions can still be weaponising even when the source itself stays private.

Hidden Tear provides a concrete example. In August 2015 security researcher Utku Sen published source for ransomware that encrypted files and sent the encryption key to a command-and-control server. He said his purposes included education, disrupting ransomware sellers and retaining ways to recover encrypted files. Attackers adapted the code, removed its recoverable weaknesses and produced operational variants. Kaspersky documented 24 additional samples by February 2016 and Microsoft later documented a ransomware family whose variants were based on the published code. In 2017 Sen described Hidden Tear and its successor EDA2 as failed experiments and apologised for the chaos they caused. His intent matters when judging him. It did not prevent the source from lowering the work needed to produce ransomware that harmed other people.⁹⁶

A deadline should not trigger an automatic release of information likely to harm bystanders. The possibility of harm should not prohibit criticism indefinitely either. An intermediate warning, limited advisory or disclosure without exploit details may protect people on both sides. Confidentiality also matters outside security. A student, worker or customer may need to submit records privately to establish a complaint. A reviewer should have a way to consider that evidence without requiring unnecessary public disclosure. The result should explain the basis as far as possible without exposing unrelated people.

An internal process can fail when the person raising a concern depends on the same decision-makers for work, progression or continued access. An alternative route needs sufficient independence and authority to examine the claim. Moving the message to another inbox under the same incentives might not change the practical position. Usable procedures and protections do not require treating every allegation as true. A person accused of wrongdoing also needs a fair process. Records should be preserved, claims specified and relevant responses examined. Public condemnation should not become the default substitute for an investigation an institution was supposed to provide.

Temporary protection requires a separate judgement. Continuing a disputed practice may cause harm while the facts are examined; suspending it may cause different harm. A responsible process compares those risks and chooses a fair temporary response. Waiting is still a choice about who carries the risk. The costs of participation matter. An institution can afford repeated requests for clarification more easily than an individual can afford repeated days away from work. A request for evidence should therefore explain its relevance and avoid asking for the same material without a reason. A deadline should account for information the institution itself has delayed supplying.

A clear rejection can be a legitimate outcome. It should answer the main allegation and explain the evidence relied upon. A response that only recites the institution’s general commitment to good practice has not done that. An investigation can establish an error while leaving the resulting action untouched. A faulty assessment remains on a record. An incorrect indicator continues to drive a block. A debt is withdrawn without correcting the information used by another agency. The institution needs to follow the relevant consequences within its authority.

The record should identify which decisions depended on the disputed evidence. If those links were never retained, the organisation may need a broader review rather than treating poor traceability as a reason to do nothing. The burden of reconstructing the problem should reflect who controlled the process that produced it. The remedy also needs somebody responsible for carrying it out. An independent reviewer may recommend a change without having authority to make it. The institution should state whether it accepts the recommendation, what will happen and how completion can be checked. A filed recommendation is not a corrected service.

The public should be able to distinguish a complaint received, an allegation established, a remedy ordered and a remedy delivered. Each describes progress but none substitutes for the next. That distinction should apply to this essay’s own accounts of settlements and regulatory announcements. A demand for accountability can itself become unreasonable. Repeatedly investigating settled questions without new evidence can consume resources needed for other people. Public access to every internal message can violate privacy and prevent honest discussion. A system needs a way to close a properly examined matter while remaining open to important new evidence.

The criteria should be understandable. A person should know why further review is unavailable and what kind of new information would justify reopening it. An institution should not use a label such as vexatious merely because a question is embarrassing or persistent. The conduct and evidentiary basis need to support the decision. The same duty applies to the critic. A disputed interpretation should remain attributed. An unavailable source should not become a confident reconstruction. A corrected account should replace the attractive but unsupported version including where the correction weakens the accusation. I want people to be able to find out what happened without needing an extraordinary capacity for personal sacrifice. That requires legitimate access, competent review and a route from findings to action. It also requires discipline from those making the allegation. Otherwise the process transfers uncertainty and work between people without establishing a result anyone should rely on.

28. An institution that can be corrected

I do not expect institutions to stop making mistakes. I expect them to recognise mistakes, change their behaviour and repair the consequences without requiring every affected person to win an exhausting campaign. That capacity needs more than a complaints address. Someone must be able to inspect the evidence, question the relevant decision and require a response. The process needs resources and a route around the people whose conduct is being examined. It also needs a way to reject an unsupported complaint fairly. Start with the path a concern follows. Does it reach someone who understands the subject? Can that person obtain the necessary records? Do they know which decision is disputed? Can they protect the affected person while the investigation continues? Is there an actual date for a substantive answer and what happens when that date cannot be met? These are practical questions. They belong beside incident response and service management because a challenge process is part of how the institution handles failure. Repeated delay in giving reasons can leave a person carrying the consequences without a usable explanation. The process should also preserve evidence. An institution cannot fairly require a detailed challenge while withholding or losing the records needed to make it. Privacy and confidentiality may require restricted disclosure, independent inspection or redaction. They should not become blanket words that make the original decision impossible to examine.

The same scrutiny applies to the remedy’s own power. A regulator can become overly dependent on the industry it oversees, exclude new entrants through rigid requirements or mistake compliance machinery for real protection. A public funder can reward familiar institutions. A professional body can defend its members more effectively than the people relying on them. Those possibilities are reasons to constrain oversight, not to abandon it. Mandates should be clear, reasons available, conflicts disclosed and important decisions reviewable. Institutions enforcing responsibility should be evaluated against the outcomes they claim to improve.

The cases already discussed include real consequences. Courts made findings, regulators imposed penalties and orders required changes. That matters, even though some remedies may still have arrived too late or fallen short. This also means allowing institutions to correct themselves without treating every admission as proof that cooperation was foolish. Concealment should not be the safer strategy. Prompt disclosure, preservation of evidence and competent remediation should matter when conduct is assessed, alongside the seriousness of the original failure.

An evaluation can establish that a feature exists while failing to establish that the buyer can operate it. A supplier might demonstrate a recovery process using specialist staff and an environment the purchaser cannot reproduce. A security control might be available only in an edition excluded from the quote. The proposal should identify the actual configuration, responsibilities and support included in the price. The buyer should test important workflows before the dependency becomes difficult to reverse. Restore a representative backup. Export a useful dataset and have an independent recipient interpret it. Apply an update under the intended maintenance process. Attempt account recovery after the assumed authentication channel is unavailable. These tests should use authorised, safe environments and acceptance criteria related to the service being bought.

No procurement process can test every future condition. It can identify the assumptions behind the purchase and specify who must respond if they stop being true. A service promise should be tied to the supplier’s actual ability, the available remedy and the evidence needed to decide whether the promise was kept. The buyer also needs to assess its own capacity. A product designed for continuous specialist administration may be unsuitable for an organisation with occasional support. The product may be sound while the purchase is still wrong for that organisation.

A requirement should therefore distinguish a necessary outcome from a preferred implementation. Overprescriptive procurement can exclude a better or smaller supplier. Underspecified procurement can admit proposals that appear equivalent only because important costs are hidden. A good specification explains the result that matters and the evidence by which alternatives will be judged. An independent assessor can provide a useful check. A separate logo does not create independence. The relationship should disclose who pays, who selects the assessor, what evidence can be examined and whether the result can be published or challenged. Relevant expertise matters as much as formal separation.

Payment by the assessed organisation creates a possible conflict, not proof of dishonesty. Other funding models create conflicts too. Safeguards should address the real incentives through a clear scope, reviewable methods, limits on misleading claims and a route for serious concerns to reach someone able to act. An audit should state what it did not examine. That limitation should survive marketing use. A supplier should not turn a limited assessment of one configuration into a general claim about every product and deployment. The assessor has a role in preventing that misrepresentation and the purchaser has a role in reading the actual scope. The same standards apply to regulators. A regulator can lack staff, technical knowledge or effective powers. Expanding its mandate without supplying capacity might create an expectation of protection it cannot deliver. Its performance should be evaluated through outcomes, response quality and the costs it imposes. The number of rules or enforcement announcements says little by itself.

A correction programme should make the remedy easier to obtain than the original failure was to suffer. A process that asks each affected person to reconstruct records the institution already holds can turn compensation into another test of persistence. Eligibility still needs evidence. The institution should identify which facts are necessary, which it can establish itself and which reasonable alternatives can resolve uncertainty. A requirement should not exist merely because a form can ask for it. The costs of fraud prevention and of excluding valid claims both matter.

Case-by-case correction can hide a common failure. If each person must prove the same defect alone, the institution may treat every result as an exception and never examine the rule producing them. Collective complaints, representative organisations, ombudsmen, regulators and group proceedings can combine evidence and obtain remedies that one person could not pursue. They have limits of their own. A representative can misunderstand a subgroup, a settlement can leave important individual needs unresolved and a public process can expose private information. Collective action should reveal the pattern without erasing the people within it. An institution needs both a route for one person’s case and a way to recognise when that case is evidence about the system.

Remedies should also be assessed for completion. Announcing a fund differs from paying claims. Publishing a new procedure differs from staff being able to use it. Supplying an export differs from a customer completing a migration. The evidence should follow the outcome the intervention was meant to achieve. This does not require perfection before any improvement is recognised. A partial remedy can reduce harm. It should be described as partial, with the remaining problem and responsible actor identified. Overstating success can remove the pressure and resources needed to finish the work. An institution should also correct remedies that perform poorly. A support duty may impose unreasonable costs on low-risk products. A disclosure rule may expose information it was meant to protect. An assessment framework may reject relevant evidence because its examples were too narrow. The response should examine why the problem occurs instead of abandoning the goal. Narrowing a requirement can preserve its benefit while reducing an unintended burden. A pilot can test whether the distinction is usable. Review dates can prompt examination. Time passing does not tell us whether the rule remains necessary.

Institutions need enough stability for people to plan. Constantly changing requirements create waste and insecurity. A disruptive change should account for people’s reliance on the current system, while the reasons for keeping it remain open to challenge. A corrected institution is therefore neither permanently rigid nor endlessly experimental. It has a way to preserve what works, identify what does not and change the relevant part without making everyone start again.

An accountable institution can be firm. It can refuse a request that exceeds its role, reject an unsupported allegation or decide between genuinely competing interests. What it should not do is make its own assertion the end of the process because challenging it would be inconvenient. The aim is a system capable of changing its mind for good reasons and acting on the change. That is a more useful form of strength than an appearance of certainty maintained until somebody else pays to break it.

29. What responsibility requires

I dislike the phrase “take responsibility” when nobody specifies the work. An organisation can endorse it without changing a budget, a decision right or a contract. Before creating a dependency, the provider should explain what the system is meant to do, its important limits, the support offered and what happens when the relationship changes. A sales page does not need every implementation detail. It should not win trust by hiding a fact that would change the decision.

When a serious failure is reasonably foreseeable, the people in control should take precautions suited to the risk. Those precautions need evidence and an account of any new risks they introduce. A security claim should name the protection. A reliability claim should survive the recovery conditions that matter. A learning claim should concern what the student can actually understand or do. The work promised must be feasible. That means people, funding, procedures and boundaries. A service-level commitment without sufficient staffing is a hope written into a contract. A duty assigned to a volunteer without their agreement is a demand disguised as public interest. An employer requiring independent judgement while giving nobody permission to delay an unsafe change has created a contradiction in its operating model.

Important decisions should be explainable at a level that permits meaningful challenge. The evidence needs to remain available under appropriate privacy and security controls. A person does not need access to everybody else’s records to deserve reasons for what happened to them. An independent reviewer may need more access than the public. Those distinctions should be designed deliberately. Where the system fails, correction must address consequences. Updating the source record, publishing a patch or revising a policy can be necessary without completing the remedy. The affected person may need restoration, repayment, migration, independent advice or protection while the correction takes effect.

Continuity also needs an owner. Support through retirement should reflect the reliance the institution encouraged and the control it retained. This does not require feature development forever. It requires an understandable ending suited to what people were led to depend on. Institutions relying on competence should also help make competence possible. Education providers need to teach and assess well. Employers need workable routes for people to gain experience. Public services must accommodate the people entitled to use them and communities need honest participation limits that their maintainers can sustain. These are ethical and design commitments. Legal duties vary between jurisdictions and do not need to enforce every expectation in the same way.

Dividing responsibility should begin with particular questions. Who made the promise? Who caused or knowingly sustained the risk? What was foreseeable? Who now controls the remedy? What can each person or organisation reasonably do? Who will otherwise bear the consequences without choosing them? The answers can divide responsibility. The supplier may own a design defect, the operator a dangerous configuration and the regulator a failure of oversight. A researcher may have a responsibility to disclose safely without acquiring responsibility for the defect itself. An affected person may reasonably need an interim remedy before every dispute between the institutions is resolved.

Responsibility for prevention, correction, compensation and punishment should not be collapsed. A customer can deserve replacement of a defective product without proving malice. Serious concealment can deserve consequences beyond merely supplying the fix that should have been offered. Honest error following reasonable care may call for a different response from deliberate disregard of known harm. A breach alone cannot settle those distinctions. Nor can an absence of visible failure prove that an organisation acted well. Luck and limited observation are poor substitutes for evidence about conduct.

Consider a difficult support case. A small supplier has sold a product people reasonably expect to use for several years. Its operating costs rise, a critical employee leaves and the current support model becomes unsustainable. The users’ needs are real. So are the staff’s interests and the limits of the business. The answer should not be an automatic demand that the remaining engineer work indefinitely for free. Nor should insolvency or commercial discomfort retrospectively make every promise meaningless. The feasible alternatives might include a funded maintenance period, transfer to another provider, release of necessary documentation, a reduced safe service, replacement or a refund within applicable obligations.

Some options may fail. Releasing source will not manufacture expertise. Transferring keys can create security risks. A refund might not cover the customer’s full transition cost. The decision needs to compare those limitations openly rather than describe the supplier’s preferred exit as the only conceivable one. Planning earlier can improve the choices. Support reserves, documented interfaces, dependency agreements and realistic pricing can reduce the chance that every obligation arrives at the same exhausted person. The point is not that all failures can be predicted. It is that foreseeable lifecycle work should be part of the product, rather than a charity appeal after the sale.

A regulation imposing those expectations also needs to be affordable to comply with. A complex certification regime can protect large incumbents by making responsible small-scale work prohibitively expensive. Shared test facilities, clear requirements, reusable evidence and duties matched to consequences can be better than requiring every supplier to construct an entire compliance department. The state is not exempt from the same discipline. A public programme needs a clear goal, resources, assessment and a way to change or end it when it fails. Public ownership can change incentives without making competence, transparency or fair treatment automatic. A regulator can cause harm through a poor rule as surely as a company can through a poor product. I do not want accountability to become a new industry of paperwork that ordinary people must navigate before receiving help. The evidence and process should match the decision. A straightforward error should be correctable without litigation; a contested serious allegation deserves a more demanding examination.

Doing this properly costs money. Some products may become more expensive. Speculative features may wait while maintenance is funded. Institutions may have to promise less. Those outcomes can be acceptable when the old price depended on other people absorbing work that the budget ignored. They can also be unacceptable if a proposed rule adds more burden than protection. That is why remedies need evaluation. What capability improved? Who now has access? Which costs fell, which rose and who paid them? Did the intervention remove a barrier or merely move it? What evidence would make us revise the policy?

A responsibility should specify an actor, an action and the circumstances that trigger it. A declaration that everyone is responsible can leave each participant waiting for someone else. A declaration that one person is responsible can be equally empty if that person has no authority over the necessary resources. Prevention, explanation, correction and compensation are different duties. A developer may be able to correct code but unable to compensate a customer’s loss. A supplier may owe the customer a remedy while a contractor performs the repair. A public authority may need to explain a decision even where the technical defect originated elsewhere. Those duties should follow the relationship and actual ability to act, not stop at the first convenient individual.

For a product sold as dependable, the organisation should know who receives reports, who can halt a damaging deployment, who funds repairs and who communicates with affected people. The process should still work when the original project lead is absent. Responsibility that depends on one person’s goodwill is fragile. For education, the institution should identify who can resolve an assessment gap, approve an adjustment and correct an administrative delay. For a shared project, the governance should identify who may make a release, change the rules and arrange continuity. The duties differ but their feasibility needs the same examination.

Some improvements will cost more. An honest argument should say so. Longer support, competent teaching, accessible services and sufficient review capacity require work that somebody must fund. The comparison should include costs borne outside the institution’s accounts. A cheap service can require substantial unpaid assistance from families. A low-priced product can impose an early replacement bill. A course with low administrative expenditure can consume students’ time through avoidable confusion. Moving those costs into a visible budget can make the service appear more expensive while reducing the total burden.

Not every proposed expenditure is worthwhile. The intervention should identify the outcome, the alternatives and the people paying. A well-intentioned measure can consume resources that would protect more people elsewhere. Providers can capture a public programme. A subsidy can preserve an ineffective process instead of improving it. The proposal should include a way to discover failure. What will the programme measure? What will that measure miss? Who can report a problem? Which conditions would justify changing or ending the programme? Evaluation belongs in the budget. Its paperwork should remain reasonable.

A safer design may require retraining, migration and temporary parallel operation. The work should identify those costs and the risk created during transition. A replacement that is better in isolation can still be introduced badly. Staging can help. A new component can begin with a limited role, retain a reversible path and expand only when evidence supports it. An old system may need interim controls while the migration proceeds. The organisation should state who accepts that interim risk and which milestones demonstrate that the transition is real.

A roadmap without resources is an intention. Repeatedly moving its dates without examining the cause can turn it into an excuse. Conversely, a delay can be justified when evidence shows that the proposed deployment would create greater harm. The decision should explain what changed and how the people relying on the plan remain protected. Practical alternatives matter here. A critic need not build an entire replacement before identifying a defect. Once somebody proposes a replacement, they need evidence that it is better and a path from the current system to the new one.

A requirement should do enough to protect the relevant interest without turning every activity into a regulated enterprise. A hobbyist sharing an experiment should be able to state its limits and decline support. A company selling a critical service should not be able to borrow that informal status while encouraging customers to depend on it. Base the distinction on what was promised, how the activity is organised and what reliance on it means. A licence label or a payment called a donation cannot decide that alone. A large commercial operation and a small voluntary project can use the same component under fundamentally different relationships.

Across these cases I keep finding the same structures even though their causes differ. A partial record is treated as the whole event. Authority is held in one place while responsibility is assigned somewhere else. A promise is made without the people, money or exit needed to keep it. A formal permission is offered without a practical way to use it. A correction reaches the original record but not the decisions that inherited it. A cost disappears from one budget by entering somebody else’s life. These are not one theory of every failure and they do not prove bad intent. They are reasons to stop accepting the first neat account of a system. When several appear together, blaming the nearest individual is unlikely to repair the arrangement that produced them.

Clear, limited duties can protect both sides. The supplier knows what it has undertaken. The user knows what to expect and what remains their responsibility. Where neither can bear a foreseeable serious risk alone, they may need insurance, pooled support, a different supplier or a decision not to deploy. Some projects should remain experiments. Some purchases should not proceed. An institution should be able to reach those conclusions without treating them as failures of ambition. Refusing to create an unsupported dependency can be the responsible technical decision.

The commitment should be to the people and the purpose, not to preserving our preferred reform after it stops serving them. A measure should change when good evidence shows a better alternative. An institution should not declare the question closed because the people in control are familiar with the current system.

30. An ordinary life

A person can be offered a freedom that takes extraordinary effort to use. The source is available but building it requires an undocumented environment. A decision can be challenged but the institution holds the evidence. An account can be closed but the work inside cannot be moved without heavy loss. A qualification can be obtained while its assessment process remains unclear. Each of those situations needs its own investigation. Together they identify the distance between a formal permission and a capability someone can reasonably exercise. I do not want independence to mean that everyone must become a programmer, administrator, lawyer and persistent complainant before they can participate safely. People should be able to rely on expertise. They should be able to choose a convenient service, accept help and concentrate on work they understand without surrendering every practical protection against a failure elsewhere. That is why the obligations in this essay concern relationships as well as products. A supplier’s promise, a public authority’s mandate, a teacher’s assessment and a maintainer’s voluntary contribution create different expectations. Treating them identically would obscure the work each has actually undertaken. Treating none of them as answerable would leave the consequences with whoever had the least ability to refuse them.

The person affected should have a practical route to an explanation and remedy. Somebody needs enough evidence and authority to act. The person should not have to become a public example before the institution examines what happened. Every institution has limits and some losses cannot be fully repaired. Some decisions remain contested after careful examination. A fair process can reject a claim. Explain those limits through the actual case instead of using them to shield every established system from scrutiny.

The people doing the work need protection too. A maintainer should be able to stop. A teacher needs time to prepare and respond. A reviewer needs a manageable queue. An engineer needs a way to raise a concern and someone with authority to act on it. An organisation should not promise dependable provision while making it depend on indefinite personal sacrifice. The argument must also recognise improvements. A manufacturer providing a usable handover, a project making its builds independently checkable, a court correcting an organisation’s claim and a course improving demonstrated learning are all evidence. They reveal alternatives and narrow accusations. An argument that treats every improvement as another reason for condemnation has become unwilling to learn. I have changed parts of this argument when the evidence required it. A licensing definition can be useful without supplying a complete ethical theory. A company can bear enormous losses and still have poor controls. An educational intervention can improve one outcome without improving another. A person’s account can reveal a problem without showing how common it is. Those distinctions make the conclusions more demanding because they require attention to what actually happened.

The demands on the critic are not exceptional. A source should support the claim attached to it. A test should establish the behaviour described. An inaccessible record should remain inaccessible, rather than be replaced with a plausible reconstruction. Where the accusation exceeds the evidence, the accusation should narrow or leave the work. The prose and its sources must be examined before publication under a person’s name. A convincing account of care would be a poor place to excuse an unsupported claim because checking it was inconvenient.

That standard applies to what I build and publish. I need to keep the evidence near a consequential claim, state which part I verified and correct the public record when I get it wrong. Software I release should make its important limits visible, keep ordinary operations proportionate and leave another person enough knowledge to maintain or replace it. A proposal for a new institution should identify who will do the work, what authority they need, how they can be challenged and what happens when the arrangement should end. I cannot demand those answers from everybody else then hide behind good intentions when the work is mine.

I will still make mistakes. Some things I build will be replaced by better work and some positions here will change. The useful commitment is not to defend every earlier choice. It is to make correction possible without erasing what happened, to fund maintenance when I create dependence and to leave people with more practical control than the system I am criticising. Writing this is one part of that responsibility. Building alternatives, testing them against people unlike me and accepting a sound correction are the harder parts.

The object of the work is larger than better compliance. Someone should be able to learn without proving in advance that the subject will make them profitable. They should be able to make a small program for enjoyment, use a paid tool because it suits them, preserve work for someone else or decline a technology they do not need. People have different purposes. A humane system should leave room for them. It should also leave room to finish. A tool can help a person complete a task and go elsewhere. A gain in efficiency can provide time they are allowed to keep. Rest, relationships and curiosity do not need to produce a commercial metric before they count as benefits.

The image at the beginning still matters to me. The materials did not become computers by themselves. Knowledge was developed, tested, shared and taught. People built on work they did not originate. They depended on others and left things for others to continue. That achievement does not make institutions easy to govern. It shows why the conditions for continuing the work deserve attention. Useful technology needs people who can learn it, maintain it, question it and obtain a response when its claims fail. I am angry at the decisions that make those ordinary expectations needlessly difficult. At preventable hazards defended through habit. At control retained after responsibility has been disclaimed. At evidence withheld from the person required to disprove it. At necessary work treated as free because its cost has been left in someone else’s life. The answer should be more specific than asking everyone to care. Identify the duty. Give the responsible person the authority and resources to fulfil it. Preserve a way to establish whether it was fulfilled. Correct the result when it was not and examine the proposed correction with the same seriousness.

Humans create software for humans. Its institutions should remain answerable to the people whose lives they shape. I am angry because there is so much worth doing properly. I want responsibility to continue after the product ships, the contract is signed and the people making the decision have moved on.

United Nations, Global Digital Compact, adopted 22 September 2024; Office of the UN High Commissioner for Human Rights, Business and Human Rights Knowledge Hub, which includes the UN Guiding Principles on Business and Human Rights. ↩
High Court of Justice (England and Wales), Bates and Others v Post Office Ltd (Horizon Issues), [2019] EWHC 3408 (QB), 16 December 2019: official judgment page, especially paragraphs 534 to 540 of the judgment. ↩
Post Office Horizon IT Inquiry, Volume 1 of the final report, 8 July 2025, concerning human impact and redress: reports and statements; In Your Own Words, the Inquiry’s listening project. ↩
Royal Commission into the Robodebt Scheme, Report, 7 July 2023, corrected 11 July 2023: report and published recommendations. ↩
Australian Public Service Commission, “Statement from the Australian Public Service Commissioner on the Robodebt Centralised Code of Conduct Inquiry”, 13 September 2024: official statement. ↩
US Securities and Exchange Commission, “SEC Charges Knight Capital With Violations of Market Access Rule”, 16 October 2013; In the Matter of Knight Capital Americas LLC, Exchange Act Release 70694, Administrative Proceeding 3-15570, settled administrative order, especially paragraphs 15 to 19. ↩
CrowdStrike, “Channel File 291 Incident: Root Cause Analysis is Available”, 6 August 2024: supplier announcement. ↩
Australian Communications and Media Authority, “Optus pays $12 million penalty for Triple Zero outage”, 8 November 2024: regulatory announcement. ↩
US Government Accountability Office, Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia, IMTEC-92-26, 4 February 1992, publicly released 27 February 1992. ↩
CISA and FBI, “CISA and FBI Release Secure by Design Alert to Urge Manufacturers to Eliminate SQL Injection Vulnerabilities”, 25 March 2024: alert. ↩
OWASP Cheat Sheet Series, “SQL Injection Prevention Cheat Sheet”, particularly prepared statements and the discussion of query elements that cannot use bind variables: guidance. ↩ ↩²
CISA and FBI, “CISA and FBI Release Updated Guidance on Product Security Bad Practices”, 17 January 2025: guidance announcement. ↩
CERT-FR, “Incident de sécurité ciblant les contrôleurs à distance des installations de réfrigération”, CERTFR-2026-ALE-012, issued 12 October 2026 and updated 16 October 2026. ↩
NIST, Guide to Operational Technology (OT) Security, Special Publication 800-82 Revision 3, September 2023. ↩
Nancy G. Leveson and Clark S. Turner, “An Investigation of the Therac-25 Accidents”, Computer 26(7), July 1993, pages 18 to 41, doi:10.1109/MC.1993.274940. ↩
Y. Rekhter, T. Li and S. Hares, eds., A Border Gateway Protocol 4 (BGP-4), RFC 4271, January 2006. ↩
RIPE NCC, “YouTube Hijacking: A RIPE NCC RIS case study”, 17 March 2008, examining the incident of 24 February 2008: case study. ↩
IETF, BGP Prefix Origin Validation, RFC 6811, January 2013. ↩
IETF, BGPsec Protocol Specification, RFC 8205, September 2017. ↩
IETF, Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, RFC 9234, May 2022. ↩
Bryton Herdes, Iliana Xygkou and Mingwei Zhang, “BGP Role model: tracking the adoption of RFC 9234”, Cloudflare, 18 August 2026: implementation survey. ↩
Martin Thomson and David Schinazi, Maintaining Robust Protocols, RFC 9413, June 2023. IAB informational document. ↩
Valve, Steam Subscriber Agreement, section 2.A: published terms. ↩
Australian Competition and Consumer Commission, “Contracts”: official guidance on standard-form and unfair contract terms. ↩
Australian Competition and Consumer Commission, “High Court dismisses Valve’s special leave to appeal application”, 20 April 2018. Regulator announcement. ↩
US Federal Trade Commission, “FTC Finalizes Order Requiring Fortnite maker Epic Games to Pay $245 Million for Tricking Users into Making Unwanted Charges”, 14 March 2023: final-order announcement. ↩
US Federal Trade Commission, “FTC Finalizes Order with Avast Banning it from Selling or Licensing Web Browsing Data for Advertising and Requiring it to Pay $16.5 Million”, June 2024: final-order announcement. ↩
Australian Competition and Consumer Commission, “Regulatory reform in digital platform markets is needed to improve competition and consumer outcomes”, 23 June 2025: official summary of the final inquiry report. ↩
United Nations, Global Digital Compact, adopted 22 September 2024, especially the commitments on information integrity; W3C, Ethical Web Principles, W3C Statement, 12 December 2024. ↩
UK Competition and Markets Authority, Cloud services market investigation, final decision 31 July 2025: case page and final report. ↩
UK Competition and Markets Authority, “CMA announces package of actions on business software and cloud services”, 31 March 2026: press release. ↩
House of Commons Committee of Public Accounts, Digital transformation in government: addressing the barriers to efficiency, report published 13 September 2023. Report. ↩
NIST, Digital Identity Guidelines: Authentication and Authenticator Management, SP 800-63B-4, July 2025. Guideline. ↩ ↩²
Office of the Australian Information Commissioner, Australian Privacy Principles Guidelines, Chapter 3, “Collection of solicited personal information”, version updated 13 May 2026. Guidance. ↩
UNICEF, Convention on the Rights of the Child, which links to the UN Committee on the Rights of the Child’s General Comment No. 25 on children’s rights in relation to the digital environment. ↩
The Rust Project, The Rust Programming Language, “Unsafe Rust”: chapter. ↩
Tim Bray, ed., The JavaScript Object Notation (JSON) Data Interchange Format, RFC 8259, December 2017, section 4. ↩
The PHP Foundation, “Today’s PHP Security Release, and How We’re Strengthening PHP Security”, 21 October 2026. ↩
PHP project security advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, published 21 October 2026. ↩
The PHP Foundation, disclosure chronology; Amazon Threat Intelligence, “PHP2Shell exploitation prior to public disclosure”, 21 October 2026.

Scope: AWS observed attempts against its sensors. It did not establish successful compromise of an ordinary production deployment or how the 17 October actor obtained exploit information. ↩
Cisco, “Transition to a Risk-Based Vulnerability Disclosure Model” and “Secure Email Gateway and Secure Email and Web Manager Security Hardening Release: September 2026”. ↩
CVE Program, CVE Numbering Authority Operational Rules, sections 4.1.9, 4.2.6, 4.2.11 to 4.2.12 and 5.1.1 to 5.1.7. ↩
BeyondTrust, “ARMORY CASTLE and BT26-05: What Security Teams Need to Know” and security advisory BT26-05, updated 16 October 2026. ↩
XZ Utils project, project and security history; Red Hat, CVE-2024-3094, last modified 4 August 2026. ↩
GitHub, “Our plan for a more secure npm supply chain”, 22 September 2025; GitHub, “Strengthening supply chain security: Preparing for the next malware campaign”, 23 December 2025; GitHub, “Disrupting supply chain attacks on npm and GitHub Actions”, 28 July 2026. ↩
LiteLLM, “Security Townhall Updates”, 27 March 2026. ↩
LiteLLM, “Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised” and “The attack chain behind the v1.107.0 LiteLLM release”, 21 and 23 October 2026. ↩
Mozilla, “eMudhra: Private key compromise of Intermediate Certificates”; Scott Helme, “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds”, 20 October 2026; Google Chrome Security, “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates”, 20 October 2026; eMudhra, incident statement, updated 21 October 2026.

Scope: The public incident remains under investigation. The sources establish recoverable intermediate keys, trust-store response and eMudhra’s preliminary account. They report no known end-entity certificates or malicious use from the affected intermediates. ↩
OpenSSF, Supply-chain Levels for Software Artifacts, version 1.2, “Build requirements”. Requirements. ↩
Reproducible Builds, “Definitions”. Definition. ↩
Andreas Kling, “Changing how we develop Ladybird”, 5 June 2026: project announcement. ↩
Daniel Stenberg’s first-party accounts of curl’s 2026 vulnerability-reporting changes: “The end of the curl bug-bounty”, “High-Quality Chaos”, “curl summer of bliss” and “What the bliss taught us”. ↩ ↩²
UK Information Commissioner’s Office, “Data protection and monitoring workers”: guidance. ↩
International Labour Organization, World Employment and Social Outlook 2021: The role of digital labour platforms in transforming the world of work, 2021: repository record and abstract and official summary page. ↩
International Labour Organization, “Fundamental Principles and Rights at Work”, which includes freedom of association and effective recognition of the right to collective bargaining. ↩
Mozilla, State of Mozilla 2025: Investing in a rebel alliance, which gives its portfolio figures and planned 2026 investment. ↩
Susan Dynarski, C.J. Libassi, Katherine Michelmore and Stephanie Owen, Closing the Gap: The Effect of a Targeted, Tuition-Free Promise on College Choices of High-Achieving, Low-Income Students, NBER Working Paper 25349, December 2018, revised June 2020. ↩
Elizabeth Burland and colleagues, Degrees of Mobility: Shifting Low-Income Students to Higher Quality Colleges, NBER Working Paper 35434, July 2026. ↩ ↩²
Australian Government, StudyAssist, “HECS-HELP”: scheme explanation and “Commonwealth supported places (CSPs)”: explanation. ↩
Australian Government, Department of Employment and Workplace Relations, “Free TAFE”: programme explanation. ↩
Scott Freeman and colleagues, “Active learning increases student performance in science, engineering, and mathematics”, PNAS 111(23), 8410 to 8415, 2014. ↩
Quality Indicators for Learning and Teaching, Student Experience Survey, 2025 national results. ↩
Louis Deslauriers, Logan S. McCarty, Kelly Miller, Kristina Callaghan and Greg Kestin, “Measuring actual learning versus feeling of learning in response to being actively engaged in the classroom”, PNAS 116(39), pages 19251 to 19257, 2019. ↩
Zen Dodd, Submission on the CyberPath Capability Framework Discussion Paper V0.1, 10 September 2026, especially sections 4, 5 and 10. Published page. ↩
Callam Pickering, “Nice Try, AI: Australian Graduates Are Still Getting Hired”, Indeed Hiring Lab, 22 April 2026: analysis. ↩
Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab, 2025, revised 12 August 2026: publication page and author-linked discussion. ↩
Court of Justice of the European Union, Public.Resource.Org and Right to Know v Commission, Case C-588/21 P, 5 March 2024, ECLI:EU:C:2024:201, especially paragraphs 65 to 90: judgment. ↩
UNESCO, “Open science”, explaining the 2021 Recommendation and its scope: framework. ↩
San Francisco Declaration on Research Assessment, “Read the Declaration”: DORA text, especially the general recommendation and recommendations to funders and institutions. ↩ ↩²
US National Institutes of Health, “NIH Public Access Policy Overview”, describing the 2024 policy effective for applicable manuscripts accepted from 1 July 2025. Overview. ↩
International Telecommunication Union, “Global number of Internet users increases, but disparities deepen key digital divides”, 17 November 2025: release of 2025 estimates. ↩
WebAIM, The WebAIM Million, 2026 results: study and limitations. ↩
NIST, Face Recognition Technology Evaluation: Demographic Effects in Face Recognition, current results and report index; Australian Human Rights Commission, Human Rights and Technology: Final Report, 2021. ↩
W3C Internationalization, “Personal names around the world”: guidance. ↩
Federal Trade Commission, “FTC Report to Congress Examines Anti-Competitive Repair Restrictions, Recommends Ways to Expand Consumers’ Repair Options”, May 2021: official summary. See also the Nixing the Fix report page. ↩
European Union, Regulation (EU) 2024/2847, Cyber Resilience Act, 23 October 2024: official text. ↩
Australian Competition and Consumer Commission, “Consumer rights and guarantees”: official guidance. ↩
Australian Competition and Consumer Commission, “iPhone and iPad misrepresentations cost Apple Inc $9 million in penalties”, 19 June 2018. Regulator account. ↩
Australian Competition and Consumer Commission, “About the Motor Vehicle Information Scheme”. Scheme explanation and industry guidance. ↩
Open Source Initiative, The Open Source Definition, version 1.9: definition. ↩
Meta, Llama 4 Community License and “Space Llama: Meta’s Open Source AI Model Is Heading Into Orbit”, 25 April 2025; Open Source Initiative, “Meta’s LLaMa license is still not Open Source”, 18 February 2025. ↩
GNU Project / Free Software Foundation, “What is Free Software?”. ↩ ↩²
GNU Project / Free Software Foundation, “What is Copyleft?”: explanation. ↩
Global Indigenous Data Alliance, “CARE Principles for Indigenous Data Governance”: framework and explanation. ↩
Apache Software Foundation, “How the ASF works”, especially the account of the board, Project Management Committees and individual roles. Governance description. ↩
Jeffrey Darlington, Andy Finney and Adrian Pearce, “Domesday Redux: The Rescue of the BBC Domesday Project Videodiscs”, Ariadne 36, 30 July 2003. ↩
Library of Congress, “Sustainability Factors”, Sustainability of Digital Formats: criteria. ↩
SQLite, “File Format Changes in SQLite”: documentation. ↩
SQLite, “Long Term Support”: statement. ↩
ITU and UNITAR, “Electronic waste is growing five times faster than documented e-waste recycling, UN report finds”, 20 March 2024, reporting the Global E-waste Monitor 2024: release and report links. ↩
United Nations Environment Programme and International Resource Panel, Global Resources Outlook 2024, 1 March 2024. ↩
Mauro Cordella, Felice Alfieri and Javier Vicente Sanfelix Forner, “Reducing the carbon footprint of ICT products through material efficiency strategies: a life cycle analysis of smartphones”, Joint Research Centre publication JRC124077, 2021. ↩
European Commission, “Smartphones and Tablets”: official explanation, covering Regulations (EU) 2023/1670 and 2023/1669 and applicability from 20 June 2025. ↩
US Department of Justice, “Department of Justice Announces New Policy for Charging Cases under the Computer Fraud and Abuse Act”, 19 May 2022: historical policy announcement. ↩
Cyberdione Labs, Tailworm security assessment of Tailscale v1.104.2 and headscale v0.29.5, 25 October 2026; Mike Shaver, Tailscale Vice President of Engineering, “Recent Tailscale vulnerability reports”, 25 October 2026; Tailscale, “Security at Tailscale”; Swati Khandelwal, “Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers”, The Hacker News, 25 October 2026.

Scope: The technical findings had not been independently reproduced or fully confirmed by Tailscale at publication. The Hacker News reports that the complete proof-of-concept code was shared privately rather than published. The public report itself contains extensive reproduction detail. The status and chronology reflect records available on 26 October 2026. ↩
Utku Sen, “I’m Sorry For Hidden Tear and EDA2”, 21 August 2017; Jornt van der Wiel, “Hidden tear and its spin offs”, Kaspersky Securelist, 2 February 2016; WatchGuard, “Hidden Tear”; Microsoft Security Intelligence, “Ransom:MSIL/Ryzerlo threat description”.

Scope: Sen’s retrospective establishes his stated purposes and judgement of the experiment. The independent analyses establish reuse in operational ransomware variants rather than a complete count of resulting infections or losses. ↩

Contents