The Price of a Check: Privacy, Friction, and Circumvention

This chapter examines the costs and pressures that determine whether an age-assurance process is trusted, completed, and sustained. The focus is broader than the seconds spent taking a photograph: what data is collected, who handles it, how long it remains, who pays for the system, what happens to traffic and revenue, and which routes around the check remain. The result is a practical test for judging whether privacy safeguards support safety or whether friction, mistrust, and circumvention weaken the intended protection.

The central mistake is to treat privacy as a veto on safety or safety as a licence to collect whatever data seems useful. A credible process has to meet both objectives. It must obtain evidence proportionate to the risk, limit the data and access created by the check, and remain effective when users and providers respond to its demands.

Privacy is part of whether a check works

Ofcom and the Information Commissioner’s Office state that compliance with online-safety and data-protection regimes is mandatory and should not be treated as a trade-off in which one side cancels the other. Their position changes how an age-assurance process should be designed. The question is not simply whether a service can collect a face image, identity document, payment signal, or behavioural profile. It is whether that collection is necessary and proportionate to the service’s risk, whether the service protects the information, and whether it deletes or limits it when the purpose is complete.

This is a lifecycle question. Before the check, the service should identify the purpose: preventing entry to restricted content, gating a function, or applying age-appropriate protections. During the check, it should limit what it and its providers can see. After the decision, it should retain only what is needed to support the permission or protection, and only for as long as that need lasts. A binary adult-or-not result can be less revealing than an identity document, but it is still a permission that needs a clear purpose, scope, and expiry or revalidation rule.

Ofcom’s evidence describes several ways services tried to reduce the data surface. Some said that personal data or proof-of-age information was deleted immediately or that no repository was created. Some reported short retention periods. Two social media services described processing personal data only on the user’s device so that facial images or biometric information were not sent to a remote server; the service received limited decision information such as a pass/fail result, a timestamp, and the method used. Several pornography services said their providers returned only a binary outcome. These examples show design choices, not a universal industry practice. Their importance is that they reduce the amount of information that must travel beyond the moment of proof.

Data minimisation can be implemented in more than one architecture. A service may build a proprietary process so that sensitive information never leaves its own controlled environment. Another may use a specialist third party so that the service itself receives only a result rather than the underlying document or image. Neither choice is automatically more private. An in-house system can still retain too much or expose too many internal users; a vendor can reduce direct holdings while creating a new concentration of sensitive data outside the service. The relevant question is who can access what, for which purpose, and under which controls.

That is why the service remains responsible when a vendor performs the check. It must assess the provider’s data-protection and security practices, define controller roles, understand retention and deletion, and ensure that important configuration settings do not undermine the intended result. A vendor’s reputation or certification may be relevant evidence, but it is not a substitute for service-level due diligence.