Over a decade ago, experts first introduced the idea of a “privacy nutrition label” to provide users with a clear and easy-to-understand snapshot of how their personal data might be collected and used. The intention with privacy nutrition labels is to offer an alternative to the traditional privacy policies that allow for clearer language and greater transparency over data usage.
Apple launched the first-ever large-scale adoption of the privacy nutrition labels concept to their App Store in December of 2020 called iOS Privacy Nutrition Labels. Since then, Google has followed with its announcement that all apps must have their Data Safety Section filled out and approved in the Google Play Store by July 20, 2022.
Read our blog to learn about the differences between Google Play Data Safety and Apple Nutrition Labels requirements and why it matters to developers and users.
What are Apple’s iOS Privacy Nutrition Labels?
Apple iOS Privacy Nutrition Labels require developers to detail their data handling practices in the App Store Connect to help users learn at a glance what data will be collected by an app, whether that data is linked to them or used to track them, and the purposes for which that data may be used. Based on the responses, your App Store product page will be updated to include data about the app’s data collection and usage.
Responses are provided at the app level and should represent your app’s data practices across all platforms. This means developers should take a holistic approach to privacy and if your app collects more data on one platform than another, you should answer in the most comprehensive and inclusive way. Additionally, developers will need to provide information about their app’s privacy practices, as well as the practices of third-party partners whose code is integrated into your app.
What is Google Play Data Safety?
Google Play has announced that July 20, 2022, is the deadline to accurately fill out its Data Safety Form. The purpose of this form is to roll out a new Data Safety section to users that require app developers to properly disclose the data they collect, if and how it’s shared with third parties, security practices, and more. Like Apple’s Nutrition Labels, it provides an opportunity for users to make more informed choices through transparency.
Developers must declare how they collect and handle user data for the apps they publish on Google Play and provide information about how they protect this data through security practices such as encryption. Additionally, this includes data collected and handled by any third-party libraries or SDKs.
Apple Privacy Nutrition vs. Google Data Safety
Both sets of labels derive from the same concept of protecting user privacy and promoting transparency, but there are still some core differences. Apple’s Nutrition Labels mostly focuses on privacy – specifically, what data is being collected, including data used for tracking purposes, in addition to informing the user what data is linked to them. However, Google’s Data Safety labels go further by putting a bigger emphasis on transparency and trust – specifically whether you can trust that the data collection is being handled responsibly by allowing developers to detail if they follow best practices around data security.
Most importantly, Google Data Safety labels give Android developers an opportunity to provide more context behind their data collection. This allows developers to make their case as to how that data is used, such as for app functionality, personalization, etc., which gives users a better understanding when they make their decision to download the app. Also, users on Google Play will have the ability to see if that data collection is required or optional.
It’s important developers read how each platform defines specific privacy terms so as to not under or overreport their app’s data collection and usage practices. For example, Apple tends to focus mostly on advertising and defines terms like “tracking” as data linked with third parties for advertising or advertising measurement purposes or shared with a data broker. Still, some developers took a broad approach to tracking and included location data or data used to track interactions which resulted in overreporting. It is worth noting that Google Data Safety is looking at both data types – precise location (GPS), and approximate location (Wi-fi/Bluetooth).
Similarly, Google requires developers to disclose data as “collected” if it is transmitted off the device, while Apple’s definition of data collection requires both transmission and backend storage. Also, iOS guidance specifies “You are not responsible for disclosing data collected by Apple”, while Google does not offer the same condition.
Reporting Differences
While the types of data that need to be disclosed are similar across Apple and Google, the way in which they display this data is different.
Apple iOS Privacy Nutrition Labels display data that each app collects from users in 3 sections:
- Data Used to Track You – ensure you have a clear understanding of how each data type is used by you and your third-party partners
- Data Linked to You – Identify whether each data type is linked to the user’s identity by you and/or your third-party partners.
- NOTE: A common mistake is assuming data is only identifiable on its own as linked to users. However, a combination of data points, while on its own may not be identifiable, together they are identifiable and should be handled as such.
- Data Not Linked to You – includes data that is collected but is not being linked to a user in any identifiable way, such as location data or browsing history.
App Privacy Requirements
The data types and categories for reporting are very similar across Apple and Google.
- Contact Information – name, email address, phone number, physical address, and other user contact information used to contact user outside of app.
- Health & Fitness – anything from medical records or symptoms to information about fitness or physical activity.
- Financial Information – Payment information, purchase history, credit information, and other financial information such as salary, income, assets, debts, etc..
- Location – Precise location and Approximate location
- Sensitive information – such as race and ethnicity, sexual orientation, pregnancy, disability, religious or philosophical beliefs, etc.
- Contacts
- User Content – emails or texts, photos or videos, audio data, gameplay content, customer support, calendar, files and docs, and other user content
- Browsing & Search History
- Usage Data – product interaction, advertising data, in-app search history, installed apps, other user-generated content, and other actions
- Diagnostics – Crash data, performance data, and other diagnostic data
- Device or other IDs – Identifiers that relate to a user’s device, browser or app. For example, IMEI number, MAC address or advertising identifier.
Why developers should care
Software developers have increasing responsibility to deal with the ever-growing privacy requirements from platform providers and recently enacted laws such as the GDPR and CCPA and consequently face an increasing number of challenges. It’s easy for developers to make under or overreporting errors when getting overwhelmed and confused over differences in privacy jargon. As both the Apple Nutrition labels and the Google Play Data Safety requirements embed themselves, it will become ever more important for developers to understand the purpose of privacy labels, the foundation of privacy, and how you can promote user trust and transparency. The future is privacy, and these requirements will only increase and become more scrutinized. The adoption of more privacy education and automation will enable developers to continue to update privacy labels quickly and easily so that app labels are always accurate.
Additionally, users’ distrust in privacy labels will produce consequences related to decreasing app downloads. For example, one study reported a developer who explained that one of his users complained that the app was collecting IP addresses while its iOS privacy label indicated “Data Not Collected”. Although he explained to the user that the IP address was used to service a request and wasn’t stored, which does not count as data collection per Apple’s definition, he still got a bad review on the App Store.
How OneTrust helps
Ever since these concepts have been introduced and adopted there continues to be a large gap in developer privacy knowledge, overall understanding of the process to comply, and how to manage ambiguity. Additionally, the challenges of creating a privacy label may make developers reluctant to update their privacy labels in the long run.
OneTrust helps app developers understand and navigate complex privacy requirements while automating the process for quick future updates. OneTrust Mobile App Compliance & Scanner is constantly evolving to eventually give our clients the ability to:
- Review third-party SDKs integrated on your app
- Get an in-depth view of what data is collected by third-party SDKs & APIs
- Review data collection by Google Play data safety category, type, and purpose
- Our mobile app scan will detect and identify data categories and data types. It will make inferences for the purpose but will need review by developers
- Create an SDK and API data collection xlsx that can be exported to a .csv format
- Map data categories directly to GDPR articles
- Full end-to-end integrated workflow for OT assessment and mobile customers
Learn more by requesting a demo today and get access to all the tools and resources needed to comply with Google Play Data Safety requirements by the July 20th deadline.
