Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prebid Server and the Apple Privacy Manifest NSPrivacyTrackingDomains #3753

Open
bretg opened this issue Jun 14, 2024 · 1 comment
Open

Prebid Server and the Apple Privacy Manifest NSPrivacyTrackingDomains #3753

bretg opened this issue Jun 14, 2024 · 1 comment

Comments

@bretg
Copy link
Contributor

bretg commented Jun 14, 2024

Background info

I believe PBS should offer the ability to recognize a second domain name by looking at the HTTP host header. If called by that name, it should disallow these activities:

  • syncUser
  • enrichUfpd
  • transmitUfpd
  • transmitEids
  • transmitPreciseGeo

See below for proposed implementation.

Prebid legal counsel is ok with this proposal.

Assumption

  • We think Apple will be blocking only FQDNs (pbs.example.com) and not TLDs (example.com). If that's not true, then a whole separate domain (pbs.example2.com) would be needed by host companies.

Implementation details

  1. Add a new host-level config external-url-privacy-safe
external-url: "https://prebid-server.examplehostcompany.com"
external-url-privacy-safe: "https://prebid-server-incognito.examplehostcompany.com"
  1. /auction endpoint

    1. Check the HTTP host header.
    2. If it matches the domain of the external-url-privacy-safe config, override the incoming lmt flag to 1
  2. /amp endpoint

    1. Check the HTTP host header.
    2. If it matches the domain of the external-url-privacy-safe config, add lmt:1 to the base ORTB request.
  3. /cookie_sync and /setuid endpoints

    1. Check the HTTP host header.
    2. If it matches the domain of the external-url-privacy-safe config, immediately return HTTP 451 with an empty body.
  4. Enhance the current behavior of LMT to tie it to the noted activities.

@bretg bretg moved this from Triage to Ready for Dev in Prebid Server Prioritization Jun 28, 2024
@bretg bretg moved this from Ready for Dev to Clarify Request in Prebid Server Prioritization Jul 3, 2024
@bretg bretg moved this from Clarify Request to Needs Requirements in Prebid Server Prioritization Jul 3, 2024
@bretg
Copy link
Contributor Author

bretg commented Sep 5, 2024

This has been discussed with Prebid legal council

  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. 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.

@bretg bretg moved this from Needs Requirements to Community Review in Prebid Server Prioritization Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Community Review
Development

No branches or pull requests

1 participant