The Location Pipeline: Tag, Finder, Network, Owner
This chapter examines the operating mechanism of a crowdsourced Bluetooth location-tracking system: how a small tag with no direct internet connection can still produce a useful location for its owner. The focus is the movement of an identifier and a location report across four roles—tag, finder device, crowdsourced network, and owner device. Following those handoffs gives readers a practical way to see who observes data, who stores it, who is authorized to retrieve it, and where a design choice can turn a finding service into an unwanted-tracking channel.
A tag can be useful without being online
A location-tracking tag is deliberately limited hardware. It may be attached to keys, a bag, or another possession, and it can communicate over Bluetooth Low Energy, usually called BLE. BLE advertisements are short wireless messages sent without first establishing a full connection. The tag can therefore announce its presence while using little power and without carrying its own cellular or internet connection.
The tag’s advertisement contains information that allows the system to recognize the tag or one of its changing pseudonymous identifiers. “Pseudonymous” means that the value stands in for the tag without necessarily spelling out the owner’s name. That distinction is useful, but it does not automatically make the broadcast private. Any nearby receiver capable of listening can potentially hear a wireless advertisement. Whether the receiver can understand, link, or query what it hears depends on the protocol and the surrounding service.
The missing internet connection is supplied by other people’s devices. A finder device—often a phone belonging to another user—scans for advertisements. When it sees a tag that is eligible for location reporting, it records the identifier and pairs it with the finder’s own location. The finder is not measuring the tag’s coordinates directly. It is reporting, in effect, “this identifier was observed near me at this time.” The service can then use the finder’s GPS and network connection to send the observation onward.
That division of labor explains both the reach and the uncertainty of crowdsourced finding. A tag can be located in a place where its owner is absent because an unrelated phone passes nearby. But a location update depends on an observation. If no participating finder is close enough, the network receives no new report. If the finder has limited connectivity, the report may arrive late. If the wireless signal is missed or the identifier cannot be interpreted, the owner may see an old location or no useful location at all.
The crowdsourced network is the coordinating service. It receives reports, associates them with a tag or an authorized representation of a tag, and makes a result available to the owner device. The owner device is the phone or other platform device associated with the accessory. When the owner opens the finding service, the owner device sends a query. The network returns a location record that was generated from one or more observations by finder devices.
This is the core sequence:
The sequence is simple enough to fit on a screen, but each arrow carries a different kind of information. The tag contributes a wireless signal and an identifier. The finder contributes a time and a place observed from its own sensors. The network contributes storage, authorization, and a lookup function. The owner device contributes the request and displays the result. A failure or privacy decision at one arrow is not automatically corrected by the next.
The sequence also unfolds over time, so there is no single moment that can be called “the location.” First, the tag is within radio range of a finder. Then the finder creates an observation, the network receives and retains a report, and the owner eventually asks to see the result. Those states can be separated by minutes or longer. A returned location can therefore be accurate about where a tag was observed without proving where it is now. A service that does not receive a new observation has not necessarily lost the tag; it may simply have no newer evidence. Conversely, a fresh-looking result is not automatically proof that the tag was physically at the exact point shown, because the report begins with the finder’s location and wireless range.
Imagine a tag hidden in a backpack that moves from a home to a bus and then to a workplace. Different finder devices may observe it along the route. The network can assemble those reports into a useful history for the tag’s owner even though the owner never approaches the backpack. The target carrying the backpack is absent from every arrow in the ordinary lookup flow. They do not have to authenticate, answer a prompt, or consent to the report. If the identifier can be linked across observations, the sequence becomes a movement record; if the identifier is difficult to link, the owner may still receive individual reports through the authorized service. Privacy and safety therefore depend on different questions at the same time: who can connect observations, who can query the resulting record, and who can tell the person being followed that the record exists.
The same timing model applies when the tag belongs to the target. A compromised account can allow an attacker to make a legitimate query without placing a new accessory nearby. The network sees an authorized relationship even though the person affected by the query is not the person using it. Likewise, a shared or transferred tag can have more than one party with knowledge that affects future observations. These are not failures that appear only when a database is breached. They can arise from ordinary protocol state—association, observation, storage, query, and revocation—if the system treats the first registered owner as the whole security story.
Consider the difference between the tag’s location and the finder’s location. If a phone hears a tag in a railway station, the report identifies the station area where the phone was located, not necessarily the exact seat, bag, or person carrying the tag. More observations can improve the owner’s understanding, but the mechanism still depends on the distribution, accuracy, and behavior of finder devices. The service is powerful because many ordinary devices act as sensors; it is imperfect for the same reason.
The system also has two different audiences for the same record. The owner wants enough information to find the tag. A finder device may need only to observe and upload an advertisement. The platform operating that device may control what scanning is allowed in the background, which tag types are recognized, and what data reaches the network. The network may hold the report even when the finder and owner never know each other. A bystander’s phone is therefore not an incidental relay. It is the observation layer that makes the service work.
Trust boundaries are design choices, not labels
The first boundary is the air around the tag. A BLE advertisement is transmitted publicly enough that a nearby receiver can attempt to observe it. That openness enables crowdsourced detection, but it creates a question about linkability: can a receiver tell that two advertisements came from the same physical tag at different times and places? A fixed identifier makes that easy. A changing identifier may make it harder, but only if other details do not provide a stable fingerprint. The IETF threat model treats the privacy of those observations as a design problem, not as a guaranteed consequence of using Bluetooth.
The second boundary is the finder-to-network report. The finder combines two facts that were separate in the air: an identifier and the finder’s own location. That pairing is what gives the owner a useful result. It is also what can expose movement to the service provider or to an attacker who can influence the report path. Transport encryption can protect a message while it is crossing a network, but it does not by itself determine whether the receiving server can read and retain the contents. Location privacy therefore depends on what the network is allowed to learn after delivery, not only on whether the connection is encrypted in transit.
The third boundary is the network-to-owner query. The network must decide whether the requesting device is entitled to receive a tag’s location. In the ordinary case, that authorization is tied to an account or ownership relationship. The word “owner” sounds complete, but it hides several questions. Is there one owner or more than one shared user? Has the tag been transferred? Does a former shared user still possess information that can identify future broadcasts? Has someone gained access to the account through a password, a device, or a web interface? What does the network log when a location is requested?
These are not exotic additions to the architecture. They follow from the fact that state persists across time. The tag has an identifier state. The network has a record of observations and account associations. The owner device has credentials and local knowledge. A sharing or transfer operation changes who may query the network, while a revocation operation is supposed to remove that authority. If old keys or identifiers remain useful, the visible ownership label may change while the practical ability to track does not. The Tile study’s analysis of sharing and transfer examines this kind of lifecycle failure in a specific implementation; the broader lesson is that authorization must be modeled as state that changes, not as a permanent property of a product record.
The target is another role the normal lookup diagram does not show. A target is the person tracked without consent. They may be carrying an attacker’s tag, carrying their own tag through a compromised account, or traveling with a tag hidden in a nearby object. The target does not need to participate in the owner query for the system to affect them. This asymmetry is central: the person who needs protection may have no account relationship with the tag and may not know that a report is being generated.
That is why a system can be functioning exactly as designed and still be unsafe. The tag broadcasts. The finder reports. The network authenticates a request. The owner receives a location. Nothing in that happy path asks whether the owner’s purpose is legitimate, whether the target has consented, or whether the target can discover and disable the tag. The functional flow and the safety flow are different flows. A design must connect them deliberately.
Some parts of the pipeline are practical necessities; others are choices that can be changed. A low-cost tag’s lack of direct internet access is a strong reason to use bystander devices. The exact identifier format, its rotation schedule, the cryptographic protection of location reports, the conditions for background scanning, the handling of multiple tags, the owner information shown to a target, and the retention of activity logs are design decisions. So are the rules for whether a tag can be made invisible to a scan, whether it can signal its presence, and whether a target can disable it after finding it.
This distinction matters when evaluating a vendor’s safety claim. “The tag is encrypted” is incomplete unless the claim identifies what is encrypted, who holds the keys, and which participant can still read the result. “The identifier changes” is incomplete unless the system explains whether other broadcast features or a long-lived key allow observations to be linked. “Only the owner can see the location” is incomplete unless the service’s own visibility and account-access paths are included. “The owner can be held accountable” is incomplete unless the system records trustworthy evidence and gives the affected person a realistic way to trigger, inspect, and preserve it.
The handoffs also explain why a central service can be both essential and dangerous. Without a network, the owner cannot conveniently query reports collected by strangers. With a network, the service becomes a point where identities, observations, and locations may meet. If the architecture exposes that combined information to the platform, the platform may become a surveillance vantage point. If it hides too much from a target, the target may be unable to detect an unwanted tag. If it lets any scanner retrieve too much owner information, an innocent person whose tag is merely nearby may lose privacy.
A well-designed system must therefore answer different questions at different boundaries. The tag needs a way to participate without broadcasting a permanent public handle. The finder needs to report useful observations without becoming a silent source of unnecessary personal data. The network needs to support authorized finding without learning every location or accepting arbitrary false reports. The owner needs access, but shared access and revocation must have real effect. The platform needs to provide scanning and alerts in conditions where the target can safely use them.
Following the pipeline has changed the original question. It is no longer enough to ask whether an owner can be identified after misuse. We must ask where the location first becomes visible, who can link observations, which device can notice persistence, and who controls the state that determines whether an alert appears. The next task is to name the security properties that make those questions precise: privacy for broadcasts and locations, detectability for the person being followed, and evidence that can support accountability without turning a plausible identifier into a false accusation.