Developers: Beware of Ad Libraries that Betray Your Users’ Location

August 5, 2026

Across mobile platforms, advertising companies offer developers software development kits (SDKs) designed to streamline app monetization. However, these same SDKs often automatically transmit users’ location data to ad systems utilized by location data brokers, raising significant privacy concerns. Many developers may remain unaware of this potential violation, and even more concerning is the lack of awareness among users who are directly impacted.

When developers permit advertising SDKs to collect location data, they expose users to risks that extend beyond receiving targeted advertisements. The advertising industry has leveraged location information for various purposes, including investigations by ICE, global surveillance initiatives, and even the tracking of military personnel. This underscores the importance of default settings, which hold implications not just for users but also for app developers.

Data Brokers Harvest Location Information From Advertising Systems

When an advertising SDK collects and disseminates location data, it integrates into a broader ecosystem involving advertisers, ad tech companies, and location data brokers. An investigation by the Electronic Frontier Foundation (EFF) has sought to illuminate the pathways through which mobile apps funnel location data to these brokers.

Location data brokers capitalize on the precise movements of billions of individuals, often without their knowledge or informed consent. This data is primarily harvested from mobile applications. Some apps directly collaborate with data brokers, utilizing SDKs developed by these brokers or employing server-to-server transfers to sell users’ location data. Others inadvertently leak this data through advertising SDKs that facilitate behaviorally-targeted ads via real-time bidding (RTB). During these auctions, ad tech companies can disseminate user data to a multitude of potential advertisers, allowing location data brokers to participate not only in bidding for ad space but also in collecting personal information embedded in bid requests.

The indiscriminate sharing of data through RTB can lead developers to unknowingly expose their users’ location to data brokers. A notable incident in 2025 involved a breach at Gravy Analytics, a location data broker, which revealed thousands of apps potentially contributing to its data pool. When journalists contacted app developers, many claimed ignorance regarding their association with Gravy Analytics. To mitigate the risk of location information leaking to data brokers via RTB, developers must thoroughly understand the location-sharing practices of their advertising SDKs.

How Advertising SDKs Leak Location Data

Developers need not intentionally share location data for it to be broadcast during RTB auctions. Once a user grants an app permission to access their location, the embedded SDKs automatically gain the same access—there are no specific permissions for SDKs. Consequently, advertising SDKs can autonomously collect users’ location data and include it in bid requests.

While apps and SDKs can derive approximate location data from users’ IP addresses without explicit permissions, having location permissions enables access to more precise estimates. With precise location permissions, apps (and their embedded SDKs) can determine locations within approximately 160 feet, and in some cases, as accurately as 10 feet. In contrast, approximate location permissions allow for estimates within about 1.2 square miles.

Moreover, both developers and advertising SDKs have financial motivations to share location data, as it can elevate bid prices for an app’s ad space. Although many advertising SDKs require developers to configure settings before collecting and sharing users’ location data, this is not universally the case. EFF’s findings indicate that several advertising SDKs openly acknowledge sharing users’ location data by default when embedded in apps that have been granted location permissions.

EFF Identified Advertising SDKs That Share Location Data by Default

In its review of public developer documentation from numerous widely-used advertising SDKs, EFF identified four SDKs that engage in particularly concerning practices: they collect users’ location by default for ad targeting whenever a user grants an app location permissions. EFF reached out to each SDK company and the associated app developers for comments. One company responded and subsequently updated its documentation, while another provided clarifications.

Focusing on SDKs with these privacy-invasive defaults is crucial, as it heightens the risk of developers unintentionally leaking users’ location data. Research indicates that developers often adhere to SDKs’ default settings. If an advertising SDK transmits location data by default, users’ precise location can inadvertently end up in advertising systems without any intentional action from the developer. These SDKs typically have separate documentation pages that instruct developers to flag users covered by privacy regulations like GDPR and COPPA for restricted data processing, but these modes are not set as defaults.

InMobi Encourages Keeping Location Sharing Enabled By Highlighting Financial Incentives

InMobi claims to reach over 2 billion users across more than 150 countries and ranks as the tenth most popular advertising SDK on Android. InMobi’s integration guide suggests that location sharing is enabled by default, stating, “The InMobi SDK automatically forwards location signals when available.” The documentation explicitly recommends sharing location data, highlighting that “location-enriched impressions typically yield higher revenue.”

While apps using InMobi may not require location information for functionality, the SDK encourages developers to request precise location permissions to enhance ad targeting accuracy. Additionally, it suggests requesting Wi-Fi network information permissions, which, when paired with precise location permissions, can facilitate further location tracking.

BidMachine Updates Previously Inaccurate Developer Documentation After EFF’s Technical Analysis Observed Precise Location Data Collection

BidMachine claims to reach over 600 million direct SDK users. The company acknowledges that it collects location data by default on the “Advanced Settings” page of its Android SDK Integration guide, stating that the “SDK can automatically track user device location to serve better ads” as long as developers request location permissions for their app. Following EFF’s inquiry, BidMachine revised its documentation to clarify its practices, although it did not change the default collection of location information once app-level permissions are granted.

Prior to EFF’s outreach, BidMachine’s “App Privacy Details On Google Play” page inaccurately claimed that only coarse location data was collected, while technical analysis revealed that precise location coordinates were indeed being transmitted. After EFF’s intervention, BidMachine updated its documentation to confirm that precise location is collected whenever app-level permission is granted.

Verve Emphasizes Consent More in its Play Store Language Than its Configuration Guide

Verve asserts that its HyBid SDK reaches over 1.5 billion users across more than 10,000 apps globally. The configuration guide for the HyBid Android SDK clearly states that location tracking is enabled by default, indicating that if users grant location permissions, the SDK will utilize the available location data for better-targeted ads.

However, Verve’s guidance for data disclosure to the Google Play Store presents a more cautious narrative. Despite the default nature of location tracking, the Google Play Data Safety Guidance claims that the SDK “does not collect or attempt to collect [location] information independently.” Furthermore, it emphasizes user consent, stating that the SDK will only collect location data if the publisher allows its app to do so after obtaining explicit user consent.

While Verve’s HyBid SDK is open source, allowing developers to inspect the code, it still raises concerns about how location data is handled. The open-source code indicates that latitude and longitude coordinates are rounded to two decimal places, and while it does collect network-derived location data, this can still reveal movements that should remain private.

Huawei Highlights Financial Incentives for Location Data Sharing Before Showing Developers How to Opt Out

Huawei claims its Petal Ads SDK is embedded in over 85,000 apps worldwide. The integration guide for the Petal Ads SDK begins with a recommendation for developers to obtain location permissions to enhance app revenue, acknowledging that location sharing will occur by default in apps with such permissions.

A separate page on the use of location data for ads reiterates that the Petal Ads SDK will include users’ location information in ad requests if the app has access to location data. However, neither page mentions that developers can disable the default collection of location information using the setRequestLocation method, which is referenced later in the Ads SDK Compliance Guide.

Location Data Sharing Can Happen Without Users’ Knowledge or Meaningful Consent

In certain instances, after an app obtains location permission, advertising SDKs can independently acquire and share users’ location information without their knowledge or meaningful consent. For example, the apps QR Scanner and GPS Speedometer shared precise location data with BidMachine without notifying users or obtaining consent beforehand. Furthermore, neither app’s Google Play Store data safety section disclosed that it may share such data with third parties.

The lack of transparency surrounding location data sharing poses significant risks. Users may not realize that granting location permissions to an app also extends those permissions to third-party SDKs embedded within the app. Many apps that request location permissions, such as GPS Speedometer, do so for essential functionality, further complicating the issue of informed consent.

Location Privacy Issues Extend Beyond These Four SDKs

The focus on four advertising SDKs does not imply that other SDKs adequately safeguard location data or that developers never choose to share location data when it is not the default. Other advertising SDKs have faced criticism and legal action for allegedly collecting location data without valid user consent. The issues highlighted regarding privacy-invasive defaults, financial incentives, and ambiguous documentation are prevalent across the industry.

Numerous studies have indicated that advertising SDKs often guide developers toward increased data collection through their design and documentation. For instance, a 2021 study found that popular advertising SDKs employed dark patterns to nudge developers toward sharing more sensitive data. A subsequent study in 2024 identified discrepancies between SDK documentation and actual data collection practices, while a 2025 study concluded that developers often have minimal control over SDK data transmission, leaving them with little choice but to accept invasive data collection practices.

Fighting Back Against AdTech Companies That Enable and Encourage Location Data Sharing

The EFF’s analysis reveals that advertising SDKs not only permit developers to share location data but often incentivize it. Default settings, financial motivations, and unclear documentation can make sharing users’ location data the simplest option for developers.

While users can take steps to protect their location privacy, the onus should not fall solely on them. Developers, regulators, and legislators must collaborate to prevent apps from leaking users’ location data to advertising companies and data brokers.

Developers

Developers should meticulously assess all third-party SDKs incorporated into their apps and disable unnecessary data collection whenever feasible. Regardless of the default settings established by advertising SDKs, developers bear the responsibility of safeguarding their users’ location data. Protecting users’ privacy should not hinge on developers locating the appropriate piece of SDK documentation. Advertising SDKs should not default to sharing personal data, particularly when it involves sensitive information like location.

Regulators

Regulators must continue to hold app developers accountable for unlawful data sharing and the inclusion of libraries that subject users to privacy risks. They should also scrutinize the companies whose SDKs promote these practices on a larger scale. Without such oversight, companies can persist in designing SDKs that make invasive data sharing the norm while shifting the burden of responsibility onto developers who utilize their tools.

Legislators

The United States urgently requires federal legislation to protect the location privacy of all citizens, ensuring that it does not override stronger state privacy laws and includes a private right of action that empowers individuals to take legal action against privacy violations. Countries worldwide should enact similar laws to safeguard their users’ location privacy. Everyone deserves privacy as a fundamental human right.

Legislators can address the root of the issue by prohibiting online behavioral advertising, effectively removing the primary incentive for companies to track and share personal data. This would also prevent users’ precise locations from being broadcast to data brokers through RTB auctions. Until such measures are implemented, developers must remain vigilant regarding ad libraries that compromise their users’ location privacy.

Notes on Methodology

The investigation focused on analyzing network traffic for various Android advertising SDKs that transmit precise location data by default when granted location permissions. Android was chosen for this analysis due to its relative openness and the team’s familiarity with the platform. Publicly available resources such as Exodus Privacy and AppBrain were utilized to identify popular advertising SDKs and the apps that incorporate them.

In a controlled environment, a machine was set up to monitor HTTP(S) traffic from a test device using mitmproxy, allowing real-time traffic analysis. The dynamic instrumentation toolkit Frida was employed where necessary to ensure the generated traffic could be effectively analyzed.

Flows files have been included in this report, which can be opened in mitmproxy to display the requests observed with location coordinates.

AppWizard
Developers: Beware of Ad Libraries that Betray Your Users’ Location