Tracking before consent: what the research measured in mobile apps
There is a lot of talk about what mobile apps collect. There is far less measurement of it. On a phone, the user sees nothing leave: the app is a closed block, its exchanges are encrypted, and the third-party components it ships are opaque. The person accountable for the app, a publisher, its DPO, sees no more than they do.
Independent research, though, has measured it. University teams ran tens of thousands of apps on real devices and observed what actually left them. Their results converge, and they are stubborn. Here is what they establish, study by study, and why you only get them by running the app.
What “before consent” means
A consent banner suggests that nothing starts before the user’s choice. On mobile, that is not the case. An app can contact a third-party server the moment it opens, before a single tap, sometimes before the banner even appears.
The distinction is simple and consequential. “Before any interaction” is what leaves at first launch, when the user has touched nothing yet. “Without consent” is what leaves when no valid choice has been collected, or despite a refusal. The work below measures both.
Seven apps in ten track before a single gesture
The most direct study on this point comes from the University of Oxford. Launching more than a thousand Android apps and observing their traffic at the very first start, the researchers found that 71.3% of them contacted at least one tracking company before any user interaction. Not after a tap on “Accept”: on opening.
On the same sample, fewer than one app in ten asked for consent, and fewer than 3.5% left a genuine choice to refuse. Each app contacted close to three different tracking servers on average, and a large majority reached a domain owned by Google.
At scale, the finding holds
A larger sample confirms the order of magnitude. A team at Germany’s CISPA research centre analysed 86,163 apps and found that nearly one in three sent personal data to third parties without prior consent: advertising identifier, location, other device identifiers.
Another Oxford measurement, across nearly a million apps, shows that an app embeds five tracking companies at the median, which means half of all apps embed more than that. The figure was unchanged before and after the GDPR. The same work shows Google could receive data from close to nine apps in ten. These are not isolated cases: it is the norm, measured across independent datasets that all point the same way.
Even the apps that show a banner
Showing a banner does not settle the matter. A study presented at the ACM CCS conference looked at the apps that do ask for consent before sharing data with third parties. Among those that could be analysed, one in five violated at least one GDPR consent requirement. Some kept sending data after an explicit refusal.
The finding is sharper still on the most widespread advertising framework. Work published in 2026 focused on apps using the TCF, the advertising industry’s consent framework. The result: 55.3% of them shared the advertising identifier before the user even touched the banner, and 66.2% did so with no lawful basis. The banner was there; the sharing had already happened.
Bypassing the permission itself
Some apps do not merely ignore consent: they bypass the phone’s permission system. That is what “50 Ways to Leak Your Data” documented, a study of more than 88,000 Android apps that won the CNIL-INRIA award in 2021.
The researchers describe workaround paths. An app denied the location permission read the hardware address of the home router, then compared it against a public database to infer the position. Elsewhere, a kit that was allowed to read the phone’s serial number dropped a copy of it on the memory card, where other apps, which had no right to it, came to collect it. In both cases the protected data left anyway, by a path the permission list does not show.
These mechanisms share one trait: they are invisible when you read the code. You only see them by watching the app while it runs.
Location is the textbook case. It leaves an app by at least four distinct paths, two of which require no permission at all.
Why the SDK list is not enough
Some tools list the trackers present in an app by reading its code, without running it. The best known, Exodus, catalogues more than four hundred trackers and finds Google’s measurement tool in close to six apps in ten. That is valuable, but it is a snapshot of what is embedded, not of what leaves.
An SDK list says what an app can do. It does not say whether that code runs, when it fires, or what actually leaves the device. A bundled SDK may stay inert; another may fire before consent. Only watching the app while it runs measures that gap, and it is why auditing a mobile app is harder than a website: on the web the traffic is in plain sight; on mobile you have to trigger it and decrypt it.
The results that moved regulators are precisely the ones reading the code does not produce: firing before consent, side channels, data leaving after a refusal. We showed it on a major French app, with real captured traffic.
What the CNIL now expects
This method did not stay in the labs. In September 2024 the CNIL published a recommendation on mobile apps, revised in April 2025, asking publishers to choose, for each permission, “the least intrusive version” that meets the need. It reminds them that obtaining a technical permission is not the same as collecting consent.
In 2025 the authority launched a control campaign bearing, in its own words, essentially on the configuration of SDKs and on access to phone data through permission management. Its review reports 323 controls over the year. The subject has moved from research to the field.
The continuity is direct. “50 Ways to Leak Your Data” received the award from the CNIL and INRIA; what the regulator rewards, then inspects, is this observation of real behaviour, not the reading of a declared list.
From one-off measurement to continuous checking
These studies share a strength and a limit: each is a snapshot, taken at one moment, by a team that prepares apps one by one, by hand. It is heavy work, and an app changes with every release. What was clean in spring may not be by autumn.
Skanopy applies this method automatically, on real traffic, on any Android app. A Google Play link or an installation file is enough, with no access to the publisher’s code.
The result is a factual report, dated and reproducible: what the app contacted, what it transmitted, to whom, and when relative to consent. The report establishes the facts, it does not judge compliance; the interpretation stays with the DPO. What researchers measure case by case, a publisher can track at every version, instead of a one-off audit that ages fast.
Sources
Every finding in this article traces back to one of these.
- SOUPS ’21A Fait Accompli? An Empirical Study into the Absence of Consent to Third-Party Tracking in Android AppsKollnig et al., Oxford
- IPR ’21Before and after GDPR: tracking in mobile appsKollnig et al., Oxford
- USENIX ’21Share First, Ask Later (or Never?)Nguyen et al., CISPA
- ACM CCS ’22Freely Given Consent?Nguyen et al., CISPA
- PETS ’26The TCF doesn’t really A(A)IDMorel, Santos et al.
- USENIX ’1950 Ways to Leak Your DataReardon et al., CNIL-INRIA award 2021
- CNIL ’24Mobile app recommendationCNIL, 2024 (revised 2025)
- CNIL ’25The CNIL’s 2025 controlsCNIL, annual review
- ExodusTracker listExodus Privacy, static analysis