From Radio Observation to Provider Record
The WILD Attack becomes intelligible only when the ordinary WPS exchange is made explicit. The important question is where a nearby radio observation becomes a provider-owned location record, and then where that record becomes an application's decision. Tracing those boundaries gives readers a practical way to tell a sensor problem from a shared-state problem—and to see why a precise answer can still be untrustworthy.
Four responsibilities behind one location answer
A Wi-Fi location estimate looks like a single result on a screen, but several systems contribute to it. The first is the scanning device. It listens for nearby wireless beacons and records identifiers such as BSSIDs, along with whatever signal information the positioning service can use. It does not need to join each network for the identifier to be useful as a landmark. The device may also have GPS, cellular information, Bluetooth observations, or other sensor inputs. At this stage, the device has observations, not a conclusion about where it is.
The second responsibility belongs to the positioning provider. A public request to Google's Geolocation API can contain a wifiAccessPoints array. Each access point is identified by a MAC address, and Google says that Wi-Fi-based results require at least two physically distinct, stationary access points. Signal strength and other optional measurements can refine the estimate. The provider receives a description of the wireless environment and uses its accumulated records to calculate a candidate position; it does not simply read latitude and longitude out of the radio signal.
That accumulated state is the third responsibility. The WILD study calls the provider's BSSID-to-coordinate mapping the Location Lookup Table, or LLT. “Table” is best understood as a name for a provider-side stateful service, not as a claim about a particular database schema. The LLT answers a lookup question: given these observed identifiers, what places does the provider associate with them? It can also be changed by new crowd-sourced observations. A device asking for a location is therefore reading state that may have been built by other devices at other times.
The fourth responsibility belongs to the application that consumes the answer. A WPS provider can return coordinates and an accuracy radius, but the application or operating system decides how that result interacts with GPS, cellular positioning, and local policy. In some conditions WPS may be the more precise source; in others, a device may fall back to a less precise source or report that it cannot locate the user. A ride-hailing app, a browser, and an emergency workflow need not make the same choice from the same candidate location.
Those responsibilities create two related but distinct paths. The lookup path begins with a device observing BSSIDs and asking the provider for a location. The update path begins with a device contributing an observation that may create or alter the provider's stored association. The first path is visible to the person waiting for an answer. The second may happen in the background, as part of normal location-dependent activity. Treating them as one undifferentiated “geolocation request” hides the security boundary: the later lookup can be perfectly ordinary while depending on an earlier update that was never adequately verified.
The scanning device is not simply a passive thermometer. Its observations are made in a changing environment, and the operating system decides which signals and measurements are available to a location service. A device may see one access point, several access points, or a mixture of stationary infrastructure and moving transmitters. Google's documentation explicitly says that moving access points, such as those on airplanes and trains, are ignored, because movement breaks the assumption that an identifier is a stable landmark. This is a useful example of a boundary condition: the provider's inference works because it treats certain observations as evidence about a place, not merely as evidence that a radio signal exists.
The provider's public request model exposes another part of that boundary. A Wi-Fi access point object must contain a MAC address, while signal strength, channel, age, and signal-to-noise information are optional. The provider can therefore receive a very compact description of the surrounding environment, but the description is still an input to an inference. The public request model does not describe it as a signed statement from the access-point owner. Filtering broadcast, reserved, or otherwise unusable addresses can keep noise out of the calculation; it cannot settle whether a valid-looking identifier has been associated with the correct coordinates.
The LLT sits between input and answer because it gives the provider memory. Without stored associations, a provider would need a fresh, independently verified survey each time a device asked for its location. With stored associations, a report made at one moment can help another device later, possibly in another place and under different conditions. That is the service's economic and practical advantage: a large population of devices supplies observations that can be reused. It is also the source of hidden coupling. The quality of today's location answer depends partly on decisions made during earlier reporting events that the current device cannot inspect.
A record update and a location lookup may also cross different trust boundaries. On the write side, the provider decides whether a report is admissible and how it changes existing state. On the read side, the provider decides how several stored records combine into a coordinate and an uncertainty radius. The querying device may be authentic, the request may be well formed, and the response may be generated exactly as designed, even if the write-side decision was wrong. Looking only at the read request would miss the event that introduced the error; looking only at the write request would miss the application consequences that make the error important.
The application boundary introduces a final conditional step. A WPS result is a candidate location, not necessarily the last word. An operating system or application may compare it with GPS, cellular positioning, or other signals, and may prefer the source with the smaller reported uncertainty. That choice is ordinarily beneficial when Wi-Fi fills a gap in satellite coverage. It also creates a dependency: if WPS appears more precise because several stored access-point associations agree on the same false place, an application may give the false result more weight than a weak but correct GPS estimate. If the provider has no usable record, the same application may fall back to a broader estimate or fail to locate.
These outcomes are not interchangeable. A false coordinate can cause a service to act confidently in the wrong place. A missing record can expose a lower-precision fallback or stop the service from acting. A record that is merely stale may produce an error that changes gradually as new observations arrive. The provider owns the state that makes these cases possible, while the application owns the final response to them. That division of responsibility is why the WILD Attack cannot be assessed by asking only whether a Wi-Fi frame looked authentic or only whether an app displayed a location.
The provider also owns the meaning of the returned uncertainty. Google's documentation defines accuracy as the radius of a circle around the estimated location. That radius communicates how tightly the input signals constrain the calculation. It is not a chain of custody for the underlying records. If a provider's map associates a BSSID with the wrong place, a calculation using several such associations can still produce a small radius. The number may accurately describe the model's confidence in its inputs while saying nothing about whether those inputs deserve confidence.
The diagram's most important asymmetry is temporal. The reporting device and the querying device may be different devices, operating in different places and at different times. The LLT is the meeting point between them. A person using a location service usually sees only the final response, not the observations that caused the provider to create or revise the record. That makes the provider's update rules as important to location integrity as the device's scanning hardware.
This also explains why a BSSID is useful and fragile as a location key. A stationary access point can be observed from many nearby devices, and a pattern of several identifiers can distinguish one neighborhood from another. Yet the identifier is still only an identifier. It says which beacon was observed; it does not, by itself, prove that the beacon was at a reported coordinate, that it remained there, or that every report referring to it was independent. The system must infer those properties from reporting history and context.
Precision is not provenance
The public documentation from Google and Apple describes useful safeguards, but it describes a different layer of the problem from the one exposed by the WILD study. Google documents which Wi-Fi inputs are useful: access points must have acceptable MAC addresses, and locally administered or reserved addresses may be filtered because they do not make reliable location signals. It also describes how signal strength, the number and density of access points, and the availability of other signals affect the accuracy radius. These rules improve the quality of an input set and make the output easier to interpret.
They do not answer a more fundamental question: why should the provider believe the relationship between an identifier and a place? An address can be formatted correctly and still be reported from the wrong location. A signal can be strong and still belong to an access point whose stored coordinate is stale or corrupted. Filtering unusable identifiers prevents some bad inputs from entering the calculation, but it is not the same as establishing the truth of a usable identifier's location.
Apple's Location Services description makes the collection side more visible. It says that the system can combine GPS and Bluetooth with crowd-sourced Wi-Fi hotspot and cell-tower locations, and that an iPhone periodically sends geo-tagged locations of nearby hotspots and towers to improve the shared database. The same document explains permissions, approximate versus precise access, anonymous and encrypted collection, and controls for disabling location services. Those protections matter to privacy and user choice. They do not, as described in that document, specify how conflicting hotspot reports are arbitrated or how a record is restored after a bad update.
That distinction is not an accusation that the public documentation lists every internal defense. It is a boundary on what the documentation can establish. Google's API page tells an engineer how to format a request and interpret an accuracy response. Apple's privacy page explains how Location Services and its crowd-sourced data are described to users. Neither page is a specification for the providers' internal conflict-resolution logic. The WILD paper therefore had to infer that logic by observing whether records changed after controlled reports were submitted.
The separation between lookup, state, and application choice also reveals a hidden coupling. A provider can make a location result look more precise by using several nearby records, while an application can give that result priority because it is more precise than a weak GPS reading. That is normally a strength: Wi-Fi can help a device locate itself indoors or in a dense city. But the same coupling means an error in shared state can gain authority downstream. The application may not know whether the 12-meter-looking answer came from a well-supported neighborhood map or from a set of records that all inherited the same bad premise.
The reverse failure is different. If records disappear rather than move to a false coordinate, a device may lose its WPS result and fall back to GPS or cellular positioning. That can be less precise but easier to recognize as a degraded service. The difference between a wrong answer and no answer is therefore determined partly before the application runs: it depends on what the provider chose to store, remove, or return. A location system's security properties cannot be judged solely from the final screen or solely from the accuracy radius.
There is a second hidden dependency in the word “crowd.” A large number of reports sounds like corroboration, but reports may share the same application behavior, the same physical signal, or the same assumptions about where an access point is. The public interfaces described by Google and Apple establish how observations can be collected and consumed; they do not establish that a provider has proved the reports independent. If several devices repeat one false observation, the system may see quantity without receiving several genuinely separate reasons to believe it.
For the WILD Attack, this is the boundary that matters. The attack does not need to make a later querying device misunderstand the structure of a Wi-Fi packet. It aims to influence the provider-side state that the querying device treats as a trusted interpretation of that packet. Once that state is separated from the moment of observation, the live radio environment and the stored map can disagree while both appear normal at their respective layers.
The practical model is consequently simple, even though the implementation may not be. The device observes. The provider stores and interprets. The application chooses how much weight to give the result. Security can fail at each handoff: an observation can be misleading, a record can be updated without enough provenance, or an application can treat a precise but unverified answer as authoritative. The next question is what happens when the provider receives legitimate and falsified observations for the same BSSID at different locations, and must decide which version of the map to keep.