Privacy Manifests
We have heard from developers like you that it can be challenging to get all the information you need from the great third-party SDKs that your apps depend on. Privacy manifests are a new way for third-party SDK developers to provide information about their privacy practices. This information helps you accurately represent privacy in your app.
Third-party SDK developers can include a privacy manifest in their SDK. They can create a new privacy manifest right from the Xcode navigator, by creating a file named “PrivacyInfo.xcprivacy”.
[…]
When you’re building your app to submit to the App Store, Xcode 15 can aggregate all the privacy manifests in your app’s project, and produce a privacy report that summarizes the declared data uses.
[…]
In some cases, domains may be used for both tracking and non-tracking functionality. An approach that you or a third-party SDK developer could take is to separate the functionality into different host names. For example, you can host tracking functionality at tracking.example.com, and non-tracking functionality at non-tracking.example.com. Then, declare tracking.example.com as a tracking domain in the privacy manifest.
This is neat, but I still question how useful this is when it’s all based on the honor system. Is there any evidence that nutrition labels do more than provide a false sense of security? Apple seems to be acting like the problem with nutrition labels is that they could be accidentally incorrect.
Privacy nutrition labels on the App Store were a step forward for how informed people could be about what an app is doing with their data, but I’d also bet that a non-trivial amount of them are incorrect in some way. 😬 In the vast amount of cases, I’d expect that to be caused by the inclusion of third-party SDKs.
[…]
But that’s not everything, and tucked away at the bottom of the news post was a little note that says everything about how seriously Apple think about this. They say that later this year, they’ll publish “a list of privacy-impacting SDKs (third-party SDKs that have particularly high impact on user privacy)”.
The rogue 2FA app that steals scanned secrets is now ranked 18 on the German App Store for the productivity category. No wonder! The app disguises as a Microsoft app. It is the top hit when you search for “Microsoft Authenticator” and the developer has updated the screenshots in the ad card to highlight the word “Microsoft”. Surprisingly, the product page of the app shows different screenshots with the word “Microsoft” removed.
The app now has 1.2K reviews, as opposed to 18 when we first addressed the app.
Previously:
- Privacy and Security in macOS 14
- Xcode 15 Announced
- Scam Authenticator App Steals QR Codes
- Plenty of Tracking Despite App Tracking Transparency
- App Tracking Transparency Doesn’t Stop Trackers
- App Tracking Transparency’s Honor System
- Misleading and Inaccurate iOS Privacy Labels
- Apple’s “Privacy Nutrition Labels” Are a Blessing and a Curse
Update (2023-08-01): Apple (Hacker News, MacRumors, The Register):
Starting in fall 2023, when you upload a new app or app update to App Store Connect that uses an API (including from third-party SDKs) that requires a reason, you’ll receive a notice if you haven’t provided an approved reason in your app’s privacy manifest. And starting in spring 2024, in order to upload your new app or app update to App Store Connect, you’ll be required to include an approved reason in the app’s privacy manifest which accurately reflects how your app uses the API.
If you have a use case for an API with required reasons that isn’t already covered by an approved reason and the use case directly benefits the people using your app, let us know.
There is now a list of APIs and reasons.
I don’t even see the point of self-documenting. Either it’s based on the “honor system”, which would be stupid, or Apple is going to test your usage somehow, in which case the privacy manifest is redundant.
Despite stupidity of explicitly declaring a reason to use foundation provided API (just prevent it from doing forbidden operations), there’s only ONE reason you can use UserDefaults for. And it’s not even clear how it contradicts API documentation.
The raise of new crazy rejections on the horizon.
all of all, this is plain stupid security by obscurity. I’m 100% sure none of the big players have to care about this, neither Apple applications. as usual just a burden put on the shoulder of small developers.
TIL that using the standard user defaults functionality is going to require special privacy declaration. Other troublesome API includes getting the modification date of a file and figuring out how much disk space is available…
What’s next, you must declare each For loop that you use within your app? Beyond stupid.
The system makes available certain defaults available to all apps based on global user preferences. These can be used to fingerprint users. Hence, the changes.
UserDefaults has always been a silent exfiltrator of private data; every framework your app can access (Photos, Music, Safari, telephony, etc) generally needs access to its own UserDefaults store, which left tons of side channels for any app to pick up things like phone number, email address, real name, recent Photos searches, etc, without any kind of permissions prompt. Any library you include in your app, like analytics packages, can yoink all of this without you [as app developer] knowing.
I agree with strengthening user privacy in general, and this approach makes sense for permissions such as user location, camera or contacts.
But in my opinion it serves no purpose for such ubiquitous permission as User Defaults. To borrow a comparison I’ve seen elsewhere, it’s like a network access permission on Android. Every single app declared it, and it became universally accepted and ignored. Or the cookie prompts, which users have been trained to ignore for years.
Wild overreach from Apple. Can’t read defaults data from other apps in the same app group. Can’t log in crash reports how much disk space is remaining, etc (their own crash reporting system basically does not work). I get that Apple is trying to protect users from being uniquely identified, but there are only a few apps where that sort of data is at the scale where it is valuable. Maybe go after them and not the rest of us.
Because clearly individuals devious enough to figure out how to do device fingerprinting won’t be able to come up with plausible-sounding reasons to use those APIs.
I see it as a way of emphasizing that you can’t do some things with it and making you acknowledge it in writing, and then when an app is caught abusing it, they can’t pretend they didn’t know 🤔
I don’t think it’s aimed at bad actors; it’s aimed at big companies with lawyers, and specifically at their SDKs. Facebook may be utterly amoral, but they’re not going to lie about fingerprinting in a privacy manifest for a library used by tens of thousands of apps; the risks from getting caught are too high.
I don’t see why they would care about getting caught. Worst case, they just stop doing it. It’s not like Apple is going to delete Facebook’s developer account.
It’s kind of amazing how much this tries to ‘both sides’ the issue of developers abusing APIs to do fingerprinting of their users; ‘an additional hoop developers must jump through’, ‘the controversial App Tracking Transparency initiative’, ‘clever developers’, ‘those who have been taking advantage of this loophole’, etc.
This is only true if you believe that Apple has the ability (and desire) to actually implement this in good faith — and we know they don’t. Apps that are clear scams (like fake authenticator apps), get past app review AND remain as the top hit for long periods of time. Meanwhile good apps get jerked around for weeks. You can write the best rules you want, but unless you execute them fairly, it becomes the equivalent of “3 felonies a day”: the ability to arbitrarily deny any app.
[…]
Of course it’ll make it worse, it’s another complicated metric. The reviewers already aren’t technical, & now they’ll judge more complicated “defenses”. And it requires more upfront work by devs (the smallest of whom will be hit hardest, huge companies can do it easily), in exchange for the same crapshoot as today. You can be flagged for an description that has never changed, you think adding more places to dock you will make things more “consistent”?
to anyone that believes apple will use privacy manifests for reasonable policies that benefit users…
like, where have you been? were you asleep for the last ten years of sandbox woes? are you new here?
sorry, but the list of totally onerous rules, missing apis, and riduluously capricious enforcement has jaded me. i can only see this pushing developers and users to more reasonable platforms.
Update (2023-08-17): Apple (via Accidental Tech Podcast):
You only need to supply
NSPrivacyAccessedAPITypesfor apps and third-party SDKs on iOS, iPadOS, tvOS, visionOS, and watchOS.
In other words, not for macOS—so far.
Update (2023-08-23): Marco Eidinger:
In this blog post, I’ll share a shell script that helps you to identify if your code base might use a required reason API.
2 Comments RSS · Twitter · Mastodon
This sounds like a gradual move from an honor system to technical enforcement measures being put in place. See e.g. https://www.branch.io/resources/blog/the-dark-horse-of-wwdc-2023-privacy-policies-finally-get-real/
@Nigel Yes, but isn’t that doomed because they can’t see what you send to a server or where that server subsequently sends the data?
