What "no" actually blocks
When an app asks for location access and you decline, one specific thing happens: the app loses access to your device's GPS API, the one capable of returning your exact coordinates down to a few meters. That's a real, meaningful block, and it's the correct response for most apps that don't have an obvious reason to need it. But it's also a narrower promise than most people assume it is. GPS is one of several ways to figure out roughly where a device is, and only one of them requires you to say yes to anything.
IP-based location
Every request your device makes online carries its IP address, and IP addresses are tied to geographic blocks assigned to internet providers, which is why a website can greet you with local weather or the right currency before you've told it anything. This works entirely independently of any permission prompt — it's a property of how internet routing works, not a feature the app has to ask to use. The accuracy is usually city-level rather than street-level, but for an advertiser trying to figure out which metro area or country you're in, city-level is often all that's needed. We cover the same mechanism from the browser side in our browser data guide.
Wi-Fi network positioning
This is the one most people have never heard of, and it can be significantly more accurate than IP-based location. Every Wi-Fi router broadcasts a network name and a unique hardware identifier. Google and Apple have spent years building enormous crowdsourced databases mapping those identifiers to physical locations, originally gathered by street-mapping cars and, more continuously, by phones with location services enabled reporting back which networks they can see and where.
How the database gets used without GPS
Once that database exists, an app doesn't need your GPS at all: it just needs to see which Wi-Fi networks are currently in range, look up those networks against the database, and triangulate a location that can be accurate to within a building.
Why it mattered more on older Android
On older versions of Android in particular, reading nearby Wi-Fi scan results required a much lower bar of permission than GPS access, which meant an app could get startlingly precise location data through a door that didn't look like a location request at all. Android has progressively tightened this over recent versions, but the underlying database and technique are still exactly what phones fall back on indoors, where GPS signal is often weak anyway.
Bluetooth proximity tracking
Retail stores, airports, and event venues increasingly deploy small Bluetooth Low Energy beacons that broadcast a constant, quiet signal. An app with Bluetooth access, which historically has been requested and granted far more casually than location access, can detect these beacons and determine not just roughly where you are, but which specific aisle or gate you're standing near — a level of granularity GPS often can't achieve indoors at all. This is how some retail apps manage to send a push notification about a sale the moment you walk past a specific shelf.
What your carrier already knows
Separately from anything an app does, your mobile carrier always knows your approximate location, since your phone has to be in contact with a nearby cell tower to work at all. For years, several major US carriers sold real-time location data derived from this to data aggregators, who resold it further down a chain that in some documented cases reached bounty hunters and location-tracking services with no direct relationship to the carrier or the customer at all. The FCC investigated and fined multiple major carriers in 2024 over exactly this practice. It's worth knowing this layer exists independently of any app or permission setting on your phone at all — it's a function of how cellular networks work, sold as a business line by the carrier itself.
The SDK you never agreed to
This is the mechanism that turns "one app's permissions" into a much bigger problem than it looks like. Many apps don't write their own analytics, advertising, or crash-reporting code; they embed a third-party software development kit that handles it for them, and that SDK runs with whatever permissions the host app has been granted, sending its own data back to its own separate company — a relationship the app's own developer sometimes doesn't fully understand the scope of either.
The X-Mode Social case
In 2020, this stopped being theoretical. Reporting revealed that a company called X-Mode Social had embedded a location-collecting SDK inside hundreds of ordinary apps, including prayer apps, weather apps, and dating apps, collecting precise location data that X-Mode then sold on, with buyers reportedly including government contractors. Apple and Google both banned apps containing the X-Mode SDK from their stores once this became public, and developers using it had to strip it out or lose distribution entirely. The apps themselves weren't necessarily built to spy on anyone; a data-broker business model was riding along inside a piece of code many of those developers had installed for a legitimate, unrelated reason.
Where it all ends up: the broker layer
Individually, none of the signals above necessarily reveal much. The privacy problem shows up once a data broker aggregates location signals across many different apps and SDKs into a single, continuous profile of one device moving through the world over time — which is precisely what regulators have started taking action against.
In August 2022, the FTC sued data broker Kochava, alleging it collected and sold precise location data from hundreds of millions of mobile devices in a form detailed enough to reveal visits to specific sensitive locations, including reproductive health clinics and places of worship, without consumers' knowledge. The case was initially dismissed in 2023 for insufficient allegations, survived an amended complaint in 2024, and concluded in May 2026 with a settlement permanently banning Kochava and its subsidiary from selling or disclosing sensitive location data without a consumer's affirmative, express consent. The nearly four-year timeline is itself informative: proving a data broker's aggregate location product crosses a legal line took genuine, sustained regulatory effort, even in a case regulators ultimately won decisively.
Precise vs approximate, and why it's not nothing
Both iOS and Android now let you grant an app "approximate" location instead of precise, giving it a location accurate to a few miles rather than a few meters — see Apple's own documentation on how the permission model works. It's a genuinely useful middle ground for apps that have a real reason to know your general area (weather, local news) but no reason to know which building you're in. Worth being clear about its limits though: a few miles is still enough to identify which city or neighborhood you live and work in, particularly once combined over time with the other signals in this article, and it does nothing at all against IP-based or carrier-level location, which operate independently of whatever you've selected in the app's own permission screen.
What actually helps
A few things are worth doing in rough order of how much they actually change:
- Turn off Wi-Fi and Bluetooth scanning when you're not actively using them, not just location services. On both major platforms, background scanning for nearby networks and devices can continue feeding the positioning systems described above even with location permission itself denied, since scanning and location access have historically been governed by different settings entirely.
- Choose "While Using the App" over "Always," and approximate over precise wherever the option exists, reserving precise, always-on access for the small number of apps that have an actual functional reason to need it, like turn-by-turn navigation.
- Check what's actually embedded inside your apps. Tools like Exodus Privacy publish independent scans of which third-party tracking SDKs are bundled inside popular Android apps, which is often the only way to find out an app is carrying an X-Mode-style passenger at all, since app store listings rarely disclose embedded SDKs by name.
- Use a VPN specifically for the IP-based layer, understanding clearly what it does and doesn't cover: it replaces your real IP-derived location with the VPN server's, which stops IP-based geolocation specifically, but has no effect on Wi-Fi positioning, Bluetooth beacons, carrier-level data, or an SDK reading your GPS directly once you've granted the app that permission.
Frequently asked questions
If I deny location permission, can an app still know what city I'm in?
Usually yes, through IP-based geolocation alone, which requires no permission at all and works the moment the app makes any network request. City-level accuracy is enough for most advertising and analytics purposes even without GPS.
Does turning off location services fully stop Wi-Fi-based positioning?
Not necessarily, and this is the least understood gap. Location services and Wi-Fi/Bluetooth scanning are governed by separate settings on both major platforms. An app or the OS itself can still scan for nearby networks in the background unless scanning specifically, not just location access, has been turned off.
How would I even know if an app has a tracking SDK like X-Mode's embedded in it?
App store listings generally don't disclose embedded third-party SDKs by name, which is exactly why independent tools exist to check. Options worth knowing about:
- Exodus Privacy, which scans Android apps and publishes which known tracker SDKs are present
- An app's own privacy policy, though disclosure quality varies enormously and third-party SDK relationships are often described only in vague, general terms
Did the Kochava settlement mean the company has to delete the data it already sold?
The FTC's May 2026 settlement focused on prohibiting future sale or disclosure of sensitive location data without affirmative, express consent going forward, rather than a retroactive deletion mandate covering data already sold to third parties in the past, which is a genuinely difficult thing to enforce once data has already changed hands multiple times.
Is any of this different on iPhone versus Android?
The underlying techniques (IP geolocation, Wi-Fi positioning, embedded SDKs, carrier data) apply to both platforms, since none of them depend on which OS is running. The specific permission model differs: iOS has generally been faster to introduce granular controls like approximate location and Bluetooth-specific permission prompts, while Android's more open app-installation model has historically made it easier for SDKs like X-Mode's to spread across a large number of apps before being caught.
Sources
- Federal Trade Commission — May 2026 Kochava settlement press release
- Federal Communications Commission — carrier location data sharing enforcement
- Exodus Privacy — independent tracker SDK scanning for Android apps
- Apple Developer Documentation — iOS location permission model, including approximate location
Written by PrivacyTestLab
This guide is grounded in the FTC's completed enforcement action against Kochava and the documented 2020 removal of the X-Mode Social SDK from major app stores, rather than a general claim about app tracking, cross-referenced against each regulator's own published record.