✨ amp-consent: Gdpr applies value #27759
Conversation
src/consent.js
Outdated
| * @param {string} policyId | ||
| * @return {!Promise<boolean>} | ||
| */ | ||
| export function getGdprAppliesInfo(element, policyId) { |
There was a problem hiding this comment.
Is the plan to migrate to getConsentPolicyInfo and deprecate the method here?
There was a problem hiding this comment.
See comments below
There was a problem hiding this comment.
// Return the stored gdpr applies value. doesn't tell what the future plan is.
There was a problem hiding this comment.
Oops I was unclear, the plan as discussed offline, is to consolidate the methods in src/consent to return a single consent info object, but for now we will keep this method to unblock the ads teams.
| consentStateValue, | ||
| responseConsentString | ||
| responseConsentString, | ||
| responseGdprApplies |
There was a problem hiding this comment.
updating gdprApplies here won't work because it requires consentStateValue to be not null.
A typical workflow is as following
- consentHref returns
gdprApplies, but noconsentStateValue. - Then the
consentStateValueis calculated on the client side.
I'd recommend we handle the gdprApplies separate from consentState and consentString. Like what we do with the dirtyBit.
Let me know if you have better ideas.
There was a problem hiding this comment.
Ok, thanks for addressing this. It was either treat it like consentString/consentStateValue or treat it like dirtyBit. I'm good to treat it like dirtyBit.
Edit: Discussed offline, will approach gdprApplies values similar to sharedData: it will only be stored in the Consent Instance and not local storage. As a future optimization, once the value starts to get used more by vendors, we will cache the gdprApplies value in local storage and use that value instead of having to wait for another round trip.
78b443f to
5a4c3d8
Compare
5a4c3d8 to
b2e9fd4
Compare
| it('uses given value', async () => { | ||
| const inlineConfig = { | ||
| 'consentInstanceId': 'abc', | ||
| 'consentRequired': 'remote', |
There was a problem hiding this comment.
Please also add a test to test the local consentRequired: false or consentRequired: true as well.
There was a problem hiding this comment.
Actually it will also work if you decide to limit the gdprApplies with checkConsentHref. But in that case, maybe we should not expose the getGdprAppliesInfo API. That it should only be retrieved with consent string.
There was a problem hiding this comment.
Actually it will also work if you decide to limit the gdprApplies with checkConsentHref.
Yes this is currently the case. In the spec, we said that it would default to consentRequired and I interpreted that to mean that we check checkConsentHref first then use consentRequired if it's not given.
That it should only be retrieved with consent string
So are you saying that we should remove getGdprAppliesInfo and getConsentPolicyInfo from src/consent and create a general API (ie: getTcfV2Info())?
There was a problem hiding this comment.
Ha the consentRequired defined in different places is confusing. What about the consentRequired in inline config?
There was a problem hiding this comment.
Discussed offline: will save consolidation of these APIs for later work (by June), so that we can unblock ads teams that are needing the gdprApplies data.
8ba1a0d to
026f1b6
Compare
|
@zhouyx Ready for review |
src/consent.js
Outdated
| * @param {string} policyId | ||
| * @return {!Promise<boolean>} | ||
| */ | ||
| export function getGdprAppliesInfo(element, policyId) { |
There was a problem hiding this comment.
// Return the stored gdpr applies value. doesn't tell what the future plan is.
|
@zhouyx PTAL |
| it('defaults correctly when checkConsentHref is not defined', async () => { | ||
| const inlineConfig = { | ||
| 'consentInstanceId': 'abc', | ||
| 'consentRequired': false, |
There was a problem hiding this comment.
Does the inline consentRequired value affect the gdprApplies value?
My understanding is it won't, if so do you think we should set the value true instead to make more obvious that gdprApplies value is not related to the inline consentRequired value.
(Sign.... two fields with the same name is soooo confusing)
There was a problem hiding this comment.
We use the inline consentRequired value when gdprApplies or checkConsentHref is not supplied. And since consentRequired will always be a valid value after consent-config.js merges it, it's a good fallback.
I've change the test name and values to reflect this.
There was a problem hiding this comment.
Updated PR description to reflect or decision (never fallback to local consentRequired)
Added @zhouyx Ready for review :D |
58fab1b to
7349144
Compare
1c03af8 to
a68fac0
Compare
a68fac0 to
3d78a81
Compare
Just a note, macro support is not in this PR, but can be future work if anyone requires it :) |
* Sync w/ cache from amp-consent * Tests * no caching for now * suggested changes * Never use local consentRequired
Adding support for TCF v2
gdprAppliesvalue.gdprAppliesto betrue,falseornull(whencheckConsentHrefis not defined)Stored asg:(0|1|undefined)in local storagegdprAppliesis not sent throughcheckConsentHref, it will default to remoteconsentRequiredvalues (never default to localconsentRequired).Future work: cache
gdprAppliesvalue, add macro support forgdprApplies, consolidastesrc/consent.jsmethods (gdprApplies,consentString, andconsentType, to be sent together, updated together, and retrieved together)Closes #27190