cmp's People
Forkers
supahnickie aramzs samtingleff tarkay ptomasroos davideperfetto andski-futurum dmytrob36 pariz rusel1989 lassalek zackcarlson bokt dharmeshptl invi2000 danilocaruso joshuamgoldstein jwrosewellcmp's Issues
Support a Config File
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)
Publisher Configuration: Support Data Purpose/Feature Whitelist
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
Suppress Background Calls Until Consent is Given
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
Placeholder: Support GDPR Consent passing for URL-based services
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#
Remove some UX functionality that is non compliant with GDPR
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)
Investigate viability of detecting whether a user is located in the EU at the edge
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.
Expose Cookie Origin
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
Publisher Configuration: Support Vendor Blacklist
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
Production deployment prerequisites
- branching/release plan in place
- 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
For browsers that don't support 3rd party cookies, set global cookie as 1st party cookie
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.
Publisher Configuration: Support Service Specific Consent
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
CMP Integration Testing Tool
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
Expand definition of consent types influencing re-prompting to be more complete
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
Publisher Configuration: GDPR Applies
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)
GDPR Applies | hasGlobalScope | Inform whether Consent window is shown? |
---|---|---|
True | True | Yes |
True | False | Yes |
False | False | No |
False | True | Yes |
Publisher Configuration: Support Global Consent
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)
Add logic to initiate the Consent UX if the consent has expired or due to expire in = or<30 days
Add logic to initiate the Consent UX if the consent has expired or due to expire in = or<30 days
Publisher Configuration: Consent Frequency Setting
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
Placeholder: Support v1.1 version of Consent string and vendor list formats
Placeholder for the work required to have the reference implementation support v1.1 of the consent string and vendor formats spec.
Additional logic required to initiate the UX when vendor/purpose whitelist and blacklists are supported
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)
Expose Metadata from the CMP
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
Manually Trigger CMP After it Has Been Closed
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
Register as a CMP
Register as a CMP:
https://register.consensu.org/CMP
Publisher Configuration: Support Group Consent
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
UX Customisation: Support optional logo/img in CMP UX
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.
Translate standardised language to IAB Recommended languages
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
Set DigiTrust ID for users that have consented to DigiTrust on vendor list
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.
define renderCmpIfNeeded command rules
Currently defined rules are not clear. Popup is not showed as expected.
UX Customisation: Publisher name/domain configuration in primary consent screen
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.
Support for Different Browsers
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)
Publisher Configuration: Support Publisher Consent
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
Dynamically retrieve Vendor information and present to users
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).
Remove references to Appnexus throughout reference implementation
Remove all references to Appnexus in reference implementation code.
Publisher Configuration: gdprAppliesGlobally
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)
GDPR Applies | gdprAppliesGlobally | Inform whether Consent window is shown? |
---|---|---|
True | True | Yes |
True | False | Yes |
False | False | No |
False | True | Yes |
Publisher Configuration: Support Vendor Whitelist
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
Support standardised content in languages outlined by IAB EU policy doc
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)
Allow for Custom Wording (in Different Languages)
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)
Dynamically retrieve Purpose/Feature information in the correct language
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
UX changes
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
Update standardised language in UX
Update standardised language in UX:https://docs.google.com/document/d/1x4kGmbuDY4mLokJPy9eZp2wSHHdRBS1oCZmmyiIwSLg/edit#
Separate purpose and feature lists for publisher vs global consent
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.
Geotargeting EU Users
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
Support creation of custom purposes for publisher specific consent
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.
Review Standardised language
Expanded support for consent types: Handling changes to consent type
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.
Get reference implementation running in a dev environment
Placeholder: Support CMP JS API v1.1 spec
Placeholder ticket for the work required to ensure the reference implementation supports v1.1 version of the CMP JS API spec
Collect Total Number of CMP Uses
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
CI/CD infrastructure
Setup automated builds to deploy master branch commits into a publicly-available CDN.
Publisher Configuration: Set consent expiry to 13 months (max)
Set consent expiry to a maximum of 13 months (13x 30 day months). It can be configurable to <13 months.
UX Customisation: Support CSS customisation of CMP UX
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.