Auditing a mobile app: as essential as a website, far harder

The same law, now enforced

What governs the reading and writing of information on a device, in France, is Article 82 of the French Data Protection Act. It draws no line between the browser and the app: dropping an identifier or reading data on a phone falls under the same rules, whether a web page or an installed app.

In September 2024, the CNIL published its recommendation on mobile applications, with compliance expected by spring 2025. It names the responsibilities along the chain, from the publisher to the SDK providers, through the developers, the app stores and the operating systems. The publisher is the data controller; an SDK provider may be a mere processor, but as soon as it reuses the data for its own ends, the publisher bears at least joint responsibility for it. In 2025, the CNIL made mobile apps a priority theme of its controls, looking in particular at third-party SDK configuration and the permissions requested.

The obligation, then, is identical to the web. Enforcement, now, is real on mobile.

The web reads like an open book

On the web, the signals are in the clear, or nearly. A page is text the browser receives and renders; its developer tools, built in and free, show the cookies written, the scripts loaded, every outgoing request and the domain it targets. A simple extension is enough to list a page’s trackers.

The reason is structural. The browser is itself the point where the encryption opens: its built-in tools show the exchange in the clear, and you can, if needed, insert a trusted intermediary to replay all of it. Tracking happens in a sandbox you can open and inspect, with no special equipment. That is what makes auditing a website accessible, sometimes even self-service.

The app is a closed box

The app offers no such transparency. It ships as a compiled binary: neither the code nor the third-party SDKs it bundles read like a web page. There is no "view source," no console a click away.

The publisher itself rarely knows exactly what each SDK sends. An analytics, advertising or attribution kit is a black box embedded inside another: you include it for a function, and it brings its own network behaviour, which the documentation does not always describe.

The signal is encrypted, and the app locks it down

Like the web, an app’s traffic is TLS-encrypted. But one difference changes everything. On a computer, you read web traffic by inserting a trusted intermediary, an authority added to the system. Since Android 7, an app no longer trusts, by default, an authority added by the user: it relies only on the system store. The move that opens web traffic therefore does not work as is on mobile.

The most sensitive apps go further and pin their certificate: they accept only their own server’s certificate and reject any intermediary. To see what leaves, you have to decrypt the signal on a controlled device, not just open a tab. The data leaves, but it leaves sealed.

The app defends itself against observation

On the web, the common obstacle is anti-bot. On mobile, the defences are of another order. Many apps embed hardening designed to resist analysis: detection of rooted devices, emulators, debuggers and instrumentation, code obfuscation, runtime protection. This is no footnote: the OWASP MASVS standard makes it a whole category, devoted to resistance against tampering and reverse engineering.

These mechanisms target fraud and intellectual-property theft. But they hinder legitimate observation just as much: an app can detect that it is being watched and, in response, change its behaviour or stop. The very thing you are trying to measure slips away as you approach it.

Behaviour depends on the hardware

An app does not behave the same everywhere. Its behaviour is tied to the real device: the hardware, the system version, the sensors, the device-specific identifiers. Emulators are often detected and handled differently, when they are not refused outright.

And the device is itself part of what gets collected. The advertising identifier, the phone’s fingerprint, its model and system version are among the data that leave. Observing the real behaviour therefore takes a real phone, not a simulation, otherwise you are measuring an app that knows it is being watched.

Triggering the real behaviour means acting like a user

A website reveals its trackers when the page loads. An app, often, reveals its flows only through use. SDKs fire at specific moments: on first launch, as the consent banner is dismissed, when a given screen opens, when a video starts, when a feed scrolls.

Reproducing those flows is not a matter of loading an address. You have to drive the interface the way a user would, on the device, and cross the journeys where the SDKs actually fire. The first cold start, banner included, and the use that follows are where the evidence is.

A blind spot the DPO can’t clear alone

Put end to end, the gap is clear. The web audits with tools within reach. The app takes a real device, decrypting the traffic, defeating hardening built to prevent exactly that, and driving the interface close to real use. That is a lab and a skill set out of reach for most DPOs and publishers.

The consequence is a paradox: the layer where exposure is highest, and that the CNIL now watches closely, is also the least examined. There, what is declared stands in for proof, for want of anything better.

This is exactly what Skanopy makes accessible: auditing a mobile app without building the lab. The analysis runs on a real device, following real user journeys, and returns a documented, reproducible record of what the app actually transmits, on any Android app, without access to the publisher’s source code. These are signals, not verdicts: the legal call stays with the DPO, with each app’s full context in hand. We make it measurable. A recent study of twenty news apps after a tracking refusal shows what that looks like in practice.