This month Meta unveiled Threads to the world. Even before the app opened its doors, people were already concerned about its privacy implications, and its Privacy Nutrition Labels in particular. The sentiment, especially by Mastodon users, was “I’m not going to install Threads because of all the data it collects”. That sentiment is not only factually wrong (more on that later), but a lot of people disagreed with it too, because Threads became the fastest growing app ever, beating the previous record set by ChatGPT.
From this aforementioned sentiment, I learned that Privacy Nutrition Labels are widely misunderstood. Something me and tech analyst Benedict Evans apparently have in common.
Oh and yes, all the embedded tweets in this article will be screenshots, so you can actually see them without a Twitter account.
So, what are Privacy Nutrition Labels?
Privacy Nutrition Labels were introduced in 2020 on the Apple App Store, and in 2022 on Google Play (called ‘Data Safety’). On both stores, its a section on every app’s listing page detailing the data the app might collect. On the App Store, data is either “Not Linked to You”, for data collected anonymously, “Linked to You”, for data collected that is not anonymized, or “Used to Track You”, for data collected and used for ad tracking.
On the Play Store, data is either collected, for data transferred to the developer’s servers, shared, for data transferred to third parties, or both. Moreover, on the Play Store the developer can indicate for each data point whether collection is optional.
For good measure, here’s Threads’:
And here’s Mastodon’s:
Big difference, huh?
The confusion
As is evident from the screenshots and links in the introduction, these Privacy Nutrition Labels seem to be understood by lots of people as if they are app permissions. That, by simply downloading the app, the user grants the app access to all this data. This understanding is similar to how app permissions actually used to work on Android before version 6 (released in September 2015). But this is not how app permissions work on either platform nowadays, and besides, Privacy Nutrition Labels are not app permissions.
Privacy Nutrition Labels are just that, labels. They are not a privacy policy you’re agreeing to by downloading the app, and they are certainly not permissions you grant the app by downloading it. These labels are self-reported by the app developer. They are not actively verified by anyone, although app store review might notice glaring omissions.
If an app wants access to your contacts in your phone, it will have to show a permission request dialog, which you have to agree to. The app cannot simply declare the Contacts label to get around this fact. This is the “sandbox” that Benedict Evans is referring to in the above tweet. Apps get almost no access by default, and have to request permission for access on a case by case basis. This is true for both platforms. If Privacy Nutrition Labels worked the way they are misunderstood, it would be a giant backdoor out of this sandbox model.
Guidance for app developers from Apple on when to declare each label is here, while Google’s is here.
The discrepancy
As you can see above, there’s quite a big difference in Privacy Nutrition Labels for Threads and Mastodon. Why is that? Let’s start by stating the obvious: Threads simply collects more data than Mastodon. However, there are some factors at play that increase this discrepancy.
As indicated above, these labels are self-reported by the developer. So, we should look at it from the perspective of the developer. For a large developer like Meta, getting this wrong is very risky. While the labels are generally not actively verified by anyone, there’s of course always a risk that someone does. Either someone from the press trying to find a story, or a lawyer trying to make a case. This risk is higher for a larger company, and maybe even more so for Meta, which traditionally is subject to a lot of public scrutiny (rightly so, given their history of privacy scandals). Moreover, they have the legal resources to interpret the guidelines and make sure they’re on the safe side. For example, a cautious legal department might read Apple’s definition of the Coarse Location label (”Information that describes the location of a user or device with lower resolution than a latitude and longitude with three or more decimal places […]”) and conclude that a user’s IP address fits that bill.
For a smaller developer, like Mastodon GmbH, the PR and legal risks are a lot smaller, and they’ll have a lot less eyes on them. They will also lack the resources to spend effort interpreting the guidelines. Lastly, it seems they are actually under-reporting the collected data. I believe at least these 3 labels are missing (definitions in italics from Apple):
- Email Address - Including but not limited to a hashed email address. An email address is required to create a Mastodon account.
- Contacts - Such as a list of contacts in the user’s phone, address book, or social graph. Even though Mastodon might not request access to the user’s contacts in their phone, it’s definitely building a social graph.
- Other User Content - Any other user-generated content. Mastodon is a social network, which is inherently full of user-generated content.
It’s important to note that Apple’s documentation says Privacy Nutrition Labels should still be declared for data used solely for app functionality (which I assume is true for the above 3 examples).
So, while I don’t doubt that Threads collects far more data than Mastodon, and that Threads uses some of that data for advertising purposes (on Instagram, until Threads gets its own ads) while Mastodon won’t, the discrepancy seems to be magnified by 2 factors: Meta being cautious and Mastodon under-reporting.
Where to go from here?
So, what can we do about this? As companies, Apple and Google could make it clearer what kind of data is behind an OS permission request dialog (like Precise Location), and what kind of data may be collected without such a request (like Coarse Location through an IP address). This might give users more peace of mind downloading apps.
There’s one thing Google is doing which Apple should adopt: in the Google Play Store, you can see which data items are optionally collected. On the Apple App Store you can’t. This at least tells the user: this data is not collected until I either enter it, grant an app permission, or take some other action related to this data. (You can think of something like payment info, which could be collected if you enter it, but you don’t have to enter to use the app.)
As an individual, there’s not much we can do. Make sure you understand that Privacy Nutrition Labels are not like app permissions, and that the data they describe is not necessarily automatically handed over to the app when you install and open it. If there’s any data you don’t want to share with an app, do not enter it voluntarily (like your birth date or credit card number).
Lastly, I hate to break it to this Twitter user, but App Tracking Transparency is only tangentially related, and it’s definitely not a catch-all data collection blocker.
Further reading
When doing some final Googling after finishing this article, I found this similar take by Pixel Envy. A recommended read if you want some more realistic Privacy Nutrition Labels content. If my article spurred your urge to comment, you can do so on Mastodon, Bluesky or Twitter. (I’m also on Threads, but currently unable to use it due to being in the EU. Feel free to follow me though.)
One more thing…
Do you love newsletters? But hate a cluttered inbox? Then you might like Feedo, which I built to solve this! Feedo takes your newsletters out of your inbox, and presents them in a beautiful feed.
More reasons to love Feedo:- 👀 No algorithm: Feedo presents your newsletters in a chronological feed. There's no AI trying (and failing) to figure out what you want to see.
- 🧠 Smart: Feedo automagically finds the newsletters in your inbox. No need to manually tell it which emails are newsletters (although you can).
- 🤷♀️ Simple: Feedo works with your current email account.
