EFF: ad SDK defaults can quietly turn your location permission into broker data
A credited summary of EFF’s investigation into mobile ad SDKs that collect and share location by default once an app has location permission. The practical takeaway for app teams is uncomfortable: your app can be ‘leaking’ location via monetization plumbing even if your product never uses it.
Original post (source): Electronic Frontier Foundation (EFF) - “Developers: Beware of Ad Libraries that Betray Your Users’ Location Privacy” (Aug 4, 2026)
What EFF is warning developers about
EFF’s report is blunt: once a user grants your app location permission, embedded ad SDKs can inherit that access. If those SDKs are configured with privacy-invasive defaults, they can collect and share location data for ad targeting, even if your app itself does not need it.
EFF’s broader point is less “ad tech is creepy” and more “defaults + incentives create accidental leakage at scale”. Developers tend to stick with defaults, and location signals can increase ad yield, so the system nudges toward sharing.
Why this matters even if you are not a ‘location app’
The risk is asymmetric:
- Your app gets the review damage if users feel betrayed.
- You carry the compliance overhead (consent, disclosures, DPIAs) once location starts flowing.
- A single permissions decision (“Allow location while using the app”) can become a supply chain event across analytics, ads, and RTB.
If you do not have a tight handle on your monetization stack, you can end up shipping “location based advertising” unintentionally.
Practical reading: what to do differently
EFF highlights four SDKs in particular, but you do not need the exact list to extract the operational lesson.
1) Treat location like a shared secret, not a feature toggle
If you request location at all, assume it can propagate to:
- ad SDKs
- mediation layers
- partner pixels
- RTB bid requests
That means the question is not “do we use location”. It is “who gets it when we have it”.
2) Replace ‘set-and-forget’ SDK installs with a recurring audit
Ad stacks change quietly. So should your checks.
A simple cadence that works:
- quarterly: list every SDK in your app + their data collection defaults
- per release: re-check location behaviour for any SDK version bumps
3) Keep ‘approximate’ and ‘precise’ separate in both product and governance
If you only need approximate location, do not ask for precise. And if you do not need location at all for core value, reconsider the permission entirely.
EFF’s point is that precise location is uniquely sensitive, and the blast radius is bigger than most teams assume.
Editorial take
This is one of those topics where “we comply” is not enough.
The highest leverage move is to minimise permission surface area and then design your stack so that when permission exists, it does not automatically become monetisation fuel.
Tiny wins
-
Inventory your ad + analytics SDKs (one page) List SDK name, version, what data it can access, and its default settings. Make one person accountable.
-
Add a ‘location data flow’ test to your release checklist If location is enabled, verify what outbound calls include location-like signals.
-
Make “no precise location” your default stance Require a written product reason to request precise location, not the other way around.
Read the source: https://www.eff.org/deeplinks/2026/07/developers-beware-ad-libraries-betray-your-users-location-privacy
Want help with ASO?
If you want this implemented for your app, check out our services - or run your workflow in APPlyzer.