One privacy initiative introduced by Apple at WWDC that received considerably less attention than the ATT framework was app privacy labels. A privacy label is a sort of “nutrition label” for an app related to data collection: the label reveals what data is collected by an app, and for what purpose. Developers were forced to start supplying the data used to generate the labels at app submission on December 8th, and the labels will start appearing in the App Store at some point this year.
With privacy labels, Apple requires a developer to identify the types of data their app collects from users — either through native app functionality or through a third-party’s SDK — as well as the purpose that data collection serves. This data is collected during the iTunes connect submission process, and the app’s privacy label is automatically created and applied to the app’s page on the App Store.
The concept of privacy nutrition labels is neither new nor novel. The privacy-focused CUPS lab at Carnegie Mellon University has been conducting research into privacy nutrition labels for years; this brief paper walks through how their approach has evolved over time. Below is an example of their grid model for a privacy nutrition label.
If privacy policies are perfunctorily accepted because users can’t summon the motivation to read through them carefully, an interesting philosophical issue to consider is whether making those policies more accessible will change that. Do users fundamentally not care about privacy? Will a user’s attitude toward a digital service — especially a free service — change if they understand how their data is collected and used?
These are important questions. But the App Store privacy labels don’t address them. Rather, these labels create operational overhead for developers while pushing privacy information below-the-fold on App Store storefront pages.
A presentation by mobile growth consultancy Phiture values the “long description” text on an App Store page at a 1 out of 5 in terms of conversion impact (the likelihood that a user downloads the app). This is consistent with my experience: users simply don’t spend much time learning about the app from its App Store page beyond looking at the app’s icon, screenshots, and review ranking, all of which are above the fold.
Further, users may take interest in privacy labels when they are launched, but the labels will ultimately look more or less the same for all apps: most apps utilize third-party analytics, ad mediation, product personalization, authentication, subscription management, etc. services, and those services collect similar sets of data to fulfill their core use cases. Even if user habits do change to include below-the-fold App Store assets as determinants of app adoption, if the privacy label for every app looks roughly the same, then those labels won’t meaningfully impact user behavior.
User privacy is a critical frontier into which Apple should invest. But privacy labels feel performative: a gesture designed to convince users that something is being done. As I wrote in Why is Apple rebuilding the App Economy?, while I think other considerations primarily motivated the deprecation of the IDFA, I do believe that Apple genuinely does care about protecting user privacy and likely sees it as a potential competitive advantage in selling hardware and services. But privacy nutrition labels don’t substantively address privacy concerns: only real platform regulation can do that.