✨Callout vendor update: adding gdpr_consent and account to Prebid Server urls

[bretg]

Adds the gdpr_consent and account parameters to Rubicon and AppNexus Prebid Server RTC vendor entries

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[zhouyx]

The macro is CONSENT_STRING.
Please also include the CONSENT_STRING to the macros declaration below. Thanks.
You can refer the usage here for an example.

amphtml/extensions/amp-a4a/0.1/callout-vendors.js

Lines 116 to 128 in 5309266

	criteo: {
	url:
	'https://bidder.criteo.com/amp/rtc?zid=ZONE_ID&nid=NETWORK_ID&psubid=PUBLISHER_SUB_ID&lir=LINE_ITEM_RANGES&w=ATTR(width)&h=ATTR(height)&ow=ATTR(data-override-width)&oh=ATTR(data-override-height)&ms=ATTR(data-multi-size)&slot=ATTR(data-slot)&timeout=TIMEOUT&curl=CANONICAL_URL&href=HREF&cst=CONSENT_STATE&cst_str=CONSENT_STRING',
	macros: [
	'ZONE_ID',
	'NETWORK_ID',
	'PUBLISHER_SUB_ID',
	'LINE_ITEM_RANGES',
	'CONSENT_STATE',
	'CONSENT_STRING',
	],
	disableKeyAppend: true,
	},

[bretg]

Thanks - fixed.

[bretg]

Working on getting Rubicon to sign the CLA.

[bretg]

Tests succeeded on Chrome, Safari, IE, Firefox, failed on Windows 10. Since I just added a parameter to the end of a URL, am suspecting that it's a test environment issue like we experience over on Prebid sometimes. Once I get the CLA issue sorted out, will ask for a re-build.

[zhouyx]

Thanks @bretg Let me know when the CLA is ready. Looks like a flaky test, I've tried rebuild.

[bretg]

@googlebot I signed it!

[bretg]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[bretg]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[bretg]

Ok @zhouyx - CLA's done. Note that I also added 'ACCOUNT' to the URL, so am requesting re-review.
Looking for guidance on how to resolve the ampproject/owners-check and percy/amphtml checks. Thanks.

[zhouyx]

Looks great. PR merged!

[bretg]

thanks @zhouyx

Question about AMP GDPR. The other Prebid interfaces accept an optional GDPR in-scope flag from the CMP. Does the AMP CMP have the ability to pass whether the current user is considered in-scope for GDPR?

https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf

OpenRTB v2.2 - v2.5

An exchange must determine whether or not it believes that GDPR is in effect for a given auction. This
may be via a signal by the publisher who has come to this conclusion, detecting that the user is located in an EU nation, or by some other means. Please consult official GDPR resources or legal counsel for making this determination.

The “Regs” object will signal whether or not the request is subject to GDPR regulations. It will do so via the extension attribute “gdpr” which is an optional integer that indicates: 0 = No, 1 = Yes. Under
OpenRTB conventions for optional attributes, omission indicates Unknown.

                      Regs.ext.gdpr

I don't believe this is the same as AMP's consentStateValue, which is the user's disposition if I understand it correctly. Rather, regs.ext.gdpr is a flag letting downstream parties know that the current request is from the European Economic Area or that the publisher wants it to be treated as such.

[zhouyx]

Thanks for the feedback.

I am assuming that in the case where a consent_string is presented, the CMP indicates that the user is in the EEA. If not, the CMP has the full control of the consent string, is it common use case to include the bit to the head of the consent string?

As you mentioned, consentStateValue is not designed for this use case. Could you please give me an example? If this is a common use case, we are always open to introduce a new variable to indicate GDPR in-scope flag. Thanks.

[adamleslie]

Hi @zhouyx ,

Trust you're well mate.

When is this due for release? - we're helping confirm this is working as expected in PROD.

Cheers,
Adam

[zhouyx]

Hello Adam, Thank you for reaching out.

The change shipped with this release https://github.com/ampproject/amphtml/releases.
Just verified that it's in pre-release canary. You can test it by opt into our dev channel here

Regarding the release date, it is always one week after the change lives in canary.
Thanks