Ad SDKs inherit your app's location permission by default

If you ship an Android app and it asks for location, you are probably also handing that location to advertisers and data brokers — and you may have never agreed to it. New findings from the Electronic Frontier Foundation say the third-party advertising SDKs developers embed to monetize apps inherit the app's location permission by default, with no separate consent layer and no opt-out unless the developer goes looking for one.

What actually happened

As TechCrunch reports, the EFF's report found there are no SDK-specific location permissions on Android. Once a user grants location to the app, the ad SDK bundled inside it gets the same precise location — and collection is on unless the developer actively switches it off.

The EFF identified Android apps quietly sharing user location this way, including two with a combined 60 million downloads. Bill Budington, a senior staff technologist at EFF, noted that the SDKs examined represent a small slice of the overall ad ecosystem but claim to reach billions of users across tens of thousands of apps.

Where the data goes is the part that should get your attention. Precise location collected this way feeds the location data broker market, which resells to advertisers, and onward to governments and intelligence agencies. EFF's position is direct: advertising SDKs should not make sharing personal data the default, "especially for data as sensitive as a person's location."

Why third-party SDK permissions matter for your business

The failure mode here isn't malice. It's that permission models are scoped to the app, and your app is not one thing — it's your code plus every vendor SDK you dropped in for analytics, crash reporting, attribution, and ads. The user sees one prompt. Behind it sit five companies.

That's your liability, not the SDK vendor's. Your privacy policy has your name on it. Your app store listing has your data-safety declaration on it. Under state privacy laws and the GDPR, you're the one who has to explain what you collect and who receives it — and "our ad SDK did that" is not a defense that survives a regulator or an angry customer.

For a small business shipping a customer-facing app — a loyalty app, a field-service app, a booking app — this is a fifteen-minute audit that almost nobody runs:

1. List every SDK in your build. Actually read the dependency tree, not your memory of what you added. Anything you can't justify in one sentence comes out.
2. Check each one's default data collection. Assume it's on. Find the config flag that turns location off and set it explicitly, even when the docs say the default is already off — defaults change between versions.
3. Ask whether you need precise location at all. Coarse location or a ZIP code satisfies most business requirements. Precise GPS is a liability you're storing on someone else's server.
4. Reconcile your data-safety declaration with reality. If the SDK ships location and your listing says you don't collect it, that gap is the actual exposure.

We've written about the same shape of problem in npm dependency compromises and OAuth apps holding your CRM. Different ecosystem, identical lesson: you own what you ship, including the parts you didn't write.

Sources: TechCrunch, Electronic Frontier Foundation.