Amphtml: [Master feature] Enable user choice using <amp-consent> component

[zhouyx]

Overview

A new <amp-consent> component that enables publisher to get consents from readers and manage their consents.

Format

<amp-consent>
   <script type='application/json'>{
     “consents”: {
        “consentInstanceABC”: {
           “checkConsentHref”: “endpointABC.com”,
           “promptUI”: “template1”
         },
        “consentInstanceDEF”: {
           “checkConsentHref”: “endpointDEF.com”,
           “promptUI”: “template2”
         }
      },
     “policy”: {
         “policyABC”: {
             “waitFor”: {
                “consentInstanceABC”: [],
              }
           }
     }
   }</script>
   <div id=”template1”>
     Collect consent for instance ABC
     <button on="tap:consentInstanceABC.dismiss">Dismiss</button>
     <button on="tap:consentInstanceABC.accept">Accept</button>
     <button on="tap:consentInstanceABC.decline">Decline</button>
   </div>
   <div id=”template2”>
     Can we use your cookie?
     <button on="tap:consentInstanceDEF.accept">Accept</button>
   </div>
 </amp-consent>

Consent instance

config

Each unique consent instance keeps a list of endpoints to get and update consent states. Initially, the configuration is simple:

• checkConsentHref: An endpoint to use to check the consent status
• promptUI: An ID corresponding to the UI container to display that's meant to collect this consent.

In the future, configuration options may be expanded for more functionality:

{
  checkConsentHref: (required)
  promptUI: (required)
  disableLocalStorage: (optional) true/false. Default to false - controls whether state does not get kept in local storage (see below)
  acceptHref: (optional) - an endpoint that is requested when the consent is accepted
  rejectHref: (optional) - an endpoint that is requested when the consent is rejected
  dismissHref: (optional) -  - an endpoint that is requested when the consent is dimissed
}

checkConsentHref

Request

Make a POST request:

{
  consentInstanceId // string for the consent ID being asked about
}

In the future, this may be expanded to include:

{
  consentInstanceId // string for the consent ID being asked about
  ampUserId // For server to identify the user
  timestamp // value stored on client side, can be empty
}

Response

Expect a response with an boolean value:

{
  'promptIfUnknown': boolean (true/false)
}

Consent Policy

A default consent policy will be auto generated to wait for every consent instance. One can overwrite the default consent policy by declaring a new consent policy instance with id "default". Or add other consent policy instances to the <amp-consent> config.

Consent Policy Instance Config

Each unique consent policy instance creates a consent blocking behavior unit that instruct other components on the page. It keeps a list of consent instances to wait for. Initially, the configuration is simple:

• waitFor: A JSON object that declare the list of consents to wait.

'waitFor': {
  'ABC': [] // Only empty array accept now.  
}

In the future, configuration options may be expanded for more functionality:

{
  'waitFor': {
    'consentId': [] // Array of items that's associated with that consent instance
  }
  'timeout': timeout in case user never respond
}

Storage

All consent instance state will be stored and handled client side.
For each consent instance. LocalStorage looks like

• Key: amp-consent:${consentInstanceId}
• Value: true/false (won’t store anything for unknown state)

Blocking Components

Use data-block-on-consent=consent-policy-id to block AMP components with consents. If no consent-policy-id is specified, "default" consent policy instance will be used.

Individual AMP component can override default blocking behaviors and implement blocking logic itself.

UI

UI Restrictions

Prompt UI

• Only a single UI can be shown at a time.
• Position fixed and stick to the bottom of the page

Revocation button

• Will only be displayed after consent state is determined
• Can overlap when there are multiple consent instances.

Text

• All text will be static inlined. No template replacing will be supported

Revocation Button Design

Coming soon, we will support the ability to specify a UI container that will be displayed once the prompt has been handled. This can be used optionally to enable a persistent UI affordance to be displayed that allows the end user to revoke their previous choice and pick a new choice.

[rudygalfi]

Some feedback:

We should avoid the term revocation to talk about the full list management flow. Maybe some terminology like "consent prompt" vs. "consent management" would sufficiently differentiate them.

In the "config" section, could you clarify the two options that are presented? It looks like the 2nd one just uses more fields.

Could you add a section talking about data persistence (viewer case and origin case)?

CONSENT_RESTRICT_STATES.CONSENT_NEEDED: It seems like it's valid for this value to be returned even if a list of items is returned, none of which requires consent. Basically, my reading of the items is:

• NO_CONSENT_RESTRICT: Consent is being asked for by this page, but it should be ignored (could be used to convey decisions relating to geo)
  
  
  
  • CONSENT_NOT_NEEDED: How is this case differentiated from the previous one? Are we asking the caller to summarize the outcome of the response or is this acting like an override (in which case it seems to be like NO_CONSENT_RESTRICT.
  
  
• CONSENT_NEEDED: Related to the above, is this saying to definitely prompt, or is it just saying that we should let the rest of the consent logic decide what to do on the page. Maybe we need some sort of prompt/no-prompt decision in this enum.

fullConsentStateList: Is id meant to be something the publisher comes up with, or is it specifically meant to say "id"?

CONSENT_STATE.DISMISS: How do you imagine this is needed? I could see AMP sending it to the pub, but I can't imagine when it's useful for the pub to tell this to AMP.

CONSENT_INSTANCE_STATUS: Can we provide more granular information about consent status to a component? Specific items/vendors?

Component management: We should include affordances for timeouts and define the defaults for consent blocking. For example, if the page has an amp-consent component but it's silent on which elements it applies to, we should conservatively block the element from loading.

[jpettitt]

Where variable replacement is overridden in the case of no consent, for example client id, it would be useful for the publisher to be able to specify a default value rather than just returning blank.

[ghost]

Hi,

Can I ask what would be the difference with this and using the <amp-user-notification> and displaying a banner at the bottom of the screen asking people to accept cookies or not see a screenshot of one I have running on a production website:

~I blanked out the website, due to the owner not wanting to show the website. But you can see the Cookie Consent banner at the bottom.

[rudygalfi]

@ayumihamsaki One key difference is that you can collect a user response of yes or no. amp-user-notification only supports being dismissed (and storing that so that the notification doesn't re-appear).

[itspauli]

@ayumihamsaki there are a number of subtle differences which are designed to comply with the detail in the GDPR. Amongst other things;

consent: the user should be given ability to optin or out, a solo accept button is equivalent to a pre-ticked box (which is non-compliant),

storage: You are required to keep an up-to-date record of users preference status and be able to demonstrate that record upon request (local storage in this instance), and

optout: The user should be able to change their mind with as much ease as they opted in, preferably using the same mechanism (DP by design).

There is a bunch more reasons. It's worth noting that cookies are one of the most ambiguous topics of the GDPR, mentioned one (I recall) but included in the scope without much direction on how to comply. It is the EU's view that much of the data collected using cookies can be used alone or in combination to pinpoint a specific users (IP, GA snippet, Zip or postcode) so it is well within scope.

P.S. Good solution @zhouyx this will help a bunch of people

[src-code]

@rudygalfi Assuming this is intended primarily for GDPR, will Google Search and other consumers of cached AMP pages actually execute this consent flow when displaying a publisher's AMP page, or will Google obtain its own consent from EU users which will cover the display of cached AMP pages, much like what's needed for 3rd party display ads, etc? In other words, is this component intended only for publishers who serve AMP as their primary experience from the own domain, or is it also intended for cached pages served by 3rd parties like Google Search? (Eg, will Google Search require the user to click through the publisher's AMP consent flow for every publisher displayed in the Google Search carousel?)

[rudygalfi]

@src-code: Whilst individual companies' interpretations of applicable law may vary, it's clear that each entity that processes personal data of European users must have a valid legal basis - such as end user consent - to do so. For Google AMP cache pages, the entities processing personal data would include Google, the publisher and any vendors the publisher works with. That's why the AMP Project is building tools to enable those entities to seek consent, if they require it for their own compliance. Put simply: because the publisher chooses the behaviors and vendor integrations in the page, the publisher is primarily responsible for managing the compliance obligations that stem from those choices.

[src-code]

@zhouyx Will it be default to pass credentials in the CORS requests (eg for acceptHref?) Or at least be configurable? I assume it'll be possible but not documented yet...

[rudygalfi]

Moving discussion from https://github.com/ampproject/amphtml/pull/14557#issuecomment-380626787 to here for more visibility (@zhouyx @src-code) regarding support for multiple consent instances.
@src-code:

@zhouyx We have a requirement to show and beacon multiple steps of consent, eg a separate step for IAB consent.

@src-code, can you provide more details on the use case and user experience? As @zhouyx said, we're going with single consent support for now, but that's mainly because we'd like to collect feedback on multi-consent related experiences?

I assume by supporting, say, 2 consent states, you want two pieces of data set that can both be either "accepted" or "rejected". Then, the question is what kind of experience you want to design for gathering those. Would it be one gathered after the other serially? Do you want both toggleable kind of like checkboxes in a form?

[sjmeff]

Is there a way to detect location on AMP pages? In the case of GDPR, we would only want to show the AMP consent messages to readers who are in the EU.

[zhouyx]

@sjmeff FYI: There is <amp-geo> extension that is currently under development.
Currently <amp-consent> allows you to configure the server response with the promptIfUnknown value, that tells AMP to not ask for consent if unknown.

[jpettitt]

@sjmeff amp-geo is in the current dev-channel build. The server side is not yet deployed but you can test it with #amp-geo=XX to force the country code. It should be fully functional early next week, just waiting on a final code review sign off.

[Tonsil]

You have an error in your example. In here:

<div id="template2">
     Can we use your cookie?
     <button on="tap:consentInstanceDEF.accept">Dismiss</button>
</div>

Either the button should have the text "Accept" or the action should be dismiss. Also, I noticed that fancy quotes have crept in; you might want to remove those.

[jweigt]

It would be beneficial for a number of reasons to make this compatible with the IAB Transparency & Consent Framework, as this is with high likelyhood the standard that most publishers will base their consent solutions on: http://advertisingconsent.eu/

[jasti]

@jweigt it is in our plans to be compatible with the IAB proposed solution but can you tell us what you see to be not compatible at this point?

[jasti]

We wanted to update this thread with some features we plan to implement in the future. Please note that we haven't committed to implement all the features and the final set will be based on the feedback we receive after amp-consent has been launched.

'checkConsentHref' related

• Enhance ‘checkConsentHref’ to respond with additional key value pairs, including support for variable substitution that can be sent to components that are blocked on consent
• Use amp-geo to selectively trigger consent if the user is from a certain country
• Use amp-geo to configure different consent UIs for users from different countries

Others

• Get consent markup in real-time instead of hardcoding it in the document
• Support making consent buttons active only upon reading the entire consent by the user (e.g. needing to scroll all the way to the bottom indicating that the user has read the content)
• Support for multiple amp-consents to work sequentially
• Get amp-consent to work sequentially with amp-user-notification
• [updated after comment below]Support per vendor consent. i.e. User should be able to accept consent on a per vendor basis.

Please add any other features that we've missed to consider or upvote any of the features with a comment.

[cramforce]

Question: For "multi-consent", are there plans to allow consent to be modeled as a set of checkboxes that get submitted with a single button like

<amp-consent id="consent">
  <input type=checkbox name=google value=google>
  <input type=checkbox name=facebook value=facebook>
  <button on="tap:consent.accept">Accept</button>
</amp-consent>

Or something like that?

[jasti]

@cramforce, yes. It's actually one big difference between the way amp-consent works versus the IAB proposal - getting consent on a per vendor basis.
This would also mean that each vendor integrated in AMP will need to have a unique ID recognized by ad networks because not only does the AMP page need to block requests, so does the ad auctions as well.
I've updated the comment with future enhancements with this FR.

[QES]

I'm still trying to understand what will be required of publishers for GDPR compliance with regard to advertising seems to provide some tools that will be useful but until there is clarity of what http://advertisingconsent.eu/ means in reality its hard to know.

However, it is important that not consenting is not the same as avoiding advertising. Looking at some of the examples and ideas shown in seems to show that this can be used to show / not show parts of the page.

In the case of advertising that consent / non consent needs to be passed into the advertising system so that the advertising network (tool) can decide what to serve the user even if they can't use cookies.

Page 16/17 of http://advertisingconsent.eu/wp-content/uploads/2018/03/Transparency-Consent-Framework-Presentation-Website.pdf give some examples of what a pop up might look like and in the case of mobile devices this is a more complex version of the current (accept cookies banner that many have).

The key is can the amp-consent tool be sophisticated enough to ask the intial question and if a person wants granularity punt them to a part of the site to complete the process.

I don't know the answer but with a month until GDPR goes live there are many more questions than answers for these questions.

[jasti]

@QES, some thoughts below.

• Purpose based consent on a per vendor basis isn't supported right now but we plan to in the future.
• Once we have purpose based consent, AMP will make the status available so each ad network implementation can read vendor consent status and purpose to process appropriately.
• Reg UI from 16/17. Please see https://ampbyexample.com/user_consent/advanced_user_consent_flow/ and let us know if you aren't able to configure the UI as you'd like
• Reg punting user to another site - yes, that's possible by configuring a link in the initial consent string but it isn't recommended since there is no easy way for the user to get back to the originating page.

Let us know if you have other thoughts/ comments.

[christian-felix]

I got some question regarding the storage of user consent:
All consent instance state will be stored and handled client side, that's ok so far, but how i am supposed to fetch it and trigger some action depending on the value (true/false)
For example disable the Opt-In button when already user has given his consent.

[jasti]

@christian-felix if consent is already obtained from the user, amp-consent will not show again. You as a publisher can configure the "post prompt UI" to help users manage their consent choices.
Details: https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md#post-prompt-ui-optional

[christian-felix]

Thank you @jasti for your response. That is exactly the solution which I had missed.
I have falsely assumed that one single div is designed to Opt-In and Opt-Out.... now I have two separate div container, where i do handle the Opt-In and Opt-Out settings.

Unfortunatelly, the post-prompt-ui does not work as expected.

1. After the User gives his consent, the div immidiately switch to the post-prompt-ui forcing user to opt-out.

2. When some button gets clicked (dismiss, opt-out) this error shows up:

Uncaught TypeError: Action execution failed: AMP-CONSENT accept: Cannot read property 'fire' of undefined _reported_ at T.push.f.T.updateConsentInstanceState

I have overlooked surely some important part and I stronly suppose, that the second issue is strongly related to the first one.
Could you please provide me some help?

[jasti]

@sebastianbenz do we have an ABE for the post prompt UI by any chance?

[sebastianbenz]

That’s already built into both samples.
Vamsee Jasti [e-mail] schrieb am Mo. 30. Apr. 2018 um
15:16:

@sebastianbenz https://github.com/sebastianbenz do we have an ABE for
the post prompt UI by any chance?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/13716#issuecomment-385394773,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXOONqvDJNItzo3oKSbXdzyCN3J7EMhks5ttw6bgaJpZM4SXHjH
.

[christian-felix]

Somehow i don't grasp the concept behind the scences, so according to the sample the post-prompt-ui serves only to display the parent element again.
I thought i can configure the "post prompt UI" somehow and apply only opt-out related elements there.
Then question remains the same: How do i may dismiss the opt-in button when user consent has been already obtained?

[clumsyjedi]

The UI framework for capturing and persisting consent seems suitable for my own purposes (GDPR compliance) but echoing some of the earlier commenters, I don't see how the users consent status can be used effectively...

For example for amp-ad components I don't want to block these from rendering outright, but would prefer the ad to receive the users consent status, so that we can serve a house ad to users who opt-out.

The docs state that

Individual components may override this behavior to provide more specialized handling. Please refer to each component's documentation for details.

I don't see any relevant consent attributes or flags in the docs of amp-ad/amp-embed - is this part of the work described by @jasti in the comment:

Once we have purpose based consent, AMP will make the status available so each ad network implementation can read vendor consent status and purpose to process appropriately.

Many thanks to the AMP team for all the work so far. I'll watch this space :)

[christian-felix]

Are there any chance that the amp-list component will work inside the amp-consent as propsed by this example:

https://ampbyexample.com/user_consent/basic_user_consent_flow/

For some reasons the content delivered by the endpoint

https://ampbyexample.com/json/consent-items.json

and stated by the text:

_This is some more information about this choice. Here's a list of items related to this choice._

want not show up.

Tested on diffrent browsers and diffrent workstations, sometimes the items appears but mostly this area is empty.

I just wanted to adapt this feature for our purposes but have to make some workaround (triggering another action) in order the get this list displayed .

[zhouyx]

Hi amp-list can worked inside the amp-consent component, as a promptUI or postPromptUI. The ampbyexample page you referred to did show the content of amp-list? Is there anything I am missing? Or could you give me more details to reproduce? Thanks.

[jasti]

@clumsyjedi

For example for amp-ad components I don't want to block these from rendering outright, but would prefer the ad to receive the users consent status, so that we can serve a house ad to users who opt-out.

That exact use case is supported! amp-consent itself don't block the ad request, it just makes the state available to the ad network to do whatever is appropriate. For e.g. when a user rejects consent, the state CONSENT_POLICY_STATE.INSUFFICIENT is made available to the ad network and they could choose non-personalized ads at that point.
For e.g. I know DoubleClick is in process of consuming the flag in this way.

Individual components may override this behavior to provide more specialized handling. Please refer to each component's documentation for details.

s/components/amp-ad vendor (e.g. doubleclick)

[sebastianbenz]

@zhouyx I can reproduce @christian-felix observation.

Steps to reproduce:

1. Visit https://ampbyexample.com/user_consent/basic_user_consent_flow/
2. Clear local storage in dev tools
3. Reload the page -> amp-list content shows
4. Reload the page -> amp-list content does not show

[dbemiller]

@zhouyx Small correction to a code block in the initial post?

acceptHref: (optional) - an endpoint that is requested when the consent is accepted
rejectHref: (optional) - an endpoint that is requested when the consent is accepted
dismissHref: (optional) - - an endpoint that is requested when the consent is accepted

Looks like it should be:

acceptHref: (optional) - an endpoint that is requested when the consent is accepted
rejectHref: (optional) - an endpoint that is requested when the consent is rejected
dismissHref: (optional) - - an endpoint that is requested when the consent is dismissed

[armydee]

I've implemented this and not sure if the following have been added, I couldn't see it on the consent examples:

acceptHref: (optional) - an endpoint that is requested when the consent is accepted
rejectHref: (optional) - an endpoint that is requested when the consent is rejected
dismissHref: (optional) - - an endpoint that is requested when the consent is dismissed

Just to add context - I ask because I want to create a cookie on the server if the user accepts. I'm using this cookie to check if the consent should be shown on the main non amp site.

[jasti]

@zhouyx @sebastianbenz about ^, can publishers read the state from local storage to understand user consent status?

[zhouyx]

@armydee As documented acceptHref rejectHref and dismissHref is a feature we are planning to implement. It's not supported now.

[jpettitt]

What is supposed to happen with ad vendors that don't bother to check consent state?

Right now it looks like they just run even if consent state is set to reject. (tested with a9 and taboola). This seems wrong. My thought is if an amp-ad element is data-block-on-consent it should stay blocked on reject if the ad tech vendor hasn't affirmatively indicated their code will honor consent State.

[armydee]

@zhouyx That is disappointing :(

Are there workarounds to this? Is it therefore possible to use a "normal" button to make an AJAX call to do something on the server? Or get the state from local storage as @jasti has pointed out? That would also be useful to know.

[clumsyjedi]

The amp-ad case works well. One integration that isn't working for me is amp-iframe. I see that there is some discussion of passing consent status to iframes as part of #14877 - is this expected to be ready for the GDPR May 25th deadline?

[christian-felix]

@jasti , sorry for the inconvenience, but how do we should handle the CONSENT_POLICY_STATE.INSUFFICIENT parameter in the intended way?
Is this something which we should ad to the json script ? I'm not able to see it within the developer tool as to be passed to the particular vendor.
What i am supposed to do in order to get it working? Do i have to conntact each vendor and ask them if they support it or not?

[zhouyx]

@armydee We've created #15238 and will implement in soon.

[zhouyx]

@clumsyjedi That's a good point for amp-iframe. For amp-ad, we will ask each ad vendor to specify whether they will handle consent state themselves. But for amp-iframe, it will require the publisher to instruct AMP whether the iframe will handle consent blocking or not. We can expose an attribute for that.

@christian-felix I assume you are asking from a publisher's perspective? In that case you don't need to contact each vendor. Ad vendor need to opt in to support customizing behaviors based on consent state. Simply putting data-on-consent-block will block amp-ad if user reject w/o ad vendor opt-in, or have ad vendor handle consent status if they opt-in.

[jpettitt]

@armydee you could use an amp-pixel and data-block-on-consent to give the similar behavior to acceptHref (the pixel would only fire if consent is accepted). Although you may not be able to set a cookie when the page is loaded from an amp-cache due to browser 3p cookie restrictions.

[zhouyx]

That only works for acceptHref, not rejectHref.

[jpettitt]

@clumsyjedi @zhouyx for amp-iframe the default could be to block if data-block-on-consent is present. Only allowing it to run, passing in the consent state, if consent has resolved and data-consent-aware-iframe (of something similar) is set.

[clumsyjedi]

@clumsyjedi That's a good point for amp-iframe. For amp-ad, we will ask each ad vendor to specify whether they will handle consent state themselves. But for amp-iframe, it will require the publisher to instruct AMP whether the iframe will handle consent blocking or not. We can expose an attribute for that.

@clumsyjedi @zhouyx for amp-iframe the default could be to block if data-block-on-consent is present. Only allowing it to run, passing in the consent state, if consent has resolved and data-consent-aware-iframe (of something similar) is set.

@jpettitt @zhouyx My use case is that we have call backs to our own site for rich content in iframes. We want to render the iframe content regardless of consent state.

For the consent states UNKNOWN, REJECTED and DISMISSED we would render the content without any tracking.

For the states NOT_REQUIRED and GRANTED we would render the content with tracking scripts in it.

So to me it's important that the iframe have access to the consent state to make that determination. Our iframes are embedded using the src attribute of AMP iframe. I would like to see something like a consent-status-parameter attribute on the amp-iframe element, which would contain REJECTED|GRANTED|etc. So consent-status-parameter=gamp-consent-status would append gamp-consent-status=GRANTED to the query string in the src parameter.

I assume other publishers who embed using srcdoc would also need the consent state communicated to the iframe document. I don't know what mechanism could be used... can a CONSENT_STATUS var be injected into the iframed document?

[zhouyx]

@clumsyjedi Thanks for explaining this. It sounds like a very solid use case to me. We've filed #15290 to track the issue.

[christian-felix]

@jasti , are there some propositions in progress as how to get/read the current user consent state?

For example, we would like to disable the opt-in button or show some additionaly info when user already has given his consent, furthermore, when mutliple user consent will be available, we want to display an list with all the vendors and the corresponding consent state.

[jgsojo]

@rudygalfi, regarding support for multiple consent instances we have the next use case:
Every page of our web has ads as well as tracking for different user actions, with the incoming law, each user should be able to manage whether they want to consent each of the functionalities.

For example, one user could accept get his navigation data stored to improve the site's knowledge about his users (analytics tracking) but not accept it for get personalized ads. In that case, we need different consents in order to enable some things and disable others.

And regarding your question about how to gather the consent states, I think that making them toggleable with checkboxes would be great.

[ArnoldLovasHeute]

hi, i have same problem. the deadline would be on 25th of may, but actually i cant see the way, to use more instances. i would ask the user about the tracking codes and the personalized ads.

is not possible actually?

it would be also important a "global" accept button, i mean, if the user press it, it would accept all instances. the basic strategy, we want to show the detailed setup about the cookies if the user press a cookie setup button, but basically the user will see just the global cookie button.

[christian-felix]

@ArnoldLovasHeute, multiuser consent is not possible yet. Actually you have only the option to opt-out or opt-in globaly, whenever you use the "block-data-on-user-consent" attribute.
Individual consent settings would be available soon as stated previously by the developers.

[jasti]

@ArnoldLovasHeute @jgsojo As @christian-felix says, "purpose-based consent" isn't available at the moment and AMP only allows accepting consent at a global state. Purpose based consent won't be available before May 25th and if you strictly need it by your interpretation of the law, a workaround might be to send the user to an external consent acceptance flow using a simple outlinks. A better version for supporting external consent flows will be available shortly but not before May 25th. (this is obviously not legal advise.)

are there some propositions in progress as how to get/read the current user consent state?

@christian-felix, I'll let @zhouyx answer.

[zhouyx]

are there some propositions in progress as how to get/read the current user consent state?
For example, we would like to disable the opt-in button or show some additionaly info when user already has given his consent, furthermore, when mutliple user consent will be available, we want to display an list with all the vendors and the corresponding consent state.

@christian-felix Individual extension is able to get current user consent state right now.
For analytics tool to collect consent state, we've filed #14916
For making consent state available to consent UI, we've file #15394

If I understand your requirement correctly (let's ignore multiple user consent for now). You want to make the consent state available and be able to customize the content (not any AMP component). One way way would to use css to hide/show content based on consent state, however that involves content position change without user interaction and I'm not convinced about that. Another way would be combine amp-consent and amp-access together and fetch content based on the consent state, would that be possible? Or if it is only a very small portion of the page, maybe <amp-iframe> can also be a workaround.

I've filed #15561 to track this individually. Thank you!

[jasti]

Hi everyone, just some housekeeping. This issue has become long with a lot of FRs, bugs and implementation advice. Now that amp-consent has been in production for a few weeks, we are moving on to phase 2. You can see the new issue at #15651 and follow along the 'In Progress' label in the dedicated 'consent tools' project to know which items are being actively worked on.
Closing this issue but please keep your feedback coming in #15651.

[wustzdd]

@zhouyx Thank you for your sharing. But I have a question. In order not to collect any data, the Facebook pixel needs to be revoked before receiving the consent. Once accepted by customer, the Facebook pixel needs to be granted, How can I deal with it in the amp project? You can see the Facebook document:https://developers.facebook.com/docs/facebook-pixel/events-advanced-use-cases/v3.0

[rudygalfi]

@jeffjose @zhouyx: In order to address @wustzdd's question, could we introduce some delay logic on amp-pixel so it will wait until consent is resolved? cc @jasti

[jasti]

@wustzdd amp-pixel already supports the data-block-on-consent attribute which allows amp-pixel pings to be held back until consent is received from the user as described here: https://github.com/ampproject/amphtml/issues/13716#issuecomment-388915569
Please let us know if that doesn't work for your use case.

[wustzdd]

@jasti Thank you for your reply, AMP supports or component to use this attribute, but in my case above, I haven't found a component to support facebook pixel. Can you give me some suggestion about my case? Thank you very much.

[wustzdd]

@jasti Thank you for your reply, AMP supports amp-ad or amp-analytics component to use this attribute, but in my case above, I haven't found a component to support facebook pixel. Can you give me some suggestion about my case? Thank you very much.

[jasti]

@wustzdd You could probably use the <noscript> version of FB's pixel tag in <amp-pixel> but the best thing to do is approach Facebook to add an integration directly in AMP.

[ayumi-cloud]

@zhouyx @jasti @aghassemi @cramforce

Quick Question: Should <amp-consent> use some kind of Cross-Site Request Forgery (CSRF) protection as it's sending a POST request, when a user clicks on one of the options?