Support new Apple App Privacy Improvements for apps and SDKs

[YuriyVelichkoPI]

// TODO

• Add privacy manifest
• Check the SDK with the Point of Interest instrument.
• Study and utilize the Reasons API if needed
• Check the Privacy Impacking SDKs
• Study and futile SDK signatures if needed

Links :

• https://developer.apple.com/app-store/app-privacy-details
• https://developer.apple.com/app-store/user-privacy-and-data-use/

[bretg]

Discussed in committee:

• Prebid will publish documentation detailing how to think about creating the privacy manifest. Timeline is February. But in sum, it doesn't make sense for Prebid to publish the manifest because one of the major fields is the domain of the Prebid Server, and different app developers use different servers. So what will happen is that Prebid will post a guideline for how Prebid can use privacy-sensitive data. We'll do it in a way that's aligned with Apple's manifest so that the app developer can incorporate the relevant usages into their app's manifest.
• This process of creating the manifest is complicated by the fact that publishers can pass privacy-sensitive information as first party data. The contents of any particular app's manifest as pertaining to Prebid SDK depends on what they're passing.
• Prebid Server host companies are going to need to publish two domains for their services: e.g. pbs1.hostcompany.com and pbs2.hostcompany.com. There's no required difference in behavior. It's just an alias. It would be up to each PBS hostcompany to provide two aliases.
• Should we explore having PBS do different stuff when invoked with the "privacy mode"? e.g. anonymize: strip user.data, removing EIDs, rounding off IP addresses. Bret to talk to Prebid legal counsel on the issue of PBS having a "privacy mode".

[YuriyVelichkoPI]

Apple Requirements

On Dec 23, 2024 Apple released an update about privacy requirements - “Privacy updates for App Store submissions”

https://developer.apple.com/news/?id=r1henawx

The key statements related to the Prebid SDK are:

As a reminder, when you use a third-party SDK with your app, you are responsible for all the code the SDK includes in your app, and need to be aware of its data collection and use practices.

It means that the app should report all data collected by the SDK to the app store so it can be verified during the review.

Starting in spring 2024, if your new app or app update submission adds a third-party SDK that is commonly used in apps on the App Store, you’ll need to include the privacy manifest for the SDK.

It is not said that manifests for all SDKs should be included in the app. However, a bit later:

This functionality is a step forward for all apps, and we encourage all SDKs to adopt it to better support the apps that depend on them.

So sooner or later, all SDKs will be required to provide the manifest.

Since the iOS Prebid SDK is shipped only in the form of the source code, the following requirement is not applicable:

Signatures are also required when the SDK is used as a binary dependency.

The update also contains the link to the doc describing the list of SDKs that require the privacy manifest and additional implementation details:

https://developer.apple.com/support/third-party-SDK-requirements/

The doc contains a description of why the privacy manifest is needed and the link to the implementation. The doc also states:

Privacy manifest files outline the privacy practices of the third-party code in an app, in a single standard format.

Prebid Action Items

Taking into consideration the updated info, we can skip providing the manifest to the publisher.

However, I would encourage us to follow the best engineering practices, especially as for community-driven products, and provide some recommendations of how to register Prebid SDK peculiarities in the app manifest. Sooner or later publishers will have to include Prebid SDK items in the app manifest later, to pass the review (since the app is responsible for all the internal code or libraries do).

So I propose to include (and support) a template maifest as standalone file in the SDK project (GitHub) that publishers can use for their apps. In addition we should to describe this template in the docs in details to keep everything transparent for the publishers.

Manifest template and Documentaion

According to the guide Privacy manifest files the Prebid’s manifest template should include:

NSPrivacyTracking - true. Because the SDK collects IDFA.
NSPrivacyTrackingDomains - the PBS domain that will be used when the user granted tracking permission through the App Tracking Transparency framework

NSPrivacyCollectedDataTypes - following the Describing data use in privacy manifests and Prebid SDK workflow, we need to provide the following info in the Privacy manifest:

Location

NSPrivacyCollectedDataTypePreciseLocation - Precise location. Information that describes the location of a user or device with the same or greater resolution as a latitude and longitude with three or more decimal places.
NSPrivacyCollectedDataTypeCoarseLocation - Coarse location. Information that describes the location of a user or device with lower resolution than a latitude and longitude with three or more decimal places, such as Approximate Location

Identifiers

NSPrivacyCollectedDataTypeDeviceID - Device ID. Such as the device’s advertising identifier, or other device-level ID.

Usage data

NSPrivacyCollectedDataTypeProductInteraction - Product interaction. Such as app launches, taps, clicks, scrolling information, music listening data, video views, saved place in a game, video, or song, or other information about how the user interacts with the app.

NSPrivacyCollectedDataTypeAdvertisingData - Advertising data. Such as information about the advertisements the user has seen.

The reason should be:

NSPrivacyCollectedDataTypePurposeThirdPartyAdvertising - Third-party advertising. Such as displaying third-party ads in your app, or sharing data with entities who display third-party ads.

NSPrivacyAccessedAPITypes - following the Describing use of required reason API and Prebid SDK workflow, we need to provide the following info in the Privacy manifest:

• UserDefaults needed for Needed for CMP API
  Reasons: CA92.1- Declare this reason to access user defaults to read and write information that is only accessible to the app itself.

The changes required for the SDK:

Need to implement an API for tracking and non-tracking PBS domains.

The changes required for the Server:

No changes in the server logic are required. All new Apple requirements are only about the client (In-App) side.

The changes required for the Server Vendors:

The PBS vendor should implement an additional tracking endpoint (domain) that SDK will use when the user granted tracking permission.

From the current docs is not clear which exactly traffic will be blocked - TLD/eTLD/eTLD+1.

[YuriyVelichkoPI]

In addition, I checked the Demo App Swift with the Points of Interest instrument as described in the Apple's Guide

https://developer.apple.com/documentation/xcode/detecting-when-your-app-contacts-domains-that-may-be-profiling-users

The result shows that Google's endpoint is in the list of tracking domains, but the endpoint of our test PBS is not. What basically is not surprising, because it is not a widely used PBS endpoint.

I'd recommend prebid vendors to check their endpoints with the Points of Interest instrument as well. If it is listed in as a tracking endpoint, they will see the message like this:

Fault: g.doubleclick.net is not listed in your app’s NSPrivacyTrackingDomain key in any privacy manifest. It may be following users across multiple apps and websites to create a profile about users of apps that contact this domain.

And it means that the apps using their PBS will have to add the respective domain to NSPrivacyTrackingDomains. Hence, the vendors will have to provide additional non-tracking endpoint.

[YuriyVelichkoPI]

The result of checking the app with the Points of Interest instrument makes me think that Apple will hunt on tracking endpoints and BLOCK their traffic. It means that widely used advertizement endpoints, sooner or later, will be in this list and additional non-tracking endpoints won't help.

Once the user deny tracking all the traffic will be blocked by iOS.

Apple, in this way, should provide some endpoint verification mechanism, that proves non-tracking utilization of the endpoint. But it doesn't look achievable.

So, if Apple applies the blocking of tracking endpoints, the AdTech industry will see a dramatic decrease in the active inventory.

@alexsavelyev @mmullin @bretg have you heard something about it?

[YuriyVelichkoPI]

DOC: prebid/prebid.github.io#5119
iOS: #954

[YuriyVelichkoPI]

Just for the note.

The website that helps to build Privacy Manifest: https://www.privacymanifest.dev/