There is a category of software that watches what a child does on their phone, and most of it is built to be hidden. Hidden icon, silent install, “stealth mode” in the feature list. That design choice makes a certain commercial sense and I think it is wrong — not only ethically, but practically, because it produces a product that cannot survive app-store review, cannot survive a teenager finding it, and cannot survive the conversation that follows.

Kidslen is built the other way. Every privacy property below is a constraint I designed the system around, not a setting a parent can switch off. This post walks through each one, how it is implemented, and then the part builders skip: what the app stores ask of software in this category, and why an honest product is the only kind that gets through.

Consent is a record, not a checkbox

When a parent enrolls a child’s device, the companion app does not go straight to “grant permissions”. It shows a screen that states, in the device’s language, who will be able to see this device’s activity, exactly what will be collected, exactly what will not be, how long it is kept, and how to ask for it to be deleted.

The child has to read it and accept it. What gets stored is a consent record: which child, which device, which version of the disclosure text they saw, and when. If the disclosure text changes materially, the old consent does not silently carry over — the record is versioned so that “what did this child actually agree to” has an answer.

This matters for three separate reasons, and only one of them is legal.

The legal one is obvious: in most jurisdictions processing a minor’s personal data requires a lawful basis and a demonstrable one. A checkbox that stored a boolean would not demonstrate anything.

The second is product: a consent record lets the app show the child the same disclosure again, any time, from the transparency screen. The information is not a wall you click past at install time; it is a permanent, re-readable part of the app.

The third is the one I care about most. Recorded consent changes what the product is for. A tool a child agreed to is a tool the family can talk about. A tool installed in secret is a tool that, when discovered, ends a conversation rather than starting one. The consent record is the technical artefact of a social decision.

The banner the child cannot dismiss

The companion app shows a permanent notice: this device is monitored, by this parent. It is not a notification that can be swiped away. It is not a settings entry you have to go looking for. It is visible in the app, and the app itself is visible — the icon is on the home screen, with the product’s name on it.

There is no hidden mode. There is no plan for a hidden mode. If a future user asks for one, the answer is no, and that is written into the product description so nobody buys it expecting otherwise.

Making that banner undismissable is a surprisingly demanding engineering constraint, because it has to survive everything: re-renders, navigation, background and foreground transitions, locale changes, accessibility scaling. During the week I wrote about in part seven, I found the banner flickering out of view for a few frames during a re-render, and treated it as a correctness bug of the same severity as a data leak. On this product, it is one.

Alongside it there is a transparency screen that lists what Kidslen collects, in plain language, with an example of each. Not a privacy policy — a screen in the app showing the actual shape of the data leaving the device.

Data minimisation: what Kidslen deliberately does not collect

The strongest privacy control is the data you never hold. Kidslen captures, from the child’s own accounts on the six supported platforms:

• the title of what was watched
• the platform it was watched on
• the duration and the time it happened

That is the list. What it does not collect is longer and more important:

Not collected	Why
Screen recordings or screenshots	The single most invasive thing a monitoring app can take, and unnecessary for the product’s purpose
Messages or chat content	Private communication is not screen-time data
Keystrokes	Same, plus it is a credential-capture risk by construction
Location	Kidslen is about media and screen time; location is a different product with different risks
Contacts, photos, files	No feature requires them
Browsing outside the supported platforms	The capture mechanism is scoped to the connected accounts, not to everything the device does

I want to be precise about why this is a design constraint and not just restraint. A screen recording, once captured, exists. It has to be stored, transmitted, retained, backed up, and deleted, and every one of those is a place it can leak. Choosing titles and durations means that even a total compromise of my database exposes a list of what someone watched — bad, genuinely bad, and still orders of magnitude less harmful than a video archive of a teenager’s screen.

Minimisation is also what makes the honest pitch possible. A parent can read the transparency screen in thirty seconds and understand the whole deal. If the list were “everything”, no amount of policy prose would make that comfortable.

Retention that actually deletes

Data that is kept forever will eventually be exposed. Kidslen runs a scheduled retention job that deletes activity events older than the configured window, on a schedule, without anyone asking.

The important details are the boring ones:

• Deletion is actual deletion of the row, not a deleted = true flag that leaves the content in the table.
• It cascades to derived data — the projections that back the charts do not outlive the events they were computed from.
• It runs whether or not anyone is paying attention, because a retention policy that depends on someone remembering is a retention policy that does not exist.
• Backups age out too. A retention window that a restore can reverse is theatre.

Alongside the schedule, a parent has two buttons in the dashboard: export everything and delete everything. Export produces a machine-readable file of what Kidslen holds about that family. Delete removes the child’s data, revokes the device’s tokens, and takes effect immediately rather than “within thirty days”.

There is no dark pattern on the delete path — no retention offer, no “are you sure you want to lose your history”, no email-support-only escape hatch. If leaving is hard, the trust is fake.

The security that makes the privacy claims true

Privacy promises are worthless if the API leaks. The backend is built deny-by-default: an endpoint has no access until an authorisation rule grants it, and every rule is scoped by the ownership chain — this parent, this family, this child, this device. A request that does not resolve to a chain the caller owns does not get a 403 with helpful detail; it gets treated as if the resource does not exist, because confirming existence is itself a disclosure.

Authentication uses Argon2id for password hashing and rotating refresh tokens with reuse detection. That second mechanism is worth explaining, because it is the one that specifically protects a child’s device.

A refresh token is used exactly once. Using it returns a new one and invalidates the old. If a token that has already been used is presented again, that means two parties hold the same token — the legitimate device and someone who copied it. The server cannot tell which is which, so it does the only safe thing: it invalidates the entire token family, and both are forced to re-authenticate. A stolen token buys an attacker one request and a guaranteed alarm, instead of indefinite access to a child’s activity stream.

On top of that: rate limiting on every authentication and ingest path, certificate pinning enforced at the platform layer on both mobile operating systems, and an audit log of privileged actions — who viewed what, who exported, who deleted, who changed a policy, when. The audit log covers my own access too. If I look at something in the ops console, that is a record.

App-store policy, which is where most of these products die

This is the section I wish someone had written before I started.

Both major app stores have specific rules for software that monitors people, and stricter ones when the people are minors. The shape of those rules is consistent even as the wording changes:

• The monitored person must know. Apps designed to operate covertly on someone else’s device are rejected, and “stealth” or “hidden icon” in your own marketing copy is evidence against you.
• Consent must be obtained and demonstrable, and for a minor, from the parent or guardian with the child informed.
• The child-facing app must disclose what it collects, visibly, inside the app.
• Data collection must be proportionate to the stated purpose. “We collect everything because parents might want it” is not a purpose.
• Parental-control functionality gets extra scrutiny, including how enrollment works and whether the app could be repurposed to monitor an adult without their knowledge — a partner, an employee.
• Your marketing is part of the review. A store can and does read your website. A landing page promising covert surveillance will sink an app that behaves correctly.

Here is the thing that took me a while to appreciate: every one of those rules is satisfied automatically by the product I wanted to build anyway. The permanent banner is the disclosure requirement. The consent record is the demonstrable-consent requirement. The minimised data set is proportionality. The absence of a hidden mode is the covert-operation rule.

I did not design Kidslen to pass review. I designed it to be a product I would install on my own child’s phone and be able to explain to them, and review compliance fell out of that for free. The builders who fight review are, almost always, the ones who built the covert version first and are now trying to argue that it is not covert.

An honest product is the only one that survives review, and it is also the only one that survives the child. Any sufficiently motivated teenager finds the hidden app. What happens next is determined entirely by whether they were told. A product built on concealment has its failure mode built in: the day it is discovered is the day it stops working and the trust it was meant to protect is worse than before.

The thing this is all actually for

None of this makes Kidslen a nicer surveillance tool. It makes it a different kind of tool.

The product is not built to catch a child doing something. It is built so that a parent and a child can look at the same screen and have an accurate conversation about how time is being spent — with limits the child knows exist, alerts the child knows can fire, and a record the child can read. The child can see everything the parent sees about them. That symmetry is the design.

Every technical decision above exists to make that claim true rather than aspirational. A consent record so the agreement is real. A banner so it cannot be quietly withdrawn. Minimisation so the promise about what is collected is checkable. Retention and deletion so “we do not keep it” means something. Audit logs so even I am accountable.

---

Next in this series: naming, domains, and building a marketing site that does not lie — including why I went the opposite direction from every competitor’s design.

Kidslen’s transparency screen is not just a screenshot on the website; it is what the app actually shows. See it at kidslen.app.