Apple’s “Privacy Nutrition Labels” Are a Blessing and a Curse
Johnny Lin (tweet):
Apple doesn’t verify any of the App Privacy information that app developers submit - because they can’t. There is currently no way for Apple to know what an app does with user data after the data is sent to the app. But by calling it equivalent to “Privacy Nutrition Labels”, Apple irresponsibly implies that this privacy information is vetted, when that is absolutely false.
This results in two unintended consequences: it creates a false sense of security for users, and an incentive for more dishonest and privacy-invasive apps in the App Store.
[…]
In this situation, both email apps collect basic analytics. The dishonest app, however, writes in their App Privacy that they don’t collect or sell any data, while the honest app admits that they collect basic analytics. So you read the App Privacy for both apps, and decide that since you want to “maximize privacy”, you download the dishonest app - the one that secretly sells your emails to third parties. It’s not your fault - it’s the fault of a poor incentive structure.
As he notes, Apple is financially incentivized to allow dishonest apps to make lots of money, which they partially pour into App Store Search Ads, and many of these have remained in the store over the long term.
Previously:
- SolarWinds Breach
- iOS App Privacy Labels
- Scam Apps and Fleeceware
- Governments Buying Phone Location Data
- Lockdown 0.1.1
Update (2021-01-22): Dimitri Bouniol:
Seems like Apple is verifying App Privacy information after all — this came in even though we didn’t submit an update or anything, though we clearly forgot that RevenueCat does indeed collect information when we thought our app didn’t collect anything…
Or, rather, Apple is verifying some of the information. As with App Review in general, it’s not possible to determine all the things an app might do.
By default @RevenueCat doesn’t actually collect any PII (we don’t even store the IP address), but Apple does consider purchase history something that needs to be disclosed even if it’s not tied to a user’s identity.
2 Comments RSS · Twitter
@Leo The app could encrypt the traffic or only engage in the bad behavior after a time delay or after being enabled by a feature flag from a server. It basically reduces to the halting problem.
If Apple really doesn’t do deep audits of these Apps, despite having the private APIs and purported automation to do so then what’s the point?
The “Nutrition Labels” just come off as more makework for developers and “job security bureaucracy” for App Reviewers.
One blogger says Apple *can’t* —can’t what? Isolate an app in a VM and do network traffic analysis with dummy data? And have automated scripts to to this before a human reviewer even touches the App? Really? I wonder what Apple does with all those “Automation SQA” hires then.
That said, Apple couldn’t even uncover Parler’s invasive data mining coupled with their rice paper thin security. (Which is the real reason Parler should never be allowed back into the store all other bluster aside).