The Electronic Frontier Foundation published an investigation this month into advertising SDKs — the third-party code libraries app developers embed to sell ad inventory — and the finding is one of those results that is simultaneously unsurprising and worse than you expected.

Four widely used Android ad libraries collect or transmit precise device location by default, once the host app has location permission. Not after a prompt. Not after a consent dialog. By default, as the documented behaviour.

The SDKs named: BidMachine, InMobi, Verve’s HyBid, and Huawei’s Petal Ads.

The mechanism

This is not a vulnerability. Nothing was exploited. It is a straightforward consequence of how Android’s permission model works, combined with defaults chosen by the SDK vendors.

Android grants permissions to an application, not to code within an application. When you tap “Allow” on a location prompt, that grant attaches to the app’s process. Every library linked into that process — analytics, crash reporting, advertising, payments — holds the same permission. The operating system has no concept of “this app may use location, but the ad library inside it may not.”

So the chain runs like this:

  1. A weather app, a fitness tracker, or a delivery app asks for location. You grant it, for an obvious and legitimate reason.
  2. The app also embeds an ad SDK, because that is how it makes money.
  3. The SDK’s default configuration calls the location API — which succeeds, because the process holds the permission.
  4. Coordinates go to the ad network, and from there into the real-time bidding stream, where they are visible to every participating bidder.

The user gave permission for step 1. Steps 2 through 4 are invisible.

The developer usually doesn’t know either

This is the part that changes how you should think about the problem.

The EFF’s finding is not that app developers are secretly selling your location. It is that many of them have no idea their app is doing it. A developer integrates an SDK by adding a dependency line and an API key. The default behaviour is documented — that is how EFF identified these four, from the vendors’ own public documentation — but SDK documentation is long, and the location-by-default behaviour is not usually the headline.

The result is a shipping build that transmits coordinates to a third party while:

  • the app’s own in-app consent flow says nothing about third-party location sharing, and
  • the app’s Google Play Data safety listing — the label users are told to check — says nothing about it either.

Play’s Data safety section is self-declared by the developer. A developer who does not know their ad SDK sends location will not declare that it does. The label is accurate to the developer’s understanding and wrong about the app’s behaviour.

That is a failure mode no amount of careful label-reading by users can catch.

Why the incentives point this way

Location makes ad inventory worth more. Geographic targeting commands higher CPMs, and location history is the highest-value behavioural signal in mobile advertising — it reveals where you live, where you work, what stores you enter, what clinics you visit, and who you spend time near.

SDK vendors compete for developer adoption on revenue per impression. An SDK that sends location earns more per impression than one that does not. So the vendor that sets location collection to on by default delivers better numbers to developers evaluating which library to integrate, and the vendor that defaults to off loses the comparison.

The default is not an oversight. It is a competitive position, and the cost of it is borne entirely by people who are not party to the transaction.

Where this data ends up

EFF’s framing on this is worth quoting in substance rather than paraphrase, because the harms are documented rather than hypothetical. Location data sourced from the advertising industry has been used for:

  • ICE investigations — the same commercial location supply that feeds the skip-tracing contracts
  • Global commercial spy tools sold to state and private clients
  • Outing a gay priest, whose Grindr-derived location data was purchased and used to force his resignation
  • Tracking union organizers
  • Tracking US military and intelligence personnel, via location data from apps on their phones — a national security exposure the Pentagon has repeatedly flagged

None of that required hacking anything. Every one of those cases ran on data that was collected under a legitimate-looking permission grant and then sold.

What to actually do

Android’s model makes this hard to fix from the user side, but not impossible. In rough order of effectiveness:

  1. Set location to “Ask every time” or “Deny” for every app that isn’t a map. Android 11+ supports one-time grants. A weather app does not need background location; it barely needs foreground location if you type in a city. This is the single highest-impact change.

  2. Use “Approximate” instead of “Precise” wherever the app still works. Android 12+ lets you downgrade a location grant to a coarse, fuzzed location. Weather, news, and most commerce apps function fine on approximate. Ad SDKs get something far less valuable.

  3. Delete your advertising ID. Settings → Privacy → Ads → Delete advertising ID. This does not stop location collection, but it severs the stable identifier that lets buyers stitch your location history together over time. It is the difference between a track and a dot.

  4. Audit which apps hold location. Settings → Location → App location permissions. Sort by “Allowed all the time.” Almost nothing belongs in that category.

  5. Prefer apps that don’t carry ad SDKs at all. F-Droid apps are built from source and generally SDK-free. Paid versions of apps often ship without the ad libraries — a one-time $3 purchase is frequently the cleanest available fix.

  6. Check Exodus Privacy (reports.exodus-privacy.eu.org) before installing. It statically analyses Android apps and lists every tracker SDK found in the binary. It reports what is actually in the app, not what the developer declared — which is exactly the gap this investigation exposed.

What should change

The structural fix is at the operating system layer, and it is not technically hard: per-library permission scoping. Android already isolates some third-party code; extending permission grants to be library-scoped rather than process-scoped would kill this entire class of leakage. Google has not done it, and the reason is not mysterious — Google’s own business is advertising, and the majority of the location data in the bidding stream flows through infrastructure Google operates.

The regulatory fix already exists on paper. Under the GDPR, precise location tied to a persistent identifier is personal data, and transmitting it to an ad network without a valid basis is unlawful — regardless of whether the developer intended it. Under the state comprehensive laws, precise geolocation is sensitive data requiring opt-in consent in most of the twenty states that now have one.

The enforcement gap is that nobody is looking inside the binaries. EFF just did, and found four.

The pattern

The consent model for mobile privacy assumes the app is the unit of trust. You evaluate an app, you decide whether to trust it, you grant it a permission.

But the app is not the unit of behaviour. The app is an assembly of code from a dozen vendors you have never evaluated and cannot see, each with its own business model, operating under a permission you granted to the assembler. The developer is trusted; the developer’s dependencies are not, and the operating system cannot tell the difference.

Every mobile privacy control you have is built on a distinction the platform does not actually enforce.