Should aliases default to the GVL ID of the main bidder?

[bretg]

Type of issue

topic of discussion

Description

One of our pubs is running a bidder that is one of the aliases of the appnexus adapter:

  aliases: [
    { code: 'appnexusAst', gvlid: 32 },
    { code: 'emxdigital', gvlid: 183 },
    { code: 'pagescience' },
    { code: 'defymedia' },
    { code: 'gourmetads' },
    { code: 'matomy' },
    { code: 'featureforward' },
    { code: 'oftmedia' },
    { code: 'adasta' },
    { code: 'beintoo', gvlid: 618 },
  ],

What's happening now is that that aliased bidder is not passing GDPR checks because it doesn't declare the GVL ID.

The workaround is easy enough:

pbjs.mergeConfig({
    gvlMapping: {
         MYALIAS: 32
    }
})

But this begs a few questions:

1. Is it legally correct for aliases to share GVL IDs with the main bidder? It's not clear to me that a user consenting to appnexus is also aware that they're consenting to pagescience, defymedia, adasta, etc.
2. If it is legally correct, why not have Prebid.js handle this scenario without the manual override?
3. If it isn't legally correct, is there any documentation desirable to help publishers determine what to do? I could see, for instance, a case where a 'white label' adapter doesn't share data with the alias, then it might be ok to share the GVL ID. But if the alias is a separate business with access to raw logs, then it might not be ok to assume the user is fine sharing their log-level data with this separate entity.

My proposal is that the right approach for Prebid is just what's happening today: the main adapter code should copy their own gvlid for aliases where they don't share data. If they share data, then the alias should have either no gvlid (which should result in failed GDPR validation) or their own gvlid so users can consent separately.

Updated req from discussion: we should do log.info (only shows in debug) if someone aliases a bidder and loses gvlid. otherwise, we'll solve the rest with docs on prebid.org

[patmmccann]

I agree with your proposed guidance

the main adapter code should copy their own gvlid for aliases where they don't share data. If they share data, then the alias should have no gvlid, which should result in failed GDPR validation.

with a slight edit:

: the main adapter code should copy their own gvlid for aliases where they don't share data. If they share data, then the alias should have an additional or no gvlid, which should result in failed GDPR validation if the vendor id is missing or the consent string does indicate consent for whichever purpose(s) the enforcement module looks for

[bretg]

thanks - wording fixed.

[bretg]

We probably ought to enhance the bidder documentation with this nuance about when it's ok to share a GVLID - agree?

[patmmccann]

absolutely

[dgirardi]

There's a related problem that I found working on GPP phase 3:

the storageManager interface takes in a GVL ID. This does not work well with aliases; for example, the appnexus adapter has a myriad of aliases, some with their own GVL ID:

Prebid.js/modules/appnexusBidAdapter.js

Lines 102 to 113 in bb81403

	aliases: [
	{ code: 'appnexusAst', gvlid: 32 },
	{ code: 'emxdigital', gvlid: 183 },
	{ code: 'pagescience' },
	{ code: 'defymedia' },
	{ code: 'gourmetads' },
	{ code: 'matomy' },
	{ code: 'featureforward' },
	{ code: 'oftmedia' },
	{ code: 'adasta' },
	{ code: 'beintoo', gvlid: 618 },
	],

But, it accesses storage using always the same GVL ID:

Prebid.js/modules/appnexusBidAdapter.js

Line 97 in bb81403

const storage = getStorageManager({gvlid: GVLID, bidderCode: BIDDER_CODE});

This means that when using for example emxDigital bidder, it will use GVLID 183 to check whether it can fetch bids; but GVLID 32 (appnexus' original GVLID) to check whether it can access storage.

[dgirardi]

Update on the above: it's not actually a problem, because the GDPR enforcement actually ignores (mostly) the GVLID passed to the storage manager:

Prebid.js/modules/gdprEnforcement.js

Lines 207 to 212 in bb81403

	// Bidders have a copy of storage object with bidder code binded. Aliases will also pass the same bidder code when invoking storage functions and hence if alias tries to access device we will try to grab the gvl id for alias instead of original bidder
	if (curBidder && (curBidder !== moduleName) && adapterManager.aliasRegistry[curBidder] === moduleName) {
	gvlid = getGvlid(curBidder);
	} else {
	gvlid = getGvlid(moduleName) || gvlid;
	}

it's still due some refactoring since the gvlid parameter is misleading - not actually used in most situations, but it's not as urgent as it would otherwise appear.

[patmmccann]

we should do log.info (only shows in debug) if someone aliases a bidder and loses gvlid. otherwise, we'll solve the rest with docs on prebid.org

[bmjoju]

@bretg Is the vendorless gvl id also missing something? After updating from 7.42 to 7.54.0 this warning now shows up "WARNING: Activity control: TCF2 denied 'accessDevice' for 'userId.pubCommonId'". I guess due to this #9736 ?

[bretg]

I'm not as familiar with the accessDevice activity as some of the others. But anyhow, the Activity Control config is quite flexible. You should be able to do something like:

pbjs.setConfig({
  allowActivities: {
    accessDevice: {
        rules: [{
            condition: ({componentName}) => componentName === 'pubCommonId',
            allow: true,
        }]
    }
  }
})

Might be worth noting that PubCommonID is gone in 8.0. Time to switch to sharedid.

[bmjoju]

@bretg Thanks. Strange is it was not necessary before, and the module can still access the device and store id and also retrieve. If I set the config, i guess unselecting prebid as vendor in tcf, it will still have access?

We are using the sharedid module, I think i noticed some writing that is still calls itself pubcommonid.

[bretg]

Sorry @bmjoju , have to defer this level of detail to @patmmccann.

[bmjoju]

@patmmccann Do you know why this error suddenly comes up?

WARNING: Activity control: TCF2 denied 'accessDevice' for 'userId.pubCommonId'

[dgirardi]

@bmjoju it looks like a bug, which should be fixed by #10183