Threat model
Who is being protected, and from whom
A privacy layer that is not tied to a named threat is decoration. This page names the threats, says which ones the design covers, and says plainly which one it makes worse.
Assets worth protecting
| Asset | Held by | Harm if it leaks |
|---|---|---|
| The child’s location history | The band, locally | Enables stalking, abduction planning, and domestic-violence tracking by an estranged parent. This is the highest-value asset in the system. |
| The child’s identity, linked to a device | Guardian account | Turns a found or stolen band into a named target. |
| The monitored adult’s location history | Supervision authority | Already collected under existing monitoring statutes. Adding a second copy adds a second breach surface. |
| The monitored adult’s identity, at a place and time | Nobody, by design | Registrants have been assaulted and killed using registry data. This is why the matching layer exists. |
| The encounter record | Guardian device, then the case file | Evidence in one direction, and an unfounded accusation in the other. |
Adversaries
The estranged parent
The most likely real-world attacker, and the one every child-tracking product underestimates. They have physical access to the child, plausible authority to install software, and a motive to locate a household that has moved. Design consequence: guardian enrolment cannot be a single unverified account, and location history must not be retrievable from the cloud by anyone holding credentials.
The opportunist with a scanner
Anyone who can receive the radio the system uses. If the band broadcasts, they can follow it. Design consequence: the child’s band is receive-only. It never announces itself. This is non-negotiable and it constrains the whole radio design.
The vigilante
Somebody who wants to know which of the people around them is on the programme, in order to act on it. The token layer stops them browsing a database. It does not stop them watching who reacts when an alarm sounds. Design consequence: the audible tier is a deliberate, restricted decision, not a default.
The monitored person
Motivated to defeat the device, and the only adversary who has continuous physical access to it. Design consequence: removal cannot be prevented and should not be designed for. It must be detected fast — see devices.
The system operator
An insider with query access. Every monitoring programme that skipped audit logging lost on exactly this point. Design consequence: every query against the encounter store is itself a logged record the subject can later obtain.
The bulk attacker
Someone breaching the service to obtain the whole picture at once. Design consequence: the service is designed so that there is no whole picture to obtain — the matching happens on the child’s device and location never reaches a server.
The finding
Tokenisation hides the database. It does not hide the person.
The silhouette is still there. A loud alert in a public place is a pointer, and everybody in earshot follows it.
The privacy layer and the alarm protect against different things, and the alarm wins
The tokenised matching layer is genuinely good at what it does: it prevents anyone — including the operator — from browsing who was where. What it cannot touch is situational identification. If a device makes a noise in a public place because a specific person is nearby, then in any setting smaller than a crowd the noise names them. The cryptography is irrelevant at that moment.
This is not an argument against the privacy layer. It is an argument for being precise about which threat it covers, and for putting the audible alert behind a much higher bar than proximity.
De-anonymisation calculator
How quickly a public alert identifies the subject—
probability that the subject is correctly identified by at least one bystander.
Assumptions, stated rather than buried. Candidates are the adults inside a circle of the given radius at the given density. “Reads the reaction” means one observer connects the alert to a person’s visible response — looking at a phone, changing direction, leaving. The model treats observers as independent, which overstates the effect slightly in a group who are all looking at each other, and understates it in a place where one person pointing is enough. It is a floor, not a forecast.
Attack surfaces, and what closes each one
| Surface | Attack | Mitigation in this design |
|---|---|---|
| Band radio | Follow the child by tracking their broadcasts | The band never transmits an identifier. Receive-only. It has no advertised service and answers nothing. |
| Published key list | Build a receiver and detect monitored people around you | Not fully closed. See below — this is a real residual risk of the local-matching design. |
| Guardian account | Estranged parent obtains location history | History stays on the band. The account can raise an alert; it cannot retrieve a track. |
| Encounter store | Insider browsing, or bulk breach | Records are written only on a tier-3 or tier-4 event, are minimised to the encounter, and every read is logged to the subject’s own audit trail. |
| The band itself | Lost or stolen, then linked to a child | No identity on the device. Pairing secret is wiped on tamper or on a guardian-issued revocation. |
| The alert | Situational de-anonymisation | Partially closed only: audible alerts restricted to tier 3+, which requires sustained dwell and a zone or repeat. The residual risk is real and is stated in the specification rather than papered over. |
The residual risk the matching design creates
Local matching requires publishing the day’s pseudonymous keys so every band can check them offline. That is what keeps location off the server. But anyone can download the same list and build their own receiver — which turns a registry that was a lookup into a proximity oracle: not “who lives on my street” but “someone on the programme is within thirty metres of me right now.”
That capability did not exist before and this design creates it. It can be narrowed — regional key partitioning, rate limits, signed client attestation — but it cannot be eliminated while matching happens on the device. The alternative is server-side matching, which reintroduces exactly the central location database this design exists to avoid. This is a genuine trade, and whoever adopts the system has to make it knowingly.