Google Play’s Data safety section: the declaration nobody verifies

What the listing shows, and what it never shows

The section describes categories of data, from location to device identifiers, taking in contacts, messages, photos, financial information and in-app activity. For each one it states whether the data is collected, whether it is shared, and for which purposes: app functionality, analytics, advertising, personalisation. A few commitments come with it, such as encryption in transit or the ability to request deletion.

What it never shows is a name. A data type can be declared as shared without a single recipient being identified. No country is asked for. And no list of the third-party software components built into the app, those SDKs a publisher assembles for analytics, advertising or campaign attribution, appears anywhere.

The word “sharing” is itself narrower than it sounds. Google defines it as the transfer of user data collected from your app to a third party, then carves out four cases. Fully anonymised data. Transfers required by a legal obligation. Transfers a user triggers themselves, knowingly. And, first on the list, the transfer of user data to a service provider that processes it on the developer’s behalf.

That carve-out makes perfect sense within the logic of a store. It simply does not match the logic of the GDPR. Where Google counts transfers to third parties outside a processing relationship, the regulation is concerned with recipients, and Article 13 requires them to be disclosed, processors included. A listing can therefore be beyond reproach under the store’s rules and still say nothing about who actually receives the data.

What the regulator expects from that same page

The CNIL’s recommendation on mobile apps, in its amended version published on 8 April 2025, addresses publishers, developers, SDK providers, operating systems and app stores in turn. Two passages bear directly on the listing.

The first is addressed to the publisher. After recalling the information duties of Articles 12 to 14 GDPR, the authority recommends making the privacy policy available before any download, on the publisher’s own site or, where possible, by using the app’s dedicated page in the app store, to state the publisher’s identity, the purposes of processing and how to exercise rights. On partners it goes further, recommending that the number and business sector of the partners who would receive the data be made plain to the people concerned.

The second is addressed to the store itself. The authority lists the information a store should obtain from each publisher: the categories of data and the purposes pursued, the third parties who have or may have access to the data, which may include the list of SDK providers used, the exhaustive list of system permissions requested by the app along with whether each is required or optional and what it is for, and where applicable the third country in which the data will be stored and processed. It closes the usual objection with one unambiguous sentence: none of that information is confidential.

Further on it says what should appear on each app’s page, encouraging app store providers to offer a sufficient level of information, in particular the list of third-party SDKs used by each app, so that users can exercise their rights more easily.

Both lists describe the same page. They overlap on none of the three points a data protection officer cares about: who receives the data, in which country, and under which permissions.

The publisher answers for code it does not observe

The form asks questions about behaviour. Does this app collect a device identifier, does it share it, what for. The publisher answers from paperwork: what it had built, and what the documentation of the SDKs it integrated claims. In between sits everything a third-party library does without telling it.

This is not a hypothesis. A study presented at the MOBILESoft conference in 2026 surveyed 41 Android developers about this form, then analysed 172 public developer discussions covering 642 more. 58.53% of those surveyed find the exercise difficult. And 37.79% of the discussions are about data handled by third-party libraries, which is precisely the part of the question the publisher cannot answer.

The outcome can be measured. In February 2023 the Mozilla Foundation compared, for the twenty most popular free apps and the twenty most popular paid apps on the Play Store, each app’s privacy policy with its own Data safety listing. Two documents written by the same publisher, on the same subject.

This is more than a store rule

A publisher filling in this form usually believes it is satisfying a Google requirement. In practice it is also feeding a public statement about its processing. The GDPR knows nothing of a “Data safety section”, but it does know the duty to inform people accurately, and the French authority names this page as one of the places to do it.

The recommendation adds an observation that describes most organisations: responsibility for publishing an app or its updates in a store rests with the publisher, yet in practice the operation is frequently carried out by the developer. Responsibility sits on one side, and the hand on the form on the other.

The scenario is ordinary. The form was completed at first release, by an agency, based on the SDKs of the day. Since then two of them have been updated, a third was added for campaign attribution, and nobody went back to the listing. What the app ships still commits the publisher, and the listing is where that commitment becomes public.

What running the app establishes

Three of the items the authority wants on that page are written nowhere in a code repository. They are observed by running the app.

The third parties actually contacted, first. Not the list of integrated SDKs, which tells you what was assembled, but the list of servers the app calls while it runs. The two do not match: an advertising flow reaches companies the publisher never signed anything with. Then permissions: not the ones the app declares, but the ones it actually uses, and when. And finally the country of the server, from its address, together with the organisation hosting it.

One caution applies to that last point, and it deserves to be written down in the file. A server located in Europe does not prove the data stays there: a geolocation finding establishes the first point of contact, not the full path. On a listing that nuance changes the wording, not the conclusion: if the first point of contact is already outside the Union, the question is open.

None of this can be read off the screen. That is what separates analysing an app from analysing a website: an app’s traffic is displayed nowhere.

Rebuilding the listing on facts

Before signing off a Data safety section, four questions are enough to tell whether it rests on facts or on documentation.

Which third parties does the app actually contact, and which of them appear in the listing? Does data declared as not shared travel to a processor, a case the store excludes but which remains a recipient under the GDPR? Do the permissions requested serve the purposes announced? And which countries do the first connections reach?

Skanopy runs the app automatically on a real phone and records what it emits: the actors contacted, the data sent, the permissions used, and the country and organisation behind each server. That is the factual material missing when a listing is filled in, and when it is reviewed. The report establishes the facts, it does not rule on compliance; the qualification stays with the data protection officer.

A listing ages quickly, since an updated SDK can change behaviour without a line of the repository moving: that check is better repeated at each version than done once. It is also one of the few public documents an inspector can read before even writing to you, alongside the privacy policy and the consent banner: all the more reason for it to be true.

Sources

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

1. Google PlayProvide information for Google Play’s Data safety sectionPlay Console Help, Google
2. Google PlayWhat the Data safety section shows usersGoogle Play Help
3. CNIL ’25Recommendation on mobile applications, amended versionCNIL, deliberation no. 2025-024 of 27 March 2025
4. MOBILESoft ’26Challenges in Android Data Disclosure: An Empirical StudyKhedkar, Schlichtig, Soliman and Bodden, Paderborn University and Fraunhofer IEM
5. Mozilla ’23Data privacy labels for most top apps in the Google Play Store are false or misleadingMozilla Foundation, 23 February 2023
6. arXiv ’26An Empirical Analysis of Google Play Data Safety DisclosuresBakheet Aljedaani, 25 March 2026