Documenting privacy options for deployers of custom apps to use

[shankari]

Here, I'm documenting my rationale for my answers to the iOS app privacy scorecard. Please let me know if you disagree.

Types of data collected:

• Health and Fitness
• Location
• Usage data
• Diagnostics
• Other data

The "Other data" captures any demographic information that is gathered from surveys. The CanBikeCO app will have an integrated survey, and we expect that most emTripLog deployments will, as well. If you are building a custom app on the platform and don't plan to request demographic information, you can remove "Other data".

All the data except "Diagnostics" are marked as "linked to the user". That is because all of them are linked with the same UUID, and we don't perform any special operations to de-link them. Diagnostic crash logs, which are automatically made available through the App Store, are not linked to the user.

Although we don't collect any PII directly in CanBikeCO, the programs do plan to potentially follow up with users for education and support. In the mini-pilot, we followed up with users via text for tech support and data collection issues. So although the app does not collect any user information directly, I don't think we can rule out combining with other datasets to contact users.

emTripLog is trickier since the study designers can configure it to meet their needs. But because of that flexibility, I am going with the more conservative approach.

The main use case for all the data is to provide a personalized travel diary, so I chose "Used for Product Personalization and App Functionality" as the reason for all the data types.

All our SDKs are open source, none of them use the IDFA and we don't use any of the information for advertising or tracking in any form.

@PatGendre @jf87 @ericafenyo FYI since you are building custom apps

[shankari]

More details for those who need them:

Part 1	Part 2

[shankari]

The Google Play Store requires the words "Privacy Policy" to appear somewhere in the privacy policy linked in the app and from the store listing.

[shankari]

The Google Play Store now requires documentation of "Sensitive App Permissions". Here's how I have filled it out.

What is the main purpose of your app?

To create a diary of user travel. The app provides the user with an estimate of their CO2 emissions from transportation. Our research group is able to use the collected data to explore better travel models.

Describe 1 location-based feature in your app that needs access to location in the background. Learn more

The core functionality of our app is building a diary of user travel. The diary is displayed to the user; they can correct the trip labels and add purposes.

[PatGendre]

It is worthwhile to note that for the laRochelle Tracemob version of the e-mission app, we replaced the pop-up when clicking on the "view privacy policy" profile button with a direct link to the privacy policy web page, so that we have the exact same terms wherever the user reads the terms of use, and that this solved the rejection issue we had from the Google Play store, for an app update.

[shankari]

I've been getting some recent pushback from Google on the "Prominent Disclosure" requirements. emTripLog was removed from the play store on Friday, apparently for that reason, because the most recent review said:

Missing information in prominent disclosure Your prominent disclosure must appear before your app’s location runtime permission, and should tell the user which feature(s) will use location in the background. Based on our review, your app’s prominent disclosure did not meet this criteria.

And attached this file:

I've been changing emTripLog to meet the criteria, including directly changing the rciti1 channel without pushing to the branch (sorry, @asiripanich @atton16). Once the app is approved, I will update master.

[shankari]

Updated version passed review. https://play.google.com/store/apps/details?id=edu.berkeley.eecs.embase

I will update master this weekend. @PatGendre @ericafenyo @asiripanich Please pull from master into your branches and forks before your next update.

[shankari]

Here are my answers to the Google "Data Safety" section.

The first two are obvious, the third is currently manual.

The demographic survey has a bunch of questions like this.

I think that the motion activity counts as "fitness"

We allow users to upload app logs to help us debug app operation.

I'm a little unsure about this. We do use Firebase to send push notifications, so we store the firebase FCM token.

• However, the FCM token != installation ID.
• However, it doesn't change very often so it probably fits the definition of an installation ID

This is also tricky. We use the demographic information to help us generalize the collected travel patterns. So the closest match is "analytics", although the analytics is not around app usage, but around travel patterns.

This is also tricky. Users can turn off the location tracking, but then the app is essentially useless. Also not sure whether to check "analytics" or not, since data analysis is part of the app features.

Fitness data (same as location).

"Other app performance data"

Device or other IDs (aka Firebase token)

[shankari]

Final preview:

[shankari]

Details and reason

• We collect demographic data such as race, ethnicity, access to vehicles, etc to allow us to generalize these travel patterns
  • I picked "analytics" since that is the closest option, although we don't really use it for app analytics as much as travel behavior analytics
  • I picked "optional" for location and fitness data, since we do have an in-app option to turn off tracking, although the app is pretty much unless without that information
  • The "app performance" data includes some information on how users navigate between screens, and the ability to upload logs for further debugging
  • "Device or other IDs" is for the firebase push notification token. It is not technically a device identifier (it is not an installation ID, see hidden comment), but I don't think it changes very often, so I guess it could theoretically be used as one. When in doubt, let's say "yes". Also, does the use of Firebase (with analytics and id collection disabled) constitute "sharing of data"?

        <meta-data android:name="firebase_analytics_collection_deactivated" android:value="true" />
        <meta-data android:name="google_analytics_adid_collection_enabled" android:value="false" />
        <meta-data android:name="google_analytics_ssaid_collection_enabled" android:value="false" />
        <meta-data android:name="google_analytics_default_allow_ad_personalization_signals" android:value="false" />

[shankari]

While filling out the "content" section of the app, selected "does not share location with other users" since that is for location sharing, not for location data collection.

[shankari]

other minor changes:

• added app interaction as a type since we instrument which buttons a user clicks
• wrt data sharing, also added personalization to reflect that program admins can provide suggestions to users

and one major change:

• marked location and motion activity as required since we don't allow users continue through onboarding without enabling them
• choosing 18+ as the target audience since younger children typically don't travel independently and do not have much control over their carbon footprint.

[shankari]

Filling it out for iOS; now options have changed. Fitness, Precise Location, Sensitive Info, Product Interaction, Other Diagnostic Data

We now have "sensitive info" for our demographic stuff, so don't need "other data".

Using "Analytics" and "Product Personalization" for all since they cover both the user and aggregate aspects of our functionality.

[shankari]

Based on feedback from legal, indicated that the data was linked with the user identity. EXCEPT for diagnostic data.

[shankari]

Changing the usage to include "app functionality" since that is the primarily functionality of the app and falls under the "enable features" category

[shankari]

Android rejected the app because:

Based on our review, your declared feature does not meet the requirements for background location access.

Please remove the background location permission requested and submit an update to your app. When declaring a feature > for background location access, please note the following: Your selected feature should deliver clear value to the user and be important to the core functionality, or main purpose of > the app. Without this core feature, the app is “broken” or rendered unusable. You should also consider if users would expect the app to access their location in the background, and if you can deliver the same experience without accessing location in the background

Have filed an appeal:

The core functionality of the app is to create travel diaries by automatically tracking user travel patterns. We display these travel diaries to users so that they can provide additional semantic information. We then use this combination of sensed and semantic information to provide individual carbon footprints to users, and support mobility research that involves user data collection. An automatically sensed travel diary is an automatically generated record of how, when and where users travel. It is not possible to create it without background access. We highlight this in (1) the app screenshots, which show a detailed travel diary with user labels, (2) the app description and (3) the privacy policy. We also highlight this after app install but before requesting the location permission - (1) on the initial "join" screen through the ℹ️ button, (2) the consent screen and (3) on the permission status page. We welcome suggestions on improving our representation of the app functionality.

[shankari]

Appeal is being considered by Google.