A push notification SDK sent 36 categories of data for four years. The publisher had no idea.

The alert did not come from an audit

It starts on 17 November 2023 with a complaint from a member of the public. He installed the app on his phone and, the decision reports, “after using the app he found that it sends [a third-party company] 47 different pieces of information about his device (location, GPS coordinates, cookies, microphone state, IP address, etc.)”. He attached a screenshot.

That screenshot did not come from an expert tool. It came from a protection feature built into a consumer browser, which detects outgoing requests from apps to known tracking companies and blocks them. The authority reproduced the test on 4 April 2024, on version 1.8.13 of the app: the feature reported “150 tracking attempts” caused by the app.

Inspectors then did what an analyst does. The decision names their second tool, an open-source app that “lets you track, analyse and block the connections made by other apps” and “export a PCAP dump of the traffic”. They installed several successive versions on a device and recorded, request by request, the parameters transmitted, decoding the payloads.

Note the path: no code review, no contract review, no questionnaire sent to the vendor. A phone, captured traffic, and a version-by-version comparison. It was also the only method that could establish the facts, since the publisher itself did not know them.

A notification module, and an option left on

The traffic authority replied on 23 January 2024, and its answer is the most useful part of the file. The app embeds a third-party module “for managing the push notifications sent to the user’s mobile device”. Then comes the sentence that explains everything: “In addition, this module includes a feature that sends usage data from the mobile device.” And the date: “this sending has been taking place since 13 January 2020”.

The publisher stressed that the two are separate. The module is needed to receive notifications, but “it is optional for that module to send usage data”. Optional, then, and switched on for four years.

The list of that data appears in the decision, as the publisher itself produced it in a technical report dated 10 January 2024. Thirty-six categories, moving from the harmless to the sensitive without transition: first name, surname, email address, gender, postcode, city, country, GPS coordinates, a unique identifier, the Android advertising ID, cookies, local IP address, network operator, device brand and model, device name, battery level, charging state, headphone state, system volume, device orientation, available internal storage.

What the module does, and what its own documentation says

The mechanics can be checked without leaving the vendor’s documentation. The decision does not name the platform, but it quotes the parameters observed in the traffic, including an installation identifier and an app instance identifier, along with the dashboards consulted. Those belong to Firebase, Google’s platform, which the Spanish press identified.

First point: the notification service never comes alone. Its documentation states that it depends on the installations module, “transitively included in your app”, and that this module “generates and collects a per-installation identifier (FID)”. Adding notifications therefore means writing and reading an identifier on the device, before the publisher decides anything.

Second point: the analytics component, when present, collects by default. Google puts it plainly: “By default, the Firebase SDK collects identifiers for mobile devices (for example, Android Advertising ID and Advertising Identifier for iOS) and utilizes technologies similar to cookies.” And further down: “By default, on Android the SDK collects the Advertising ID.” Opting out exists and is documented, but it is an action to take, not a starting state.

These two properties explain the case better than any intent. The publisher wanted notifications. The default configuration gave it full analytics, with an advertising identifier and persistent identifiers; and, in this particular app, the person’s name and email address, which the decision lists among the data the publisher itself reported. On the advertising identifier, the logic is the one we set out elsewhere: it is personal data, not a technical setting.

The record of processing said the opposite

On 27 March 2024, the authority looked at the privacy policy and at the entry in the ministry’s record of processing activities. The entry exists, it is public, it names the controller and the legal basis, consent. It describes the data: “name, surname, identifier, date of birth, licence issue date, remarks, number plate, vehicle data, points”. No GPS coordinates, no advertising identifier, no email address.

Then come the two lines the traffic capture contradicts: “Categories of recipients: no data communications are envisaged.” and “International transfers: no international data transfers are envisaged.”

On the second point, the authority read the vendor’s contractual terms, which provide that “Customer Data may be processed in any country in which [the vendor] or its Subprocessors maintain facilities”. It notes that it found no data location commitment in the terms of either service in use.

A record of this kind is not wrong through sloppy drafting. It is wrong because it describes what the publisher intended, and nobody compared that description with what left the phone. It is the same gap as Google Play’s Data safety section, and it is measured the same way: by looking at where the data actually lands.

Four versions, four captures

Once alerted, the publisher moved fast. Version 1.11.5 shipped on 11 January 2024 to remove the sending. From here on, the file becomes useful to anyone who publishes an app.

In late May and early June 2024, the authority captured the traffic of four successive versions, installed one after the other. Here is what it still observed at each step. The decision writes “data such as”: the list is not exhaustive, it is what was observed.

1.8.13   device model, country, build, language, app version, time zone,
         user-agent, IP address, app instance id, country+operator code

1.11.4   device model, country, build, language, app version, user-agent,
         IP address, installation id, country+operator code

1.11.5   country, build, language, app version, time zone, user-agent,
         IP address, installation id, app instance id

1.12.12  build, user-agent, IP address, installation id

The fix did not stop everything

So the version released four months after the fix was still sending the IP address, the user agent and the installation identifier. The authority draws a blunt conclusion: “Even in the latest version produced after this agency’s request, personal data such as the IP address would be captured.”

On IP addresses, it restates its own long-standing position, an opinion from 2003: “IP addresses, both fixed and dynamic, whatever the type of access, are considered personal data”. The publisher had argued that an IP address is transport data, unavoidable as soon as a device talks to a server. The argument did not carry.

Another parameter disappears along the way and deserves to be named, because nobody looks for it: a code which, the decision writes, “indicates the country to which the subscriber belongs as well as the subscriber’s specific operator”. It appears in no permission list, it triggers no dialog, and it left with every call.

The lesson is mechanical, not moral: a fix is a hypothesis until it is measured on the wire, version by version. That is exactly the point of monitoring rather than one-off audits.

What cannot be recalled

That leaves the problem the decision treats most seriously and that is discussed least: the versions already installed.

The publisher spells it out: “DGT cannot make corrections to versions released in the past. It can only release a new version that includes the corrections.” And: “Official distribution channels do not allow obsolete versions already installed on users’ devices to be invalidated or revoked.”

It does have a safeguard, added in November 2020: a feature that stops the app from working below a minimum version and prompts the user to update. It also notes, without being able to prevent it, that older versions remain downloadable outside the official stores. Those are the ones the authority installed for its own tests.

The vendor’s dashboards give the scale of the reprieve. For versions predating the fix, the console showed “2.3M” users in Spain and “7.6 thousand” in Morocco; for later versions, 25 users. Between 17 February and 16 March 2025, more than a year after the fix, the first-open event still fired 2,009 times for 2,007 users, across all versions.

The measure the publisher eventually proposed shows where the problem sits: delete the project at the vendor, so that old versions keep writing to an installation that no longer exists. You cannot recall a version. You can only close the door at the receiving end, and know which of the versions in circulation sends what, which means tracking them one by one.

What the authority held

The breach is Article 5(1)(c) of the GDPR, data minimisation: data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”. The reasoning has two steps: “The DGT app is entitled to capture the data necessary for its functionality. However, in this case, there is an excess in the data collected by that app.”

The authority then names what was left: “the various versions of the app would be collecting more data than strictly necessary, as is the case with the IP address, the country, or the operator the data subjects are subscribed to”.

Two points are worth noting, because they hold anywhere in Europe. First, ignorance erases nothing. The publisher acknowledged the breach, stating that “this breach was not conscious on DGT’s part” and that it followed “as a collateral effect, from the use of a legitimate and common feature in mobile app development”. The infringement was declared regardless. Second, fixing erases nothing either. The acknowledgement and the measures taken, the authority writes, “do not undo the breach of Article 5(1)(c) of the GDPR for the facts established up to the adoption of those measures”.

No fine was imposed, and that is the only part of the file that does not transpose: Spanish law prohibits fining a public body and provides instead for a declaration of infringement, notified to the body and communicated to the Ombudsman. For a private publisher, the same breach falls under Article 83(5) of the GDPR, capped at 20 million euros or 4% of total worldwide annual turnover, whichever is higher.

The French regulator has already written the method

Nothing in this file is specific to Spain, and the CNIL’s recommendation on mobile apps covers every step of it.

On default configuration, it addresses SDK vendors: “Default SDK configurations that respect this principle must be offered, including in the configuration examples provided in its documentation.” It even names the data at the heart of the Spanish case: “the collection or retention of device or network identifiers (IP address, surrounding network hardware) that can be linked to individuals must be avoided where the use of the SDK does not require it”.

On the bundling of features, it asks vendors to design their service “so that its features can be decoupled from one another”. And it closes the most common escape route: “These recommendations also apply to SDKs provided by OS vendors or to those offered by default in Apple’s and Google’s documentation”. A module blessed by the platform is not exempt from scrutiny: that is the vendor’s blind spot, and what the regulator expects from them.

On verification, finally, the recommendation describes exactly what the Spanish authority did: “An audit method based on intercepting network communications may be considered.” It gives the checklist, five points, one of which describes this case word for word: “the SDK does not collect more data than defined in the register provided”. And it adds the clause that turns an audit into monitoring: “Where the SDK changes, these analyses may be updated.”

On the publisher’s side, writing about consent collection tools, it goes as far as the setup: putting in place “(or engaging a third-party provider for this purpose) a test bench”, “equipping a test phone or an emulator to intercept network communications”, then testing the app. The rest of the grid is in the CNIL mobile app recommendation, and the liability that comes with it in your app, your responsibility.

The questions only execution answers

The Spanish file boils down to a series of questions no document settles.

Which third parties does the app contact on first launch, before the user does anything? Which persistent identifiers leave, and which of them were written on the device by a module nobody configured? Does the list of data actually transmitted match the record of processing? Are the IP address, the operator code and the installation identifier still leaving after the fix? And the previous version, still installed on thousands of phones, is it still sending?

You answer them by running the app on a real phone and reading its traffic. That is what Skanopy does: a map of the third parties actually contacted, every finding backed by the timestamped request that proves it, and the analysis replayed at every release. The report establishes the facts; qualifying them stays with the DPO. It is the substance of a mobile app GDPR audit.

Sources

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

1. AEPD ’26Decision PS/00287/2025, file EXP202317928: declaration of infringement of Article 5(1)(c) GDPRAgencia Española de Protección de Datos, published 9 September 2026
2. GDPRRegulation (EU) 2016/679, Article 5(1)(c): data minimisationOfficial Journal of the European Union
3. LOPDGDDOrganic Law 3/2018, Article 77: regime applicable to Spanish public bodiesBoletín Oficial del Estado
4. GoogleData collection: identifiers collected by default by the Google Analytics for Firebase SDKFirebase documentation, help centre
5. GooglePrepare for Google Play’s data disclosure requirements: data collected by Cloud Messaging and by the installations SDKFirebase documentation for Android
6. GoogleConfigure Analytics data collection and usage: disabling collectionFirebase documentation
7. CNIL ’25Recommendation on mobile applications, amended versionCNIL, deliberation no. 2025-024 of 27 March 2025
8. CNIL ’25Mobile apps: how to integrate SDKs while respecting users’ privacyCNIL, 21 January 2025