In May 2026, the Federal Trade Commission finalized a settlement that banned data broker Kochava and its subsidiary from selling sensitive location data without explicit consumer consent. The case, which had been working through courts since 2022, produced a clear regulatory finding: selling a database of precise location histories linked to hundreds of millions of mobile devices — movements that reveal visits to doctors’ offices, places of worship, domestic violence shelters, and fertility clinics — is an unfair trade practice under federal law.
What the ruling did not do is fix the underlying mechanism that made the Kochava case possible in the first place.
The way Kochava got your location data was not through a security breach. It was through a software development kit — an SDK — that other app developers embedded in their apps to earn advertising revenue. When you used any of the hundreds of apps that included Kochava’s SDK, the SDK ran quietly in the background, collecting precise GPS coordinates and sending them to Kochava’s servers. You were never asked. You were rarely informed in any meaningful way. In many cases, even the app developer didn’t fully understand what the SDK was doing with the data it collected.
Kochava is now banned from this practice without consent. The SDKs of dozens of similar companies are not.
What an Advertising SDK Is
Most free apps are built on an ad-supported business model. Showing you advertisements generates revenue for the developer; the more precisely an ad can be targeted, the more valuable it is to the advertiser; the more data the targeting system has about you, the more precise it can be.
To plug into advertising networks and enable targeting, app developers typically include one or more third-party SDKs in their code. These SDKs handle tasks the developer doesn’t want to build from scratch: displaying ads, measuring whether users clicked, tracking which app features were used, attributing installs to advertising campaigns. The developer includes the SDK as a code library — a chunk of pre-built functionality — and the SDK takes over certain data collection functions when the app runs.
The problem is that the SDK operates under the data broker’s privacy policy, not the app developer’s. When you read the weather app’s privacy policy, it may say nothing specific about precise location sharing with Kochava or any other third party by name. The app developer may have agreed to the SDK’s terms without reading them carefully, because the SDK offers a monetization stream and the developer’s focus was on building the app, not auditing data broker practices.
This is not a hypothetical scenario. The FTC’s 2022 complaint against Kochava alleged that the company’s SDK was present in hundreds of apps — spanning weather, fitness, navigation, retail, and other categories — and that the location data pipeline ran without meaningful disclosure to users of any of those apps.
The Scale of What Gets Collected
The Kochava complaint included specific allegations that illustrate what “precise location data” actually means in practice:
- Data accurate to within one meter, timestamped to the second
- Location histories going back months or years
- Movement patterns that enabled reconstruction of daily routines, home addresses, and workplace locations
- Visits to specific locations — named clinics, named shelters, named religious institutions — cross-referenced with the categories of what those locations are
The FTC’s description of Kochava’s data product included a documented example: a data file showing a device’s precise location at a family planning clinic at a specific time, followed by a location at a specific residential address. The combination creates a reasonable inference about a person’s medical situation without any medical records being involved. The inference comes from geography and time alone.
Kochava claimed it was an ad-tech company doing standard industry work. The FTC’s position, which the settlement affirms, is that “standard industry work” can be sufficiently harmful to qualify as an unfair trade practice regardless of how common it is.
Companies Still Running the Same Playbook
The FTC has now settled or pursued enforcement actions against Kochava, InMarket, Outlogic (formerly X-Mode Social), Gravy Analytics, and Mobilewalla — five companies in the mobile location data aggregation space. Most settlements ban the companies from selling sensitive location data without explicit opt-in consent and require deletion of previously collected data.
But the location data industry has far more than five players. SafeGraph, Veraset, StreetLight Data, and numerous smaller companies operate in the same general category. Many have updated their contractual terms and data handling disclosures in response to FTC enforcement activity, but “updated practices” varies widely in meaning: some now require app developers using their SDK to certify that users have been informed of location sharing; others have added disclosure language to their developer-facing terms without materially changing the user experience.
Whether these modifications change the practical experience of someone downloading a coupon app or a local news app is a separate question. The SDK is still there. Location data is still flowing somewhere. The audit trail from the data on your phone to the company ultimately using it to build a targeting profile is still largely invisible to the person whose phone it is.
How Location Data SDKs Work in Practice
To understand why this problem persists despite enforcement, it helps to understand the data flow:
- You download a free flashlight app, weather app, or retail store app.
- That app includes an advertising SDK from a company you’ve never heard of.
- The SDK requests location permission on behalf of the app — or, if you’ve already granted location to the app, uses that permission silently.
- The SDK collects your precise GPS coordinates at intervals and transmits them to the data broker’s servers.
- The data broker aggregates location data from thousands of apps, linking all movement associated with the same device identifier.
- The resulting dataset — a timestamped movement history linked to a persistent identifier — is sold to advertisers, analytics firms, hedge funds, insurance companies, or anyone else willing to pay for behavioral location data.
At no point in this chain does a user meaningfully consent to step 5 or 6. The permission they granted was to the weather app to show local weather. The data that permission enabled is being sold to entities that have nothing to do with weather.
How to Audit Your Apps
You can’t directly see which advertising SDKs are embedded in apps you’ve installed — that requires reverse engineering the app’s code, which most users aren’t equipped to do. But you can significantly reduce the flow of location data through a combination of system settings and app management.
On iPhone
Audit location permissions comprehensively. Go to Settings > Privacy & Security > Location Services. For each app that doesn’t specifically require location to function, change the permission to “Never.” Navigation and maps apps need location; weather apps can use your city without precise GPS; retail, games, social media, and news apps almost never need any location access at all.
Turn off Allow Apps to Request to Track. Under Settings > Privacy & Security > Tracking, disable this option. It doesn’t prevent all location sharing — apps can still observe coarse location from your IP address — but it prevents apps from reading your Advertising Identifier (IDFA). The IDFA is the primary mechanism by which location data collected by different apps gets linked into a single persistent profile. Without it, the data is harder to cross-reference.
Use Precise Location selectively. Apple provides a “Precise Location” toggle within each app’s individual location settings. Turning this off gives the app an approximate region rather than a GPS coordinate. For apps you’ve kept location access for but that don’t need your exact address, this is a meaningful reduction in what any embedded SDK can collect.
Check App Privacy Labels before installing. Apple’s App Store shows a summary of what data an app uses to track you and what data is linked to your identity before you download it. An app showing precise location under “Data Used to Track You” is specifically disclosing participation in cross-app advertising tracking.
On Android
Review and revoke permissions in Permission Manager. Go to Settings > Privacy > Permission Manager > Location. Android shows every app with location access and lets you set each to “Allow all the time,” “Allow only while using,” or “Don’t allow.” Revoking access from apps that don’t require location removes their ability to contribute to a location data pipeline, regardless of which SDK they contain.
Switch to Approximate Location where possible. Android lets you grant approximate location rather than precise location to any app. Where you’ve granted location to an app that doesn’t need GPS-level accuracy, switching to approximate significantly reduces the precision of data any embedded SDK can collect.
Delete your Advertising ID. In Settings > Privacy > Ads (or Advertising), use “Delete advertising ID” (Android 12+). This removes the persistent device identifier that links your location history across apps. Some SDKs will fall back to other identifiers, but deleting the advertising ID makes cross-app profiling meaningfully harder.
On both platforms
Delete apps you don’t use. An app you installed once and rarely open still runs in the background, still has whatever permissions you granted, and still allows any embedded SDK to collect data. The simplest way to eliminate data collection you’re not getting value from is to remove the app.
Review background app refresh settings. On iOS, go to Settings > General > Background App Refresh and disable it for apps you want to restrict. On Android, review battery optimization settings, which can also restrict background activity. Limiting background activity reduces how much location data an app can collect when you’re not actively using it.
Why the Problem Is Structural
The FTC’s enforcement actions against Kochava and similar companies are meaningful. They establish that precise location data aggregation without consent can be illegal under existing law, create real compliance requirements for the companies targeted, and set a deterrent for the industry.
What they don’t do is change the fundamental economics of app development, which still reward embedding monetization SDKs that enable data collection, or give users a straightforward way to see which SDKs are in any given app and what data each SDK collects.
Proposed structural solutions include app store mandates requiring disclosure of all embedded third-party SDKs; technical standards that sandbox SDK data access so that an advertising SDK cannot read location data without explicit user permission at the SDK level; and privacy-by-default OS settings that make location data opt-in rather than opt-out.
Some progress has been made. Apple’s App Tracking Transparency framework, implemented in 2021, required apps to ask permission before reading the IDFA and had measurable impact on the industry’s ability to link location data to persistent user profiles. But the underlying SDK ecosystem continues to operate, and the FTC’s enforcement actions address individual companies rather than the industry structure.
Until there’s a comprehensive technical fix, the practical approach is the one that’s always been available: audit what’s on your phone, revoke permissions you don’t actively need, and assume that free apps with advertising-based business models are generating revenue through your data in ways their user interfaces don’t describe clearly.
The Personal File Dimension
Location data is the most visible example of SDK-based data collection, but it isn’t the only one. Some advertising SDKs collect device information that can be combined with data from other apps to infer demographic attributes, interests, and behavioral patterns. Contact list access, camera permissions, and file system access granted to one app can all feed data flows to third parties the user has never heard of.
For personal files — documents, photos, notes — the relevant question is slightly different: not whether an embedded SDK is silently reading your files (which is less common, because file permissions are more narrowly scoped than location on modern operating systems), but whether the apps you use to create, edit, and store personal files are themselves sending content to cloud services that then process it for advertising or other commercial purposes.
The best protection against this is the same basic principle: store personal files with services that have clear, explicit policies about what they do with your data, and that don’t depend on advertising revenue models that create incentives to maximize data collection.
The Kochava case named one player in a large industry. The structure that enabled it is still mostly intact. Enforcement is catching up to the practice; the practice is still operating while the enforcement catches up.