Location data: how it leaves a mobile app, and how far it travels

What a single location point says about a person

The CNIL puts it this way: people’s movements say a great deal about them. They reveal habits, home, workplace, going out, but also interests, associations, and sometimes convictions or other sensitive data, such as visits to places of worship, to a trade union or association’s premises, or a stay in hospital.

It adds a point that empties the anonymity argument: contrary to a common belief, you do not always need someone’s name to identify them. A handful of location points is often enough to recognise an individual, particularly when they reveal a home, a workplace or a commuting pattern.

This is not a laboratory hypothesis. LINC, the CNIL’s own research lab, tested it by buying a dataset from a broker, with, in its words, no constraint and no verification. The sample held 100 million position records and 5 million phone identifiers, of which roughly 800,000 were usable.

The method comes down to three moves. The team took twenty identifiers at random. It looked at where each phone spent its nights, and where it spent its days. Then it looked up the matching addresses on a public map. Within a single day of work it had put a name to seven of those twenty people. The write-up concludes: so much for anonymous.

The lab also gives the price of this market, a few thousand euros a month or more than a hundred thousand a year depending on the territory covered. Then it adds the sentence any publisher should sit with: the apps that allowed this data broker to aggregate the information are, for now, not known. Even the regulator, once it has bought the data, cannot tell which apps it came from.

The permission settles one question, and only one

On Android, location runs through two distinct permissions, and Google’s documentation quantifies the gap. Approximate location places the phone within an area of about 3 square kilometres, roughly a neighbourhood. Precise location places it within about 50 metres, sometimes within a few metres. Since Android 12 the user chooses between the two when the app asks, and that choice overrides whatever the app had planned.

That dialog settles one question: may the app read the position. It says nothing about what happens to it next, nor who receives it. The CNIL sums it up in a sentence: a technical authorisation granted by the operating system does not, on its own, amount to consent for the uses made of location data, in particular advertising uses or sharing with third parties.

The resulting rule is clear. Freely given, specific, informed and unambiguous consent is required as soon as location is not strictly necessary to the service, and that is the case in particular for advertising use of the data or resale for marketing. Conversely, a navigation app that needs the position to compute a route is exempt. The distinction is not about the data, it is about the use. That is the same reasoning that governs the mobile app recommendation as a whole.

How position leaves an app

The first path is the most visible. A third-party SDK embedded in the app reads the position the app requested for its own feature. The permission was granted once, to the app; the third-party code it hosts inherits it. The CNIL states it plainly: if a permission is granted to the app, every embedded SDK has, by default, the technical ability to access the data, and those accesses can then escape the developer’s control. It adds that an Android app embeds, on average, more than 15 SDKs.

The recommendation also settles the liability: the publisher is the controller for including in the app an SDK whose function is to access location data, and the SDK provider is its processor when it pursues no purpose of its own. The CNIL cites a telling precedent of its own: in 2020 a prayer app was accused of selling its users’ location data to brokers, and later stated it had ended its contracts with the SDKs behind the collection. The publisher answered for what it had not seen.

The second path requires none of the recipient’s code inside the app. When an ad slot needs to render, the app puts it up for auction, in a fraction of a second. The standard format for those auctions provides dedicated fields for position: latitude, longitude, estimated accuracy in metres, the age of the fix, and how the position was obtained. Alongside it travels the phone’s advertising identifier, the number the system assigns to each device for advertising, which lets a recipient recognise it from one time to the next.

The request goes out simultaneously to every eligible buyer. One wins the auction. All of them have read it.

The third path needs no location permission at all. Internet access, by contrast, is granted automatically at install time: Android does not count it among the sensitive permissions, the ones that trigger a question to the user. Yet an IP address is enough to place a phone at city or district level. The auction format anticipates exactly that case, down to naming the companies that sell the service. The study "50 Ways to Leak Your Data" observed it on real apps: 70 of them were sending position to 45 distinct domains while none held the location permission, most often because the ad mediator handed it back to them in its response.

The fourth path is the quietest. The same study showed that a system file, readable by any app and protected by nothing, holds the hardware address of the router the phone is connected to. Compare that address against a public database and you get a street-level position. The authors found the technique inside an advertising SDK, with one detail that says everything: the code only used it after the user had refused access to their location.

A regulator had already documented the mechanism. In 2016 the FTC fined a mobile advertising network 4 million dollars: even when a user had refused access to location, the company harvested nearby Wi-Fi networks, their names and signal strength, then compared them against its own database to infer the position. The 2019 study describes a variant that does not touch the network at all: reading the information a camera writes into every shot, including the place and date it was taken. An app with access to the photo library thereby picks up a history of movements, not just the current position.

Those last two paths share a property. The user’s refusal is technically respected: the app has no permission, the location indicator never lights up. And the position leaves anyway. This is exactly the kind of gap that reading the code does not reveal.

What the CNIL already established in 2018

France has a precedent that is rarely cited. Between June and October 2018 the CNIL issued formal notices against four location-advertising companies, all on the same pattern: an SDK embedded in partner apps, collecting the phone’s advertising identifier and its position. The decisions remain public; the company names no longer are, the CNIL having since removed their identification.

The collection rates are in the decisions, and they speak for themselves. In decision MED-2018-022 of 25 June 2018, the SDK collected people’s location data roughly every five minutes. Over a single day the CNIL’s inspectors recorded 1,635,402 advertising identifiers paired with location data, and close to 14 million distinct identifiers over thirteen months.

In decision MED-2018-043 of 8 October 2018, collection fires every 200 metres on iOS and every five minutes on Android. The database held 14,344,670 distinct advertising identifiers, of which 5,529,383 were tied to location data, drawn from around 25 apps. That is five and a half million phones whose movements could be retraced.

The fourth decision, MED-2018-042 of 30 October 2018, goes further, because the company under inspection received data through two channels. The first is the SDK, like the others. The second requires no code at the publisher at all: the company is a recipient of personal data, notably location data and smartphone advertising identifiers, by way of real-time auctions. The CNIL then records what becomes of it: the company retains and subsequently processes that personal data whether or not it bid on the auction in question.

The inspection quantifies both stocks, held in a single database: 24,688,863 advertising identifiers from auctions the company had answered, and 42,934,160 from auctions it had not. The larger share of its database therefore came from auctions it never took part in.

The same mechanism, elsewhere, at another scale

In December 2024 the US Federal Trade Commission acted against a broker on precisely this point. According to its complaint, the company retained the information contained in bid requests even when it did not win the auction, although the rules of those exchanges forbade it. This is the first time the US authority has alleged the practice to be an unfair act.

The figures give the scale. The broker itself estimated that roughly 60 percent of its consumer data came from those auctions. Over two and a half years, the FTC attributes to it more than 500 million advertising identifiers paired with precise location data.

The same authority had, in January 2024, banned another broker from selling sensitive location data. Its supply was described as follows: third-party apps that incorporate its software development kit, its own apps, and purchases from other brokers and aggregators. Its complaint puts numbers on it: the SDK was integrated into more than 300 apps, and the company ingested over 10 billion location data points daily, advertising that data as 70 percent accurate within 20 metres or less. The FTC noted that this raw data, associated with mobile advertising identifiers, is not anonymised and makes it possible to match a device to the places it visited.

In Europe, a long-running investigation by netzpolitik.org and Bavarian public broadcasting, published in France with Le Monde in December 2025, worked on datasets obtained from brokers. For the free sample alone, the French leg covers around one billion location points attached to as many as 16.4 million devices in France.

In January 2025 a breach at a broker made the circuit legible from outside. French researcher Baptiste Robert published the list of Android apps present in the sample: 3,455 packages, from casual games to dating apps, from weather to pregnancy tracking. Several of the publishers named stated they had no commercial relationship with the broker, while acknowledging that they display advertising in their app. Both statements can be true at once, and that is the whole problem: the chain binds the publisher without the publisher choosing it.

What the CNIL asks of publishers

The mobile app recommendation devotes a section to location. It asks the publisher to pick, among the permissions the system offers, the one that suffices: approximate location rather than precise, a one-time permission rather than a permanent one, a permission active only while the app is in the foreground rather than at all times, and a permission that does not transmit information to third parties where that is possible.

Two requirements there are more concrete than most of what gets written on the subject. First, truncate before sending: before any transmission of location data to the app’s servers, the publisher must identify the minimum level of precision needed for its purposes and truncate the coordinates locally to match. Second, do not collect while idle: the CNIL recommends not collecting location when the app is not actively being used.

Consent itself exempts nobody from anything: even with consent, actors may not collect location more precise than necessary, nor retain movement histories over a long period for targeting or resale. And liability does not stop at the publisher, since these obligations bind every actor involved in the location data processing chain, advertising partners, ad networks and data brokers included.

The doctrine was followed by inspections. In 2025 data collected through mobile apps was among the CNIL’s priority themes, publishers and SDK providers alike. Its annual report states that it inspected ten apps or embedded-code providers, and summarises the finding: a lack of transparency in the information given to people, including when collecting consent for the use of geolocation. That is the kind of finding a publisher would rather reach first, and the preparation comes down to a few checks.

Google Play adds a rule many publishers discover late. The store’s data safety declaration covers third-party libraries and SDKs too, and the developer alone is responsible for it. Store policy further states that location permissions must never be requested for the sole purpose of advertising or analytics, and that device location may never be sold nor shared for a purpose facilitating sale.

The questions only execution answers

A privacy policy describes an intention. An SDK list describes what is shipped. Neither says what actually left the phone, at what precision, to whom, or when.

The useful questions are concrete. Does position leave while no location permission has been granted? With how many decimal places, that is, at what scale? Does it leave before the consent banner appears? Does a refusal actually stop it, or only on the main path? How many distinct recipients receive it, and which of them are absent from the declared list? Does it keep leaving once the app is no longer in the foreground?

Those questions are only answered by running the app on a real phone and reading its traffic. That is what Skanopy does: mapping what an app really emits, each finding backed by the dated request that proves it. The report establishes the facts, it does not rule on compliance; the interpretation stays with the DPO. And because an app changes with every release, this verification is worth more repeated than one-off.

Sources

Every finding in this article traces back to one of these documents.

1. CNIL ’26Geolocation and mobile apps: the rules protecting user dataCNIL, 7 July 2026
2. CNIL ’25Mobile app recommendation, amended versionCNIL, deliberation no. 2025-024
3. CNIL ’25Permissions: the CNIL’s recommendations for respecting privacyCNIL, 14 January 2025
4. CNIL ’25Mobile apps: how to integrate SDKs and respect privacyCNIL, 21 January 2025
5. LINC ’23GeoTrouveTous: a re-identification project using location dataLINC, the CNIL’s research lab
6. MED-2018-042Decision of 30 October 2018, SDK and real-time biddingCNIL, via Légifrance
7. MED-2018-022Decision of 25 June 2018, collection every five minutesCNIL, via Légifrance
8. MED-2018-043Decision of 8 October 2018, collection every 200 metresCNIL, via Légifrance
9. FTC ’24Action against a broker retaining data from auctions it lostFederal Trade Commission, 3 December 2024
10. FTC ’24Order prohibiting the sale of sensitive location dataFederal Trade Commission, 9 January 2024
11. FTC ’16An ad network inferred location despite the user’s refusalFederal Trade Commission, June 2016
12. USENIX ’1950 Ways to Leak Your DataReardon et al., CNIL-INRIA prize 2021
13. OpenRTB 2.6Real-time bidding specification, Geo objectIAB Tech Lab
14. AndroidLocation permissions and their documented accuracyAndroid developer documentation
15. Databroker FilesThe French leg of location data sold by brokersnetzpolitik.org, BR and Le Monde, December 2025