Checkpoint: Follow the Trust, Not the Label

This checkpoint connects the crowdsourced location pipeline with the security properties that are supposed to make it safe. The concrete judgment is simple to state but demanding to apply: a tracker cannot be called accountable merely because a database contains an owner, an app can display an identifier, or a company promises to cooperate with authorities. We need to ask what each participant can learn, what the target can see and do, and whether an alleged tracking event is genuine.

Trust is distributed, but harm is not

The location pipeline has a useful division of labor. A tag emits a Bluetooth advertisement. A finder device observes it and contributes a time and place. The crowdsourced network stores or processes the report. An owner device queries for a result. The security properties cut across that sequence rather than belonging to one component.

Tag indistinguishability limits what a passive observer can learn by joining broadcasts. Location indistinguishability limits what the platform can learn from the reports it receives. Tag detectability gives a target’s device a chance to recognize that an unfamiliar tag has persisted nearby. Finding and disablement give the target a way to interrupt the channel. Framing resistance protects the evidence if someone later tries to identify an owner or seek a remedy. Accountability is the response built on those earlier conditions.

This arrangement makes the label “owner” too narrow to serve as the whole security model. The finder may be the only device that actually observes the signal. A shared user may possess information that affects future broadcasts. A person who gains access to the target’s account may use a target-owned tag without placing a new accessory. The platform may decide whether an alert runs in the background, and the network may decide what records are visible. The target may be the person carrying the tag while appearing nowhere in the account relationship.

A useful audit therefore follows relationships and state, not just product names:

erDiagram TAG ||--o{ ADVERTISEMENT : emits FINDER_DEVICE ||--o{ OBSERVATION : records ADVERTISEMENT ||--o{ OBSERVATION : informs CROWD_NETWORK ||--o{ OBSERVATION : stores ACCOUNT ||--o{ TAG_ACCESS : grants TAG ||--o{ TAG_ACCESS : has OWNER_DEVICE }o--|| ACCOUNT : uses PLATFORM ||--|| CROWD_NETWORK : operates TARGET }o--o{ TAG : may_carry

The diagram is not a catalog of every implementation object. It is a reminder that control and exposure are distributed. The tag controls what it emits. The finder controls which observations it makes and submits. The network controls storage, lookup, and perhaps filtering. The account and its devices control who appears authorized. The platform controls important parts of scanning and notification. The target bears the consequence even when none of those relationships name them.

That last asymmetry changes the meaning of a successful operation. If the owner receives a location, the finding function has worked. It does not follow that the target has consented, that the platform has kept the location private, or that the target has any way to discover the tag. Similarly, if a scan returns a tag identifier, it does not follow that the identifier was produced by the genuine hardware at that place and time. Functional success and safety success are different outcomes.