Criteo Adapter Changes

[gglas]

Type of issue

Enhancement / Review Requested

Description

Criteo's adapter contains legacy third party javascript dependencies that don't perfectly align with the new Prebid best practices and rules -- this is because the technology predated prebid and appropriately couldn't develop around best practices that didn't exist! We were hoping to have someone in the community review Criteo's documentation to make sure the planned development strategies align with where prebid is going.

Other information

Documentation is available here :

https://docs.google.com/document/d/1pTjeUR7v8QxVyZMarYBlTzc6Dq_TW4vPoI_6hbK9jok/edit?usp=sharing

[patmmccann]

Of particular note, the build time crypto library seems to only be useful if the pubtag is included. One would hope there is a simple way for publishers to build without this library if a publsher does not use the publisher tag.

[patmmccann]

A couple other notes, the #5644 hash might be able to be used in place of the criteo hash included at build time and the ceh property can now be read from #5767 if available

[allanjun]

Thanks for the comments @patmmccann

Of particular note, the build time crypto library seems to only be useful if the pubtag is included. One would hope there is a simple way for publishers to build without this library if a publsher does not use the publisher tag.

This can be one possibility but then we would perhaps have to split our adapter in two. Or perhaps we could offer an explicit build command option to remove these.

The #5644 hash might be able to be used in place of the criteo hash included at build time

Our crypto library uses assymetrical encryption to validate the content is not modified

The ceh property can now be read from #5767 if available

We do have T&C signed with the publisher to ensure that the data collected is in accordance with our privacy requirements. Setting this parameter at bidder level works as an explicit optin, whereas on #5767 the publisher may send data to all bidders without prior agreement.

[bretg]

Can someone please explain the crypto concern and the options?

[patmmccann]

The concern is that if a publisher disables the calling of the Criteo external code, the adapter is still importing a huge build time dependency into prebid that it doesn't need. I'm not sure of all the options, if build time dependency options are even a thing, if an alternative or more compact function could be used, if this implies one would need two version of the adapter, or if the functionality could move to the criteo external library. I know the LiveIntent team is working on build time options.

[bretg]

Got this background:

The function tryGetCriteoFastBid verifies the authenticity of the content stored on criteo_fast_bid
Verification is based on a RSA signature;
First line of criteo_fast_bid contains a hash of the code signed with a secret key;
The public key is available on the adapter code;
The function computes the checksum of the code and validates the authenticity based on the public key and the signed hash;
Finally, the content is loaded via eval and the Publishertag is available.

For that we import a library to handle the RSA in javascript. PAtrick sugested using one of existing hash methods, but they don't actually do asymetric signatures like RSA

My take is that this is just more external code, even though it's build-time. As far as I'm concerned, that just requires another disclosure.

Here's a proposed disclosure that will be placed on the criteoBidAdapter page:

This module loads external code both at run-time and at build-time. The build-time code is an open source
RSA security library. The run-time code is not open source but the default version has been inspected by
Prebid.org core reviewers. Note that disabling the external run-time code will still pull in the build-time code.

I'm signing off on this approach -- over to @gglas to figure out how can we get full signoff from the group so Criteo can start building it.

[patmmccann]

I don't think this disclosure is accurate, as the version of the code that is available to prebid core reviewers has been changing regularly for several months in an unavailable location and includes extensive unreviewed functionality.

…

On Tue, Dec 1, 2020 at 1:19 PM bretg ***@***.***> wrote: Got this background: The function tryGetCriteoFastBid verifies the authenticity of the content stored on criteo_fast_bid Verification is based on a RSA signature; First line of criteo_fast_bid contains a hash of the code signed with a secret key; The public key is available on the adapter code; The function computes the checksum of the code and validates the authenticity based on the public key and the signed hash; Finally, the content is loaded via eval and the Publishertag is available. For that we import a library to handle the RSA in javascript. PAtrick sugested using one of existing hash methods, but they don't actually do asymetric signatures like RSA My take is that this is just more external code, even though it's build-time. As far as I'm concerned, that just requires another disclosure. Here's a proposed disclosure that will be placed on the criteoBidAdapter page: This module loads external code both at run-time and at build-time. The build-time code is an open source RSA security library. The run-time code is not open source but the default version has been inspected by Prebid.org core reviewers. I'm signing off on this approach -- over to @gglas to figure out how can we get full signoff from the group so Criteo can start building it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[patmmccann]

For more details, here is the commit history on that location https://github.com/prebid/Prebid.js/blob/master/modules/criteoBidAdapter.js . There were no commits from March to August and a batch of commits on August 28. The current version is not available there. I think the code should be locked to a version of this file. Commits on Aug 28, 2020 Add version 96 afewcc committed on Aug 28 3543e21 Add version 95 afewcc committed on Aug 28 17947b0 Add version 94 afewcc committed on Aug 28 6fbc08a Add version 93 afewcc committed on Aug 28 588de00 Add version 92 afewcc committed on Aug 28 7d18e90 Add version 91 afewcc committed on Aug 28 879dc21 Add version 90 afewcc committed on Aug 28 19e22e4 Add version 89 afewcc committed on Aug 28 9a6b06b Add version 88 afewcc committed on Aug 28 c2d8021 Add version 87 afewcc committed on Aug 28 92b7e6b Add version 86 afewcc committed on Aug 28 f69ded9 Commits on Mar 11, 2020 Add version 85 afewcc committed on Mar 11 ce02c5c

…

On Tue, Dec 1, 2020 at 1:23 PM Patrick McCann ***@***.***> wrote: I don't think this disclosure is accurate, as the version of the code that is available to prebid core reviewers has been changing regularly for several months in an unavailable location and includes extensive unreviewed functionality. On Tue, Dec 1, 2020 at 1:19 PM bretg ***@***.***> wrote: > > Got this background: > > The function tryGetCriteoFastBid verifies the authenticity of the content stored on criteo_fast_bid > Verification is based on a RSA signature; > First line of criteo_fast_bid contains a hash of the code signed with a secret key; > The public key is available on the adapter code; > The function computes the checksum of the code and validates the authenticity based on the public key and the signed hash; > Finally, the content is loaded via eval and the Publishertag is available. > > For that we import a library to handle the RSA in javascript. PAtrick sugested using one of existing hash methods, but they don't actually do asymetric signatures like RSA > > My take is that this is just more external code, even though it's build-time. As far as I'm concerned, that just requires another disclosure. > > Here's a proposed disclosure that will be placed on the criteoBidAdapter page: > > This module loads external code both at run-time and at build-time. The build-time code is an open source RSA security library. The run-time code is not open source but the default version has been inspected by Prebid.org core reviewers. > > I'm signing off on this approach -- over to @gglas to figure out how can we get full signoff from the group so Criteo can start building it. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe.

[patmmccann]

Sorry, https://github.com/Prebid-org/prebid-js-external-js-criteo/commits/master/dist/prod.js is the location

…

On Tue, Dec 1, 2020 at 1:27 PM Patrick McCann ***@***.***> wrote: For more details, here is the commit history on that location https://github.com/prebid/Prebid.js/blob/master/modules/criteoBidAdapter.js . There were no commits from March to August and a batch of commits on August 28. The current version is not available there. I think the code should be locked to a version of this file. Commits on Aug 28, 2020 Add version 96 afewcc committed on Aug 28 3543e21 Add version 95 afewcc committed on Aug 28 17947b0 Add version 94 afewcc committed on Aug 28 6fbc08a Add version 93 afewcc committed on Aug 28 588de00 Add version 92 afewcc committed on Aug 28 7d18e90 Add version 91 afewcc committed on Aug 28 879dc21 Add version 90 afewcc committed on Aug 28 19e22e4 Add version 89 afewcc committed on Aug 28 9a6b06b Add version 88 afewcc committed on Aug 28 c2d8021 Add version 87 afewcc committed on Aug 28 92b7e6b Add version 86 afewcc committed on Aug 28 f69ded9 Commits on Mar 11, 2020 Add version 85 afewcc committed on Mar 11 ce02c5c On Tue, Dec 1, 2020 at 1:23 PM Patrick McCann ***@***.***> wrote: > > I don't think this disclosure is accurate, as the version of the code > that is available to prebid core reviewers has been changing regularly > for several months in an unavailable location and includes extensive > unreviewed functionality. > > On Tue, Dec 1, 2020 at 1:19 PM bretg ***@***.***> wrote: > > > > Got this background: > > > > The function tryGetCriteoFastBid verifies the authenticity of the content stored on criteo_fast_bid > > Verification is based on a RSA signature; > > First line of criteo_fast_bid contains a hash of the code signed with a secret key; > > The public key is available on the adapter code; > > The function computes the checksum of the code and validates the authenticity based on the public key and the signed hash; > > Finally, the content is loaded via eval and the Publishertag is available. > > > > For that we import a library to handle the RSA in javascript. PAtrick sugested using one of existing hash methods, but they don't actually do asymetric signatures like RSA > > > > My take is that this is just more external code, even though it's build-time. As far as I'm concerned, that just requires another disclosure. > > > > Here's a proposed disclosure that will be placed on the criteoBidAdapter page: > > > > This module loads external code both at run-time and at build-time. The build-time code is an open source RSA security library. The run-time code is not open source but the default version has been inspected by Prebid.org core reviewers. > > > > I'm signing off on this approach -- over to @gglas to figure out how can we get full signoff from the group so Criteo can start building it. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub, or unsubscribe.

[bretg]

the version of the code that is available to prebid core reviewers has been changing regularly

Agreed - this draft disclosure is intended to be what we post when the adapter changes are approved and released.

There hasn't been discussion about putting a disclosure in place for the current situation, but that would be a different block of text.

[patmmccann]

I follow now, thanks for clarifying

…

On Tue, Dec 1, 2020 at 2:00 PM bretg ***@***.***> wrote: the version of the code that is available to prebid core reviewers has been changing regularly Agreed - this draft disclosure is intended to be what we post when the adapter changes are approved and released. There hasn't been discussion about putting a disclosure in place for the current situation, but that would be a different block of text. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5804 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM25Z5QQGYO6KREOCH6ZTLSSU4NRANCNFSM4R7IGZKA> .

[patmmccann]

Here is an example of a build time option, I think this is a great approach

#6016

[allanjun]

hi all, thanks for the comments

• @patmmccann regarding the RSA script, this is at build time and available as NPM package: https://www.npmjs.com/package/criteo-direct-rsa-validate and https://github.com/criteo/criteo-direct-rsa-validate#readme

• We could come up with a solution to remove it at build time if anyone wants, not sure if that would be easily achievable from the download page though. But I'd say that the publishers who are concerned about this are probably already compiling prebid.js by themselves. Would that work ?

• I see other modules using other npm packages, so they should also work on disclosures for consistency

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[patmmccann]

• I see other modules using other npm packages, so they should also work on disclosures for consistency

@allanjun now is a very good time to insist on those disclosures as we transition to 5.0. Could you indicate which ones?

[gglas]

@allanjun @patmmccann can we close this issue out? Seems like it's been handled for the most part

[patmmccann]

I believe so

[gglas]

closing out - adapter pushed in 5.0 with updated infrastructure