It should have been a surprise to exactly nobody that Threads, Meta’s Twitter-alike, was going to seem hungrier for personal data than Bluesky or Mastodon.
That is how Meta makes its money: its products surveil as much of your behaviour as possible, then they let others buy targeted advertising. That differs from the other two services I mentioned. Bluesky says its business model “must be fundamentally different” because anyone will be able to spin up their own server; it has raised venture capital and is selling custom domain names. Mastodon is similarly free; its development is supported by various sponsors and it has a Patreon account pulling in nearly half a million dollars annually, while most individual servers are donationware.
Meta is not currently running advertising on Threads, but one day it will. Even so, its listings in Apple’s App Store and Google’s Play Store suggest a wide range of privacy infractions, and this has not gone unnoticed. Reece Rogers, of Wired, compared the privacy labels of major Twitter-like applications and services on iOS, and Tristan Louis did the same with a bunch of social apps on Android. Michael Kan, of PC Magazine, noticed before Threads launched that its privacy label indicated it collected all the same data as Twitter plus “Health & Fitness, Financial Info, Sensitive Info, and “Other Data””. That seems quite thorough.
Just as quickly as these critical articles were published came those who rationalized and even defended the privacy violations implied by these labels. Dare Obasanjo — who, it should be noted, previously worked for Meta — said it was “a list of features used by the app framed in the scariest way possible”. Colin Devroe explained Threads had to indicate such a vibrant data collection scheme because Threads accounts are linked to Instagram accounts. My interpretation of this is because you can, for example, shop with Instagram, it is possible to link billing information to a profile.
That there is any coverage whatsoever of the specific privacy impacts of these applications is a testament to the direct language used in these labels. Even though Meta’s privacy policy and the supplemental policy for Threads have been written with comprehension in mind, they are nowhere near as readable as these simplified privacy labels.
Whether those labels are being accurately comprehended, though, is a different story, as indicated in the above examples. The number of apparent privacy intrusions in which Threads engages is alarming at first glance. But many of the categories, at least on iOS, require that users grant permission first, including health information, photos, contacts, and location. Furthermore, it is not clear to me how these data types are used. I only see a couple of passing references to the word “health” in Meta’s privacy policy, for example, and nothing says it communicates at all with the Health database in iOS. Notably, not only does Threads not ask for access to Health information, it also does not request access to any type of protected data — there is no way to look for contacts on Threads, for example — nor does it ask to track when launched. In covering all its bases, Meta has created a privacy label which suggests it is tracking possibly everything, but perhaps not, and there is no way to tell how close that is to reality nor exactly what is being done with that information.
This is in part because privacy labeling is determined by developers, and the consequences of violations for misrepresentation are at the discretion of Apple and Google. Ironically, because each of the players involved are giant businesses, it seems to me like there may be limitations about the degree to which these privacy labels are able to be policed. If Apple or Google were to de-list or block Meta’s apps, you know some lawyers would be talking about possibly anti-competitive motives.
That is not to say privacy labels are useless. A notable difference between the privacy label for Threads and some other apps is not found in the list of categories of information collected. Instead, it is in the title of that list: “Data Linked to You”. It should not be worrisome for a developer to collect diagnostic information, for example, but is it it necessary to associate it with a specific individual? Sure enough, while some apps — like Tapbots’ Ivory and the first-party Mastodon client — say they collect nothing, others, like Bluesky and Tooot — a Mastodon client — acknowledge collecting diagnostic information, but say they do not associate it with individual users. Apple is also pushing for greater transparency by requiring that developers disclose third-party SDKs which collect user data.
All of this, however, continues to place the onus of responsibility on individual users. Somehow, we must individually assess the privacy practices of the apps we use and the SDKs they use. We must be able to forecast how our granting of specific types of data access today will be abused tomorrow, and choose to avoid all features and apps which stray too far. Perhaps the most honest disclosure statements are in the form of the much-hated cookie consent screens which — at their best — give users the option for agreeing to each possible third-party disclosure, or agreeing or disagreeing in bulk. While they provide an aggressive freedom of choice, they are overwhelming and easily ignored.
A better option may be found in not giving users a choice.
The rate at which tech products have changed and evolved has made it impossible to foresee how today’s normal use becomes tomorrow’s privacy exploitation. Vacation photos and selfies posted ten or twenty years ago are now part of at least one massive facial recognition database. Doorbell cameras become a tool for vigilante justice. Using the web and everyday devices normally subjects everyone to unchecked surveillance, traces of which persist for years. The defaults are all configured against personal privacy, and it is up to individuals to find ways of opting out of this system where they can. Besides, blaming users for not fully comprehending all possible consequences of their actions is the weakest rebuttal to reasonable consumer protections.
Privacy labeling, which appeared first in the App Store before it was added to the Play Store, were inspired by food nutrition labels. I am happy to extend that metaphor. At the bottom of many restaurant menus will often be printed a statement which reads something like “eating raw or lightly cooked foods of animal origin may increase your risk of food poisoning”. There are good reasons (PDF) to be notified of that risk and make judgements based on your personal tolerance. But nobody expects the secret ingredient added by a restaurant to their hollandaise to be salmonella. This reasonable disclosure statement is not sufficient to protect kitchen staff from taking reasonable precautions to avoid poisoning patrons.
We can only guess at some pretty scary ways these everyday exploitations of our private data may be used, but we do not have to. We have plenty of evidence already that we need more protections against today’s giant corporations and tomorrow’s startups. It should not be necessary to compare ambiguous labels against company privacy policies and imagine what they could do with all that information just to have a text-based social media account. Frivolity should not be so poisoned.