The Invisible Map Behind Wi-Fi Location
The subject of this series is the WILD Attack, a recently described way to undermine Wi-Fi-based geolocation by poisoning the shared records maintained by Wi-Fi Positioning System providers. The immediate question is not whether a radio signal can be forged, but whether a provider can be induced to remember the wrong place; understanding that distinction gives readers a way to judge both the study's evidence and the defenses it proposes.
A location estimate built from other people's observations
When people hear “location,” they often picture a device calculating its position from satellites. That is only one route. Satellite signals can be weak indoors, distorted among tall buildings, unavailable during interference, or absent because a laptop or other device has no GPS hardware. In those situations, a device can use its surroundings as clues. Nearby mobile networks and Wi-Fi access points become landmarks whose known locations help estimate where the device is.
A Wi-Fi access point is the familiar device that provides wireless network access. It also broadcasts an identifier called a Basic Service Set Identifier, or BSSID. A phone or computer can observe the BSSIDs around it without joining those networks. A WPS provider can then compare the observed identifiers with records it has accumulated from earlier measurements. If the records are reliable, the surrounding wireless landscape acts like a rough map: several known access points, seen together, narrow down the likely position.
Google's public Geolocation API documentation makes this model concrete. A request can include a list of Wi-Fi access points, each identified by a MAC address, and Google's documentation says that Wi-Fi results require at least two physically distinct, stationary access points. The response contains latitude and longitude plus an accuracy value expressed as a radius around that estimate. The radius is important. It describes uncertainty around the answer; it does not certify that every underlying association between an access point and a place is true.
Apple describes a related system in its Location Services privacy documentation. Location Services can combine device sensors such as GPS and Bluetooth with crowd-sourced Wi-Fi hotspot and cell-tower locations. An iPhone may periodically send geo-tagged locations of nearby hotspots and towers to improve that shared database. Apple's description focuses on permission, anonymization, encryption, and user controls, while Google's documentation focuses on the shape and quality of location inputs and outputs. Together, these sources show both sides of the service: devices contribute observations, and a provider turns accumulated observations into a location capability.
It is useful to separate three things that are often treated as one. The first is the radio fact: a device detected a particular identifier at a particular moment. The second is the provider's inference: that identifier is probably associated with a place. The third is the application claim: the person using the device is probably at that place. Each step adds interpretation. A device can genuinely detect a signal while the provider's record is stale, and the provider can return a mathematically precise coordinate even when the association behind it is wrong.
The public API model also shows why the identifier is such a powerful key. Google does not need the device to join the network for the BSSID to be useful as an input; the documented request is built around observed access-point identifiers and signal information. The service filters certain unusable or reserved addresses, but those input checks are about whether an identifier is suitable for location estimation, not whether a person has proved the identifier's physical ownership or current position. That distinction will become important when reports disagree.
Crowd-sourcing gives the system reach and freshness that a provider could not obtain by surveying every building itself. It also makes the LLT a historical object. A record may reflect many observations gathered at different times by different devices, while a later lookup sees only the provider's current conclusion. The device asking for a location is usually not shown that history. It receives an answer and an uncertainty radius, not a provenance trail explaining which observations established the answer or why one location defeated another.
This is where apparent precision can become misleading. Google notes that Wi-Fi accuracy depends on the source, number, density, and strength of available signals. More strong signals can narrow the reported radius, but a smaller radius describes confidence in the calculation given the stored associations; it does not independently validate those associations. In other words, precision and integrity are related but not interchangeable. A system may be very good at calculating a location from its map and still be vulnerable if the map contains the wrong landmarks.
The crucial object in that picture is not the signal alone. A signal exists at a particular moment and can disappear when a device moves. The provider's record can persist after the original observation, and later devices may rely on it without knowing who supplied it or how recently it was checked. That record is the hidden layer between “I can see a Wi-Fi access point” and “the service believes I am here.”
The shared record is the real point of failure
The WILD Attack—short for Wi-Fi Infrastructure-Level Disruption—focuses on that hidden layer. In the study's terminology, the provider maintains a Location Lookup Table, or LLT, that associates BSSIDs with geographic coordinates. The table is not necessarily a literal table exposed to users; it is a useful name for the provider-side state that answers the question, “Where has this access point been observed?”
The distinction matters because a conventional Wi-Fi positioning spoofing attack works on the victim's immediate environment. An attacker brings rogue access points near the victim, makes them resemble legitimate ones, and may interfere with genuine signals. The victim's device is then receiving an unusual local radio picture. Such an attack can be conspicuous, requires physical proximity, and generally loses its effect when the rogue transmissions stop.
The WILD Attack changes the layer being targeted. The study describes an attacker who causes observations of selected, legitimate access-point identifiers to be reported from a different location. Those observations enter the ordinary crowd-sourcing process and compete with reports from the access points' real surroundings. If the provider updates its LLT using the falsified coordinates, the shared record—not the victim's local radio environment—has been altered. A later device can scan perfectly ordinary Wi-Fi at the victim location and still receive a false result or no result because the provider is consulting a damaged map.
That is why the attack is more than a stronger version of signal spoofing. It separates the place where the misleading input is created from the place where the consequence is felt. The reporting location can be chosen elsewhere; the victim does not need to be approached at the moment they ask for directions, request a ride, or use a location-aware website. The proposed attack also aims at persistence. Once a provider has changed or removed a record, stopping the falsified reports does not necessarily restore the earlier state immediately.
The WILD study examined four providers—Google WPS, Apple WPS, A-Map, and WiGLE—and found that their observed responses to the same broad conflict were not alike. One might replace a coordinate, another might remove the record, and a third might let successive reports pull the record from one place toward another. Those differences are not implementation trivia. They determine whether a user receives a confident but wrong answer, an obvious failure to locate, or an answer that drifts while still appearing usable.
The evidence also has a necessary boundary. The authors used access points and devices under their control, designed the experiments to avoid misleading real users, and restored affected records. Their results are controlled demonstrations and black-box observations, not a report of an uncontrolled public outage. They show that the data path and observed update behavior can support the attack under tested conditions; they do not reveal every internal safeguard or prove that every production record behaves identically.
The question WILD Attack raises
The central question is therefore a question about trust in shared state: when a provider receives reports that point the same BSSID to different places, how does it decide what to believe? A system that always accepts the newest or most numerous observations may preserve availability while silently publishing a false location. A system that rejects every conflict may protect against false precision by returning no location, but it can also turn a temporary disagreement into a lasting service failure. A system that averages observations may produce a plausible coordinate that corresponds to no actual place at all.
This is also why privacy and integrity must be considered separately. Apple's permissions and privacy controls govern when location information may be used and how crowd-sourced data is described. Google's filtering and accuracy documentation help define usable inputs and communicate uncertainty. Those are valuable protections, but they do not, on their own, answer whether a reported BSSID was physically present at the reported coordinates, whether multiple reports are independent, or how an old record is repaired after a conflict.
The rest of this series follows that distinction through the WILD Attack and the four providers it studies. It will first make the device, provider, and application boundaries concrete; then it will examine how falsified observations enter the normal reporting path, how conflict policies produce different LLT outcomes, and why those outcomes can persist. It will also test the practical significance under weak GPS and GPS-less conditions, before asking what a resilient provider should do. The immediate next step is to look more closely at the ordinary exchange itself: what a device sends, what the provider remembers, and where a location estimate acquires its apparent precision.