Get started with privacy manifests

♪ ♪ Tony: Hi, I'm Tony from Privacy Engineering. Welcome to "Get started with Privacy Manifests." At Apple, we believe privacy is a fundamental human right. In addition to techniques like data minimization, a key part to bring this value to life is to make sure people have transparency and control. To support this, we now provide new tools to make it even easier for you to provide accurate Privacy Nutrition Labels and integrate App Tracking Transparency. This is because the apps you build are integral parts of people's lives. There are many apps to choose from, and as a refresher, Privacy Nutrition Labels help people learn more about how your apps collect and use their data. People often want to know: What are the categories of data that apps collect about them? Is data used to track them? Is data linked to them? Privacy Nutrition Labels demonstrate the great privacy work that you've done in your apps, and they give people the information they need to make great choices. For all new and updated apps on the App Store, developers like you have been providing Privacy Nutrition Labels. And you've been using App Tracking Transparency to give people control over when their data is used to track them. It's now easier for you to provide accurate Nutrition Labels and integrate App Tracking Transparency. You are responsible for all code included in your apps, per the App Store Review Guidelines. This includes any data collection and tracking practices. A large part of your app's privacy story often depends on third-party SDKs. 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".

This file is a property list that declares what data types the SDK collects, how each data type is used, whether they are linked to the user, and whether they're used for tracking as defined by the App Tracking Transparency policy. Taking a closer look at this manifest, the Example Sharing SDK is listed as not tracking. It collects name and user ID, linked to the user, for both app functionality and product personalization. It also collects photos or videos, linked to the user, for just app functionality.

Check that the privacy manifest matches your understanding of the third-party SDK's functionality. The definitions for types of data and data use for privacy manifests are the same as for the Nutrition Label, so refer to the Apple developer documentation on app privacy details.

And the new privacy report brings all this information to one place. Let me show you how that works.

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. To view this, go to Xcode Organizer, show the context menu for an archive, and select "Generate Privacy Report." The privacy report is a PDF and easy to use. It is organized in a similar way to Privacy Nutrition Labels. So you can easily reference this report when you provide your app's privacy details in App Store Connect. This helps you review, understand, and describe the privacy practices of your app and its dependencies.

To learn more about Nutrition Labels, watch the WWDC22 video: Create your Privacy Nutrition Label.

Another feature of privacy manifests is helping you manage tracking domains, by making it easier for you to understand and control network connections from your app.

While you don't intend to track people without their permission, there may be edge cases that create un-intended network connections to domains that are used for tracking. For example, many third-party SDKs check tracking permission status before tracking people. However, some third-party SDKs rely on you to manually disable tracking when the user has not granted permission. The third-party SDK might default to tracking unless you specify otherwise, either through a function in their library, or some configuration change. This could lead to edge cases. To make it easier for you and third-party SDK developers to avoid tracking people without their permission, privacy manifests that declare tracking include tracking domains. In cases when a user has not provided tracking permission, iOS 17 automatically blocks connections to tracking domains that have been specified in any privacy manifest included in your app. This helps you eliminate those edge cases. In addition to the privacy manifests included in third-party SDKs, you can also choose to create a privacy manifest for your app, which may also include tracking domains. By preventing accidental connections, this feature helps to preserve your intention to not track users without their permission. Tell iOS your tracking domains, and the system will help.

For more information about tracking, visit the Apple Developer website, or watch the WWDC22 video, Explore App Tracking Transparency.

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.

You may not always realize if your app, or a third-party SDK, is connecting to a tracking domain. In Xcode 15, the Points of Interest instrument can help you with this during your testing. It now shows connections to domains that may be following people across multiple apps and websites to combine their activity into a profile.

This puts you in the driver's seat, and you can assess whether a domain is used for tracking under the App Tracking Transparency policy. If it is, then you or your SDK developer should declare the domain as a tracking domain in the privacy manifest.

With the user's permission, tracking is allowed. However, fingerprinting is never allowed. Fingerprinting is using signals from the device to try to identify the device or user. Regardless of whether a user gives your app permission to track, fingerprinting is not allowed. There are existing APIs in our platforms that have the potential of being mis-used for fingerprinting. However, these APIs also provide powerful user experiences when accessed appropriately. To support important use cases that benefit the user while avoiding fingerprinting, there is a new category of APIs called Required reason APIs. We have begun by grouping these APIs into categories, taking into consideration their functionality and the information they provide. For each category, there is a list of approved reasons to access these APIs, based on their use cases. For example, one Required reason API is NSFileSystemFreeSize, which indicates the amount of free space on the file system. One of its approved reasons supports using this API to check whether there is sufficient disk space before writing files to disk.

The list of Required reason APIs and approved reasons, including any future updates, is published in the Apple developer documentation. The total number of Required reason APIs is small, but it is likely that you use one or more of them. If you have a use case for an API category that is not already covered by an approved reason, and the use case directly benefits the user, the documentation will link to a feedback form where you can let us know.

To protect users from possible fingerprinting, apps and SDKs are allowed to access the Required reason APIs only for the approved reasons. Data returned from these APIs may not be used for other purposes. To help you clearly state why you use Required reason APIs, and to make it easy for third-party SDK developers to do the same, privacy manifests include this information. An app or third-party SDK that accesses a Required reason API declares the API category, and all of its reasons for using the API. These must be selected from the list of approved reasons for that category.

Just like Nutrition Labels in the App Store, which help people make choices about your app, privacy manifests help you make decisions about your dependencies. Each privacy manifest also gives you a better picture of your app's privacy story by making the Xcode privacy report more complete. It's a great idea to leverage third-party SDKs that provide privacy manifests, and SDK authors can add manifests to existing versions of their SDKs.

Looking at the app ecosystem, we have identified some third-party SDKs that have particularly high impact on user privacy. These are called privacy-impacting SDKs. A list of these third-party SDKs, and any future updates, is published in the Apple developer documentation. Because it is especially important for you to get information from privacy-impacting SDKs, apps that include a privacy-impacting SDK will be required to include a copy of that SDK with a privacy manifest. Xcode 15 also supports SDK signatures, which help you protect your app and verify the integrity of third-party SDKs. Including a signature is a best practice for all third-party SDKs. To help you confirm that the developer you expect provided the privacy manifest for privacy-impacting SDKs, apps that include a privacy-impacting SDK will also be required to ensure that the SDK is signed. For more information about SDK signatures, watch "Verify app dependencies with digital signatures." Starting in Fall 2023, App Store will check if new and updated apps include a library from a privacy-impacting SDK. If the privacy-impacting SDK does not include a signature and privacy manifest, Apple will send an informational email to the app developer. Apple will also send informational emails for apps that access Required Reason APIs without declaring approved reasons. Starting in Spring 2024, these will be expected and become part of App Review. You'll need to address any issues before you can submit new and updated apps to the App Store. Okay, here's what's next. App developers: Ask for SDK privacy manifests from your third-party SDK developers. Always refer to the Xcode privacy report when you are submitting your app to keep your Nutrition Label up to date. SDK developers: Adopt signatures and manifests. These are super helpful to your customers. All developers: Document and declare tracking domains and Required Reason API usage in your app or SDK's privacy manifest. With the new privacy manifests, providing accurate, complete, and clear privacy information to your users will be easier than ever. Thanks for watching. ♪ ♪