Amphtml: amp-consent postPromptUI shown even if no consents apply to user

[src-code]

What's the issue?

When targeting a consent to a group of users via amp-geo, the postPromptUI will be shown to the user even if no consents apply to the user.

The documentation for postPromptUI states:

When defined, the post-prompt UI is shown when all prompt UIs have been hidden, or initially on page load if no prompt UI was triggered.

So judging by this description, current behavior is correct - no prompt UI was triggered, therefore postPromptUI is displayed. But it's odd in practice because amp-geo determined that the prompt didn't apply to the user, therefore why should the user be given the chance to trigger that prompt via postPromptUI, assuming that postPromptUI is going to be used to give the user a chance to revisit their original consent choices?

I'd like to propose that there should be a way to conditionally display the post-prompt UI based on the same amp-geo group used for the promptUI, or that the display of a post-prompt UI should be explicitly tied to the state of the consent (where "doesn't apply" is a valid state along with "accepted", "rejected" and "dismissed") rather than based on a prompt shown/not-shown binary state.

What browsers are affected?

All

Which AMP version is affected?

1526427887786

I believe this has always been part of the design of amp-consent, and is not a regression.

[jpettitt]

Looks a like a bug, I can replicate it on amp-by-example in an incognito window.

A temp workaround would be

:not(.amp-geo-group-myconsentgroup) #post-consent-ui * { display: none; }

However that would mean that users would not be able to change their consent settings when outside the geo that has consent enabled.

The desired behavior would seem to be to only show the post consent UI if the user had previously interacted with amp-consent (accept, reject, dismiss). This would let users alter their consent state no matter where they are now but not bug those who were never in the consent area with consent notices.

[src-code]

The desired behavior would seem to be to only show the post consent UI if the user had previously interacted with amp-consent (accept, reject, dismiss). This would let users alter their consent state no matter where they are now but not bug those who were never in the consent area with consent notices.

I think this is the best approach.

To clarify, technically amp-geo is not really part of this issue, since the issue happens in any scenario where the prompt is never shown to the user (eg promptIfUnknown == false), but I think it's still relevant to mention since GDPR consent is a primary use case for this component right now.

[QES]

looking at this post consent UI is there a way to position the element on the page, I have been looking at the examples and they don't seem to have any obvious way to manipulate this element and it would be nice if the post consent button could be placed on a menu or other element that is not always active.

[jpettitt]

You can position it anywhere. Just reference an element id that is outside the amp-consent block. As long as you have on="tap:myUserConsent.prompt()" it will work.

[zhouyx]

Please don't position it anywhere. It's supposed to be a child of the <amp-consent> block to avoid position change without user interaction.
@jpettitt What you mentioned is probably a bug : ( Let me take a look and fix it instead.

[zhouyx]

@jpettitt I created #15604. Want to make sure this won't break your current usage.

[jpettitt]

It will break some of my sites. There is a design pattern where the show/hide functionality of postPromptUI is useful but we don't want a fixed element. An example would be having the UI as a button in the footer. Short of putting the whole amp-consent element in the footer they is no way to do this if you scope it.

Now if amp-consent exposed consent state as a css class I could use that to control visibility of the button ... :-)

What is the reasoning for scoping is?

[zhouyx]

I think what you described is a valid use case. But it is exactly what I want to avoid here.
Putting the postPromptUI in the footer won't be a big problem. But it can be easily placed anywhere in the doc. And hide/show the button will cause page jump w/o user interaction.

[jpettitt]

The show hide of postConsentUI could case a jump scoped or not depending on where the amp-consent parent is in the doc since it's not a fixed layer.

[zhouyx]

Right, and that's the exact reason why we ask postPromptUI and promptUI to be child of <amp-consent>, because we force <amp-consent> to be position:fixed.

This requirement is documented here: https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md#post-prompt-ui-optional

[jpettitt]

It's certainly possible to have a the consent on="tap:myUserConsent.prompt()" on a regular element not gated by postConsentUI. It gets complicated when there are multiple consents on the page and/or you want to suppress the button outside the consent geo.

For users not in the consent geo it's desirable to have the on="tap:myUserConsent.prompt()" suppressed, you can do this with amp-geo easily enough.

However this presents a problem for users who are from a consent geo or who visited a consent geo but are now outside. They will no longer be able to re-launch the consent dialog to change their consent state. I think this is undesirable from a UX standpoint and makes it hard to meet the requirement that "_The data subject shall have the right to withdraw his or her consent at any time._"

We also need to think had about how to manage there case where there differing consents for multiple geo's. This may well become an issue if the fall ballot initiative in California passes. Each will need to be managed from both inside and, if set, outside the geo in question.

I think we need to have a way to cause an element to be shown if consent has been set (either way) and that it needs not be a forced fixed layer.

[jpettitt]

cc @jasti

[src-code]

@zhouyx I don't think this issue should've been closed - #15604 seems to be about keeping the prompt UI inside amp-consent, but this issue relates to users being shown the post-prompt UI even if they're outside a defined geo group and therefore not subject to consent. The comments took a turn though toward the subject of enforcement of the fixed layer, but the original issue is still valid. cc @jpettitt @jasti

[src-code]

@jasti @jpettitt Can we get this one reopened? The original issue hasn't been addressed.

[jasti]

@src-code Apologies for closing this early. we'll regroup internally and get back to you.

[zhouyx]

@src-code Apologies for closing this one too early, I think I misunderstood you issue before.

You want the postPromptUI to not be displayed if user is not within geo group. While the current implementation, we don't respect the geo group for postPromptUI.
FYI: There's another requirement. To display the postPromptUI even when user is not within the geo group, but have grant/reject consent. This happens if a user has travelled to some consent required area before.

Does the following logic work for you ?

if ( in geoGroup) {
  display postPromptUI
}
if (not in geoGroup) {
  if (has local stored state) {
    display postPromptUI
  } else {
    do not display postPromptUI
  }
}

[src-code]

Does the following logic work for you ?

Looks right, though you could simplify - whether the user is in the geo group or not is irrelevant, as you point out. It's only a matter of whether the user has previously acted on a consent prompt (accepted or declined, not dismissed) that should determine if the postPromptUI should be displayed to that user.

[src-code]

So...

if (has local stored state) {
    display postPromptUI
} else {
  if ( in geoGroup or promptIfUnknown == true) {
    display consent prompt
  } else {
    do not display consent prompt
  }
}

[zhouyx]

@src-code Sounds good. Thank you

[zhouyx]

@src-code The improvement was merged and in canary. You should be able to see the new behavior in dev channel.