I2I: Support CMP Integration with <amp-consent>

[zhouyx]

To #15653

Overview

The following sections will try to answer these questions:

• What to include in the prompt dialog and how to allow CMP to customize it?
• What is the blocking behavior with CMP?
• What the data flow looks like between different parties?
• What the CMP needs to do to integrate with AMP?
• What does a publisher need to do to include a CMP solution on their AMP page?

Background

<amp-consent> provides a solution for publishers to collect user consent and block or unblock any AMP component in an AMP page. Currently, this solution only allows the publisher to collect a boolean consent for all vendors in the consent UI.

To support per purpose and per vendor based consents and allow for third party integration from Consent Management Platforms (CMP) with publisher AMP pages, AMP will enhance <amp-consent>. It will allow for richer interaction between the publisher page, vendors, CMP and ad extensions on AMP pages that need to know about the consent status. AMP must make such an API for CMPs because AMP doesn’t allow custom JavaScript to run on the page and therefore a CMP must integrate with the AMP framework to integrate with a publishers page.

Data Flow Desing

The following section explains each step in terms of data structure and API.

Read data from localStorage (Step 1)

Data includes the stored consent string and CMP stored information.

Pass information to CMP endpoint (Step 2)

The following data with be passed through a POST request

   {
     'consentInstanceId': string,
     'consentStr': string,
     'pubConfig': object,
     'cmpStoredData': string,
   }

CMP endpoint response (Step 3)

Endpoint returns a JSON object

   {
     'promptIfUnknown': boolean,
     'sharedData': object,
     'forcePrompt': boolean, //optional
   }

Initiate the UI iframe (Step 4)

Data will be stringified and passed via the iframe name attribute

   JSON.stringify({
     'publicConfig': object,
     'cmpStoredData': string,
     'consentStr': string,
   })

Iframe returns user decision (Step 5)

UI iframe will pass the consent information back to <amp-consent> via postMessage

window.parent.postMessage({
 type: 'consent-response',
 cmpStoredData: '',
 consentStr: '',
 action: 'accept/reject/dismiss'
}, '*');

consentStr is required to pass the value to vendors.

action is optional. When specified, it instructs components that don’t understand consent string to load or not based on the publisher’s configurations.

cmpStoredData value will be stored per the CMP request

Store consent information (Step 6)

Store the consentStr and the cmpStoredData to localStorage

Pass consent information (Step 7)

AMP components on the AMP page (vendors in the format <amp-ad type=${vendorName})> can access consent information with function call

getConsentPolicySharedData(ampdoc, policyId)

Where the function returns an object that merge the value of consentStr and sharedData

   {
     'consentStr': string,
     'sharedData': object
   }

Blocking Behaviors

Default Blocking Behaviors

When a CMP is present on the page, AMP runtime behavior will default to:

• Block all <amp-ad> components on the page from rendering
• Send request to the CMP endpoint to ask whether consent is required
  • If no -> Stop here
• Check if there’s a response stored in the AMP runtime, or the CMP endpoint returned with a response
  • If yes -> Unblock <amp-ad> and pass the response to them
  • If no -> Prompt the consent collect dialog in a foreign iframe
• Get the response from the prompted iframe Store the response as instructed.
• Unblock all <amp-ad> components (unless the publisher specifies not to by adding the data-block-on-consent attribute) and passesthe response to them.

Special Cases

Publishers can override the default behavior and customize the blocking behaviors by tagging the components manually.

• If a publisher wants to avoid ad blocking with a CMP,: Use <amp-ad data-block-on-consent=”_never”>
• If the publisher wishes to block a component other than <amp-ad>: Use the existing data-block-on-consent attribute. However, the value of the returned action (accept/reject/dismiss), depends on the agreement between the publisher and the CMP.

Prompt Window

External Iframe

AMP consent will load and render the CMP’s prompt UI in a cross domain iframe, where the CMP will have full control. However, AMP runtime will control the life cycle of the iframe, dictating when to load or unload it.

• The iframe will be loaded if a user consent is required but missing, or if a user wants to manage their consent at any point.
• The iframe will be unloaded once a user decision has been made and the prompt UI needs to be hidden.

Default placeholder

AMP will apply a placeholder before the CMP iframe loads to improve user experience. The placeholder will not block the user from interacting with the rest of the page. UX design will be added once ready.

Iframe Size and Placement

AMP will make the prompt UI interstitial by default. CMP and publishers will NOT be able to customize the size and the placement of the iframe. AMP will create a modal layer and place the iframe with default aspect width and height ratio in the center.

Consent String

Consent string contains the user decision and will be stored and passed to vendors. Vendors will interpret the consent string and respond accordingly.

Format

Because different CMPs want to store different consent strings for customized vendors in addition to the IAB consent string, AMP will not enforce format on the consent string, or attempt to interpret the consent string before passing the information to vendors. AMP would require CMP to indicate their string as IAB so that vendors can understand. Please note in MVP, not API will be provided to vendors, and vendors need to interpret consent string themselves.

Storage Limit

When the cached AMP page is served from the google.com. All information will be stored under the google.com domain. Because of it, AMP consent has to be very cautious of the storage usage.

In order to be space efficient, AMP restricts the size of total stored value to an upper limit of 300 bytes. That includes the consent string and the CMP private stored string, if one exists. CMPs should work with their partner vendors to compress their consent string.

In the case that a CMP asks AMP to store information that exceeds the size limit, AMP will:

• Erase the current stored value
• Log an error
• Unblock <amp-ad> components and make the consent string information globally accessible to all AMP components the consent string information but w/o storing the value for next visit.

Access

The consent string is made available to all AMP components on the page and to the CMP.

• To AMP components and vendors

  AMP components can call where the policyId can be interpreted from the data attribute.

  getConsentPolicySharedData(ampdoc, policyId)

  3P ad that integrate with AMP can find the string at (similar to supported sharedData)

  window.context.consentString

• To CMP

  • CMP will have access to the consent string. Per their request a CMP will also have access to the CMP stored data. Note that passing CMP stored data is not in scope with the initial implementation.
  • The stored value will be divided into two parts.
  • Standard Consent string

  • Private CMP stored string

    Where consent string can be shared to all components, stored string will only be shared with the CMP.

CMP Integration

A CMP named foo_bar will integrate with AMP in the following way.

Check in configuration

Add the configuration as part of the <amp-consent> codebase. This will allow AMP to recognize the CMP, perform steps to check if consent is necessary, handle storage and UI.

 'foo_bar': {
   ‘storageKey’: ‘cmp_foo_bar’,
   'checkConsentHref': 'https://foo-bar.com/amp/endpoint',
   'promptUISrc': 'https://foo-bar.com/cmp.html',
  }

storageKey instructs AMP runtime to store the consent information under this unique key name. Note: AMP will append prefix to the key. If not specified, AMP will assume CMP does not require consent string to be stored client side.

Unlike the current DIY approach with <amp-consent>, CMP will be able to specify the storage key value instead of publishers. This is easier for CMP to bump up versions because they have control of the storageKey.

checkConsentHref is a field AMP consent already supports. It allows the AMP consent component to ask the CMP if consent is required for a user. This field is required, as it is the key to instruct AMP runtime to ask for consent and block other components on the page. For more details, please refer to the section here

Note:the existing promptIfUnknowForGeoGroup for CMP integration won’t be provided as AMP expects CMP to host their own endpoint instead of depending on publishers configuration on the <amp-geo> component.

src is the source for the foreign iframe. It is also a required field. Once AMP consent decides to prompt, it will create a foreign iframe with the src given.

Host endpoint

AMP consent will rely on the host endpoint to determine if the prompt is required with the checkConsentHref request.

Consent Dialog

The CMP will need to modify their prompt logic to function in a cross domain iframe. And communicate with the parent host AMP page through the proposed communication APIs.

Publisher’s Configuration

To work with a CMP, publisher’s configuration will need to stay minimal.

   <amp-consent id="ABC" type="foo-bar" layout="nodisplay">
     <script type="application/json">{
       “cmp”: {
         “token”: xxx
       }
     }</script>
   </amp-consent>

Type Attribute

A type attribute with a valid CMP name value instructs the <amp-consent> component to load the CMP config.

CMP Object

All configuration within the cmp object will be passed to the CMP, both with checkConsentHref and iframe (added to the name attribute).

PostPromptUI

CMP’s support to postPromptUI has not been discussed yet. Right now publishers can still put their own postPromptUI element on the page and reference the element.

   <amp-consent id="ABC" type="foo-bar" layout="nodisplay">
     <script type="application/json">{
       "postPromptUI": "postPromptUI"
     }</script>
     <div id="postPromptUI">
       Post Prompt UI
       <button on="tap:ABC.prompt" role="button">Manage</button>
     </div>
   </amp-consent>

Other topics

Below is a list of topics we have talked about but not covered in the current design. We may look into supporting it in the future. Allow publishers to still use the <amp-geo> component to reduce one roundtrip of latency Provide support for CMP to store consent server side but not client side

[jawadst]

@zhouyx

1. On the format that is stored by AMP in the consentString field (consent string vs CMP-specific string): if what is stored gets passed to vendors then it forces CMPs to store the IAB consent string there and prevents us from storing consent for non-IAB vendors. I think we'll have to assume that non-IAB vendors are not supported in this first version but please keep them in mind for future evolutions. They are a big part of what we do with our publishers. One option would be to open another field (cmpConsent) that would only contain CMP-specific information and would allow us to store extra information as needed.

   If I understand it correctly, what you want is to store a piece of information that's only for CMP use. This is something we can support as long as the string size under the cap. What confuses me a bit is How will this string work with non-IAB vendors?

What we usually do for non-IAB vendors on the regular web or mobile apps is the following:

• If the vendor has a custom API for consent, we call into that with a custom integration. DFP, for instance, exposes the googletag.pubads().setRequestNonPersonalizedAds function (https://developers.google.com/doubleclick-gpt/reference#googletag.PubAdsService_setRequestNonPersonalizedAds) that can be called to request personalized or non-personalized ads.
  • If the vendor does not have a custom API, we simply condition the loading of the vendor tag to the consent given by the user through a tag manager or a hard if in JavaScript

I think that, for AMP, only the second case matters and it could translate into a custom format stored by the CMP like: { vendorId: true/false, vendorId2: true/false, }

that could be interpreted by AMP and used in conjunction with a data-block-on-vendor-consent=""vendorId"" attribute to block any element based on specific consent given to a vendor. That's just an example of how that would work but the overall idea is that the CMP can report consent status by vendor (instead of a global consent state) and that blocking behaviors can tap into the status by vendor for a more granular control.

2. Do you have a way to exit the fullscreen mode?

Short answer: No, but we can definitely add support

That would be great :)

4. Consent re-collection

Thanks for bringing this up. AMP decides to support a one behind model that allows the endpoint to erase the stored consent and force prompt next time. This will be supported with the 'forcePromptOnNext' feature. However it is something the team decides to de-prioritize until CMP integration is added. I'm happy to prioritize if you find it to be a big blocker.

It would definitely be great to re-prioritize this. Is my understanding correct that the HTTP endpoint defined for checkConsentHref is the one that you are refering to when saying "allows the endpoint to erase the stored consent and force prompt next time"? If yes, are you also planning to pass all the consent information (what is being passed to the iframe) when calling that endpoint?

I wonder in the non AMP case, how CMP passes the IAB consent string to vendors? I assume it will be very similar in AMP pages. Happy to discuss this further.

The IAB spec currently has three different use cases for passing consent to vendors:

• In web pages (web or desktop), the CMP exposes a JavaScript on the page (a __cmp function) that vendors are responsible for calling to collect the consent status and act accordingly: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/CMP%20JS%20API%20v1.1%20Final.md#CMP-JS-API
  • In mobile apps, the CMP writes the consent string into the local storage (NSUserDefault or SharedPreferences) and vendors' SDKs read from there: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Mobile%20In-App%20Consent%20APIs%20v1.0%20Final.md
  • For other cases, the consent string can be passed as a query-string parameter with somewhat standardized parameters and macros; https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/URL-based%20Consent%20Passing_%20Framework%20Guidance.md (and the future version of it proposed by Google: https://docs.google.com/document/d/1laqa_jilzDxDoiF-341PLP7QM_NEXqUmbwgQ7U_JS54/edit#heading=h.nunn6u7p2k25)

I am not an AMP expert so I am not sure what would work for you. Maybe the #3. I think it would also be acceptable to have an AMP-specific way as every platform tends to have its own preferred way of passing data around.

[torch2424]

@jawadst Hello, sorry for cutting in here, but yes we can definitely do the CSS thing. If you could, can you provide a small example of the iframe contents you are looking to achieve. Perhaps even a screenshot, and I can look into a fix for you 😄

[zhouyx]

@torch2424 Let's track the UI issue in a separate thread : )

@jawadst thank you for the detailed explaination

I think that, for AMP, only the second case matters and it could translate into a custom format stored by the CMP like: { vendorId: true/false, vendorId2: true/false, } that could be interpreted by AMP and used in conjunction with a data-block-on-vendor-consent=""vendorId"" attribute to block any element based on specific consent given to a vendor. That's just an example of how that would work but the overall idea is that the CMP can report consent status by vendor (instead of a global consent state) and that blocking behaviors can tap into the status by vendor for a more granular control.

Ad vendor specific blocking can be achieved today. This would require the ad vendor to add their support to AMP. We expose the getConsentState() to them. However others like analytics vendor is currently not available because analytics vendors only check in the configuration json to AMP, and can't handle consent status client side today. The AMP team has considered the case here. AMP doesn't want to enforce any consent string standard, so if there's future request for blocking individual vendors, we can explore other approaches such as allowing integrated vendors to insert their plugin functions.

I am not an AMP expert so I am not sure what would work for you. Maybe the #3. I think it would also be acceptable to have an AMP-specific way as every platform tends to have its own preferred way of passing data around.

Yes. Having the consent string passed as a query-string parameter with somewhat standardized parameters and macros is what AMP supports today. So I assume vendors can handle the consent string from AMP pages without much of extra effort.

It would definitely be great to re-prioritize this. Is my understanding correct that the HTTP endpoint defined for checkConsentHref is the one that you are refering to when saying "allows the endpoint to erase the stored consent and force prompt next time"? If yes, are you also planning to pass all the consent information (what is being passed to the iframe) when calling that endpoint?

I'll add the task to our spring planning list. Correct it's the same endpoint I'm referring to. I suppose the consent information is what's required to determine to force prompt or not, so yes if it is requested.

[jawadst]

@torch2424 Thanks for chiming in!

Here is an example of what the current style is with a fullscreen pop-in:

As you can see, there is a weird border at the top of the screen. We want to make sure there is no background, border or or box shadow applied to the iframe that contains the CMP UI (for both fullscreen and non-fullscreen mode0.

[torch2424]

@jawadst Awesome, thanks for sending that!

Opened an issue at: #21245

[MaximePlancke]

Hi @torch2424 @zhouyx ,

We have worked on our Iframe and POST endpoint. I created a PR to add Didomi to the list of vendors https://github.com/ampproject/amphtml/pull/21693

I wasn't sure which branch or what to reference. Please let me know if I need to do any changes.

Thank you

[jawadst]

@torch2424 @zhouyx Do you have a sense of when the updates to AMP Consent will be merged into master and the documentation updated? (https://amp.dev/documentation/components/amp-consent)

We are ready to start deploying a few of our publishers and would like to know what timeline we can communicate to them.

I also want to re-emphasize the importance of working out how the IAB consent string gets passed to vendors :)

[torch2424]

@jawadst

Hello! Thank you for your patience, we were out for AMP Conf last week.

If I could ask, which updates are you looking for? Can you pass along some PRs you are waiting to be deployed? That way I can help you from there.

But in terms of my Consent PRs I may have made, those should be in PROD, but there are some pending documentation details I need to add.

Let me know if there is a particular PR. Thanks! 😄 👍

[jawadst]

@torch2424 We weren't clear on whether the support for CMPs in was deployed in AMP PROD as we have been testing with a custom build. Is it still part of an experiment? ie do our clients need to add the following code to their pages:

AMP.toggleExperiment('amp-consent-v2', true);

The main features that were discussed earlier in this issue and that we think are high priority:

• Being able to exit full-screen mode from the iframe (ie have a postMessage to tell AMP to exit full-screen mode). In our current setup, once the user enters full-screen mode (clicking on "Learn More" from a notice, for instance), we are unable to exit it.
• Pass the consent string to IAB vendors. Currently, no matter what choices the user makes, IAB vendors do not get the consent string and are unable to respect the user's choices.
  • Pass the CMP configuration to checkConsentHref endpoint

Do you have Github tickets to track those?

[torch2424]

@jawadst Thanks for the thorough response. 😄

I'll let @jasti chime in here, as they are the PM for <amp-consent>.

But to answer some of your questions:

Is it still part of an experiment? ie do our clients need to add the following code to their pages

Yes, there is still an experiment for our CMP implementation of amp-consent. I can sync with @zhouyx and @jasti on that 👍

The main features that were discussed earlier in this issue and that we think are high priority:=

Awesome thank you for this! I opened the following issues:

Being able to exit full-screen mode from the iframe (ie have a postMessage to tell AMP to exit full-screen mode). In our current setup, once the user enters full-screen mode (clicking on "Learn More" from a notice, for instance), we are unable to exit it.

Opened #22005 . However, if I remember correctly, I think our team had a discussion about this, and decided that the UX flow would just also allow "accept" / "deny" buttons at the bottom of the "learn more" paragraphs / list of items. But, I may have dreamt it 🙃 Will definitely bring it up during our next sync.

Pass the consent string to IAB vendors. Currently, no matter what choices the user makes, IAB vendors do not get the consent string and are unable to respect the user's choices.

Opened #22006

Pass the CMP configuration to checkConsentHref endpoint

Opened #22007

Also, just a heads up, a lot of us are just now returning from AMP Conf. So we will probably get started on these once we get everyone back. Thanks! 😄

[jasti]

Regarding #22006, the consumption of the consent string is made available to the ad networks on the page and it is it up to the ad network to consume the string and process it. For Google ad networks, I believe there seems to be continued work with the IAB to launch a new version of the consent string, if I'm not mistaken.

@jawadst could you clarify the purpose for the feature: #22007?

[MaximePlancke]

Hi @zhouyx @torch2424

I have a quick question. We need the URL of the website where we are integrated and it has to be dynamic (We can't just pass it through string in the JSON). Would it be possible to use one of your pre-built variables: https://github.com/ampproject/amphtml/blob/master/spec/amp-var-substitutions.md#amp-document-hostname inside the JSON passed through amp-consent?

Thank you in advance

[jawadst]

@zhouyx Some of our publishers' pages are failing AMP validation with the message The tag 'meta name=amp-consent-blocking' is missing or incorrect, but required by 'amp-consent [type]'.
There seems to be a new constraint that was recently added on the meta tag (https://github.com/ampproject/amp-wp/issues/2551). I can see a mention of it on https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md but apart from that, it does not seem to be documented anywhere (I couldn't find it on https://amp.dev/documentation/components/amp-consent/).

Would you be able to provide documentation on that meta tag? What is it used for and why is it required?

[zhouyx]

@jawadst Thank you for reporting. That's is an expected behavior.

The amp-consent-blocking meta tag is required if a publisher is working with a CMP using amp-consent component.

The meta tag serves the same purpose as the data-block-on-consent attribute. Except that it applies the rule to all components with that tag name.

For example <meta name=amp-consent-blocking content=amp-ad> blocks all <amp-ad> component on the page by default.

Unlike publishers who create their own consent management solution, we figured it's likely that publisher won't be tagging their page with the data-block-on-consent attribute manually when working with the CMP. To prevent the case where there's amp-consent implemented, but no component is actually blocked by it, we decided to make this meta tag mandatory with amp-consent [type].

Good point about documentation. I'll add the doc to the publisher facing amp-consent doc as well. Thanks for bringing that up.

Please let me know if this answers your question. Thank you.

[jawadst]

@zhouyx That makes sense, thanks for the explanation. The main caveat is that vendors (and, in particular, IAB vendors), are expected to read the consent string in JavaScript so you will have websites that do not explicitly block anything with a meta tag or a data-block-on-consent attribute but still use a CMP for IAB vendors. I don't think that a page that lacks the meta tag is always invalid.

[zhouyx]

Thank you for clarifying.

When you mentioned vendor, I believe you're referring to the ad vendor. As you said some ad vendors choose to only read the consent string, but not have them blocked by the consent. The behavior can be overwritten by vendors. For example, adsense has the consentHandlingOverride: true, in their config, so <meta name=amp-consent-blocking content=amp-ad> won't be able to block this vendor unless publisher specifically overwrite the behavior again.

I understand that there are websites that do not explicitly block anything. But even that we'd like that to be explicitly declared using the meta tag <meta name=amp-consent-blocking content>. This is our best effort to avoid the case where publishers fail to tag their page.

Please let us know if you think that it's a very common usage where one doesn't want to block any components on the page. Open to other design ideas. Thank you

[jawadst]

@zhouyx I wasn't aware that you could have an "empty" <meta name=amp-consent-blocking content> tag. I think that works fine in this case. More documentation on this tag that we could refer our clients to would be appreciated but the principle works well :)

Thanks for your help!

[mguerra10128]

@zhouyx Im in the process of supporting amp consent in our cmp (will be utilizing the iframe based approach), read over the following two docs:

https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md

I dont see in the docs details about where/how the consentString gets created and stored?

From the docs it mentions that the checkConsentHref instructs AMP to make a POST to the specified URL when the consent state is unknown. So lets say, its the first time a user is coming to the AMP page, and therefore that consent is unknown. The endpoint is hit, returns true to show the prompt. We open an iframe showing a consent message, and the user hits Accept.

For this case, where/when does the consent string get generated and stored. If its the cmp thats creating it, can you let me know from which API that the cmp has should this be coming back in the response?

[mguerra10128]

@zhouyx we are currently blocked on the above question, any details you can share would be greatly appreciated.

[zhouyx]

Thank you @mguerra10128 for the question.

consentString is generated by the CMP, and passed to the AMP doc from the CMP iframe using a post message.

For example:

window.parent.postMessage({
  type: 'consent-response',
  action: 'accept',
  info: /string/, /* optional */
}, '*');

The info here can be used to pass the consentString. The AMP doc will handle the string and store it using the localStorage API afterwards.

The post message API is documented at https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md#accept

Please let me know if this answers your question. Thank you!

[andresilveirah]

@zhouyx thank you for your quick reply, it was definitely helpful. I'm working with @mguerra10128 to integrate our CMP solution to AMP and there's still one piece of the consent puzzle missing. We're trying to pass some info to the iframe (according to https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md#client-information-passed-to-iframe) but the value of window.name inside the iframe is "amp_iframe0".

Here's a snippet of our implementation

<amp-consent id="consent" layout="nodisplay">
  <script type="application/json">{
    "consents": {
        "publishers-site-id": {
            "checkConsentHref": "/consents/check",
            "promptUI": "consentUI"
        }
    },
    "postPromptUI": "privacy-settings-prompt"
  }</script>
  <div id="consentUI" class="popupOverlay">
      <div class="consentPopup">
          <amp-iframe
              layout="fill"
              sandbox="allow-scripts allow-same-origin allow-popups allow-popups-to-escape-sandbox"
              src='//localhost:8080/amp-ui.html'>
            <div placeholder>Loading...</div>
          </amp-iframe>
      </div>
  </div>
  <div id="privacy-settings-prompt">
    <button on="tap:consent.prompt()">Privacy Settings</button>
  </div>
</amp-consent>

Not sure if this is worth noticing, but we're using localhost to serve the consent ui. Are we missing something?

[zhouyx]

Hello @andresilveirah and @mguerra10128

You mentioned that you are integrating with AMP as a CMP. I have a question on how you want to work with publishers. The example you provide (with inline <amp-iframe>) is the solution we provide to publishers who want to manage their own consent. There are some restrictions with this approach, including not allowing consent string.

If you are providing solution as a CMP to publishers, please try the promptUISrc documented here. Another example you can refer to is the local example we built. Please let me know if that works for you.

Re: the iframe window name. Yes that how the <amp-iframe> window is calculated. Which shouldn't be an issue if you are using the promptUISrc. https://github.com/ampproject/amphtml/blob/7e27f4ef9eac01f48751971323325a6645a79602/extensions/amp-iframe/0.1/amp-iframe.js#L404

Thank you

[andresilveirah]

Hi @zhouyx our intention was to make sure our consent UI (which will be wrapped in the iframe) is complete and working well with the AMP APIs before opening a PR to change the https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/0.1/cmps.js adding our configuration. But it seems to me that we'll first have to add our CMP as a valid type and then make sure our code is working well, since the <amp-iframe> is created differently when using <amp-consent> with the type attribute, right?

[zhouyx]

Hello @andresilveirah I see, that's commonly asked question. I should definitely document it better. All configuration can be inlined. When you work on the development, you can simply inline the configuration to test locally. Could you please try inline your configuration? For example:

<amp-consent id='fake' layout='nodisplay'>
      <script type="application/json">{
        "consentInstanceId": "publishers-site-id",
        "checkConsentHref": "http://localhost:8000/get-consent-v1",
        "promptUISrc": //example ui src,
        ....
      }
</script></amp-consent>

Let me know if that helps with your development. Thanks.

[andresilveirah]

Hello @zhouyx that's great! By inlining the CMP's config like you suggested I'm able to test our solution 🎉 At the moment everything seem to be working fine with one exception. Entering fullscreen. In our consent UI I'm calling:

window.parent.postMessage({ type: 'consent-ui', action: 'ready' }, '*');
window.parent.postMessage({ type: 'consent-ui', action: 'enter-fullscreen' }, '*');

But the iframe is still displayed at the bottom of the screen:

Not sure if this is something related to AMP or styling. And if it's styling, not sure if this is the consent ui's fault or the amp page (loading the <amp-consent>).

Do you have an idea? Just in case it's useful, this is our amp page and here's our consent ui.

Really appreciate your help!

[zhouyx]

Hi @andresilveirah Great to hear that the inlining configuration works.

Just tested your example page. And I can confirm that the enter-fullscreen doesn't work well.

Implementation wise, there's a delay between AMP receives the ready message and actually set the UI visibility to true. If the enter-fullscreen is received between this period, the message will be discarded. Which is what happens with your case. However the behavior is sort of by design. The consent UI shows up without any user interaction, because of that we want to keep its initial size to be small enough to not block users. enter-fullscreen is an API we provide to expand the consent UI upon user click, not an API to be called along with ready by design.

Please let us know your opinion on introducing an initial non blocking prompt window before entering the full screen. Thanks

Also regarding amp-consent-blocking meta tag, the topic has been discussed here. https://github.com/ampproject/amphtml/issues/17742#issuecomment-512564655 Thanks!

[andresilveirah]

Hi @zhouyx thank you for all your support. The enter-fullscreen wasn't clear to me. I understand the intention behind showing the message on the bottom by default, I believe it's less intrusive than the fullscreen. However, the way we implemented our UI, the publisher will be able to choose which experience best suit their needs, hopefully the user needs will be their 1st priority :)

Regarding the blocking behaviour. If I understood correctly, just by having a <amp-consent> present in the page won't, by default, block ads from loading, right? Also, once the user has accepted the consent message (thus triggering the accept action) it'll be up to the add vendors to consume the consent string and decide to respect that or not, is that correct?

Perhaps, if I can stretch this comment just a bit further, do you mind having a look at #23917 ? Once again, thanks for the fast replies.

[zhouyx]

Hello @andresilveirah

However, the way we implemented our UI, the publisher will be able to choose which experience best suit their needs, hopefully the user needs will be their 1st priority :)

Thanks for the feedback. The decision was made along with our UX engineer after studying a list of existing CMP solutions. We are hoping to not break user experience too much by limiting the size of the consent UI. Please let us know if you can workaround with this. We're also open to any change as long as we can ensure good user experience. Thanks

Regarding the blocking behaviour. If I understood correctly, just by having a present in the page won't, by default, block ads from loading, right?

That's right. You will either need the data-block-on-consent attribute to block individual element on the page. Or <meta amp-consent-blocking> to block certain component.

Also, once the user has accepted the consent message (thus triggering the accept action) it'll be up to the add vendors to consume the consent string and decide to respect that or not, is that correct?

Yes and no. If an ad vendor has opt-in to handle consent, then yes. It will be up to them to consume the consent state and string. However if an ad vendor hasn't declared to handle consent, then the AMP runtime will instead handle the consent state and block the ad from rendering accordingly.

[andresilveirah]

Hi @zhouyx I have the feeling every time you answer me I come up with 2 new questions 😅

If an ad vendor has opt-in to handle consent, then yes. It will be up to them to consume the consent state and string. However if an ad vendor hasn't declared to handle consent, then the AMP runtime will instead handle the consent state and block the ad from rendering accordingly.

That makes sense. But what happens if the user has given consent to only some vendors in the page? In our case, that'd trigger an accept action and the consent string would be encoded to include the vendors and purposes consented by the user. However, if the ad vendor did not declare to handle consent, it'd be allowed to render (since the consent state is accepted) even if the consent string says otherwise. Right?

What about non-IAB vendors? Is there a way we could pass the consent signal to vendors which aren't included in the consent string, individually? Or do we have to stick with a binary accept all or none?

[zhouyx]

Hello @andresilveirah Those are great questions!

if the ad vendor did not declare to handle consent, it'd be allowed to render (since the consent state is accepted) even if the consent string says otherwise. Right?

That's right. I tend to think the action accept/reject to be the generic signal to block components which don't support customized consent handling. And then the consent string to be the extra information for opt-in vendors to consume. So in the case you described I think it's best to go with reject I think.

As you also mentioned. There's a caveat here, Two vendors that don't handle consent doesn't work well together. The reason behind is that AMP doesn't want to set up its own consent string format to support such use case.

Let me know what do you think, or if there are any good ideas on collecting consent for individual vendors. Thanks!

[tla-sirdata]

Hi @zhouyx

We have a CMP and would like to integrate AMP. Here is the related I2I issue : https://github.com/ampproject/amphtml/issues/24879

We started the development and everything works well so far but after having been through all the discussions and documentation, I still have some questions.

• As the consent prompt is not shown again when there is an existant consent state, how long the consent information is stored ?

• In the window.name passed to the iframe, I can see two attributes consentState and consentStateValue with the same value ('accepted'/'rejected'/'unknown'). What's the difference between them ? And what is the isDirty attribute for ?

• In the checkConsentHref response I tried to add some key-value pairs with the sharedData field but I can't find how the client can read them.

• Is it possible to add the promptUI button outside the amp-consent component ? Typically, a publisher could add the button in the footer.

• In addition to IAB vendors, our CMP allows to collect consent for Google and publisher's purposes. How can we provide these information ?

• I understand that you want the initial size to be small enough to not block users. However, we have to display a very significant amount of information on the initial layer so it's better for us to use the fullscreen mode in order to keep the layer readable. Moreover, our CMP do not block users as there is always a way to close it without giving consent. What do you think about this approach?

Thanks!

[tla-sirdata]

Hi @zhouyx can you help us in integrating our CMP in AMP ? Thanks!

[zhouyx]

@tla-sirdata replied to your questions in #24879 as this thread is getting too long. Thanks

[Vasile-Peste]

Hi, @zhouyx I'm implementhing a Cookie/CMP solution, I need some clarifications:

1. In this issue you mentioned a 'forcePrompt': boolean, //optional field (which is not documented) that can be returned to the checkConsentHref POST request. I tried to use it because we need to load the promptUI each pageview (which is an iframe in our case: we need to load the iframe for each pageview), but it doesn't work.

2. The documentation says that the consentString is passed in the name attribute of the iframe... how does this makes sense if the iframe is loaded only if there is no consent given? If I give consent then the iframe is not loaded on the next pageviews... so you are not passing the consentString to it. When the iframe (promptUI) loads for the first time or after expireCache is set, its name attribute is just name="amp_iframe0".

Summary:

1. Is there a way to load the iframe (promptUI) each pageview, even after consent is given?
2. Is there a way to get the last known consentString from within the iframe? As I explained I can't read the name attribute. I'm missing something?
3. Since we can return a JSON sharedData from the checkConsentHref endpoint, is there a way to access this sharedData also from withing the promptUI iframe?

Regards, Vasile.

[zhouyx]

Hello @Vasile-Peste, happy to clarify. We've changed the API and naming a bit from the proposal here. Please refer to https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md for latest doc.

Is there a way to load the iframe (promptUI) each pageview, even after consent is given?

Yes an no. expireCache (which equals to the forcePrompt field you mentioned) would clear the stored consent, so that iframe will be load again the next user visit. However there's no way to force reload the iframe within the current visit.

Is there a way to get the last known consentString from within the iframe? As I explained I can't read the name attribute. I'm missing something?

Stored consentString will be passed to the iframe via name attribute, it will also be passed to checkConsentHref within the request body. https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md#request

Since we can return a JSON sharedData from the checkConsentHref endpoint, is there a way to access this sharedData also from withing the promptUI iframe?

Good point! There's currently no way to pass sharedData to the iframe. Can I ask what kind of information you want to pass from the endpoint to the iframe? sharedData is introduced to pass addtional information to vendors, I'm thinking maybe a good feature to have is to allow checkConsentHref endpoint to expand and override the clientConfig instead?

[zhouyx]

Hello folks, Wonder if the new ITP's 7-Day Cap on All Script-Writeable Storage is going to affect your product. https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ Thanks.

[jawadst]

@zhouyx There will definitely be an impact on most CMPs as we use client-side storage for keeping a local copy of the consent (just like AMP). We have a few workarounds possible: using server-side cookies (as cookies set by HTTP responses are unaffected at the moment) or login-based consent when possible being the main two options.

[zhouyx]

Thanks @jawadst Could you expand a bit more on the server-side cookies workaround. Will publishers need to host the server to echo the consent information via http cookies, otherwise my understanding is that there will also be the third party cookie restriction.

[zhouyx]

Hello all! We're going to hold a breakout session about consent support in AMP during the online OpenJS World & OpenJs Collaborator Summit next week. (The AMP Contributor Summit has been merged into this summit this year)

We'll be covering updates on <amp-consent>, and are open to feedback and questions. Please register for the summit if you're interested! Registration for the online OpenJS World & OpenJS Collab Summit is now open!

Monday June 22 - OpenJS Collab Summit New Contributor Day Tuesday June 23 and Wednesday June 24 - OpenJS World, bringing together the entire OpenJSF/JS/web community Thursday June 25 and Friday June 26 - OpenJS Collab Summit Project Summit Days

Most of the AMP-community-specific talks and breakout sessions will be on Thursday & Friday, but everyone is welcomed/encouraged to attend all days to engage with the wider web/JS community. When you register, make sure to indicate that you are part of the AMP community so we can get a sense of how many AMP people will be there.

The AMP talk & breakout schedule will be coming soon. :)

Thanks!

[zhouyx]

Here's the AMP talk & breakout schedule. https://docs.google.com/spreadsheets/d/1GY9qNrjxM6Ro-jFSGscL11sKQA46msRMdSrQMhTL8K0/edit#gid=461228868

[heikostaab]

I'm wondering if there is a plan to support Google's Additional Consent Mode in AMP: https://support.google.com/admanager/answer/9681920 Thanks!

[zhouyx]

Thanks for the question. Yes the AMP team is aware of the additional consent string and has added support to allow CMPs to pass that to AMP via metadata additionalConsent field. Vendors could access the information via provided API, but we are not aware of any vendors who are utilizing the API today.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.