App rejected by Google Play because "Data Safety Section: Location Data Type - Approximate Location"

[nicolas-raoul]

App Status: Rejected

Your app has been rejected and wasn't published due to the policy issue(s) listed below. If you submitted an update, the previous version of your app is still available on Google Play.

Issue found: Invalid Data safety form

We reviewed your app’s Data safety form in Play Console and found discrepancies between it and how the app collects and shares user data. All apps are required to complete an accurate Data safety form that discloses their data collection and sharing practices - this is required even if your app does not collect any user data.

We detected user data transmitted off device that you have not disclosed in your app’s Data safety form as user data collected.

You must ensure that your app’s Data safety section accurately reflects your app’s data collection, sharing, and handling practices. This includes data collected and handled through any third-party libraries or SDKs used in your app. When available, we’ve included details on SDKs that contain code similar to the code in your APK that may be sending user data off device. You can check if your app uses any of these SDKs, but note that this list of SDKs may not be exhaustive. You must review and account for all data collected and shared by your app.

Issue details

We found an issue in the following area(s):

• Version code 1039: Policy Declaration - Data Safety Section: Location Data Type - Approximate Location

About the Data safety section in Google Play User Data policy

Your app must be in compliance with this policy. If your app continues to be non-compliant, your app updates will be rejected and your app may face additional enforcement actions in the future.

Please make changes to align your app’s Data safety form with the app’s behavior. This can be done by either:

• Updating your form in Play Console to declare collection of Data Types noted below; or
• Removing unwanted functionality and attributable code that collects this user data from your app or libraries used in your app, and when applicable to deactivate all non-compliant APKs.
  • To deactivate non-compliant APKS, you can create a new release and upload a compliant APK to each track containing the non-compliant APKs.
  • Be sure to increment the APK version code. If using staged rollout, be sure to set the release to 100% rollout.

For helpful resources, you can:

• Learn more about how to provide app privacy and security information for Google Play's Data safety section.
• Watch the Google Play PolicyBytes - Data safety form walkthrough.
• Check Google Play SDK Index to see if your SDK provider has shared a link to their data safety guidance. Review how any third-party code (such as third-party libraries or SDKs) in your app collects and shares user data.

[nicolas-raoul]

I think we collect location for Nearby, Explore>Map, location edition in the upload wizard and media details, and in the camera-based upload in certain conditions. I might be missing some.

As seen in the screenshot below, the app currently declares precise location as "Data collected" and "Data shared".

Maybe we don't explain sufficiently to the user before asking for permissions, or something like that? @sivaraam

[sivaraam]

Their explicit mention of "Approximate location" was peculiar. So I checked the data safety form and it indeed had a "Approximate location" field that we hadn't filled. So, I went ahead and filled the same.

I used the opportunity to make some more tweaks to the Data Safety form. Since we no longer share the location to Mapbox for analytics and also only share the location to Wikimedia Maps to obtain the tiles, I removed the "Analytics" category from Location and also mentioned that the location is not shared with third-parties.

I've republished the changes for review. Let's see how it goes

[sivaraam]

It just occurred to me that I had missed the location we gather via the image metadata and removed the changes sent to review for now. I had mentioned we only use the location ephemerally to process a request considering the "Nearby" scenario.

Does the location gathered via the metadata count as permanent storage of user location? What do you think? 🤔

[nicolas-raoul]

Does the location gathered via the metadata count as permanent storage of user location?

I would say yes.

[sivaraam]

Ok, Nicolas. I've mentioned that the location data is collected permanently and submitted both the update and the new data saftey form for review.

Let's see how it goes.

PS: I noticed this interesting tool which claims that it helps with generating the data safety form for the app. Need to check if it could helps us in some way in the future 🙂

[sivaraam]

Ok, Nicolas. I've mentioned that the location data is collected permanently and submitted both the update and the new data saftey form for review.

Let's see how it goes.

The update went through this time. The v5.0.1 (#5528) has been published to testing now 🙂

[nicolas-raoul]

Fantastic!!!

Please do not hesitate to update https://github.com/commons-app/commons-app-documentation/blob/master/android/Project-maintenance.md with your tips and any setting export available. :-)

[sivaraam]

Fantastic!!!

Please do not hesitate to update https://github.com/commons-app/commons-app-documentation/blob/master/android/Project-maintenance.md with your tips

Sure. I do have a few updates to do there which can be seen in a draft PR found below.

commons-app/commons-app-documentation#52

Will complete the changes while promoting the app to production and mark the PR as ready. 🙂

... and any setting export available. :-)

Do you suggest to export the answers to the data safty form and capture those in the document too?

[sivaraam]

Closing this as I think we're done with this :-)