Summary

  • On 9 September, the UK government said it would prepare legislation intended to make it impossible for under-18s to take, view or send nude images across device features, including cameras and third-party apps.
  • The announcement follows three months of talks with Apple and Google. The government said there had been progress, but not enough to meet its ambition; it also left open reassessing legislation if companies implement solutions voluntarily.
  • No bill, liable-actor list, regulator, test protocol, privacy design or compliance timetable accompanied the announcement. Existing Ofcom age-assurance duties apply to in-scope online services and cannot simply be presumed to govern device-local capture.
  • A cross-layer capability-obligation map should state, for every action, who controls it, who issues and consumes the age signal, where imagery is processed, who retains evidence and how a mistaken decision is corrected across the stack.

One promise, several machines

The 9 September announcement uses three short verbs: take, view and send. It says a person under 18 should be unable to perform any of them with a nude image. Protection should cover every device feature, including the camera and third-party apps; detection should be on by default; an adult should unlock the capability only through robust age assurance.

Each verb travels through a different control surface. “Take” may begin in a camera application but depend on an image-signal processor, operating-system permissions and local storage. “View” can mean opening a gallery file, rendering a browser page, receiving an attachment or displaying a cloud-backed preview. “Send” may use an operating-system share sheet, an app-owned composer, a remote service or an encrypted channel whose provider does not see the media in the same form as the endpoint.

The government has therefore announced an ecosystem outcome, not merely an app feature. It says it will legislate for device-level protections and, in a separately qualified statement, that it is exploring legislation that could apply to apps used by children. Those are different policy states. Neither identifies which participant must stop which action when device maker, operating-system provider, app developer, age-assurance supplier, cloud service, retailer and user account are not controlled by the same organisation.

That distinction matters before the argument reaches technical preferences. The current record does not mandate on-device processing, cloud scanning, a particular model, an exception list or any change to encryption. It does not say how existing devices will receive protection, although the 8 June announcement said the ambition covered existing and newly sold UK smartphones and tablets and could reach operating-system providers and other supply-chain actors, including retailers. A promise this broad needs an actor-by-action map before anyone can test compliance.

The three-month clock ended in a legislative state, not an operating one

On 8 June, the government gave technology companies three months to act. It named Apple and Google and described gaps across the camera, broader apps, third-party messaging and search. On 9 September, it said negotiations had produced progress but not progress matching the scale of its ambition. The government then announced that legislation would be brought forward “as soon as possible.”

That sequence should be reported precisely. It is not proof that either company violated a legal duty that did not yet exist. It is not a completed enforcement finding, and it does not establish the capability of every product or version. Nor is the decision irreversible: the government says it will reassess whether legislation is necessary if companies implement solutions themselves.

The observable state is narrower. A voluntary phase produced changes the government judged insufficient; the policy moved to legislative preparation; the public still lacks draft clauses, dates, accountable regulators and an implementation test. The government's own children and young people's summary states the constitutional boundary plainly for its wider programme: Parliament must approve new laws before plans take effect.

That leaves a useful space for scrutiny. The question is not whether the objective sounds protective. It is whether the eventual legal instrument can join the layers it invokes without allowing responsibility to disappear between them.

Existing service duties do not silently extend into the camera

Ofcom's current age-assurance guidance describes duties for in-scope online services under the Online Safety Act. User-to-user services and providers displaying regulated pornography face specified service-level obligations. Ofcom says existing duties continue while future age restrictions are developed.

For those current duties, highly effective age assurance must be technically accurate, robust, reliable and fair. Accessibility and interoperability also matter. Ofcom recognises that operating systems and app stores may provide wider system-level age signals, but it keeps current compliance responsibility with the regulated service regardless of whether an assurance step is performed in-house or by a third party.

That is an important precedent, not an automatic expansion of jurisdiction. A service can consume an operating-system age signal while remaining responsible for where it places its gate. A device camera, by contrast, may create an image without contacting an online service. A local gallery may display it without a platform moderation event. The 9 September announcement does not say that Ofcom will enforce the future device law, and the current Online Safety Act perimeter should not be stretched to fill that blank.

The Online Safety Act explanatory notes also show why legal artifacts matter. Existing Part 5 providers must keep records of their age-assurance measures and publish summaries. That record duty has a defined statutory subject. A future cross-layer regime will need equivalent clarity about which actor makes which record, how two records are reconciled, and which authority can require correction.

An age signal is not a universal passport

If an adult must verify age once and then unlock taking, viewing and sending, the design immediately raises a scope question. Is the result a device-local state, an account attribute, a reusable token or a series of service-specific decisions? Who signs it, who may read it, how long does it last, and what happens when a shared device or recovered account changes hands?

Ofcom's four effectiveness criteria answer only part of that problem. A method can be accurate in a laboratory yet fragile in a household context. A reliable issuer can produce a signal that a downstream app misreads. A fair model at one threshold can perform differently across devices or demographic groups. Interoperability can reduce repeated checks, but it can also turn a narrowly collected attribute into a credential presented across many services.

The Information Commissioner's Office supplies the necessary brake. Age-assurance data must have a specific purpose, be limited to what is necessary and not be reused for advertising. Sharing a child's age-assurance information requires a compelling reason and a documented necessity. Age estimates must be treated as estimates, and people must be able to challenge inaccurate personal data.

Those principles make “verify once, unlock everywhere” a governance problem, not a convenient default. Every recipient of the signal should have a stated purpose, minimum field set and expiry. A correction should propagate to every layer that acted on the wrong result without creating a permanent ledger of a child's media behaviour.

The same discipline applies to the image decision. “Nudity detected” is not identical to illegal content, harmful intent or abuse. It may justify a bounded product action under a future rule, but the action, exception and appeal must be specified. The design must not silently convert a classifier into a legal decision maker.

Publish the handoffs, not the sensitive media

A public capability-obligation map can expose accountability without exposing images, identities, model weights or attackable device internals. Its unit should be the action-and-handoff, not the company slogan.

For “take,” a row could identify the controlling camera or operating-system layer, the accountable operator class, the age signal accepted, whether analysis is local, the block state and the correction owner. For “view,” separate rows could cover local gallery, browser, app and cloud preview because their evidence and authority differ. For “send,” the map should distinguish local share initiation, app acceptance and service delivery rather than claiming that one participant controls the entire path.

Each row should also state the legal basis once Parliament supplies it, the effective date, test version, denominator, false-result measure, retained evidence and deletion rule. It should identify where responsibility passes to another actor and what receipt proves that the next layer accepted it. If an adult's age is wrongly assessed, the map should show who restores capability and how that correction reaches dependent apps. If an image is wrongly classified, it should show whether review is local, human, provider-based or unavailable—and who is accountable for that choice.

This is Daniel Kade's editorial implementation test, not a system the government or Ofcom has promised. It is also not a demand for a central register of young people's images. The Ofcom 2026 age-assurance report already warns that no single method eliminates circumvention and argues for layers of protection. Layering only becomes governable when every layer has a bounded capability, an owner and an observable handoff.

The policy ambition is now easy to quote. The next useful document is harder and more prosaic: a bill that tells the device stack which actor must do what, with which data, under whose review, and with what remedy when the system is wrong.

Sources