Allow publisher defined consent policy #15724
Conversation
src/custom-element.js
Outdated
| // data-block-on-consent attribute not set | ||
| return null; | ||
| } | ||
| if (policyId == '') { |
There was a problem hiding this comment.
Note: this will be a breaking change for docs with data-block-on-consent=default' now. We did document to not set value to the data-block-on-consentattribute, however I know there're usage ofdata-block-on-consent=defaultout there. Any ideas on what to do? I can easily add an extra check topolicyId == 'default'`
There was a problem hiding this comment.
I'm running to existing usages. Let's see what was the intention of such usage.
Just to clarify, so the distinction is:
data-block-on-consentleaves the consent handling to individual element (extension). Which by default is the same as_if_accepted. Element/extension can override this behavior.data-block-on-consent=defaultis considered as pub explicitly want to have control over consent handling. Which right now is also_if_accepted. Pub can override this by modifying amp-consent config policydefault.
BTW, now I feel the naming _if_accepted is a bit confusing. data-block-on-consent=til_accepted is more accurate.
There was a problem hiding this comment.
renamed to _till_accepted and _till_responded
There was a problem hiding this comment.
To clarify the behavior: publisher always have the final words on consent behavior using data-block-on-consent=_till_accepted/_till_responded/_auto_reject. That will block component at #buildCallback().
On top of that, individual extension can customize their behaviors like what they does today.
data-block-on-consent and data-block-on-consent='default' are exactly the same thing. data-block-on-consent and data-block-onconsent='_till_accepted are the same thing if the publisher doesn't customize the default consent blocking behavior, and the component doesn't have its blocking behavior customized.
I'll add all these to documentation once the feature is out.
| * Get the consent policy to follow. | ||
| * @return {?string} | ||
| */ | ||
| getConsentPolicy_() { |
There was a problem hiding this comment.
A comment here is that no element will be able to say I don't want to be blocked by amp-consent now. Even <amp-consent> it self can be blocked by data-block-on-consent : ( Which eventually lead to a deadlock.
We can either ignore the case, I don't believe anyone will put the data-block-on-consent attribute on the <amp-consent> component.
Or we can introduce another #shouldBeBlockedByConsent method. Any ideas?
There was a problem hiding this comment.
can you just use AmpConsent.getConsentPolicy() to force it to never block? (do we need a an _never policy preset?)
There was a problem hiding this comment.
On second thought I think this is fine.
What we want to provide here is to allow publisher to make the final decision on consent blocking behaviors. I think it is the publisher's responsibility to use the feature correctly, and not introduce deadlock.
@jpettitt isn't _never preset equals to not adding data-block-on-consent. I'm open to more presets, but I'll add them upon requests.
zhouyx
force-pushed
the
respect-predefined
branch
from
801e6cf
to
5b1d7f5
Compare
zhouyx
force-pushed
the
respect-predefined
branch
from
5b1d7f5
to
bf8195b
Compare
zhouyx
force-pushed
the
respect-predefined
branch
from
bf8195b
to
bc7a6d3
Compare
For #15290
#15325 introduced a list of predefined consent policy. They are
data-block-on-consent=_if_responded,data-block-on-consent=_if_acceptedanddata-block-on-consent=_auto_reject. With those predefined consent policy, publisher can easily customize the consent blocking behavior of a given AMP component.Individual AMP component can also overwrite the
#getConsentPolicy()method to customize its own consent blocking behaviors. This PR allows publisher to customize blocking behaviors on top of that. So the order will bepublisher defined consent blocking behavior > AMP element defined consent blocking behaviors.