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

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 <amp-consent> 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.

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

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.