This article is a shorter version of one argument in my Submission to the OAIC Children’s Online Privacy Code consultation. The full submission deals with children’s privacy more broadly including but not limited to; specifics on data minimisation, profiling, artificial intelligence, default visibility, deletion rights, age assurance, privacy impact assessments and the risk of normalising identity-by-default online participation.
Age assurance is usually discussed as though it were a narrow compliance step.
That framing is far too small.
The question is not only whether a service can tell whether someone is old enough to use a feature. The deeper question is what kind of identity architecture the service creates to answer that question. Who has to prove what. To whom. How often. With what evidence. Through which vendor. Under what retention rules. With what fallback. With what risk of reuse later.
That is why age assurance is not just a child-safety mechanism. It is an identity infrastructure problem.
That does not mean age assurance is always wrong. Some online contexts create real risk and may justify proportionate age-related controls. But treating age assurance as a neutral checkbox hides the architectural consequences. A poorly designed age-assurance system can become a durable identity layer across ordinary digital life.
That is the failure mode this piece is about.
Age Assurance Is Not One Thing
The phrase “age assurance” is incredibly broad. That is part of the problem. It can mean self-declaration. It can mean estimating age from signals. It can mean inferring age from behaviour, account history or metadata. It can mean parental attestation. It can mean checking a government document. It can mean biometric age estimation. It can mean using a reusable credential that proves a person is above or below a threshold. Those are by no means equivalent systems.
A service asking a user to choose an age range is very different from a service asking for a passport scan. A local, ephemeral age signal is very different from a persistent cross-service credential. A yes/no age flag is very different from a vendor holding face data, identity documents, device identifiers or behavioural signals.
This distinction matters because regulation often asks a narrow question. Should this user receive child-protective defaults or should this user access a particular feature?
That question does not always require knowing who the person is.
A service should not ask who you are when the real question should be whether you are in an appropriate age range for a feature. Identity verification is more intrusive than age assurance. It should by no means become the default answer to every age-related compliance problem.
The Architecture Matters More Than the Label
The safest age-assurance model is not defined by marketing language. It is defined by architecture.
A system that claims to be privacy-preserving but creates persistent identifiers, stores raw evidence, centralises decisions through a small number of vendors or allows cross-service tracking has created a serious privacy problem. The fact that it is framed as child protection does not remove that risk.
The key design questions are concrete:
- does the service need age assurance at all
- can the same protection be applied to all users instead
- is the method proving age range or legal identity
- is raw evidence retained
- is a biometric signal collected
- is a government document uploaded
- is the result reusable across services
- can the vendor track where the user goes
- can the data be used for profiling, advertising, fraud scoring, analytics or AI training
- can the user contest a wrong decision
- is there a practical fallback for people without compatible documents, devices or stable access
These are not secondary implementation details. They define what the system is.
If age assurance requires identity documents, biometric checks, persistent credentials or repeated verification across ordinary services then the result is not just an access-control mechanism. It is undeniably identity infrastructure.
Identity Infrastructure Has Function Creep
Identity infrastructure rarely stays confined to its first use.
Once a system exists for checking access to one category of service, it becomes tempting to reuse it for another. Once a vendor or platform can issue reusable age or identity decisions, it becomes tempting to expand the credential. Once services become accustomed to asking for proof before access, the boundary of “reasonable” proof can tilt.
That is the long-term risk for these systems.
A system introduced for children’s online safety can become a general-purpose mechanism for access control, speech control, content gating, fraud scoring, risk ranking, advertising exclusion, account recovery, law-enforcement requests or broader regulatory compliance. Some of those uses may sound individually defensible. The problem is accumulation. Each additional use turns a limited safety mechanism into a more general identity layer.
This is why the Australian Human Rights Commission’s warning matters. Keeping children safe should not mean a loss of privacy for everyone. The same concern appears in the Internet Society’s policy work; age checks should not require people to identify themselves or allow providers to track which online services they visit.
That is the right design principle. The end state should be, this user falls within an appropriate age range. It should not be “this service, this vendor and possibly other parties know who this person is and where else they have gone”.
Blanket Age Verification Is a Weak Substitute for Safer Design
There is also a more basic problem. Blanket age verification can look strong while avoiding the harder work.
If a service is unsafe because it profiles children, amplifies harmful recommendations, exposes them to strangers by default, tracks them across contexts, uses dark patterns, retains too much data or pushes targeted advertising then the core failure is design. Age checks alone do not fix that. They may simply decide who is allowed to enter the unsafe environment.
Worse, identity-heavy age checks can create new risks. They can generate valuable data stores. They can create phishing targets. They can exclude people who lack documents or compatible devices. They can push teenagers toward shared accounts, borrowed credentials, VPNs, fake information or less regulated services. They can make ordinary browsing feel conditional on proof.
UNICEF has warned that age restrictions alone will not keep children safe online. That is the correct starting point. The answer to harmful service design is not only to identify users more aggressively. It is to make the service less harmful.
For many services, the better route is simple in principle: apply child-protective defaults to everyone.
Reduce collection. Reduce profiling. Reduce discoverability. Reduce public visibility. Reduce direct marketing. Reduce unnecessary retention. Give users clear deletion rights. Make recommender systems safer. Limit geolocation. Explain data practices in language people can actually understand.
If those protections can be applied broadly, the service does not need to identify every user merely to decide who receives basic privacy protections.
Age Assurance Should Be a Last-Resort Control, Not the Starting Point
A better model starts with design minimisation.
- First, ask whether the service can be made safer without age assurance. If the answer is yes, do that. A privacy-preserving service design is usually more durable than an identity gate.
- Second, if age assurance is genuinely needed, use the least intrusive effective method. That may mean an age range rather than date of birth. It may mean a local device signal rather than document collection. It may mean a short-lived proof rather than retained evidence. It may mean a yes/no eligibility result rather than identity disclosure.
- Third, separate age assurance from advertising, profiling, analytics and broader account identity. An age-assurance vendor should not be able to reuse the data for its own purposes. The result should not become a persistent identifier. Raw evidence should not be retained unless strictly necessary.
- Fourth, provide fallback and contestability. Any age-assurance system will make mistakes. It may wrongly exclude adults. It may wrongly include children. It may fail for people without the right documents, devices, connectivity or biometric reliability. A system that cannot be challenged is not a safeguard. It is an automated barrier.
This is why age assurance should itself be treated as a high-risk privacy activity. It is not neutral just because it is used for compliance.
Anonymity and Pseudonymity Are Protections
A common mistake in online safety debates is to treat anonymity as a loophole.
It is not.
Anonymity and pseudonymity protect people who need to seek information, participate, explore identity, avoid retaliation, discuss sensitive subjects or separate different parts of their lives. This is especially important for children and teenagers seeking information about health, bullying, family conflict, sexuality, religion, politics, abuse, mental health or support services.
It also matters for adults. Adults should not be forced to identify themselves merely because children may also use a service or related service.
A well-designed age-assurance system should preserve anonymity or pseudonymity wherever practicable. It should answer the narrow age question without unnecessarily documenting identity. The fact that a person is age-assured should not mean that the service knows their legal identity, that an age vendor could plausibly track their browsing or that the user is linked across unrelated services.
The distinction is not theoretical. It is the difference between privacy-preserving eligibility and identity-by-default participation.
The Real Standard Should Be Safe by Default
The better standard is not identify first.
It is safe by default.
A children’s privacy regime should not reward services for collecting more information about children in order to prove they are complying with rules designed to reduce privacy harm. That would invert the purpose of the policy. The right direction is less data, not more. Less profiling, not more inference. Less retention, not larger stores of identity evidence. Less manipulation, not better-targeted nudging. Less exposure, not more monitoring. Better security, not more centralised sensitive data.
Age assurance can have a role but only as a proportionate control for a clearly identified risk. It should not become the default architecture of participation in online spaces.
That is the central point. Age assurance is not merely a compliance technique. It is a design decision about identity, privacy and power. If implemented narrowly, locally, ephemerally and with strong limits, it may help reduce specific risks. If implemented broadly, persistently and identity-first, it can create a new surveillance layer around ordinary digital life.
Children need better protection online but the durable way to protect them and all others is to make services safer, less data-hungry and less manipulative by design.
Building identity infrastructure around every user is not the same thing as building a safer internet.