Built-in bid adapter Aliases without a GVLID

[andyblackwell]

Type of issue

Question

Description

From what I can tell v8 changed functionality so an aliased bidder needs it's own GVLID to pass GDPR checks and work as expected. I'm wondering why all the current aliases inside bid adapters weren't also updated to use their corresponding GVLID along with this change?

#9717 even points out the issue where an aliased bidder that used to work no longer does
we ran into the issue similarly, but with the built in alias qortex on the adkernel's bid adapter, which has 29 aliases, only one of which includes a gvlid

#10451 attempts to warn users about this, but that only works for custom aliases, and falls short of warning about aliases shipped with a bidder itself, which registers aliases differently and bypass the logic that triggers the warning

This seems to be a fairly large "gotcha" when migrating from v7 to v8, and I would have expected the built in aliases to be properly configured, or something to call this out specifically in the v8 release notes. Would it be possible to put an initiative together to rectify this? A good number of aliases I'd hope could be found with a simple lookup on the vendor list: https://iabeurope.eu/vendor-list-tcf/ 🤞 (... update, so yeah that doesn't help for many of the bidder aliases)

Steps to reproduce

in the EU, run a consented auction for a built-in aliased bidder that doesn't have a gvlid set. example: the qortex alias of the adkernel bid adapter

Expected results

The aliased bid fires off a bid request

Actual results

bid fetching is blocked

Warning: Activity control: TCF2 denied 'fetchBids' for 'bidder.X'

Platform details

v8.21.0

Other information

#9717, #10451

[andyblackwell]

maybe as a related helpful bit of data, when I was looking to see if the aliases could be matched up to a gvlid programatically (didn't have good luck there 😞), I also grepped for all the bid adapters currently with no GVLID at all, filtered those down to ones that closely match names in the vendor list, and here's a gist of the resulting mapping
https://gist.github.com/andyblackwell/ab4ffe56bac78f6ca9fc5c780eadbc39
maybe this would be useful to update those bid adapters?

[patmmccann]

We decided not to fill in the gvlids without guidance as there was no way for us to know if a company (bidder) were sharing the personal information with another entity (the alias) or not. I think we might have filled in some short codes where it was obviously the same company.

I think this came up in the activity controls re-architecture in 7.52, which was a huge effort. Do you know if qortex should use the adkernel gvlid? It seemed quite risky to make these decisions

[andyblackwell]

Qortex happened to be an easy one to find in the vendor list, and had its own id

1082 Watch Fantom Inc. AKA Qortex

[andyblackwell]

before completely closing/forgetting this, would you be able to address the other bug I mentioned where the new warning about this only affects custom aliases, and doesn't warn pubs about built-in aliases?

#10451 attempts to warn users about this, but that only works for custom aliases, and falls short of warning about aliases shipped with a bidder itself, which registers aliases differently and bypass the logic that triggers the warning

[bmjoju]

@patmmccann What about the ‘gvlMapping’ object https://docs.prebid.org/dev-docs/modules/gdprEnforcement.html? It does not have any affect after version 8? But just until now not visible until #10451.

[patmmccann]

Reopening this to track the development of the feature request: If GVLID is missing, the TCF enforcement module should be more verbose about its warning message for bid suppression

[patmmccann]

@bmjoju do you have evidence gvlMapping object is broken? Please open a new issue if so.