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

[jasti]

Hi @jeffnordlund-ghost @jawadst @janwinkler, @Waschnick and @consentmanager.
Since you've previously expressed interest in amp-consent's ability to integrate with CMPs, we'd love to have you participate in our design review this Wed @ 1PM PT where we'll go over this component and it's design. Details in #17357.
Please feel free to leave feedback on this issue in the mean time.

[jawadst]

@jasti Thanks for pinging me, I'll definitely join!

[zhouyx]

Few thing I recall from the design review

1. The concern about blocking analytics vendors
   • There's no good way to support that with the current design
   • Would require analytics offline mode to store events before user giving consent
   • To follow up with some analytics vendors and see if they wish to be blocked.
2. The concern about vendor list changes
   • To introduce dirty bit to force ask user consent the next time they visit the page
3. Decided to support the integration with <amp-geo> with CMP integration as it provides faster experience for users that doesn't require consent.
4. storage limit concern
   • CMP use the client side storage as their primary source of storage.
   • We'll start with 300 bytes limit and work on the LRU/LRR to expand the storage limit.

[lannka]

Hi @jeffnordlund-ghost @jawadst @janwinkler, @Waschnick and @consentmanager

we are looking for a CMP to integrate with the amp-consent API. Please let me know if you are interested and we can schedule a VC to go over integration details.

[consentmanager]

yes please :-)

[oliverfernandez]

Hi @lannka

We also have an IAB certified CMP, deployed in several sites, what we'd like to integrate with AMP. I'd appreciate a lot if you could keep me in the loop regarding this

Thanks!

[jawadst]

@lannka Happy to help! We already have a first setup running with the existing amp-consent at Didomi so happy to see how the new version would perform with that.

[jeffnordlund-ghost]

Sure, we would like to explore a better integration with the amp-consent api.

[lannka]

Thanks all. @consentmanager @oliverfernandez @jawadst @jeffnordlund-ghost
If you have a launched CMP product, could you share a link?

Also what's your timezone so we can schedule a VC.

[consentmanager]

Its http://www.consentmanager.net
Timezone is CET

[oliverfernandez]

You can find and example of our CMP working here (mobile only): https://nospensees.fr/

My timezone is CET as well

[zhouyx]

@consentmanager @oliverfernandez @jawadst @jeffnordlund-ghost Thank you all for the interest. We scheduled a meeting on Thursday.
Time: 2018-09-13 15:30 UTC (add to Google Calendar)
Location: Video conference via Google Hangouts

To #17983 for meeting details. Please let us know if you plan to attend or suggest a different time. Thanks.

[oliverfernandez]

@zhouyx works for me

[lannka]

@consentmanager @jawadst @jeffnordlund-ghost in case you didn't see.
are you able to join us tmr?

[consentmanager]

Yes, will be there

[jawadst]

@lannka
That works for me as well

[jeffnordlund-ghost]

Sorry, I’ve been out of the office for a bit and just catching up. I might be able to join (if it hasn’t happened yet). My timezone is MST (in the US). I thought I saw a mail with the date/time earlier but I’m not seeing it now. When are you looking to schedule this? Thanks! - Jeff From: Hongfei Ding <notifications@github.com> Reply-To: ampproject/amphtml <reply@reply.github.com> Date: Wednesday, September 12, 2018 at 7:59 PM To: ampproject/amphtml <amphtml@noreply.github.com> Cc: Jeff Nordlund <jeff.nordlund@crownpeak.com>, Mention <mention@noreply.github.com> Subject: Re: [ampproject/amphtml] I2I: Support CMP Integration with <amp-consent> (#17742) @consentmanager<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconsentmanager&data=02%7C01%7Cjeff.nordlund%40crownpeak.com%7C238b63efda5f4c0ce4ff08d6191c8797%7Ca5a244c1af69471fb4c7ae6e94586df5%7C0%7C0%7C636724007657104766&sdata=FhEa0FQB1GAo274LLa7aoFrA4JYEfjbKQp2CiUA5e0s%3D&reserved=0> @jawadst<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjawadst&data=02%7C01%7Cjeff.nordlund%40crownpeak.com%7C238b63efda5f4c0ce4ff08d6191c8797%7Ca5a244c1af69471fb4c7ae6e94586df5%7C0%7C0%7C636724007657104766&sdata=93UCkKp%2BfaLczXwEepx2z1pnCa5xtPOBdgs8Er3oR04%3D&reserved=0> @jeffnordlund-ghost<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjeffnordlund-ghost&data=02%7C01%7Cjeff.nordlund%40crownpeak.com%7C238b63efda5f4c0ce4ff08d6191c8797%7Ca5a244c1af69471fb4c7ae6e94586df5%7C0%7C0%7C636724007657114774&sdata=CotWh9hfJRYk6FyXcih5dn7LPY9EYyI5auTbQoSGS3c%3D&reserved=0> in case you didn't see. are you able to join us tmr? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fampproject%2Famphtml%2Fissues%2F17742%23issuecomment-420857254&data=02%7C01%7Cjeff.nordlund%40crownpeak.com%7C238b63efda5f4c0ce4ff08d6191c8797%7Ca5a244c1af69471fb4c7ae6e94586df5%7C0%7C0%7C636724007657124782&sdata=utwcKcqXU5G3AceOkBp6OjjtPQwttlG%2BOSGPONV3g6c%3D&reserved=0>, or mute the thread<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIP0R6Xu9gS6KxkFQthsnMuxDlUDMQbKks5uabv7gaJpZM4WOiEN&data=02%7C01%7Cjeff.nordlund%40crownpeak.com%7C238b63efda5f4c0ce4ff08d6191c8797%7Ca5a244c1af69471fb4c7ae6e94586df5%7C0%7C0%7C636724007657124782&sdata=6YtJsqegpX%2B674jw1irTeMZN9Gll8M%2F9pSF57yzDJ3Y%3D&reserved=0>. Empower - September 26-27 2018 In New York

[jawadst]

@zhouyx There is an IAB Techlab call at that time that a lot of us are likely to attend. Can we do Friday instead?

[zhouyx]

Thank you @jawadst for the heads up. Would the same time on Friday, 2018-09-21 15:30 UTC work for everyone? If so I'll go ahead and change the invitation.

Please let us know. Thanks

[jawadst]

Works for me

[consentmanager]

works

[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.

amphtml/extensions/amp-iframe/0.1/amp-iframe.js

Line 404 in 7e27f4e

iframe.name = 'amp_iframe' + count++;

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. #17742 (comment) 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 : #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]

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.