What France’s top news apps do after you refuse tracking

How we measured

Everything here comes from a physical Android phone running Android 15, not an emulator. The steps were the same for each app. Launch it, with instrumentation in place to record what it sends and what it writes to the device. Tap refuse on the tracking prompt as soon as it shows up. Then browse the home, scroll, open a few articles, play a video, for about two minutes. The charts show what happened in that window.

Ninety-five third-party vendors

Start with the count. Across these apps there are 95 distinct third-party vendors, spread over close to 150 domains, more than 300 counting subdomains. Tracking was refused across the whole measured journey.

Most are there to advertise: 40 of the 95, about 42 percent. Add identity and data brokers, audience measurement and social networks, and tracking purposes reach 65 percent of the total. The rest is infrastructure, video, payment, and the consent tools themselves.

The banner is not missing

The question does get asked. We identified four different consent platforms, with Didomi well ahead, then OneTrust, AppConsent by SFBX, and TrustArc. A few names also come back in nearly every app. Google is present in all of them, Didomi in close to three quarters, Piano Analytics and Meta follow.

The issue is timing

About four in ten vendor contacts happen in the first ten seconds. The banner itself shows up around the ninth second. So part of the collection has already started before the question is on screen, and the rest fires while the banner waits for an answer.

What leaves the device

What leaves is not trivial either. 41 vendors send at least one identifier before consent. The most common is a persistent pseudonym, and about nine identifiers out of ten are persistent rather than disposable. Some are shared identifiers, the same value received by several separate vendors, which is what lets them recognize the same person across each other.

Tracking does not stop at the network

On the device, data gets written from the moment the app opens, mostly into app preferences and local databases, and a good share of it comes from tracking SDKs. Again, before any consent.

Two more things, on the side. In one app, email addresses were sent to an error monitoring tool. And two SDKs, including Google’s advertising SDK and Batch, encrypt their payload on top of HTTPS, which makes the content unreadable to ordinary network inspection.

One request worth a closer look

Most of the above is a pattern. This one is a single request, and it is hard to read any other way. The same behavior shows up in five of the apps, from an advertising SDK named Start.io.

With tracking refused, the SDK calls home, and the request proves it got the message: the advertising identifier is zeroed out, and a flag named limit ad tracking is set to true. On its own, that looks like a vendor doing the right thing.

Then you read the rest of the body. In the same request it ships its own device identifier, which our detection flags as persistent, next to a fingerprint of the phone: model and manufacturer, OS version, free and used memory, network type and roaming state, time since the last boot, and whether the device is rooted. The official identifier is off. The device is recognized by everything around it instead.

Proof a DPO cannot wave away

This is the part a DPO cannot really wave away. The request itself is the proof that the refusal was received, since the SDK zeroed the ad ID and set the limit flag on its own. Collecting a persistent id and a hardware fingerprint in the same breath is not a technical need for reading the news. It is recognition by other means, after a no.

What the banner lists, and what actually runs

The banner is supposed to name the vendors an app works with. A consent platform can declare them three ways: through the IAB vendor list, through custom vendors the publisher adds by hand, and through Google’s Additional Consent list for ad tech outside the IAB. A vendor counts as declared if it shows up in any of the three.

So we took every advertising, identity, analytics and social vendor that fired before consent and checked it against all three. A vendor that runs without appearing in any of them is active without being declared. We could only do this where the consent setup was readable in full, which here means the apps on the most common of the four platforms.

After that check, thirteen vendors come back active before consent while missing from the declaration in at least one app. A single app is enough to count.

The gap takes three shapes

A vendor registered with the IAB that the app simply left off its list. A Google ad tech provider the app did not select. And a vendor that is nowhere in the consent setup at all. Adjust, an attribution SDK, runs unlisted in three of the apps. Meta is active before consent in one app without being declared there, even though another app does declare it through Google’s list, the sort of thing you only catch by checking all three routes.

A careful reading

A few of these come with a reading a DPO might offer. One analytics vendor can point to the audience measurement exemption. Two of the social names are embedded posts and a comments widget rather than partners the publisher chose. Take those out, and what is left is advertising and attribution, the vendors whose whole purpose needs consent.

Even on that careful reading, ad and attribution vendors are running before consent that the banner never names.

How to read all this

These are signals, not verdicts. What governs reading and writing information on a device in France is Article 82 of the Loi Informatique et Libertés, not the legitimate interest basis people often reach for. Whether any of it is compliant is a call for the DPO, with the full context of each app in hand.

That last point is the reason we built Skanopy: replay the analysis on every release, keep a reproducible record, and leave the qualification to the people whose job it is.