The oldest privacy myth on mobile is that tracking is mostly about GPS. It is not. Modern app surveillance is an industrial system built from many smaller signals: advertising IDs, app-instance IDs, IP addresses, Bluetooth encounters, sensor exhaust, analytics events, and the hidden software components that shuttle data to third parties. The commercial incentive is enormous. U.S. digital advertising revenue hit a record $259 billion in 2024, and the FTC’s 2024 social-media surveillance report concluded that major platforms engaged in vast data collection to monetize personal information.
Apple’s own definition of “tracking” is useful because it exposes how much broader the ecosystem is than users tend to assume. Under App Tracking Transparency, tracking generally means linking data collected from one app with data from other companies’ apps or websites, or sharing it with data brokers for targeted advertising. That definition already implies the real architecture: collection inside the app, linkage outside it, and resale somewhere farther downstream. GPS is only one input in a much larger machine.
Beyond the Basics (The Technical Layer)
IP Address Tracking
Every app session begins with network metadata, and the most basic field is the source IP address. IPs can usually be mapped to a country, region, city, and ISP or enterprise network. Android’s own disclosure guidance explicitly notes that location can be derived from IP address or access-point information. On its own, an IP address is usually a coarse locator rather than a house number. But once it is joined with timestamps, login state, ad identifiers, or purchase history, it becomes a powerful correlation key.
MAC Addresses
MAC addresses used to be the classic durable identifier: hardware-bound, globally unique, and difficult for users to change. That is precisely why modern platforms have tried to reduce their value. Android’s identifier guidance says developers must not associate Advertising IDs with persistent device identifiers such as MAC address or IMEI, and Android restricts third-party access to device MAC addresses. Apple now uses private Wi‑Fi addresses so devices can present random MAC addresses to networks, with newer versions supporting fixed or rotating modes depending on the network type. The result is important: the old story that any app can freely read your factory MAC address is no longer accurate. The modern problem is subtler. Direct access is constrained, but surrounding infrastructure can still infer presence, recurrence, and proximity.
Device Fingerprinting
When explicit identifiers become resettable or regulated, trackers often fall back to probabilistic identity. Device fingerprinting does not rely on a single stable number. Instead, it combines many semi-stable characteristics into a signature that is unique enough to recognize a device across sessions. Standards bodies have warned for years that exposing device settings and characteristics can enable fingerprinting, and Apple explicitly says some APIs can be misused for fingerprinting even when a user has not granted tracking permission. Even battery state has been identified as a fingerprinting vector, while academic work on mobile fingerprinting points to fields like screen resolution and OS version as useful inputs.
Typical fingerprint inputs include:
- Screen resolution, aspect ratio, and pixel density.
- OS version, patch level, device model, and hardware class.
- Locale, language, time zone, and regional settings.
- Battery level, charging state, and other transient system properties.
- Network metadata such as IP range, carrier, or access-point context.
The point is not that any one field is definitive. The point is that the combination can survive resets that were supposed to restore privacy. That is why Android explicitly warns developers not to bridge Advertising ID resets with another persistent identifier or fingerprinting technique without consent.
The Silent Listeners (Permissions & Sensors)
The most revealing telemetry is often the data users do not think of as location data. Motion sensors are a prime example. On Android, raw accelerometer and gyroscope data do not require the Activity Recognition permission, even though those sensors can be fused to understand how a device is moving through space. In research settings, accelerometer and gyroscope traces have been shown to leak much more than simple “step counts,” including behavioral signatures and environmental clues.
What can sensor streams reveal in practice?
- Whether a user is walking, stationary, driving, or carrying the phone in a pocket, bag, or dashboard mount.
- Repeated motion patterns that can become a behavioral signature when fused with time and app activity.
- Whether two devices are moving together or stopping at the same places over time when sensor and network signals are correlated.
Bluetooth Low Energy adds another layer. Android’s documentation says BLE scanning requires the BLUETOOTH_SCAN permission, and if scan results are used to derive physical location the app must also declare fine location access. Apple’s Core Location framework can monitor entry into beacon regions and range nearby beacons by signal strength. In a mall, stadium, or airport, that means a phone does not need to report “I am in Store X” explicitly. The app can infer it from beacon proximity, dwell time, and repeat visits. With enough backend correlation, proximity to a store becomes a consumer signal; proximity to another phone becomes a social one.
The Paper Trail (Software Development Kits)
Most apps are not single products so much as software supply chains. A fitness app, weather app, or puzzle game may bundle analytics, attribution, crash-reporting, login, A/B testing, and ad SDKs from several outside companies. Large-scale Android research shows that the majority of apps embed multiple third-party SDKs, with one recent study putting the average at about 8.6 SDKs per app. That matters because an SDK can operate under the visual identity of the host app while the actual data flow ends at a third party the user has never consciously chosen.
Google’s Firebase Analytics is a clear illustration of the plumbing. Its documentation exposes APIs for logging events, retrieving an app-instance ID, setting user IDs, and storing user properties across sessions; Google describes it as an app measurement solution for app usage and engagement. Meta’s iOS SDK documentation similarly warns developers that tracking events collected and sent to Facebook may require disclosure under Apple’s privacy rules. None of that is inherently improper—SDKs also support fraud prevention, debugging, and product improvement—but it means the phrase “innocent app” can be misleading. The more accurate question is: which vendors ride inside it, and what data do they receive?
Platform owners have started responding to that hidden layer. Apple says developers are responsible for the behavior of third-party SDKs bundled into their apps, and the company now requires privacy manifests for many SDK scenarios so developers must declare data collection, tracking domains, and use of certain sensitive APIs. That does not eliminate the paper trail, but it confirms the basic investigative fact: some of the most consequential privacy behavior in an app may live in code the app developer did not write and the user never sees.
The Economic Engine (Data Brokers)
A single app event becomes economically valuable when it leaves its original context. The FTC says data brokers compile detailed consumer profiles from online and offline sources, often without people’s knowledge, and then sell or transfer those profiles to businesses and other brokers. Recent FTC actions show what that can mean in practice: brokers handling precise or sensitive location data tied to visits to clinics, places of worship, shelters, and other intimate venues.
How one data point travels
A typical journey looks like this:
- An app records an event: app open, ad click, purchase, beacon encounter, or location update, tagged with time, IP address, and a device-level or app-level identifier.
- An embedded analytics or advertising SDK transmits that event to the vendor’s servers as part of routine app measurement or ad attribution.
- The vendor enriches it with other streams—web activity, other apps, offline commercial data, or historical location—until it becomes a profile attribute rather than a single event.
- A broker or downstream partner packages the result into audience segments, risk scores, or location-derived products and sells access to them.
- Sensitive inference emerges: not merely “device visited coordinate X,” but “likely commuter,” “frequent pharmacy visitor,” or “regular attendee at a sensitive venue.” FTC complaints against location-data firms show how quickly raw telemetry can become intimate conclusion.
The same machinery can extend beyond registered users. Privacy researchers use the term shadow profiles for profiles inferred from fragments collected elsewhere—contact uploads, ad-tech identifiers, web pixels, and social graphs. Academic work on Facebook tracking found substantial observation of browsing behavior for both users and non-users, and related research describes “partial” and “full” shadow profiles in which missing facts about a person are filled in through other people’s data. In plain terms: you do not always need an account to be modeled. Sometimes you only need to be adjacent to people who do.
The Countermeasures
App Tracking Transparency (ATT)
Apple’s ATT framework remains one of the clearest consumer-facing interventions. Since iOS 14.5, apps must ask permission before tracking a user across other companies’ apps and websites or sharing data with brokers for advertising. That matters. But ATT is not a full invisibility cloak. Because Apple’s definition focuses on cross-company tracking, an app can still perform some first-party analytics and core functionality measurement inside its own environment. That is why Apple’s anti-fingerprinting rules matter just as much: the company explicitly says fingerprinting is not allowed, regardless of whether a user granted tracking permission.
Privacy Sandboxes
Google’s Privacy Sandbox on Android was designed around a different bargain: preserve key advertising use cases while reducing reliance on cross-app identifiers. Its Topics API was meant to generate coarse, on-device interest signals, and its Attribution Reporting API aimed to measure conversions without cross-party user identifiers. But there is an important update here: Google’s own documentation says Privacy Sandbox on Android was deprecated on October 17, 2025. That makes it less a settled privacy destination than a revealing experiment in where platform thinking appears to be heading—toward on-device classification, coarser signals, and aggregated measurement instead of raw identity sharing.
DNS filtering
The most practical defense many users can deploy immediately is below the app layer. DNS filtering blocks requests to known tracking or advertising domains at the name-resolution stage, and encrypted DNS protocols such as DoH and DoT reduce the ability of intermediate networks to see which domains you are querying. Android supports Private DNS, which lets users point the device at a chosen encrypted resolver. The limits are real: DNS filtering cannot stop a tracker hidden behind the same first-party domain the app genuinely needs, and it cannot prevent data you deliberately type into the app from reaching the service operator. What it can do is cut off a large class of routine third-party calls before they leave the device.
Pro-Tip: Improve your privacy in the next 10 minutes
- On Apple devices, go to Settings → Privacy & Security → Tracking and deny cross-app tracking requests you do not trust; ATT exists specifically to limit data linking and sharing across companies for advertising and brokerage uses.
- On Android, treat the advertising ID as a resettable ad token, not a harmless background detail; reset it regularly and review which apps truly need Bluetooth or precise location.
- Use a reputable encrypted DNS or Private DNS filter on mobile to block known tracker domains before apps can resolve them.
- Delete apps you do not actively use. Every installed app is a standing telemetry surface, and research shows the average app carries multiple third-party SDKs.
The Future of Privacy in an AI-Driven World
The next phase of app tracking will be defined less by one spectacular identifier than by inference. In an AI-driven market, the value of weak, messy, incomplete signals rises because models can extract patterns humans would never spot in isolation. A few motion traces, some beacon encounters, a sequence of app events, and a history of coarse locations may not look like a dossier to a casual observer. Joined together, they can become one. The privacy question is therefore shifting from What data was collected? to What can be inferred when hundreds of small signals are combined? That is a harder question, and a more urgent one. The future of privacy will depend not just on better prompts and disclosures, but on limiting linkage, hidden third-party collection, retention, and the downstream use of AI to turn exhaust into identity.