Default Settings Let Ad Trackers Harvest Location Data From Millions of Android Apps

The Invisible Handoff

When you tell a weather app where you are, you expect it to fetch the forecast for your city. When you authorize a fitness tracker to see your running route, you understand the trade. What you probably don't expect is that the same tap of "Allow" may also route your coordinates to advertising networks, data brokers, and eventually government agencies.

Research from the Electronic Frontier Foundation shows that many Android app developers are inadvertently becoming data couriers. The culprit is not malicious intent but architectural default: software development kits embedded in apps to serve ads automatically inherit whatever permissions the host app requests. If the app asks for precise location and the user agrees, the SDK gets it too, unless the developer explicitly shuts off that pipeline.

At DailyTechWire, we've tracked the Asia-Pacific mobile advertising ecosystem long enough to know that SDK bundling is standard practice. What this research underscores is how rarely developers audit what those bundles actually do once deployed.

How Permission Inheritance Works

Android's permission model operates at the app level. A user grants location access to the app as a whole, not to individual components inside it. Third-party SDKs, the snippets of code that handle ad placement or analytics, inherit those permissions the moment they initialize.

The EFF's methodology was straightforward: researchers installed apps, granted location permissions, then monitored network traffic to see which remote servers received coordinate payloads. The pattern repeated across titles: user taps Allow, app collects location, SDK relays that data to its own backend, often without the developer writing a single line of code to enable it.

Bill Budington, a senior staff technologist at the EFF, noted that while the SDKs examined represent a fraction of the broader ad-tech stack, they claim reach across tens of thousands of apps and billions of users. Two Android apps alone, identified in the research, have been downloaded a combined sixty million times and were quietly transmitting location data through embedded SDKs.

There is no Android API for SDK-specific location permissions. Once the gate is open, every piece of code inside the app can walk through it.

The Broker Chain

Advertising SDKs are pitched to developers as a monetization layer: integrate a few lines of code, serve targeted ads, collect revenue. The implicit cost is data. Location histories flow from the SDK to the ad network, then onward to data aggregators who package and resell the information.

Buyers of this data include not only marketers but also military contractors, federal law enforcement, and intelligence services. The FBI, for instance, has purchased location datasets from commercial brokers rather than seeking warrants, a practice that has drawn legal scrutiny but remains widespread.

The same datasets pose security risks. Several data brokers have suffered breaches in recent years, exposing not only where users go but patterns that reveal home addresses, workplaces, and daily routines. When location data leaks, it doesn't just reveal a dot on a map; it reveals life.

Developer Blindness

Many app creators, particularly smaller studios and independent developers across Southeast Asia and India, rely on SDK documentation that emphasizes ease of integration. What those guides rarely highlight is that data collection settings default to maximum permissiveness.

The EFF argues that this design is not accidental. The companies offering SDKs are commercially motivated to harvest as much data as possible; their business models depend on data volume and granularity. Making data sharing opt-in rather than opt-out would shrink those datasets, and with them, revenue.

For a developer in Jakarta or Bengaluru building a casual game or utility app, the priority is often functionality and speed to market. Auditing network calls from a third-party SDK, especially one wrapped in obfuscated code, requires time and expertise that many small teams lack.

The result is a silent delegation of user privacy. The developer thinks they're adding an ad banner. The SDK thinks it's doing exactly what it was designed to do. The user assumes their weather app isn't telling advertisers they visit the gym every Tuesday at six AM.

Policy Gaps and Friction

Android's permission model has evolved, especially around location. Recent versions of the operating system introduced approximate location as an option, and users can now grant location access only while the app is in use. But these controls still operate at the app level. There is no mechanism for a user to say, "The app can have my location, but the ad SDK inside it cannot."

Google's policy for the Play Store requires developers to disclose data collection in privacy labels, but enforcement is inconsistent and the labels themselves are often vague. A declaration that an app "shares location data with third parties" does not convey the broker chain or end use.

Europe's GDPR and California's CCPA impose consent requirements, but both rely on the assumption that developers know what data their apps collect. When an SDK operates as a black box, that assumption breaks down.

The EFF's research does not call for banning advertising SDKs outright. Instead, it urges a shift in defaults: SDKs should collect only what the developer explicitly enables, not everything the app is allowed to access. That change would require cooperation from ad networks, whose incentives currently run in the opposite direction.

What Developers Can Do Now

Until platform-level or regulatory fixes arrive, the responsibility falls on developers. The EFF recommends several steps: audit which SDKs are embedded in an app, review their documentation for data collection settings, disable location sharing unless it directly supports the SDK's function, and test network traffic to verify what data actually leaves the device.

For developers working with ad networks, it is worth asking whether location data is necessary at all. Many ad targeting models can operate on coarser signals, device type, language, time of day, that don't require precise coordinates.

Transparency with users also matters. If an app does share location with third parties, stating that clearly in plain language, not just in a privacy policy, builds trust and gives users the information they need to make informed choices.

The Broader Reckoning

This issue is a microcosm of a larger tension in mobile ecosystems: the gap between what users think they're authorizing and what actually happens behind the interface. Permissions are blunt instruments. They assume that all code running inside an app has the same purpose and the same relationship with the user. In practice, an app is often a composite, mixing the developer's own logic with third-party modules that serve entirely different masters.

As regulatory pressure mounts and users become more privacy-conscious, the current model, where data flows freely by default and developers must actively intervene to stop it, will face increasing scrutiny. The question is whether the ad-tech industry will adjust its defaults voluntarily or wait for mandates.

For now, millions of Android users are sharing more than they realize, one permission grant at a time, because the architecture assumes sharing is the goal and silence is consent.