Earlier this month the Electronic Frontier Foundation published an investigation that should make every Android developer open their build.gradle and start reading. According to the EFF — and covered by TechCrunch on August 4, 2026 — four widely-used advertising SDKs can collect or transmit a device's precise location by default the moment the host app already holds location permission. The named libraries are BidMachine, InMobi, Verve's HyBid, and Huawei's Petal Ads. Among the apps the EFF flagged were two that had been downloaded a combined 60 million times.
The most uncomfortable part for developers: many of them had no idea it was happening.
Why this happens, and why "we don't sell your data" can still be false
Android's permission model treats an app and every piece of code embedded in it as a single permission holder. When your app asks for location — maybe for a legitimate feature like a store locator or a weather widget — that grant doesn't stop at your code. Any third-party SDK compiled into the same APK inherits the same access. So an ad library can read and transmit coordinates using a permission the user granted for something completely unrelated.
The result is a gap between what your app does and what your app says. Your consent screen and your Google Play Data safety listing can honestly describe your first-party behavior while a bundled SDK quietly ships location data to advertisers and data brokers. You didn't write that code. You may never have read its documentation. But it's in your build, running under your app's name, using your users' permission.
The EFF also found that some SDK providers actively nudge developers toward more invasive collection — telling them that "location-enriched" ad impressions earn more, and encouraging requests for precise rather than approximate location. The incentive structure points the wrong way.
The standard advice — and its ceiling
The EFF's guidance is sound: audit your dependencies, read each SDK's documentation, and disable any data-collection features you don't need. Do that. Turn off the defaults. Request approximate location instead of precise where you can. Re-check after every SDK version bump, because a default that's off today can flip back on in the next release.
But notice the shape of that advice. It's a containment strategy. You are managing a risk that lives inside your own binary, hoping you've found every toggle, trusting that the next update won't quietly re-enable one. Every new SDK, every version bump, every acquired ad network is another surface you have to keep watching. The data is being collected by default; your job becomes an endless game of turning it back off.
There's a different architectural stance that removes the game entirely: don't collect the data, and don't embed the code that would.
What "collect nothing" looks like in practice
I build Background Camera RemoteStream, an Android app that turns a spare phone into a security camera — screen-off recording, a built-in web server so you can watch the feed from another device on your network, and optional unlisted YouTube Live streaming from anywhere. It's exactly the kind of app that could justify all sorts of data collection: location for "where is this camera," analytics for "which features get used," an ad SDK to monetize a free tier.
It ships with none of that. No advertising SDK. No third-party analytics. No account system. No cloud backend. Footage is written to local storage on the device and stays there. There's no location permission to inherit, because there's no ad library sitting in the build waiting to inherit it, and no feature that needs your coordinates.
This isn't a claim of superior virtue — it's a claim about attack surface. You cannot leak a data type you never collect. You cannot have a bundled SDK exfiltrate location if there's no bundled SDK and no location permission. The EFF's finding is a problem for apps built on the ad-supported, SDK-heavy model. It simply isn't reachable in an app whose architecture never opens that door.
For a security camera in particular, the stakes are obvious. A camera watching your front door or your baby's crib is one of the most sensitive data streams a person owns. The moment that stream — or metadata about that stream, like where the camera is — routes through a third party's servers, it becomes someone else's honeypot. Local-only storage and zero embedded trackers mean there's no honeypot to breach in the first place.
The takeaway for developers
The EFF story is a genuinely useful wake-up call, and if you ship an app with ad SDKs, please go audit them today — the containment work matters and users are counting on it. But when you're planning your next app, or deciding whether to add that ad network to your current one, weigh the full lifetime cost of the containment strategy against the alternative. Every SDK you embed is a permission your app effectively delegates to a company whose incentives are not your users'. Data minimization isn't just a privacy nicety; it's the only defense that doesn't require you to be perfect forever.
Collect nothing you don't need. Embed nothing that collects on your behalf. It's the one configuration a bad default can't undo.
Background Camera RemoteStream is a privacy-first Android camera app by Super Funicular LLC — local-only storage, no cloud, no account, no tracking. Get it on Google Play or read more at superfunicular.com.
Source: EFF investigation, via TechCrunch, "Android app developers may be unwittingly sharing their users' location data with advertisers," August 4, 2026.
Top comments (0)