Location Sharing Doesn't Stop at the App You Gave Permission To

Granting a weather app access to your location feels like a two party exchange. You tap allow, the app pulls your coordinates, and it hands back a forecast for the block you are standing on. Android does not actually treat it as two parties. Once permission is granted at the app level, every piece of code bundled inside that app inherits the same access. That includes the advertising kits stitched in to help the app pay its bills. A report the Electronic Frontier Foundation published in early August found several of those kits handling location sharing by default, sometimes without the app's own developer realizing it. One permission, several passengers Android has no separate permission for the software development kits, or SDKs, that developers drop into an app to handle ads. A location permission granted to the app becomes a location permission granted to everything running inside it. EFF's researchers watched real network traffic from live apps to see where location data actually traveled once permission was granted. What they found was already written down. The ad companies describe exactly this behavior in their own developer guides. Your browser works the same way The same design carries over outside of apps. A browser grants location the way an app does. Every script running on the page that is asked can draw on that same grant, whether the script belongs to the site itself or to an ad network riding along inside it. A few browsers push back against this by default. Firefox blocks known trackers automatically through its enhanced tracking protection. Brave strips out third party ads and tracking scripts before a page renders. DuckDuckGo's browser applies its own tracker blocking along with a privacy grade for each site visited. Aloha Browser bundles a VPN and ad blocker directly into the mobile app, cutting down on third party requests a page can make in the first place. A browser that blocks those third party scripts by default cuts down on how much of that location grant ever reaches anyone besides the site that asked for it. EFF named four widely used advertising SDKs that collect location by default the moment an app has permission. Each one skips a separate opt in for the person whose location it is. InMobi, which reaches more than two billion users, tells developers its SDK forwards location automatically. The company recommends keeping that setting on, since location enriched impressions pay more. BidMachine, running across more than 600 million devices, describes the same automatic collection in its own configuration guide. Verve's HyBid SDK, embedded in over 10,000 apps, states plainly that location sharing is on by default. A separate disclosure to the Google Play Store claims the SDK does not collect location on its own. Huawei's Petal Ads SDK, built into more than 85,000 apps, pitches the extra ad revenue location data brings before it ever mentions how to turn location sharing off. That instruction sits buried in a compliance document developers rarely open. Caught passing location along EFF did not stop at reading documentation. Researchers traced real traffic from two popular Android apps, a QR code scanner with more than 50 million downloads and a GPS speedometer app with more than 10 million downloads. Both were found sending precise coordinates to BidMachine's servers. Neither showed a permission prompt specific to that sharing, and neither app's Google Play data safety listing mentioned location as shared with third parties. The location left the phone through a door the person granting permission never saw open. Where the auction takes it Once location data reaches an advertising SDK, it can move into real time bidding. Real time bidding is the automated auction system that decides which ad to show and what it is worth. A single bid request can reach thousands of potential advertisers in a fraction of a second, and location data brokers sit in on those auctions specifically to harvest the coordinates riding along inside them. A 2025 breach at the broker Gravy Analytics exposed thousands of apps feeding it location this way, and several of the developers behind those apps said they had no idea the company existed. EFF traces where that pipeline surfaces. The data has turned up in immigration enforcement investigations, foreign surveillance tools, and tracking of military personnel, all far from what a person approving a weather app's location request had in mind. Regulators have drawn this line before None of this sits in a regulatory blind spot. InMobi settled with the FTC back in 2016 over a related trick, collecting precise location through WiFi data even when a person had denied location permission outright. The FTC's case against the broker Mobilewalla went further, ordering deletion covering both the location data it collected and the analysis already built from it. A location permission stretched to feed a data broker pipeline the user never agreed to is still a stretched permission, whether an ad kit or the app's own developer did the stretching. What actually tells you something A permission prompt cannot say whether the code sharing that access is an ad kit with a financial reason to keep it on. A few checks get closer to an answer. Check the Google Play data safety section, since it is supposed to list location under shared data whenever a third party gets it, though EFF's findings show that listing can be wrong Choose approximate location over precise wherever a feature does not need exact coordinates Look at permissions app by app and site by site, since a phone's general privacy screen tends to miss these cases Hitting allow was supposed to settle one question, whether an app or a page could see where you are. It turns out to settle that question for every piece of code riding along behind it too.