Location History and Geolocation Artifacts

The GNSS receiver in a modern smartphone can fix position to within 3 to 10 metres under open sky. The chipset logs raw measurements and computed fixes, and the operating system exposes these to applications through a location API. Applications that request location permission receive a stream of coordinates, which they may store in their own databases. The operating system itself may also cache recent fixes for performance.

On iOS, the most forensically significant GPS artifact is the Significant Locations database at /private/var/mobile/Library/Caches/com.apple.routined/. The main SQLite file, LocalHistory.db (or in older versions, Cache.db), contains visit records with start time, end time, latitude, longitude, and an uncertainty radius. Apple encrypts this database, and access requires either the device passcode or a physical acquisition with hardware decryption. The database persists across device restarts and is not cleared by a standard app uninstall.

On Android, there is no single equivalent to Significant Locations. The Google Location History feature, when enabled, sends location data to Google's servers and stores it in the Google Maps timeline. The on-device cache of recent GPS fixes is held in /data/misc/location/ or in chipset-specific directories that vary by manufacturer. Application-specific GPS records are in each application's data directory under /data/data/[package.name]/. Photo EXIF metadata is a reliable secondary source: when location permission is granted to the camera app, each image stores the GPS coordinates at the time of capture in the EXIF GPS tags.

Wi-Fi based location works by matching the MAC addresses of nearby access points against a crowd-sourced geolocation database. When a device scans for networks, it hears beacons from access points and can query a database (Apple's, Google's, or a third-party service) to retrieve the known coordinates of those access points. This method works indoors where GPS cannot, and it resolves position to within 15 to 40 metres in areas with dense access point coverage.

The Wi-Fi connection history is stored in several places on a device. On iOS, the preferred network list and connection timestamps are in /private/var/preferences/com.apple.wifi.plist and related property lists in the wifi.d directory. On Android, the WifiConfigStore.xml file (path varies by Android version, typically under /data/misc/wifi/) stores SSIDs, BSSID of the connected access point, and the last connected timestamp for each remembered network. These records confirm that a device connected to a specific network at a specific time, which can be mapped to the physical location of that access point.

Probe requests are a separate and often overlooked artifact. When a device's Wi-Fi radio is on and not associated with a network, it broadcasts probe request frames listing the SSIDs in its preferred network list. Any access point or passive 802.11 monitor within radio range can capture these frames. A hotel, retailer, or transport operator that runs a wireless monitoring system may hold logs of probe requests including MAC address, SSID advertised, timestamp, and signal strength. From signal strength, an experienced analyst can estimate rough distance. From the SSID list in the probe, an analyst can infer which networks the device owner habitually connected to, potentially revealing home network, workplace network, and frequently visited locations.

Every time a mobile device registers with a cell tower, the network operator logs the event. The log typically records: the device's IMSI and IMEI, the tower identifier (Cell-ID), the timestamp, and in some systems the signal strength and the sector of the tower that served the device. These records accumulate continuously whenever the device is powered on and in coverage, regardless of whether any call, message, or data session is active.

The geographic area covered by a cell tower varies from a few hundred metres in a dense urban deployment to several kilometres in rural areas. A single Cell-ID therefore places a device within a zone, not at a point. Where operators provide sector information (most tower sites have three directional sectors), the zone narrows further. Drive-test data, which maps signal coverage against GPS coordinates, can help an analyst define the probable coverage footprint of a specific tower and sector at a given time.

Tower dumps are requests for all devices registered at a given tower during a time window. They are used to identify suspects who were near a crime scene. A tower dump for a busy urban tower during a peak hour may return tens of thousands of records, requiring filtering by other criteria such as devices that also appeared at a second location or devices matching a known IMEI prefix. Admissibility of tower-dump evidence has been challenged on privacy grounds in multiple jurisdictions, and some courts have required particularity before authorising broad requests.

Applications that request location permission store coordinates in their own SQLite databases, property lists, or JSON files. The content and structure varies by application, but the forensic approach is consistent: acquire the application's data directory, parse the database schema, and extract any table containing latitude and longitude columns together with timestamps.

Google Maps on Android stores search history, destination history, and navigation logs in the com.google.android.apps.maps package directory. The visited_locations.db or equivalent file (the schema has changed across versions) records coordinates and timestamps for places the user searched or navigated to. Apple Maps stores similar data in com.apple.Maps on iOS, including recents and favourite locations with timestamps. Fitness applications such as Strava, Nike Run Club, and Apple Fitness store route traces as ordered sequences of GPS coordinates with timestamps at one-second or sub-second intervals, making them among the most detailed location records available.

Social media applications record the location at which posts and stories were created, and some store a separate location history for the purpose of serving local content. Dating applications, delivery applications, and ride-share applications all generate location records as part of their core function. When a target application has been deleted, its data directory may be recoverable through file-system carving if the blocks have not been overwritten. The deleted data recovery methods described in Deleted Data Recovery on Mobile Devices apply directly to application location databases.

Geolocation correlation is the process of combining location records from two or more independent sources to produce a movement timeline with higher confidence than any single source would support. The output is typically a sequence of time-anchored position estimates, each labelled with the source or sources that support it and an accuracy estimate.

The basic method proceeds in four steps. First, collect all available location records: GPS fixes from the device, Wi-Fi connection logs, application location databases, and CSLI from the network operator. Second, normalise timestamps to a single timezone and verify each source's clock accuracy. Third, plot each record on a timeline, noting the source, coordinates or coverage area, and accuracy. Fourth, look for periods of agreement, periods of conflict, and gaps.

Conflicts between sources require explanation rather than dismissal. A GPS fix placing a device at point A while a cell-tower record places it within the coverage area of a tower serving a different neighbourhood is a genuine conflict that must be resolved. Possible explanations include: GPS fix cached from an earlier time (check the fix timestamp versus the cell registration time), the device moved between the GPS fix and the next cell registration, or one of the records has an error. The analyst must document which explanation is adopted and why.

Gaps in the timeline are as evidentially significant as the records themselves. A device that appears at location A at 10:00 and location B at 11:00 may have taken any route between those points. The analyst should calculate the minimum travel time between A and B (using reasonable assumptions about transport mode) and compare it to the one-hour window. If the journey is physically impossible in the available time, that is material evidence. If it is possible, the gap is simply uninvestigated, not evidence of any particular route.

Commercial forensic tools commonly used for location artifact extraction include Cellebrite UFED (with the Physical Analyzer report module), Oxygen Forensic Detective, and Magnet AXIOM. Each tool parses known application database schemas and presents location records in a timeline view with map overlay. Analysts should verify the tool's output against the raw SQLite database for any record cited in a report, because tool parsers can misinterpret schema changes in application updates.

Open-source options include iLEAPP (iOS Location Evidence Artefact Parser) and ALEAPP (Android Location Evidence Artefact Parser), both actively maintained community tools that parse device images without a commercial licence. These tools are widely accepted in court when the analyst can demonstrate they understand the underlying database structure and can validate the output independently.

Expert testimony on geolocation evidence faces scrutiny in several areas. Accuracy claims must be grounded in documented specifications, not general familiarity with GPS. Coverage mapping for cell-tower evidence should be supported by operator-provided drive-test data or publicly available propagation models, not just a circle drawn at a nominal radius. The relationship between a location record and a specific person requires the additional step of establishing that the device was in that person's possession at the relevant time, which is a separate inferential step from the location analysis itself. See Digital Evidence in Mobile and Network Contexts for the broader evidentiary framework.