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 | Nobody - the child-side device is receive-only and stores no track | Would enable stalking, abduction planning, and domestic-violence tracking by an estranged parent. It is the highest-value asset in the system, which is why the design refuses to create it: there is nothing to breach and nothing to subpoena. |
| 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 enrollment 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 program, 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 program 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 membership decision happens on the anchor, locally and offline, against a set of identifiers valid for the next few minutes that carries no identities and no history. There is no movement database to exfiltrate, and that absence is the primary structural defense rather than an access control on top of one.
The record for children's tracking wearables
This is not a hypothetical threat class. It is a nine-year published record, it has not improved across that span, and it is the most directly relevant evidence there is about the component this design document treats as most dangerous.
- An assessment for the Norwegian Consumer Council found watches where the device identifier alone authenticated the account - returning the child's name and geofence locations - and one that could be commanded to place a silent outbound call, which is a remotely controllable listening device strapped to a child [33].
- About 600,000 children's tracking devices were found using the default password 123456, with all traffic in plaintext HTTP.Avast / Martin Hron, Shenzhen i365 tracker research (2019) [34]
- 70+ tested children's tracking devices - tens of millions of units - funnel through just three shared backends.Stykas & Solferini, Black Hat (Aug. 7, 2026)
An attacker could locate a watch, alter emergency contacts, falsify location, and activate microphones and cameras with no visible indication. [35] - More than 40,000 stalking reports involving item trackers reached one manufacturer between April 2021 and April 2024.AirTag stalking litigation reporting (2026)
That manufacturer's own documents conceded its safeguards would "deter as opposed to prevent" misuse. [36]
The structural lesson: the backend is the attack surface, and it is probably not run by the vendor whose name is on the box
Tens of millions of units funnelling through a handful of shared backends is not a coincidence and it is not a scandal about three bad companies. It is what the economics of this category produce. A brand sources a white-label device, the device talks to the platform the manufacturer already operates, and the brand on the packaging has neither the contract nor the engineering access to secure it. Every buyer in that chain believes they are buying from the name on the box.
So the procurement requirement is a naming requirement before it is a technical one. The contract must name the backend operator, subject that named operator to independent penetration testing, and require the results to be published. A vendor who cannot say who operates the backend has answered the security question already.
This is the reason for constraint C-2 on the child-side device: no microphone, no camera, no remote-call capability - absent from the bill of materials, not disabled in software. A capability that is not present cannot be re-enabled by whoever ends up holding the backend.
The item-tracker record adds the second failure mode, and it is the one that has nothing to do with a breach. A two-sided proximity system is, by construction, also a proximity-surveillance system. Which party it protects and which it endangers is decided entirely by who controls the account - which is why guardian changes on the child-side device are visible to every existing guardian and take effect only after a delay, and why the device reports no location at all.
The finding
Tokenization 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 tokenized 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.
The paparazzi limit: no cryptography defends against an adversary with eyes
There is a harder version of the same point, and it comes from the security analysis of the exposure-notification protocols this design borrows from [28]. An anchor operator who observes a person walking past and simultaneously captures the identifier their device broadcast has bound that identifier to that human being by direct observation. Nothing in the key hierarchy prevents it, because nothing in the key hierarchy was ever addressed to it. The rotation defeats following an identifier across time; it does not defeat anchoring one to a face at the moment it is heard.
The honest description therefore is not that this is an anonymous system. It is a pseudonymous system with a trusted matching party, whose operator is in a position to break the pseudonym for anyone they can physically see. The right responses are contractual and structural rather than cryptographic - a named and audited anchor operator, siting that does not put an operator's staff on top of a Class A zone's approach, and a published false-alert record that makes selective observation visible. Borrowing privacy vocabulary the architecture does not support is how a design loses the argument in front of a reviewer who knows the literature.
De-anonymization 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. |
| Current-interval enrollment set | Obtain the set, build a receiver, and detect monitored people around you | Narrowed, not closed. The set goes to anchors under contract, not to the public. See below. |
| Guardian account | Estranged parent obtains location history, or silently adds themselves as a guardian | No track exists to retrieve. Adding or changing a guardian notifies every existing guardian and takes effect only after a delay. |
| Encounter store | Insider browsing, or bulk breach | Nothing leaves the anchor below Tier 1. Records are minimized to the encounter, identity is resolved only under a judicial order together with an independent key custodian, and every resolution writes an immutable audit record. |
| 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-anonymization | Partially closed only: the audible alert exists at Tier 3 alone, which takes two agreeing modalities, a 30-second dwell, a Class A zone and a human adjudication. The residual risk is real and is stated in the specification rather than papered over. |
The residual risk the matching design creates, restated for the anchored model
An earlier version of this page described a day's pseudonymous keys published openly so that every child-side device could match them offline. Under that design anyone at all could download the list, build a receiver, and turn a registry that was a lookup into a proximity oracle: not "who lives on my street" but "someone on the program is within thirty meters of me right now." That was a real and serious risk, and it was created by putting the matching on a device in a child's pocket.
The anchored model narrows it substantially. What is distributed is a current-interval enrollment set - the identifiers valid for the present ten-minute window - pushed hourly to fixed, contracted anchors. It contains no identities and no history, it expires in minutes rather than days, and it goes to a known list of installations rather than to the public. The oracle no longer exists for a passer-by.
It does still exist for an anchor operator, and it is bounded by contract rather than by mathematics. Whoever holds a current set can detect enrolled devices near their own hardware, and - per the paparazzi limit above - can bind one to a person they can see. That capability did not exist before and this design creates it. The controls that remain are the ones that apply to a named party: contractual scope, audit, published statistics, and the fact that an anchor is a physical installation with an owner rather than an anonymous receiver in a pocket. This is a genuine trade, and whoever adopts the system has to make it knowingly.
How this works
0:58 · narrated · captioned · nothing here is sent anywhere when you press play. Prefer to read it? The transcript is below.
Transcript
| At | Section | What it says |
|---|---|---|
| 0:02 | Who, 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. |
| 0:13 | The likely attacker | The estranged parent is the most likely real attacker, with physical access to the child and a motive to find a household that moved. So no location history exists at all. |
| 0:24 | The band is deaf | The child's band never transmits an identifier. It is receive-only, it never announces itself, and that single rule constrains the whole radio design. |
| 0:35 | The finding | Tokenization hides the database. It does not hide the person. A loud alert in a public place is a pointer, and everybody in earshot follows it. |
| 0:44 | A number on it | The page carries a calculator for that. Density, radius, and who is paying attention. It reports a probability, stated as a floor rather than a forecast. |