Architecture
Everything converges, and nothing is retained
The matching happens on the child’s band. No server is told where anybody was, because no server is ever sent a position.
The design problem is to let two devices establish that they are close to each other without either one learning who the other is, and without any server learning where either of them was. This is a solved problem, and the solution has been deployed at national scale before.
The shape is the one used by exposure-notification systems: a per-day key, short-lived identifiers derived from it, and matching performed entirely on the receiving device against a published list. It is adapted here in one important way — the population whose keys are published is a small, legally defined set rather than everybody.
The flow
The dashed red line is the point of the whole architecture: it is a path that does not exist. The band holds the location history and never sends it anywhere. A guardian, an officer, an operator, and an attacker who takes the entire service all learn the same thing about where a child has been, which is nothing.
The scheme
A key a day, an identifier a quarter hour
Neither one carries a name, and yesterday’s identifiers cannot be linked to today’s without the key that generated them.
Derivation
DTK(day) = HMAC-SHA256( master_secret, "SP-DTK|" + day ) [first 16 bytes]
RPI(day, win) = HMAC-SHA256( DTK(day), "SP-RPI|" + win ) [first 16 bytes]
master_secret never leaves the monitored device
DTK published daily by the supervision authority
RPI broadcast over the air, rotating every 15 minutes
win the quarter-hour index within the day (0–95)The band receives an RPI, downloads the day’s DTK list, and re-derives every candidate RPI to test for a match. It never uploads what it heard. A passive observer sees only 16 opaque bytes that change four times an hour.
Token derivation
Real HMAC-SHA256, computed by your browser’s WebCryptoChange the day and the daily key changes completely, which is what makes yesterday’s broadcasts unlinkable to today’s. Change the window and the identifier changes while the key stays the same — the band can still match it, an observer cannot follow it. The key-list size is the number that decides whether this design is practical: at county scale it is tens of kilobytes a day, which any device can hold. At national scale it is not, which is why the keys must be partitioned by region.
Retention
| Record | Where it lives | How long | Who can read it |
|---|---|---|---|
| Received identifiers | Band only | 14 days, then destroyed | Nobody — not exportable |
| Position track | Band only | 72 hours, rolling | Nobody. Not synced, not backed up |
| T1 log entries | Band only | 30 days | Guardian, on the device, on request |
| T2 notifications | Guardian device | 90 days | Guardian |
| T3 / T4 encounter record | Case system | Per jurisdiction’s evidence rules | Officer, subject, subject’s counsel — every read logged |
| Daily key list | Public | 14 days rolling | Everyone, by design — see the residual risk in the threat model |
What the supervision authority never receives
Not a position, not a track, not a heat map, not a count of encounters that did not escalate. It receives enrolment status changes and tier-3-and-above records. If the authority wants aggregate statistics it has to ask for them as a deliberate, separately authorised collection — not harvest them as a side effect of the alerting system.