Feature request: Prebid should validate vendor consents on returned user syncs?

[adtechnology]

Type of issue

Bug, Question ?

Description

we have not authorized, implemented or released in our Prebid.js ID5. Nevertheless, we see that ID5 is diligently passed on to the SSPs. Unfortunately, this is a major data protection no-go. How can we prevent IDs from being passed on to the SSPs without consent or even being collected?

See Network Traffic

See Initiator. It is Prebid

Steps to reproduce

Just visit f.e. https://www.bild.de/regional/hamburg/hamburg-aktuell/mann-steigt-mit-verdaechtigem-guertel-in-linienbus-passagiere-rufen-die-polizei-81442996.bild.html and check the network traffic. We dint see always ID5, I suppose, they sync it once a day.

Test page

https://www.bild.de/regional/hamburg/hamburg-aktuell/mann-steigt-mit-verdaechtigem-guertel-in-linienbus-passagiere-rufen-die-polizei-81442996.bild.html

Expected results

No IDs to be passed to SSPs without Publisher's consent

Actual results

IDs (ID5) is being passed to SSPs by Prebid without Publisher's consent

Platform details

Prebid 7.10.0 , Tested on Chrome 105.0.5195.125 and Opera 91.0.4516.20

Other information

[dgirardi]

That traffic does not necessarily mean that id5 is passed on to SSPs; rather, it looks like a user sync. In your case it comes from the improvedigital adapter, which fires syncs returned from the backend:

https://github.com/prebid/Prebid.js/blob/e3d0038f365bf3b0ff68709f7bd4e10d5bb1d36d/modules/improvedigitalBidAdapter.js#L253-L262

[patmmccann]

@jbartek25 does your bidder honor https://docs.prebid.org/dev-docs/publisher-api-reference/setConfig.html#setConfig-ConfigureUserSyncing-UserSyncExamples syncs per bidder in its for loop?

@adtechnology this appears to be normal pixel syncing activity. Which providers your ssps sync with is a matter to discuss with each of them. Prebid doesn't have a rule or reasonable way to police the list, but we're open to proposals.

@smenzer fyi

[smenzer]

@adtechnology as @patmmccann mentioned, this is cookie syncing and has nothing to do with the Prebid User ID module or our submodule. Based on the consent string we receive, we determine if we have consent to perform the usersync. If you do not wish to allow ID5 to operate on your website, you may remove us from the vendor list that your CMP uses to prevent us from ever having users' consent.

[adtechnology]

@dgirardi Thank you! unfortunately this is not allowed, I spoke with out legal and privacy teams, this sync ist not allowed without publisher's and user's consent. @smenzer We don't have id5 in our CMP's Vendor List. You can see it on. the following link, https://www.bild.de/corporate-site/privatsphaere/bild-de/artikel-privatsphaere-72035848.bild.html, Privatsphäre-Einstellungen --> Drittanbieter. There you can see, no id5 is listed.

[adtechnology]

@patmmccann our Legal and Privacy department says, that this is a not allowed behavior. The publisher has to be able to accept or reject this syncs. Allowing and passing an ID requires a lot of legal effort.

[smenzer]

@adtechnology In that case, we are not processing any user data and do not perform the cookie sync. You'd need to work with your SSP to make sure they don't fire our pixel if we don't have consent - we have no way to prevent ourselves from being called, but we do ensure we don't process data if we don't have consent.

[dgirardi]

@adtechnology, as a stopgap, you can disable improvedigital's user syncs with

pbjs.setConfig({
    userSync: {
        filterSettings: {
            image: {
                bidders: ['improvedigital'],  
                filter: 'exclude'
            }
        },
    }
});

Currently, Prebid has no good way to pick and choose syncs beside the bid adapter; it does not "know" that a particular pixel returned by improvedigital is really from id5. As @smenzer noted, improve digital (and other SSPs) should be able to verify consent before asking for a sync.

For consent to be enforced by Prebid we would need to require a GVLID for user sync registration. At first glance it seems doable but relatively expensive to implement.

[patmmccann]

If syncs and gvl ids come back as tuples, prebid checking sync list for consent could be possible on pixel syncs but not iframe syncs, but this seems quite onerous and is not planned at this time.

We prefer the ssp that pushes the syncs to prebid is responsible for eliminating non-consented vendors from sync lists. In this case @jbartek25 ; could you provide detail on why a nonconsented vendor is being added to your sync array?

@jdwieland8282 can you weigh in

[jdwieland8282]

@adtechnology In your original screenshot I don't see any cookies actually being set. The response header section lists:

• cf
• cip
• cnac
• car
• gdpr
• callback

Those cookies all have names but no values. Although I do see a query param on the GET to id5-sync.com called publisher_user_id where what looks like an uid is present. In principal, everyone should be checking for consent bf passing a uid or setting one on the users browser. While we can't control who inits user syncs to us, we can all decode the IAB daisy bid and look for our gvlid before we do anything else.

[adtechnology]

@adtechnology In your original screenshot I don't see any cookies actually being set. The response header section lists:

• cf
• cip
• cnac
• car
• gdpr
• callback

Those cookies all have names but no values. Although I do see a query param on the GET to id5-sync.com called publisher_user_id where what looks like an uid is present. In principal, everyone should be checking for consent bf passing a uid or setting one on the users browser. While we can't control who inits user syncs to us, we can all decode the IAB daisy bid and look for our gvlid before we do anything else.

@jdwieland8282 it is not just about cookies. You can see, that my ID5 is being sent to the SSP. Without Publisher and User Consent is this behavior not allowed, specially if in this case Id5 is not listed in the CMP.

[adtechnology]

If syncs and gvl ids come back as tuples, prebid checking sync list for consent could be possible on pixel syncs but not iframe syncs, but this seems quite onerous and is not planned at this time.

We prefer the ssp that pushes the syncs to prebid is responsible for eliminating non-consented vendors from sync lists. In this case @jbartek25 ; could you provide detail on why a nonconsented vendor is being added to your sync array?

@jdwieland8282 can you weigh in

Thx @patmmccann as publisher we would like to have the possibility in Prebid to opt-in this user syncs/spp, independent of the user consent. of course, if the ssp is reading out the IDs without respecting the TC-String is even worst.....

[adtechnology]

@adtechnology, as a stopgap, you can disable improvedigital's user syncs with

pbjs.setConfig({
    userSync: {
        filterSettings: {
            image: {
                bidders: ['improvedigital'],  
                filter: 'exclude'
            }
        },
    }
});

Currently, Prebid has no good way to pick and choose syncs beside the bid adapter; it does not "know" that a particular pixel returned by improvedigital is really from id5. As @smenzer noted, improve digital (and other SSPs) should be able to verify consent before asking for a sync.

For consent to be enforced by Prebid we would need to require a GVLID for user sync registration. At first glance it seems doable but relatively expensive to implement.

thx! @dgirardi - yes! to verify consent would help. nevertheless, we need a solution in Prebid in the long term. I am of the opinion that the IDs should only be managed using the Prebid ID module.

[yashraj-02]

Can I pick this up? @patmmccann @jdwieland8282

[smenzer]

@adtechnology I think you're getting two things confused... there are cookie syncs that occur that SSPs initiate (you can control which SSPs initiates them within prebid, but that's it) and there is the User ID module.

SSP initiated cookie syncs are managed entirely by the SSP. There is no way Prebid can tell an SSP which platforms it can sync with once it calls their initial pixel. This must be managed within the SSP. While I completely agree with you that all user identity should ultimately be done through the User ID module (and thus, through "universal ids"), as an industry we aren't there yet - DSPs still rely mostly on receiving their own cookie-based identifier from SSPs, which means SSPs still need to cookie sync with them to make the impression valuable.

The User ID module gives publishers full control over what IDs are made available in the auction - these are "universal ids" and not cookie syncing pixels, though. Prebid has extensive controls over who is called and when already, so I think you're covered on that front.

ID5 is included in the cookie syncing part because we help ad tech platforms improve match rates by trying to centralize some of this cookie syncing to limit how many connections need to be made in the browser and instead send user id pairs (SSP id >> DSP id) in a s2s process. We still ensure there is consent for ID5, the SSP, and the DSP when we perform these syncs, and we do not call platforms without consent for them; but as mentioned above, if we are called by a platform when we don't have consent, there's nothing we can do to prevent the call, but we do make sure we don't process user data and return an empty 200 response back. I hope that helps clarify things a bit...but feel free to reach out directly if you want to discuss further - you can find me in the Prebid or Adops slack groups.

[patmmccann]

@yashraj-02 anyone is welcome to pick these sorts of things up, could you remind me what company you're at? As warning though, we expect this to be a bit harry. Adapters do not currently deliver tuples of gvl id with sync id, so some sort of module with lookups would need to exist, which might be difficult to maintain.

[yashraj-02]

Well, I work for AdPushup Ltd. We are a service provider in adtech industry. We partner with the prebid adapter providers like pubmatic, rubicon etc & run them on publishers' websites. We don't have our own adapter or analytics integrated in prebid.js Hope that is fine.

[adtechnology]

@patmmccann I am Working for Axel Springer in Germany, we are publisher and we need urgently controls over these syncs.

[jdwieland8282]

Thanks @smenzer. @adtechnology does that make sense? The call to id5-sync isn't happening from prebid. The initor is your SSP.

[adtechnology]

Thanks @smenzer. @adtechnology does that make sense? The call to id5-sync isn't happening from prebid. The initor is your SSP.

@jdwieland8282 sure! It would be great if Prebid gets Cookie/ID Sync-Controls in the future. If a SSP makes it by its own we would remove it.

[avuim]

ms without consent for them; but as mentioned above, if we are called by a platform when we don't have consent, there's nothing we can do to prevent the call, but we do make sure we don't process user data and return an empty 200 response back. I hope that helps clarify things a bit...but feel free to reach out directly if you want to discuss further - you can find me in the Prebid or Adops slack groups.

To add on what @smenzer mentioned and @adtechnology requests, I would like to make you aware of a specification (a.k.a. 1st Party/Publisher Curated Addressability) being written by some german market experts to cover ID/1st party data transmission throughout the programmatic value chain: Publisher > SSP > DSP > SeatLevel (Advertiser/Agency) > e.g. DMPs when doing bidding/fc/analysis/... Although it goes beyond Prebid configuration, it incorporates the given control mechanisms (pbjs.userIds/filterSettings) described here as part of the solution and shows a mid-term control mechanism required to fullfil privacy requirements in EU/DE not stopping with the (Prebid) API between publisher and bidder/SSP but going beyond.

Note: Aside the tech spec, a legal component (contract) will be required to bind DSP/other parties involved to the publisher controlled config, but this is not part of the description.

The group of authors is planning to hand over the given spec to IAB techlab for further work as part of the open source initiative in the coming weeks. We anyway warmly welcome everybody to contribute on this if benefitial to the discussion with a PR.

[patmmccann]

AdPushup's contribution is quite welcome, thanks! Please post back the mechanics here for feedback before submission.

[avuim]

ms without consent for them; but as mentioned above, if we are called by a platform when we don't have consent, there's nothing we can do to prevent the call, but we do make sure we don't process user data and return an empty 200 response back. I hope that helps clarify things a bit...but feel free to reach out directly if you want to discuss further - you can find me in the Prebid or Adops slack groups.

To add on what @smenzer mentioned and @adtechnology requests, I would like to make you aware of a specification (a.k.a. 1st Party/Publisher Curated Addressability) being written by some german market experts to cover ID/1st party data transmission throughout the programmatic value chain: Publisher > SSP > DSP > SeatLevel (Advertiser/Agency) > e.g. DMPs when doing bidding/fc/analysis/... Although it goes beyond Prebid configuration, it incorporates the given control mechanisms (pbjs.userIds/filterSettings) described here as part of the solution and shows a mid-term control mechanism required to fullfil privacy requirements in EU/DE not stopping with the (Prebid) API between publisher and bidder/SSP but going beyond.

Note: Aside the tech spec, a legal component (contract) will be required to bind DSP/other parties involved to the publisher controlled config, but this is not part of the description.

The group of authors is planning to hand over the given spec to IAB techlab for further work as part of the open source initiative in the coming weeks. We anyway warmly welcome everybody to contribute on this if benefitial to the discussion with a PR.

The Project is now an IAB TechLab OpenSource Project: https://github.com/IABTechLab/1st-party-curated-addressability

[patmmccann]

So one way to validate the syncs is to look for vendor id's here

or in GPP

and simply suppress any there is no purpose 1 consent for in Canada or Europe.

This of course may be difficult on iframe syncs but should work if a block of pixel syncs comes back?

Appears ready for dev if we rely on these macros existing in syncs?