Surveillance Is Not Safety: Monitoring Children Online

Proposals to protect children from digital surveillance often rely on surveilling them first. Here is why that logic is broken — and what it means for engineers and product teams building platforms.

The Irony at the Heart of "Child Safety" Tech

There is a recurring argument made in legislatures and boardrooms whenever online child safety comes up: to protect children from being watched, we must first watch them. Verify their age. Scan their messages. Monitor their activity. The logic sounds protective. In practice, it is self-defeating.

This is not a fringe observation. It is a structural problem that every software team building consumer-facing products — especially platforms with any youth audience — needs to reckon with honestly.

What "Protect the Children" Legislation Usually Builds

When governments mandate age verification or parental monitoring tools, the mechanisms they reach for are almost always surveillance infrastructure:

Biometric age gates that collect facial data or government ID scans from millions of users
Message scanning that reads private communications to detect harmful content
Parental dashboards that give adults full visibility into a child's online behaviour, contacts, and location

Each of these creates something valuable beyond its stated purpose: a data asset. A centralised repository of sensitive information about minors. A honeypot for bad actors. A surveillance surface that did not exist before the "protection" was mandated.

The stated goal is safety. The engineered outcome is a new attack vector.

The Data You Collect Is the Risk You Accept

Here is a principle that should be tattooed on every product roadmap: you cannot be breached for data you never collected.

When a platform is compelled — by regulation, by liability fear, or by a misguided product decision — to verify and log the ages, identities, or behavioural patterns of young users, it takes on a security obligation it may not be equipped to honour. Most platforms are not equipped to honour it. The graveyard of breached "KYC" databases is long and well-documented.

Consider what a compromised age-verification database looks like in practice: names, dates of birth, government ID references, and behavioural metadata — all linked to minors. The harm potential from such a leak is not abstract. It is identity theft, targeted grooming, and blackmail material, delivered in a single breach.

The protection mechanism becomes the threat vector.

Minimum Viable Privacy: An Engineering Posture

There is a better design philosophy, and it starts at the architecture stage rather than the compliance stage.

Collect nothing you do not strictly need. If the goal is to prevent a 10-year-old from accessing adult content, there are privacy-preserving cryptographic approaches — zero-knowledge proofs, anonymous credential schemes — that can attest to an age threshold without revealing the age itself, let alone an identity.

# Conceptual: ZK-style age attestation
# Third-party age authority issues a signed token: "user is over 13"
# Platform receives only the token — not the birthdate, not the name

def verify_age_gate(signed_token: str, minimum_age: int) -> bool:
    """
    Validates that a user meets a minimum age threshold
    using a blind-signed credential. No PII touches our system.
    """
    return age_authority.verify(signed_token, threshold=minimum_age)

This is not science fiction. Academic and open-source implementations of anonymous credential systems exist today. The barrier is not technical. It is that regulators and product managers default to the most legible solution — which is usually the most invasive one.

The Power Asymmetry Problem

There is a second issue that sits alongside the data risk: power asymmetry between children and the adults monitoring them.

Blanket parental surveillance tools do not distinguish between a teenager researching mental health resources and one planning something harmful. They do not accommodate the reality that some children's greatest threat is not a stranger online — it is someone inside their household. A mandatory monitoring dashboard handed to an abusive parent is not a safety tool. It is a control tool.

Good product design acknowledges that "parent" and "safe adult" are not synonyms. Any platform that treats them as such is not doing child safety work. It is doing liability management while calling it ethics.

What Responsible Platforms Can Actually Do

Rather than building surveillance infrastructure, teams building products for general audiences — which will inevitably include minors — should consider:

Default-private settings for any account that could belong to a young person
Content classification at the content layer, not the user identity layer — keep the filter away from the profile
Clear, low-friction reporting mechanisms that empower users without requiring identity disclosure
Transparent data minimisation policies that are auditable, not just published in a terms-of-service document nobody reads
Regular third-party audits of what is actually being collected versus what policy says is collected

None of these require knowing who your users are. All of them reduce harm.

The Regulatory Trap for SaaS Founders

If you are building a SaaS product in a regulated market — and increasingly, any market touching consumer data is a regulated one — the temptation is to over-collect in order to demonstrate compliance. More data looks like more diligence. It is not.

Over-collection increases your liability surface, your breach impact, and your operational cost. Regulators in the EU under GDPR and increasingly across Africa under frameworks like Nigeria's NDPR are moving toward data minimisation as a compliance expectation, not just a best practice. Building lean data architecture now is not just ethical. It is commercially rational.

Source

Cory Doctorow, Destroy the Village, Pluralistic — https://pluralistic.net/2026/06/23/destroy-the-village/

Why this matters for your project: Whether you are building a consumer app, a SaaS platform, or an AI product with a broad user base, the architecture decisions you make around identity and data collection are safety decisions — not just compliance ones. At Code!nk Technologies, we design systems with data minimisation baked in from the first sprint, because the safest data is the data that never touches your servers in the first place. If your current stack is holding more user data than your core product logic requires, that is a risk conversation worth having before a regulator — or a breach — forces it.