iabtechlab / cmp Goto Github PK

Summary:
We are offering the standardised CMP text in a single set of translations, but we would like for publishers to be able to provide their own wording (and translations of this wording) if they would like

Acceptance Criteria:
As a publisher, I should be able to provide my own wording for the CMP with the required translations
As a publisher, I should expect that the correct translation of my wording will be shown to each user based on their browser/device language

Details:
The Digitrust group will provide one set of wording (and the translations)
The CMP should accept a JSON package of all the languages (this can be its own file alongside the configuration information)

Summary:
Global consent is where publishers collect consent for a set of purposes and features on behalf of their vendor partners. This consent applies to the user when they are on the publisher's site and on other sites across the net that also opt for global consent. Global consent is stored in consensu.org

Acceptance Criteria:
As a publisher, I should be able to configure the CMP for global consent

Details:
If the user has disabled third party cookies or the browser does not support third party cookies, global consent should fallback to service specific consent (consent string is stored in the publisher domain)

The standardised language displayed on the primary consent window says, ' Thank-you for visiting XXXX'
Allow publishers to customise XXXX. If they provide no customisation remove this content entirely.

Set consent expiry to a maximum of 13 months (13x 30 day months). It can be configurable to <13 months.

As a publisher, I might want to brand the CMP UX with a logo/image to give my users trust that the pop up they see is initiated by my organisation.

Change current UX to reflect mock ups here.

Changes include:
ALL SCREENS

• Updated disclosure language) (core content and buttons)

Primary Screen (nice to have)

• Add <pop up or hover over when user interacts with “purposes”> on primary screen
• Add <pop up or hover over when user interacts with “information about your device”> on primary screen

Purpose screen

• Addition of instructions at top of purpose screen
  -Functionality to expand vendor list within each purpose (no option to toggle on/off by vendor)
• Dynamically pulling vendor info specific to each purpose (no option to consent by vendor within each purpose) (in another ticket)
• Dynamically pulling purpose and feature names and descriptions (in another ticket)
• Addition of link to show all companies on the purpose screen
• Addition of enable all button on purpose screens

Partner Screen

• Addition of instructions at top of partner screen
  -Dynamically pulling vendor information from GVL for all vendors in pub whitelist or all vendors in GVL if no whitelist exists (no option to consent by vendor within each purpose) (in another ticket)

• Link to each vendor's privacy policy on partner screen

• Addition of enable all button on partner screens

• Get rid of ‘Make more choices’ button and show toggle by default

• UX (bonus)

• Cookie style banner UX option for primary screen (everything else stays the same)

• Different CSS option (so it doesn’t look like Appnexus ref imp)

ADDITIONAL CHANGES AS OF 7th MAY 2018

• Ensure 'Active' toggle switch stays next to Purpose Name
• Change behaviour of Enable ALL button in that it will enable all purposes and vendors. If the user does enable all, the button will change to say disable all so the user has the option to reverse the change.
• Add each vendors privacy policy link to the partner page in the easiest way possible

Summary:
There are core use cases that cause the user to see the consent UX. The publisher might want to influence how often the user is prompted for consent in order to manage their user experience.

Acceptance Criteria:
As a publisher, I should be able to configure how frequently the user will see the consent window based on when the last consent information was collected (frequency/timeperiod)
As a Publisher, I should be able to configure different frequency values based on the level of consent given in the previous cookie. (Three levels: Full consent, no consent, anything in the middle)

Details:
The input should be an editable field in the configuration file
Default should be once per 30 days

Summary:
Expose a function that returns the source of a consent whether it comes from the global cookie or the current publisher cookie

Acceptance Criteria:
As a developer, I should be able to request the source of consent from the CMP

If we are supporting the collection of multiple types of consent we should consider the scenario when a CMP user wants to change the type of consent they are collecting. As per the specification, service specific overrides group consent which overrides global consent. If the CMP user changes from a higher priority consent type to a lower priority consent type (e.g. service specific to global consent), they must choose whether this applies to either:
All users regardless of existing consent record (default) OR
New users with no consent record only and users with consent due to expire in 30 days
The existing cookies associated with the higher priority types should be deleted when the user provides their consent for the new type. No action is required when a CMP user switches to have the CMP collect a higher priority consent type instead of a lower priority consent type aside from setting the cookie associated with the new consent type.

Remove all references to Appnexus in reference implementation code.

Placeholder ticket for the work required to ensure the reference implementation supports v1.1 version of the CMP JS API spec

Summary:
Websites have tracking calls that fire immidiately when a user visits the site. Many of these will require that consent is given before they can fire.

Acceptance Criteria:
As an advertiser/publisher, I should be able to set a toggle in the CMP config file that activates a suppression feature
-If the feature is activated, tracking calls will be suppressed until the user has given consent to be tracked (either in the CMP window or by retrieving their previously given consent information)
-If the feature is deactivated, all background activity continues as it would otherwise

Details:
We want to make sure that advertisers/publishers have the option to selectively continue background activity that does not involve PII

Some publishers want to get user consent for custom purposes that are specific to the way they process their user's personal data.

Allow publishers to create custom purposes that are shown alongside standardised purposes in the consent window. Store consent status against custom purposes in the publisher consent cookie (first party cookie set in publisher domain) as per the v1.1 cookie and vendor format specification.

Currently defined rules are not clear. Popup is not showed as expected.

Summary
Support declaration of whether GDPR applies to user (compulsory). Input can be static or dynamic based on geo location detection. DigiTrust will not be partnering with a geo location vendor to detect user location but vendors offering this CMP to their clients, could leverage existing geo tech vendor relationships to inform the input to this variable if their client would like to detect whether the user is located in the EU on their behalf. gdprApplies: Boolean

Acceptance Criteria
As a publisher, I would like to inform the CMP whether GDPR applies to the user
As a publisher, I would like to have the option to have the CMP detect whether a user is located in the EU if it is available (i.e. vendor offering the CMP has made it available)
As a user, I don't want to have to give consent if GDPR is not applicable to me

Detail:
If GDPRapplies=true show the consent UX if the user has no consent record or an out dated consent record

This is how the GDPRapplies and hasglobalscope inputs inform when the consent window is shown to users with no consent or out of date consent (expired or for old set of purposes/features/vendors)

Summary:
Service Specific consent is the ability for a publisher to collect consent for how their vendor partners process their users personal data (purposes and features) while they are on the publishers site. SS consent is stored in the publisher's domain.

Acceptance Criteria:
As a publisher, I should be able to configure the CMP for service specific consent

• branching/release plan in place
  • proposal: http://www.nomachetejuggling.com/assets/three-flow.png
• separate hostnames for dev/test and production
  • proposal: cmp-origin-{branch}.digitru.st/ with production CDN at cmp.digitru.st
• monitoring
  • minimum: directly monitor production assets
  • ideal: transactional monitoring
• SSL cert in production
• CDN configuration
  • geoip header working
  • cache html content
  • cache headers
  • send cache content on origin failures
  • CORS headers

Summary:
Publisher consent is where publishers choose to collect user consent for themselves (purposes and features). This type of consent has a different storage format and location to the other consent types (see spec).

Acceptance Criteria:
As a publisher, I should be able to configure the CMP for publisher consent

https://drive.google.com/open?id=1x4kGmbuDY4mLokJPy9eZp2wSHHdRBS1oCZmmyiIwSLg

Addition of new vendors/data purposes
Publishers would like to control when users with an existing consent record are presented with a consent modal if a new data purpose or vendor is added. Note that the publisher configured ‘consent frequency setting’ (time interval between requests for consent - default once per 30 days but configurable) should apply also.

Use cases where the consent UX would trigger include:
If managing a vendor whitelist, when the publisher adds new vendors to their whitelist.
If managing a purpose whitelist, when the publisher adds new purpose to their whitelist.
If an existing vendor adds a new data purpose or changes their legal basis to consent for an existing purpose.
If managing a vendor blacklist, when a new vendor is added to the centralised vendor list.
When the publisher manually adds a new data purpose to the whitelist.

Removal of vendors/data purposes
If consent is no longer required for a vendor and/or data purpose, the consent signal for the removed vendor or data purpose should be set to ‘0’ when the user is next seen without any user interaction. This may occur in the following scenarios:
Vendor added to blacklist
Vendor removed from whitelist
Vendor deleted from centrally managed list (?)
Data purpose removed from whitelist by publisher
Data purpose removed by vendor in centralised list (if pub using function to auto-populate data purpose whitelist based on whitelisted vendors)

When we decide to show the CMP JS, we should dynamically retrieve up to date vendor information for the vendors specified by the publisher from the GVL so that it can be presented to the user in the consent UX. The below information for each vendor should be shown under each applicable purpose (so the same vendor may be shown multiple times under each purpose used by the vendor:
-Vendor name
-Link to privacy policy
-Link to other Section14 disclosures

If the vendor requires consent for a specific purpose, the user should be able to toggle the vendor 'on/off'. If the vendor is relying on LI for a specific purpose, the toggle shouldn't be shown and the user must understand that they have to 'opt out' and the CMP should provide a link to direct them to the right page to do so (per the GVL).

Expand the definition of the following consent types that influence reprompting:
From:
no consent given - all vendors are not allowed
some consent given - some, but not all vendors are allowed
full consent given - all vendors in the list are allowed)

TO
no consent given - all vendors are not allowed and all data purposes are not allowed, all vendors are not allowed and some data purposes are not allowed, some vendors are allowed and all data purposes are not allowed.
some consent given - some vendors and some purposes, but not all are allowed
full consent given - all vendors and purposes in the list are allowed

Summary:
We need a way for publishers to setup the CMP tool with configuration information

Acceptance Criteria:
As a publisher, I should be able to edit a text based, human readable file to determine all the CMP settings
As a developer, I should be able to deploy newer versions of the CMP without having to update outdated configuration files

Details:
We will need to add additional configuration fields to this file as we build support for more features

Config fields:
hasGlobalConsent
storeConsentGlobally
storeBublisherData
logging
customPurposeListLocation
globalConsentLocation
Wording
Consent type (Global, Server Specific, Group, Publisher Only)

Allow publishers to get consent for themselves for a different list of purposes and features than the purposes and features they get for their partners. In the MVP there will be no distinction to the user in the UX about whether the purposes/features are applicable to the vendors or the publisher but there will be a distinction in the formation of the publisher and global cookies.

We can make the distinction in the UX in a later version if this is deemed important to publishers.

Summary:
The format of the consent cookie is pretty obfuscated, which makes testing difficult. We need a thin tool to turn the cookie into some human readable format so that our partners can test their CMP implementation by comparing inputs and outputs.

Acceptance Criteria:
As a partner (advertiser/publisher), I should have access to a CMP integration testing tool
As a partner, I should be able to feed a consent cookie into the testing tool, and get returned the "contents" of that cookie in a human readable format. (specifically, what type(s) of consent have been given, and to which data partners)

Details:
The UI for this should be simple, but clean enough to share with external teams.
"IAB Tech Lab Transparency and Consent Framework Cookie and Vendor List v1.1" can be found here:
https://docs.google.com/document/d/1UmarlyN3mwDZOcECil996vPjmE9Xds-FoLGhzC4xySY/edit
"IAB Consent String and Vendor List Format: Transparency & Consent Framework" can be found here:
https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md

Setup automated builds to deploy master branch commits into a publicly-available CDN.

Summary
Investigate viability of detecting whether a user is located in the EU at the edge

Why?
For those publishers that don't want to show the CMP to all site visitor, offer them the option to show it to users located in the EU. Have this dynamically influence the input of the 'gdprapplies' variable. If the user has chosen for the CMP to detect whether the user is located in the EU, 'hasglobalscope' should be set to false.

Acceptance Criteria:
As a publisher, I should be able to configure the CMP to detect whether a user is located in the EU to inform whether the consent window should be triggered.

The IAB recommends the following languages are supported:
Bulgarian, Czech, Croatian, Danish, German, Greek, English, Spanish, Estonian, Finnish, French, Hungarian, Icelandic, Irish, Italian, Lithuanian, Latvian, Malti, Dutch, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovene, Swedish and Turkish

Currently the consent modal sets a consent cookie (consenting to all vendors/purposes) if the user closes the consent window or clicks out of this. If the user has a consent cookie already, it refreshes the consent expiry date.

Remove the ability for the user to:

• Click outside of the consent window
• Close the consent window down (remove the X)

Support CSS customisation of CMP UX

As a publisher, I would like to customise look and feel of the consent UX so that it is consistent with the user experience on my site.

Summary:
The wrapper we are using for the the tool will need to collect some information from the tool itself

Acceptance Criteria:
As a developer, I should be able to access metadata from the CMP

Details:
This is primarily to help the CMP communicate with the wrapper
Use some method call to the window.__cmp object

Summary:
In the spirit of "allowing the user to withdraw consent as easily as it was given", we need a way to trigger the CMP on a publisher's page after it has been closed

Acceptance Criteria:
As a user, I should be able to click a link on the publisher's page that triggers the CMP at any time

Details:
The trigger mechanism needs to have some flexibility so that the publisher can style it to match their page

Summary:
Support standardised messaging in the CMP in the following languages:
Bulgarian, Czech, Croatian, Danish, German, Greek, English, Spanish, Estonian, Finnish, French, Hungarian, Icelandic, Irish, Italian, Lithuanian, Latvian, Malti, Dutch, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovene, Swedish and Turkish
The user must be shown messaging in the correct language based on their browser/device language

Acceptance Criteria:
As a CMP, I must support standardised consent messaging outlined in the IAB EU Consent and Transparency policy
As a publisher, I should expect that the user should be shown messaging in the correct language based on their browser/device language
As a user, I should expect to be shown consent messaging in a language familiar to me and the content I'm consuming

Details:
The Digitrust group will provide one set of wording (and the translations)

Summary:
Group consent is the ability of a private group of publishers to collect and share consent information among themselves

Acceptance Criteria:
As a publisher, I should be able to configure the CMP for group consent
As a publisher, I should be able to specify a domain where consent information is shared

Details:
If the user has disabled third party cookies or the browser does not support third party cookies, group consent should fallback to local consent

Add logic to initiate the Consent UX if the consent has expired or due to expire in = or<30 days

Summary:
Some publishers (or advertisers) may only want to ask users for consent on behalf of a specific set of vendors (a subset of vendor ID's in the centralised vendor list). The CMP needs to support ingesting a list of vendors that limit who consent is gathered for

Acceptance Criteria:
As a publisher, I should be able to upload a formatted list of vendors to serve as a whitelist
As a user, I should only see the whitelisted vendors in the CMP
As a user, if I "consent to all" in the CMP, I should only be consenting to the whitelisted companies

Details:
This can be a file alongside the configuration file

Summary
The CMP should retrieve the data purpose and feature names along with their descriptions dynamically from the GVL in the correct language based on the users browser/device language

Acceptance criteria
As a CMP, when I decide to show the consent modal, I should retrieve the data purpose and feature names and descriptions from the GVLto ensure I'm showing the user up to date information in the appropriate language based on the user's language expectations
As a user, I expect to be shown data purpose and feature names and descriptions in a language I understand

As a user, I would like to have my consent apply regardless of whether I'm using a browser that doesn't support first party cookies.
As a publisher, my user's consent signal should apply regardless of the browser they use.

If a user's browser does not support third party cookies, set as a first party cookie in the publisher domain. This will essentially act as service specific consent.

Update standardised language in UX:https://docs.google.com/document/d/1x4kGmbuDY4mLokJPy9eZp2wSHHdRBS1oCZmmyiIwSLg/edit#

Summary:
In order to help us optimize the UX of the CMP we need to know the total number of people who "visit" the CMP

Acceptance Criteria:
As a developer, I should be able to track and access the total number of people who see the CMP without having to ask for permission to use their data

Details:
The current recommendation is to use a counter pixel that fires when the CMP opens

Placeholder for the work required to have the reference implementation support v1.1 of the consent string and vendor formats spec.

Summary:
Some publishers (or advertisers) may want to limit the partners they are collecting user consent on behalf of. The CMP needs to support ingesting lists of vendors (subset of vendors in centralised list) that limit who consent is gathered for

Acceptance Criteria:
As a publisher, I should be able to upload a formatted list of vendors to serve as a blacklist
As a user, I should see all of the IAB vendors, less the blacklisted ones, in the CMP
As a user, if I "consent to all" in the CMP, I should only be consenting to all IAB vendors except those that have been blacklisted

Details:
This can be a file alongside the configuration file

Summary
Support declaration of whether the publisher wants to declare that they want GDPR to apply to all users regardless of their location through leveraging the hasglobalscope variable (compulsory). This variable will be used downstream by vendors (see spec) and will influence when the consent window is triggered.

Acceptance Criteria
As a publisher, I would like to inform the CMP whether GDPR applies to ALL users

Detail:
This is how the GDPRapplies and hasglobalscope inputs inform when the consent window is shown to users with no consent or out of date consent (expired or for old set of purposes/features/vendors)

Summary:
Some publishers (or advertisers) may only want to ask users for consent for specific purposes and features. The CMP needs to support ingesting a list of purposes (all or subset of purposes/features in centralised list) that limit what consent is gathered for

Acceptance Criteria:
As a publisher, I should be able to upload a formatted list of purposes/features to serve as a whitelist
As a user, I should only see the whitelisted purposes in the CMP
As a user, if I "consent to all" in the CMP, I should only be consenting to the whitelisted purposes

Details:
This can be a file alongside the configuration file

Summary:
For those publishers that don't want to show the CMP to all site visitors, we need a way of determining who to show it to based on their location data.

Acceptance Criteria:
As a publisher, I should be able to configure the CMP with the hasGlobalScope method so that the CMP is only shown to users who are in the EU

Details:
For the time being, we are going to rely on the navigator.language object to determine location
This will be used in conjunction with http://ut-usc.ra.linksynergy.com/gdpr

This is a placeholder for the work required to support the industry-standard proposal for passing consent signals (outside of the OpenRTB fields) suitable for direct HTTP called services.
https://docs.google.com/document/d/1g3y9qQ-F1sMbwRG9Bbw_tD9aXGlylG36Jc1Miwx2pUk/edit#

Register as a CMP:
https://register.consensu.org/CMP

Summary:
The CMP needs to be able to collect consent from users on different browsers

Acceptance Criteria:
As a publisher, I should expect that consent will be collected from the majority of users, regardless of their browser

Details:
For the time being, we would like to start by supporting the most popular browsers, and move down the list until we reach a 92% coverage rate (this may change with additional research)

The DigiTrust CMP should set DigiTrust ID as a first party cookie and in DigiTru.st domain whenever the user sees the consent window and DigiTrust has consent as a vendor. DigiTrust (vendor ID 64 on the GVL) added as a vendor on the publisher vendor whitelist by default. At a high level:
On "OK",
if consent granted for ID 64
url encode the current page url
send a redirect through https://cdn.digitru.st/prod/1.5.10/redirect.html?redirect={current_page_url}

CMP users can opt for a different CMP if they don't want to set an id that widely distributes a persistent identifier.