Support Tracking Domain

[YuriyVelichkoPI]

Background

According to the changes in Apple's privacy approach, some SDKs should register the Tracking Domain in the privacy manifest file.

For now, the Prebid SDK is not on the list of such SDKs. And it doesn't use a centralized server endpoint that can be caught by the Points of Interest instrument.

However, that time may come, or publishers may want to register the PBS endpoint in the privacy manifest proactively. For this case, the SDK should support both tracking and nontracking domains.

Objectives

• Introduce function Prebid.setCustomPrebidServer(url: String, trackingURL: String)
• If publishers provided trackingURL use it in when a user allowed the app to track. Otherwise - use the URL for the bid requests.

[bretg]

I'd like to propose that we switch the order here... let's assume the main Prebid Server can track, and offer an additional "non-tracking" version of the Prebid Server URL.

Prebid.setCustomPrebidServer(url: String, nonTrackingURL: String)

Here's what I think the proposal is:

1. sniff the user's permission settings
2. if tracking is allowed, use the first parameter as the PBS URL
3. if tracking is not allowed, use the second parameter as the PBS URL. Make sure the lmt flag is set because Prebid Server does a bunch of anonymization activities when that's set.

I've opened https://github.com/prebid/prebid-server/issues/3753 to track building a feature in Prebid Server that can recognize when it's invoked in "privacy mode", where it will anonymize key aspects as if the LMT flag were set.

[bretg]

Discussed with Prebid legal counsel. In short, this general approach is approved.

1. Prebid recommends to app developers that they disclose the "worst case" in their privacy manifest - i.e. define the 5 'CollectedDataType' fields.
2. Define the "main" Prebid Server domain in the NSPrivacyTrackingDomains field.
3. If the user declines to be tracked, we should assume that iOS will block that domain. That's fine.
4. But If the app developer so chooses, they could also supply a secondary "privacy mode" Prebid Server URL to PBSDK with the feature described in this issue. The SDK would check for user permissions, and if they've opted out of tracking, then it would use this "privacy mode" PBS domain instead and be sure to set the LimitAdTracking ORTB field. PBS could recognize that it's being called as the secondary domain and see the LMT flag, and take steps to anonymize the request so the app can receive contextual ads. This "privacy mode" domain does not go on NSPrivacyTrackingDomains because it trusts the server-side anonymization.
5. Depending on how Apple chooses to monitor domains, it's possible that even the "privacy mode" domain could be blocked by iOS. If that happens, the PBS host company may have recourse to discuss with Apple.
6. If an app developer is concerned about app store review, they do not have to utilize this secondary privacy mode domain - just let iOS block the PBS requests.

[YuriyVelichkoPI]

To be on the same page. Why don't you consider client-side anonymization?

It's not clear how Apple will decide to add the domain to the list of tracking domains. But if they see that requests don't contain tracking data, it will be harder to add the domain to the list.

On the other hand, they may consider the domain a "tracking domain" not by the request's content but just by the ownership of this domain by some business that can track users (advertising domain). And it can be a reason not to perform client-side anonymization.

[bretg]

@YuriyVelichkoPI - client-side anonymization would be good too. A reason to do it on both sides would be in case there are server-side modules in the future that enrich the request.