The curious case of Apple's third-party SDK list for privacy manifests

At last year’s WWDC, Apple introduced privacy manifests. They recently sent out a reminder that the deadline for complying with these new requirements is May 1. Privacy manifests expand on the previously introduced privacy “nutrition labels” that are self-reported by developers and displayed on the App Store. Developers must start including a privacy manifest in their apps by the aforementioned deadline, but what’s more interesting is that Apple is, for the first time, imposing these new privacy rules on third-party SDKs as well. Even more interesting is the list of SDKs that Apple has published, which, upon inspection is quite bizarre.

Historically, Apple has rarely, if ever, explicitly acknowledged any third-party SDK or library. It took years for them to even acknowledge community tools like CocoaPods in Xcode’s release notes (usually when they made a change that broke it). Thus, it is interesting to see which SDKs they have deemed important or concerning enough to explicitly mandate a privacy manifest. And, in typical Apple fashion, I’m pretty sure SDKs authors were not notified about this in advance. We all learned which SDKs need privacy manifests at the same time — when the list was published.

The first few entries in the list make sense:

• Abseil, a low-level C++ library.
• AppAuth, an SDK for communicating with OAuth 2.0 and OpenID Connect providers.
• AFNetworking and it’s successor Alamofire, networking libraries that wrap Apple’s APIs, which almost every iOS developer has encountered.
• BoringSSL, a fork of OpenSSL maintained by Google.

I can see how these libraries could be concerning with regard to user privacy, they are all dealing with networking, authentication, and security (except for Abseil) — these are common vectors for privacy-related issues. Abseil is the exception, but I could see an argument for why a low-level C++ library might be a concern. There are also a lot of SDKs from Google and Facebook on the list — neither of those companies have a particularly good reputation when it comes to user privacy. It makes sense for those to be included.

But then… you see that the list contains UI libraries that haven’t seen significant updates or any activity for multiple years, like SVProgressHUD. Why does a library that provides a single UI component need a privacy manifest? Is it as concerning and as potentially privacy invasive as the Facebook SDK? Some of the UI-only SDKs on the list haven’t seen significant updates (or any updates at all) within the last 4-5 years. Furthermore, even AFNetworking hasn’t had an update in 4 years because it was deprecated long ago after being supplanted by Alamofire. The AFNetworking repo on GitHub has been archived and read-only for over a year! Who’s going to bother adding a privacy manifest to that?

And then… there are some entries that are simply obscure and absurd: connectivity_plus, image_picker_ios, video_player_avfoundation, file_picker. What the hell are those?! They don’t even sound like SDK or library names. I have never heard of any of these, and I’ve been involved in the iOS open source community for a decade.

And then… you know what’s even more bizarre about this list? There are no links! There are no links to the SDK project homepages or GitHub repos. It is a plain text list of names, and in some cases, seemingly random names like “file_picker”. Ok LOL. SDK and library names are not necessarily unique. How are you supposed to know exactly which SDKs they are referencing with so little information? Searching for “file_picker” or “image_picker_ios” or any of the other obscure names on both CocoaPods and the Swift Package Index returns no results!

Finally, wouldn’t you expect some sort of reason or justification for each of these SDKs being on the list? We don’t need a 10-page essay but a brief explanation of a few sentences explaining why each of these SDKs is on the list would be helpful in understanding the logic and reasoning behind it.

Nothing about this list makes any sense.

* * *

For a company that has positioned itself as a staunch privacy advocate, this list of SDKs is slapdash at best. The lack of attention to detail, like simply including links to SDK homepages, makes the list appear like it was assembled hastily and carelessly. It makes you wonder, how was this list compiled? What was the criteria for including or excluding an SDK from this list?

I was venting about the list on Mastodon, and the general consensus is that it was most likely just a script dump from a static analysis of app binaries on the app store, with the sole criterion being “what are the most popular libraries” used across all apps, with some minimum threshold for inclusion. It is quite clear from the list that no one at Apple really put much thought into it. 🤡

If we operate under the hypothesis that this list is merely the output of a script that someone at Apple wrote to check off the line item “determine which third-party SDKs should be required to included privacy manifests”, then it all starts to make more sense. This list is ultimately the result of a popularity contest, not a thoughtful analysis of SDKs that have meaningful implications for user privacy. They couldn’t even bother to link to the projects or provide brief explanations. There’s literally an entry titled “file_picker” with no other explanation. Did anyone at Apple even look into any of these libraries? Did anyone at Apple even read through this list after some script vomited it out?

When Apple imposes new privacy regulations in such a slipshod manner, how are we, as developers and as users, supposed to take this seriously? This feels like more bureaucratic security and privacy theater. Let’s all take off our shoes and throw away sealed bottles of water we purchased at the airport before we proceed through the TSA security checkpoint — meanwhile doors and wheels are falling off the damn plane.