diff --git a/CMP JS API v1.1 Final.md b/CMP JS API v1.1 Final.md index 6f9253f0..a3504d1e 100644 --- a/CMP JS API v1.1 Final.md +++ b/CMP JS API v1.1 Final.md @@ -34,12 +34,12 @@ # Introduction -In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. +In February 2017, the IAB Europe assembled parties representing both the supply, and demand sides of the digital advertising ecosystem, to work collectively on guidance, and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. ## About the Transparency & Consent Framework -The scope of the technical working group?s initiative increased to include a technical industry solution to allow website operators to: -1. Control the vendors they wish to allow to access their users? browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem +The scope of the technical working group's initiative increased to include a technical industry solution to allow website operators to: +1. Control the vendors they wish to allow to access their users' browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem 2. Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through the online advertising ecosystem In summary, have one place to go to: @@ -68,13 +68,13 @@ Resources including policy FAQ, Global Vendor List Registration, and CMP registr For purposes of this documentation, the following terms have the following definitions: -* "**_CMP_**" means a company that can read the vendors chosen by a website operator and the consent status of an end user (either service specific (through a first-party cookie) or global (through a third-party cookie). A CMP is not synonymous with a company that surfaces the user interface to a user (although it can be the same). +* "**_CMP_**" means a company that can read the vendors chosen by a website operator and the consent status of an end user (either service specific (through a first-party cookie) or global (through a third-party cookie)). A CMP is not synonymous with a company that surfaces the user interface to a user (although it can be the same). * "**_Purposes_**" mean the purposes for which a Controller enabled by a website operator is using personal data collected from (or received by a third party) about an end user. * "**_Daisybit_**" means information compressed into a binary value and passed throughout the online advertising ecosystem through the OpenRTB specification. -* "**_Vendor_**" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user?s device or browser; and/or (2) collects or receives personal data about the website operator?s end users. As such, a vendor need not be a Controller. +* "**_Vendor_**" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the website operator's end users. As such, a vendor need not be a Controller. ## License @@ -88,11 +88,11 @@ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLI ## Disclaimer -THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED ?AS IS? AND ?AS AVAILABLE,? AND IAB TECHNOLOGY LABORATORY, INC. (?TECH LAB?) MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. +THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. ## About IAB Tech Lab -The IAB Technology Laboratory (?Tech Lab?) is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and ?TV?/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London. +The IAB Technology Laboratory ("Tech Lab") is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and "TV"/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London. Learn more about IAB Tech Lab here: [https://www.iabtechlab.com/](https://www.iabtechlab.com/) @@ -116,7 +116,7 @@ Learn more about IAB Europe here: [https://www.iabeurope.eu/](https://www.iabeur ## What is supported by this API? -This API can be used by on-page javascript tags to obtain consent and vendor list information from the Consent Manager Provider. This API draft takes the approach of specifying the minimum-necessary functionality that the CMP needs to provide DSP?s and SSP?s vendor consent info. There?s a large potential surface area of publisher-CMP functionality (including publisher UI control and configuration) that is best provided by CMP-specific, rather than standardized, API?s. +This API can be used by on-page javascript tags to obtain consent and vendor list information from the Consent Manager Provider. This API draft takes the approach of specifying the minimum-necessary functionality that the CMP needs to provide DSP's and SSP's vendor consent info. There's a large potential surface area of publisher-CMP functionality (including publisher UI control and configuration) that is best provided by CMP-specific, rather than standardized, APIs. ## What API will need to be provided by the CMP? @@ -147,21 +147,16 @@ This API has to support the following functionality: getVendorConsents vendorIds: Uint16Array - Callback( -VendorConsents object, success: boolean) - The vendorIds array contains the vendor ids (as identified in the Global Vendor List) for which consent is being requested. If vendorIds is null or empty, the operation will return consent status for all vendors in the vendor list. -The callback function will be called with a VendorConsents object as the parameter. If vendorIds is provided and not empty, then VendorConsents.vendorConsents will only included IDs from vendorIds, The callback is called only after consent is obtained from the UI or existing cookies. + Callback(VendorConsents object, success: boolean) + The vendorIds array contains the vendor ids (as identified in the Global Vendor List) for which consent is being requested. If vendorIds is null or empty, the operation will return consent status for all vendors in the vendor list. The callback function will be called with a VendorConsents object as the parameter. If vendorIds is provided and not empty, then VendorConsents.vendorConsents will only included IDs from vendorIds. The callback is called only after consent is obtained from the UI or existing cookies. -The consent will be returned false ("No Consent") for any invalid vendorId. -The boolean success parameter passed to the callback indicates whether the call to getVendorConsents() was successful. +The consent will be returned false ("No Consent") for any invalid vendorId. The boolean success parameter passed to the callback indicates whether the call to getVendorConsents() was successful. getConsentData consentStringVersion: string Callback(VendorConsentData object, success: boolean) - If consentStringVersion is provided, then fetch that version if available (else returns null). If consentStringVersion is null, then the latest supported version of the consent string is returned. -The callback is called only after consent is obtained from the UI or existing cookies. -The boolean success parameter passed to the callback indicates whether the call to getConsentData() was successful. + If consentStringVersion is provided, then fetch that version if available (else returns null). If consentStringVersion is null, then the latest supported version of the consent string is returned. The callback is called only after consent is obtained from the UI or existing cookies. The boolean success parameter passed to the callback indicates whether the call to getConsentData() was successful. @@ -179,13 +174,8 @@ The boolean success parameter passed to the callback indicates whether the call getPublisherConsents purposeIds: Uint16Array - Callback( -PublisherConsents object, success: boolean) - The purposeIds lists the purpose ids the publisher is requesting consent for. If this array is null or empty, it will default to all configured purposes. PurposeId's 1-24 indicate standard purposes, while 25-88 indicate custom (publisher-configured) purposes. -The callback function will be called with a PublisherConsents object as the parameter. -The purpose ids would be set by the publisher using a CMP-defined initialization function. -The callback is called only after consent is obtained from the UI or existing cookies. -The boolean success parameter passed to the callback indicates whether the call to getPublisherConsents() was successful. + Callback(PublisherConsents object, success: boolean) + The purposeIds lists the purpose ids the publisher is requesting consent for. If this array is null or empty, it will default to all configured purposes. PurposeId's 1-24 indicate standard purposes, while 25-88 indicate custom (publisher-configured) purposes. The callback function will be called with a PublisherConsents object as the parameter. The purpose ids would be set by the publisher using a CMP-defined initialization function. The callback is called only after consent is obtained from the UI or existing cookies. The boolean success parameter passed to the callback indicates whether the call to getPublisherConsents() was successful. @@ -193,8 +183,7 @@ The boolean success parameter passed to the callback indicates whether the call vendorListVersion (scalar) Callback(GlobalVendorList object, success:boolean) The callback function will be called with the GlobalVendorList parameter being the vendor list object of the requested version. -If the vendorListVersion is null, the vendor list for the VendorListVersion in the current consent string is returned. If no consent string value is currently set, the latest version of the vendor list is returned. -If the vendorListVersion value is ?LATEST?, the latest version available is returned. +If the vendorListVersion is null, the vendor list for the VendorListVersion in the current consent string is returned. If no consent string value is currently set, the latest version of the vendor list is returned. If the vendorListVersion value is "LATEST", the latest version available is returned. If the vendorListVersion is invalid, the callback function will be called with 'null' as the first argument and false as the success argument. The boolean success parameter passed to the callback indicates whether the call to getVendorList() was successful. @@ -236,7 +225,7 @@ This object contains the global purposes, and vendors, consented to by the user: } ``` -where *vendorId* and *purposeId* are the keys and *consentBoolean *are the values for the consent (false="No Consent?, true=?Consent?). The *gdprApplies *field will be true if the user is determined (by geo-IP lookup) to be in the EU, or the publisher has configured the CMP (via a CMP-specific method not specified by this spec) that they are a EU publisher and thus the CMP UI should be shown for everyone. The *metadata* will be the [base64url-encoded](https://tools.ietf.org/html/rfc4648#section-5) value of the following "header" information described in the cookie format: +where *vendorId* and *purposeId* are the keys and *consentBoolean *are the values for the consent (false="No Consent", true="Consent"). The *gdprApplies *field will be true if the user is determined (by geo-IP lookup) to be in the EU, or the publisher has configured the CMP (via a CMP-specific method not specified by this spec) that they are a EU publisher and thus the CMP UI should be shown for everyone. The *metadata* will be the [base64url-encoded](https://tools.ietf.org/html/rfc4648#section-5) value of the following "header" information described in the cookie format: 1. Cookie Version @@ -349,13 +338,13 @@ Typically, code will not need to check if the CMP script is loaded. Code can sim 6. Set the **__cmp** function to the CMP?s full API implementation. - 7. Replace the stub?s postMessage handler with the full CMP handler. + 7. Replace the stub's postMessage handler with the full CMP handler. 8. Run any queued calls using the parameters stored by the stub, in the order received. ## Is there a sample CMP stub? -This code should be as close-to-top as possible in the header. The tag also includes the postMessage handler [as described below.](#heading=h.b8yti5hje2qu) In the snippet provided by a CMP to the publisher, the CMP must replace the value of the gdprAppliesGlobally variable with the value as determined by the publisher in the CMP?s publisher configuration. Additionally, it is recommended that the CMP provide a minified version of the snippet to publishers. +This code should be as close-to-top as possible in the header. The tag also includes the postMessage handler [as described below.](#heading=h.b8yti5hje2qu) In the snippet provided by a CMP to the publisher, the CMP must replace the value of the gdprAppliesGlobally variable with the value as determined by the publisher in the CMP's publisher configuration. Additionally, it is recommended that the CMP provide a minified version of the snippet to publishers. If immutable-version URL's are used for cmp.js, [a subresource integrity attribute](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) should be provided by the CMP and used. diff --git a/Consent String SDK/README.md b/Consent String SDK/README.md index 0e0ef5dd..1b688397 100644 --- a/Consent String SDK/README.md +++ b/Consent String SDK/README.md @@ -24,5 +24,4 @@ These implementations are not supported by the IAB. - [Go](https://github.com/prebid/go-gdpr) (prebid/go-gdpr) - [Go](https://github.com/LiveRamp/iabconsent) (LiveRamp/iabconsent) -- [Rust](https://github.com/cirla/gdpr_consent) (cirla/gdpr_consent) - +- [Rust](https://github.com/cirla/gdpr_consent) (cirla/gdpr_consent) \ No newline at end of file diff --git a/Consent string and vendor list formats v1.1 Final.md b/Consent string and vendor list formats v1.1 Final.md index 2c24e35b..1bdcfdb1 100644 --- a/Consent string and vendor list formats v1.1 Final.md +++ b/Consent string and vendor list formats v1.1 Final.md @@ -32,12 +32,12 @@ # Introduction -In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. +In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. ## About the Transparency & Consent Framework The scope of the technical working group's initiative increased to include a technical industry solution to allow website operators to: -1. Control the vendors they wish to allow to access their users' browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem +1. Control the vendors they wish to allow to access their users' browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem 2. Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through the online advertising ecosystem In summary, have one place to go to: @@ -66,13 +66,13 @@ Resources including policy FAQ, Global Vendor List Registration, and CMP registr For purposes of this documentation, the following terms have the following definitions: -* "**_CMP_**" means a company that can read the vendors chosen by a website operator and the consent status of an end user (either service specific (through a first-party cookie) or global (through a third-party cookie). A CMP is not synonymous with a company that surfaces the user interface to a user (although it can be the same). +* "**_CMP_**" means a company that can read the vendors chosen by a website operator and the consent status of an end user (either service specific (through a first-party cookie) or global (through a third-party cookie). A CMP is not synonymous with a company that surfaces the user interface to a user (although it can be the same). * "**_Purposes_**" mean the purposes for which a Controller enabled by a website operator is using personal data collected from (or received by a third party) about an end user. * "**_Daisybit_**" means information compressed into a binary value and passed throughout the online advertising ecosystem through the OpenRTB specification. -* "**_Vendor_**" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the website operator's end users. As such, a vendor need not be a Controller. +* "**_Vendor_**" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the website operator's end users. As such, a vendor need not be a Controller. ## License @@ -86,11 +86,11 @@ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLI ## Disclaimer -THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. +THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. ## About IAB Tech Lab -he IAB Technology Laboratory ("Tech Lab") is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and "TV"/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London. +The IAB Technology Laboratory ("Tech Lab") is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and "TV"/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London. Learn more about IAB Tech Lab here: [https://www.iabtechlab.com/](https://www.iabtechlab.com/) @@ -235,7 +235,7 @@ Features are informational and should be shown on the UI as a data use by that v 1 Storage and access of information - The storage of information, or access to information that is already stored, on user device such as accessing advertising identifiers and/or other device identifiers, and/or using cookies or similar technologies. + The storage of information, or access to information that is already stored, on user device such as accessing advertising identifiers and/or other device identifiers, and/or using cookies or similar technologies. 2 @@ -244,7 +244,7 @@ Features are informational and should be shown on the UI as a data use by that v 3 - Ad selection, reporting and delivery + Ad selection, reporting and delivery The collection of information and combination with previously collected information, to select and deliver advertisements and to measure the delivery and effectiveness of such advertisements. This includes using previously collected information about user interests to select ads, processing data about what advertisements were shown, how often they were shown, when and where they were shown, and whether they took any action related to the advertisement, including for example clicking an ad or making a purchase. @@ -256,7 +256,7 @@ Features are informational and should be shown on the UI as a data use by that v 5 Measurement - The collection of information about user use of content, and combination with previously collected information, used to measure, understand, and report on user usage of content. + The collection of information about user use of content, and combination with previously collected information, used to measure, understand, and report on user usage of content. feature number @@ -297,7 +297,7 @@ Features are informational and should be shown on the UI as a data use by that v Host .consensu.org - The DNS resolution for the name cmp-name.mgr.consensu.org will be delegated by the standardizing authority (IAB) to each CMP. CMP's will host their code, API's, and CDN at this domain or subdomains. + The DNS resolution for the name cmp-name.mgr.consensu.org will be delegated by the standardizing authority (IAB) to each CMP. CMPs will host their code, APIs, and CDN at this domain or subdomains. Path @@ -330,69 +330,57 @@ The following fields are stored in big-endian format. Example values are provide Version - 6 bits -(0-5) + 6 bits (0-5) "1" for this version Incremented when consent string format changes Created - 36 bits -(6-41) + 36 bits (6-41) Epoch deciseconds when consent string was first created Deciseconds fits into 36 bits with enough precision to record a user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) LastUpdated - 36 bits -(42-77) + 36 bits (42-77) Epoch deciseconds when consent string was last updated CmpId - 12 bits -(78-89) - + 12 bits (78-89) Consent Manager Provider ID that last updated the consent string A unique ID will be assigned to each Consent Manager Provider CmpVersion - 12 bits -(90-101) + 12 bits (90-101) Consent Manager Provider version Each change to the CMP should receive a new version number, for logging proof of consent ConsentScreen - 6 bits -(102-107) + 6 bits (102-107) Screen number in the CMP where consent was given The screen number is CMP and CmpVersion specific, and is for logging proof of consent ConsentLanguage - 12 bits -(108-119) + 12 bits (108-119) Two-letter ISO639-1 language code that CMP asked for consent in Each letter should be encoded as 6 bits, A=0..Z=25 . This will result in the base64url-encoded bytes spelling out the language code (in uppercase). VendorListVersion - 12 bits -(120-131) + 12 bits (120-131) Version of vendor list used in most recent consent string update. Vendor list versions will be released periodically. 12 bits allows for 78 years of weekly updates. PurposesAllowed - 24 bits -(132-155) - For each Purpose, one bit: -0=No Consent -1=Consent + 24 bits (132-155) + For each Purpose, one bit: 0=No Consent 1=Consent Purposes are listed in the global Vendor List. Resultant consent value is the "AND" of the applicable bit(s) from this field and a vendor's specific consent bit. Purpose #1 maps to the first (most significant) bit, purpose #24 maps to the last (least significant) bit. @@ -403,17 +391,14 @@ user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) MaxVendorId - 16 bits -(156-171) + 16 bits (156-171) The maximum VendorId for which consent values are given. VendorIds are numbered 1 to MaxVendorId. Allows the consent string to be interpreted without waiting for the vendor list fetch. EncodingType - 1 bit -(172) - 0=BitField -1=Range + 1 bit (172) + 0=BitField 1=Range The consent encoding used. Either a BitFieldSection or RangeSection follows. Consent string encoding logic should choose the encoding that results in the smaller output. @@ -424,11 +409,8 @@ user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) BitField - MaxVendorId bits -(173-...) - For each Vendor, one bit: -0=No Consent -1=Consent + MaxVendorId bits (173-...) + For each Vendor, one bit: 0=No Consent 1=Consent The consent value for each VendorId from 1 to MaxVendorId @@ -440,22 +422,18 @@ user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) DefaultConsent - 1 bit -(173) - 0=No Consent -1=Consent + 1 bit (173) + 0=No Consent 1=Consent Default consent for VendorIds not covered by a RangeEntry. VendorIds covered by a RangeEntry have a consent value the opposite of DefaultConsent. NumEntries - 12 bits -(174-185) + 12 bits (174-185) Number of entries to follow NumEntries instances of RangeEntry follow. - RangeEntry -(repeated NumEntries times, indicated by [idx]) + RangeEntry (repeated NumEntries times, indicated by [idx]) A single or range of VendorIds, whose consent value is the opposite of DefaultConsent. All VendorIds must be between 1 and MaxVendorId. @@ -463,8 +441,7 @@ user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) SingleOrRange[idx] 1 bit - 0=Single VendorId -1=VendorId range + 0=Single VendorId 1=VendorId range Whether a single VendorId or a start/end range of VendorIds is given @@ -482,7 +459,7 @@ user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) EndVendorId[idx] 16 bits - The end of an inclusive range of VendorIds + The end of an inclusive range of VendorIds Exclusive with SingleVendorId. Must be paired with a StartVendorId. @@ -620,8 +597,7 @@ The following table indicates which fields are used by which cookie: Vendor Consent - 3rd-party global location -(.consensu.org). Required cookie name: euconsent + 3rd-party global location (.consensu.org). Required cookie name: euconsent global vendor consent diff --git a/In-App Reference/Android/readme.md b/In-App Reference/Android/readme.md index 892efa41..fd8893f7 100644 --- a/In-App Reference/Android/readme.md +++ b/In-App Reference/Android/readme.md @@ -1,7 +1,6 @@ # Implementation Guide for Android App Publishers -* Drag and drop the classes from the `cmpconsenttool` package to your project. You will have to update the copied classes `package` name to point to yours, - update the `import` where needed and add the `CMPConsentToolActivity` to your `AndroidManifest.xml` +* Drag and drop the classes from the `cmpconsenttool` package to your project. You will have to update the copied classes `package` name to point to yours, update the `import` where needed and add the `CMPConsentToolActivity` to your `AndroidManifest.xml` * Configure the consent tool by providing a set of properties encapsulated in the `CMPSettings` object. Where: * `SubjectToGdpr`: Enum that indicates @@ -12,7 +11,7 @@ * `consentString`: If this property is given, it enforces reinitialization with the given string, configured based on the `consentToolURL`. This property is optional. ``` -CMPSettings cmpSettings = new CMPSettings(SubjectToGdpr.CMPGDPREnabled, “https://consentWebPage”, null); +CMPSettings cmpSettings = new CMPSettings(SubjectToGdpr.CMPGDPREnabled, "https://consentWebPage", null); ``` * In order to start the `CMPConsentToolActivity`, you can call the following method: `CMPConsentToolActivity.openCmpConsentToolView(cmpSettings, context, onCloseCallback);` @@ -29,7 +28,7 @@ CMPSettings cmpSettings = new CMPSettings(SubjectToGdpr.CMPGDPREnabled, “https * `CMPGDPRDisabled`- value 0, not subject to GDPR * `CMPGDPREnabled` - value 1, subject to GDPR * `CMPGDPRUnknown` - value -1, unset - * CMPPresent: Boolean which indicates if a CMP implementing the `iAB` specification is present in the application. (stored in SharedPreferences under key `IABConsent_CMPPresent`) + * CMPPresent: Boolean which indicates if a CMP implementing the `IAB` specification is present in the application. (stored in SharedPreferences under key `IABConsent_CMPPresent`) * consentString: The consent string as a websafe base64-encoded string. (stored in SharedPreferences under key `IABConsent_ConsentString`) * purposes: String of purposes created from a subset of the decoded consentString converted to binary. (stored in SharedPreferences under key `IABConsent_ParsedPurposeConsents`) * vendors: String of vendors created from a subset of the decoded consentString converted to binary. (stored in SharedPreferences under key `IABConsent_ParsedVendorConsents`) diff --git a/In-App Reference/Mobile In-App Reference Implementation/README.md b/In-App Reference/Mobile In-App Reference Implementation/README.md index 2fae4f80..ff931e94 100644 --- a/In-App Reference/Mobile In-App Reference Implementation/README.md +++ b/In-App Reference/Mobile In-App Reference Implementation/README.md @@ -23,7 +23,7 @@ This produces a production build of the `cmp` script and the docs application: ## Documentation -Instructions to install the CMP as well as API docs and examples are available in the `docs` +Instructions to install the CMP as well as the API docs and examples are available in the `docs` application included with the repo. ```sh @@ -34,6 +34,7 @@ The documentation can be viewed at: `http://localhost:5000/docs/` ## Development + You can start a development server that will monitor changes to all CMP and docs files with: ```sh npm run dev @@ -46,4 +47,4 @@ Development server can be accessed at: ```sh npm test -``` +``` \ No newline at end of file diff --git a/In-App Reference/iOS/readme.md b/In-App Reference/iOS/readme.md index 11b6371e..aebc8f7e 100644 --- a/In-App Reference/iOS/readme.md +++ b/In-App Reference/iOS/readme.md @@ -2,7 +2,7 @@ # CMP Wrapper Implementation Guide for iOS App Publishers -* Configure the consent tool by providing a `cosentToolURL` to `CMPConsentToolViewController`. +* Configure the consent tool by providing a `consentToolURL` to `CMPConsentToolViewController`. * `consentToolURL`: `NSURL` * It is used to create and load the request into the `WKWebView` – it is the request for the consent webpage. This property is mandatory. * `cmpPresent`:`BOOL` @@ -47,7 +47,7 @@ int purposeId = ; BOOL purposeConsent = [consentToolViewController.consentToolAPI isPurposeConsentGivenFor:purposeId]; ```` -* To access vendor consent for given vendorId `isVendorConsentGivenFor:` can be used. Return type is YES if consent is given else returns NO. +* To access vendor consent for given vendorId `isVendorConsentGivenFor:` can be used. Return type is YES if consent is given, else returns NO. ```` int vendorId = ; BOOL vendorConsent = [consentToolViewController.consentToolAPI isVendorConsentGivenFor:vendorId]; diff --git a/Mobile In-App Consent APIs v1.0 Final.md b/Mobile In-App Consent APIs v1.0 Final.md index ba21e203..a120fc0e 100644 --- a/Mobile In-App Consent APIs v1.0 Final.md +++ b/Mobile In-App Consent APIs v1.0 Final.md @@ -30,7 +30,7 @@ # Introduction -In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. +In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. This mobile in-app specification is dependent on the following Transparency and Consent Framework; - [CMP JS API v1.1](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/CMP%20JS%20API%20v1.1%20Final.md) @@ -39,8 +39,8 @@ This mobile in-app specification is dependent on the following Transparency and ## About the Transparency & Consent Framework -The scope of the technical working group?s initiative increased to include a technical industry solution to allow website operators to: -1. Control the vendors they wish to allow to access their users? browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem +The scope of the technical working group's initiative increased to include a technical industry solution to allow website operators to: +1. Control the vendors they wish to allow to access their users' browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem 2. Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through the online advertising ecosystem In summary, have one place to go to: @@ -71,9 +71,9 @@ For purposes of this documentation, the following terms have the following defin * " **_CMP_** " or Consent Management Platform means a company that can read the to transmit information about which vendors and which purposes a user has consented to with vendors. The back end storage and retrieval components of a CMP is optional and also is not necessarily to be provided by the same company that surfaces the front end consent collection aspects of the CMP via a user interface to a user (although it can be the same). -* " **_Purposes_** " mean the purposes for which a controller enabled by an online publisher is using personal data collected from,or received by a third party about an end user. +* " **_Purposes_** " mean the purposes for which a controller enabled by an online publisher is using personal data collected from, or received by a third party about an end user. -* " **_Vendor_** " means a third party that a publisher is using, directly or indirectly, in connection with surfacing content to its end users that either (1) accesses an end user?s device or browser; and/or (2) collects or receives personal data about the publisher?s end users. As such, a vendor need not be a controller. +* " **_Vendor_** " means a third party that a publisher is using, directly or indirectly, in connection with surfacing content to its end users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the publisher's end users. As such, a vendor need not be a controller. ## Scope of the document and definitions @@ -91,7 +91,7 @@ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLI ## Disclaimer -THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. +THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. ## About IAB Tech Lab @@ -161,12 +161,12 @@ Here is the list of the preferences created by the CMP: 0 - (not subject to GDPR), Nil - undetermined (default before initialization) Aligns with IAB OpenRTB GDPR Advisory. -Decided to be String, to have the uninitialized status. +Decided to be String, to have the uninitialized status. IABConsent_ConsentString Consent string as defined in "Cookie and vendor list format specification" - Aligns with IAB OpenRTB GDPR Advisory + Aligns with IAB OpenRTB GDPR Advisory IABConsent_ParsedPurposeConsents @@ -298,12 +298,12 @@ The preferred way to make this happen in current AdServers are macros for perfor {gdpr} 1 (subject to GDPR), 0 (not subject to GDPR), unset (unknown) - Aligns with IAB OpenRTB GDPR Advisory + Aligns with IAB OpenRTB GDPR Advisory {gdpr_consent} Consent string - Aligns with IAB OpenRTB GDPR Advisory + Aligns with IAB OpenRTB GDPR Advisory @@ -348,7 +348,7 @@ At app start, before the user can access the app the GDPR consent UI should be s **Revoke / change consent:** -A UI access (either in app or through settings/app (iOS)) that allows the user to revoke/change the consent using the same UI that the user was asked to provide consent in to begin with +A UI access (either in app or through settings/app (iOS)) that allows the user to revoke/change the consent using the same UI that the user was asked to provide consent in to begin with. **Selecting purposes and access vendorlist:** diff --git a/README.md b/README.md index 029256a1..135580f4 100644 --- a/README.md +++ b/README.md @@ -2,13 +2,13 @@ # GDPR Transparency and Consent Framework -Hosted in this repository are the technical specifications for IAB Europe Transparency and Consent Framework that will help the digital advertising industry interpret and comply with EU rules on data protection and privacy - notably the General Data Protection Regulation (GDPR) that comes into effect on May 25, 2018. +Hosted in this repository are the technical specifications for the IAB Europe Transparency and Consent Framework that will help the digital advertising industry interpret, and comply with EU rules on data protection and privacy - notably the General Data Protection Regulation (GDPR) that comes into effect on May 25, 2018. #### IAB Europe Transparency and Consent Framework -In November 2017, IAB Europe and a cross-section of the publishing and advertising industry, announced a new Transparency & Consent Framework to help publishers, advertisers and technology companies comply with key elements of GDPR. The Framework will give the publishing and advertising industries a common language with which to communicate consumer consent for the delivery of relevant online advertising and content. IAB Tech Lab is charged with the technical governance of these specifications. +In November 2017, IAB Europe and a cross-section of the publishing, and advertising industry announced a new Transparency & Consent Framework to help publishers, advertisers, and technology companies comply with key elements of GDPR. The Framework will give the publishing, and advertising industries a common language with which to communicate consumer consent for the delivery of relevant online advertising and content. IAB Tech Lab is charged with the technical governance of these specifications. -Specifications published here support the Framework, including the following v1.1 final specifications ready for industry adoption: +Specifications published here support the Framework, including the following v1.1 final specifications that are ready for industry adoption: * Consent Management Provider JavaScript API v1.1 Final (referred to as CMP JS API v1.1) * Consent string and vendor list formats v1.1 Final * Mobile In-App CMP API v1.0 @@ -17,7 +17,7 @@ Specifications published here support the Framework, including the following v1. Upcoming final release of: * pubvendors.json v1.0 -Please submit any general feedback to feedback@advertisingconsent.eu and any technical feedback to transparencyframework@iabtechlab.com. +Please submit any general feedback to feedback@advertisingconsent.eu, and any technical feedback to transparencyframework@iabtechlab.com. #### About IAB Tech Lab @@ -39,4 +39,4 @@ GDPR Technical Working Group members provide contributions to this repository. P #### Disclaimer -THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE “PRODUCTS AND SERVICES”) ARE PROVIDED “AS IS” AND “AS AVAILABLE,” AND IAB TECHNOLOGY LABORATORY, INC. (“TECH LAB”) MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME, INCLUDING, BUT NOT LIMITED TO, DATA PROTECTION LAWS, SUCH AS THE PERSONAL INFORMATION PROTECTION AND ELECTRONIC DOCUMENTS ACT (CANADA), THE DATA PROTECTION DIRECTIVE (EU), THE E-PRIVACY DIRECTIVE (EU), THE GENERAL DATA PROTECTION REGULATION (EU), AND THE E-PRIVACY REGULATION (EU) AS AND WHEN THEY BECOME EFFECTIVE. +THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME, INCLUDING, BUT NOT LIMITED TO, DATA PROTECTION LAWS, SUCH AS THE PERSONAL INFORMATION PROTECTION AND ELECTRONIC DOCUMENTS ACT (CANADA), THE DATA PROTECTION DIRECTIVE (EU), THE E-PRIVACY DIRECTIVE (EU), THE GENERAL DATA PROTECTION REGULATION (EU), AND THE E-PRIVACY REGULATION (EU) AS AND WHEN THEY BECOME EFFECTIVE. diff --git a/URL-based Consent Passing_ Framework Guidance.md b/URL-based Consent Passing_ Framework Guidance.md index c0fd6bd8..3590669e 100644 --- a/URL-based Consent Passing_ Framework Guidance.md +++ b/URL-based Consent Passing_ Framework Guidance.md @@ -10,7 +10,7 @@ This document contains implementation guidance reviewed by the IAB Tech Lab GDPR ## OVERVIEW -Consent signals (for GDPR) can currently be obtained through the CMP Consent JS javascript API (for services running as a javascript tag), or through OpenRTB extension fields for exchanges and bidders. However, consent signals also need to be provided to pixels, pixel redirects used in beaconing and user ID matching processes, and other URL-based services, because they may collect personal information but, being called by either direct HTTP GET requests from properties of another party or redirects therefrom, the receiving service does not have an opportunity to run javascript in the browser in order to access the CMP Consent javascript API itself. These URL-based service fetches are initiated by publisher's or other vendor's javascript code which has access to the consent signal, or as the impression of a winning bidder which also has access to the consent signal from OpenRTB. +Consent signals (for GDPR) can currently be obtained through the CMP Consent JS javascript API (for services running as a javascript tag), or through OpenRTB extension fields for exchanges and bidders. However, consent signals also need to be provided to pixels, pixel redirects used in beaconing and user ID matching processes, and other URL-based services, because they may collect personal information, but being called by either direct HTTP GET requests from properties of another party or redirects therefrom, the receiving service does not have an opportunity to run javascript in the browser in order to access the CMP Consent javascript API itself. These URL-based service fetches are initiated by publisher's or other vendor's javascript code which has access to the consent signal, or as the impression of a winning bidder which also has access to the consent signal from OpenRTB. ## GOALS @@ -110,4 +110,4 @@ CMP's can implement a consent redirector and host it at [https://](https://cmpna 2018/03/12: posted for working group review in IAB Tech Lab's working group -2018/05/09: posted as implementation guidance on Tech Lab github, after review by Tech Lab GDPR Commit Group +2018/05/09: posted as implementation guidance on Tech Lab github, after review by Tech Lab GDPR Commit Group \ No newline at end of file diff --git a/pubvendors.json v1.0 Draft for Public Comment.md b/pubvendors.json v1.0 Draft for Public Comment.md index a24e1962..003d938d 100644 --- a/pubvendors.json v1.0 Draft for Public Comment.md +++ b/pubvendors.json v1.0 Draft for Public Comment.md @@ -36,14 +36,14 @@ # Introduction -In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. +In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data. This specification "pubvendors.json" is a draft for public comment. Please submit your general feedback to feedback@advertisingconsent.eu and any technical feedback to transparencyframework@iabtechlab.com by June 1, 2018. ## About the Transparency & Consent Framework -The scope of the technical working group?s initiative increased to include a technical industry solution to allow website operators to: -1. Control the vendors they wish to allow to access their users? browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem +The scope of the technical working group's initiative increased to include a technical industry solution to allow website operators to: +1. Control the vendors they wish to allow to access their users' browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem 2. Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through the online advertising ecosystem In summary, have one place to go to: @@ -78,7 +78,7 @@ For purposes of this documentation, the following terms have the following defin * "**_Daisybit_**" means information compressed into a binary value and passed throughout the online advertising ecosystem through the OpenRTB specification. -* "**_Vendor_**" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user?s device or browser; and/or (2) collects or receives personal data about the website operator?s end users. As such, a vendor need not be a Controller. +* "**_Vendor_**" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the website operator's end users. As such, a vendor need not be a Controller. ## License @@ -92,11 +92,11 @@ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLI ## Disclaimer -THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED ?AS IS? AND ?AS AVAILABLE,? AND IAB TECHNOLOGY LABORATORY, INC. (?TECH LAB?) MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. +THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME. ## About IAB Tech Lab -The IAB Technology Laboratory (?Tech Lab?) is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and ?TV?/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London. +The IAB Technology Laboratory ("Tech Lab") is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and "TV"/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London. Learn more about IAB Tech Lab here: [https://www.iabtechlab.com/](https://www.iabtechlab.com/) @@ -123,7 +123,7 @@ The high level goals of "pubvendors.json" supports the following: 5. Enable publishers to limit features on a per vendor basis -## Publishers concerns about IAB?s GDPR Transparency & Consent Framework version 1.1 +## Publishers concerns about IAB's GDPR Transparency & Consent Framework version 1.1 As understood by IAB Europe Transparency and Consent Steering Group and IAB Tech Lab GDPR Commit Group, the following are the core publisher concerns: @@ -135,29 +135,29 @@ Transparency and consent may not be seen as valid when many vendors and purposes * Surfacing thousands of vendors with broad rights to use data w/out tailoring those rights may be too many vendors/permissions - * Concern that even if a user consents to vendors or doesn?t opt out of a vendor?s processing and broad purposes where the vendor asks a user to, a user may not fully understand what it was told/consented to and publishers may be found to have not done a good enough job limiting the further use of that data for broader arguably more privacy-intrusive uses + * Concern that even if a user consents to vendors or does not opt out of a vendor's processing and broad purposes where the vendor asks a user to, a user may not fully understand what it was told/consented to and publishers may be found to have not done a good enough job limiting the further use of that data for broader arguably more privacy-intrusive uses - * Ideally, publishers would be able to pick a small subset of vendors to which they give broader rights ("tier 1") and then limit the rights of the rest of their vendors (?tier 2?) since publishers recognize that delivering ads to their users,either through direct online deals or programmatically, requires more vendors than those in ?tier 1? + * Ideally, publishers would be able to pick a small subset of vendors to which they give broader rights ("tier 1") and then limit the rights of the rest of their vendors ("tier 2") since publishers recognize that delivering ads to their users,either through direct online deals or programmatically, requires more vendors than those in "tier 1" * Publishers recognize there is no technical way to limit the way data is used after the data is received by a vendor for decisioning/bidding on/after delivery of an ad but need a way to clearly signal the restriction for permitted uses in an auditable way * Thus, publishers need a way to differentiate between those 2 tiers of vendors in what they surface to a user and in what they signal to vendors on page and downstream and upstream through creatives and need to have an audit trail to show this -* Control of purpose and data use by vendor. Publishers and vendors need a signal to communicate to the vendors, purposes and legal bases that have been disclosed on a publisher?s site. Publishers control the disclosures to their users and therefore which vendors can lawfully process the data of users visiting their properties +* Control of purpose and data use by vendor. Publishers and vendors need a signal to communicate to the vendors, purposes and legal bases that have been disclosed on a publisher's site. Publishers control the disclosures to their users and therefore which vendors can lawfully process the data of users visiting their properties * For example vendor 1 has permission for purposes 1, 2 and 3 but vendor 2 only has permission for purpose 3 only * Example uses publishers may wish to control: - * use of a user?s data processed through the delivery, or measurement, of an advertisement or the opportunity to deliver, or measure, of an advertisement to inform future personalisation for such user based on preferences or interests known or inferred from the data collected (inferences about a user can be aggregated across sites) + * Use of a user's data processed through the delivery, or measurement, of an advertisement or the opportunity to deliver, or measure, of an advertisement to inform future personalisation for such user based on preferences or interests known or inferred from the data collected (inferences about a user can be aggregated across sites) ### Disagreement over legal basis (LI vs. consent) -A publisher may disagree with a vendor?s legal analysis on which legal basis the vendor can rely upon for a defined purpose +A publisher may disagree with a vendor's legal analysis on which legal basis the vendor can rely upon for a defined purpose -* Publishers can?t dictate the legal basis on which a vendor (that?s a controller) relies (that?s a legal analysis that has to be made by each controller) +* Publishers cannot dictate the legal basis on which a vendor (that is a controller) relies (that is a legal analysis that has to be made by each controller) -* But Publishers can, based on the legal bases disclosed by a vendor for each purpose (registered in the global vendor list), either choose not to work with that vendor or allow vendors which use one or other legal basis ( LI or consent) +* But Publishers can, based on the legal bases disclosed by a vendor for each purpose (registered in the global vendor list), either choose not to work with that vendor or allow vendors which use one or other legal basis (LI or consent) * Given technical feasibility of publishers signalling information about the disclosures they have made on behalf of a vendor, it is further possible for publishers to choose from several available legal bases that a vendor is willing to rely on. For example, a vendor may be willing to operate on the basis of either user consent if a publisher is willing to obtain it, or justify processing under a legitimate interest in cases where a publisher is not willing obtaining consent for a given vendor. @@ -181,27 +181,27 @@ Framework must support vendors relying on LI and support publishers that only wa Users would be able to consent/approve specific purposes and specific vendors. Publishers may provide additional information to users, such as information that the publisher has imposed additional restrictions on certain vendors and their ability to collect data about a user on its site. The publisher may also provide information to the user about which additional limitations apply to each vendor (for example: Vendor 25 may not process data for Personalization, i.e. enhancing profiles, even though the user consented to that Purpose in general) -Vendors would crawl for "pubvendors.json" periodically. In future revisions the Daisybit will signal to vendors when a new ?pubvendors.json? is available and possibly the content as well. +Vendors would crawl for "pubvendors.json" periodically. In future revisions the Daisybit will signal to vendors when a new "pubvendors.json" is available and possibly the content as well. ## Publisher integration -A publisher would place a file named "pubvendors.json" at the ".well-known path" of their domain at: ?http://publisher.com/.well-known/pubvendors.json? similar to ads.txt and robots.txt ([https://tools.ietf.org/html/rfc5785](https://tools.ietf.org/html/rfc5785)). The publisher should use a CMP that supports ?pubvendors.json?. +A publisher would place a file named "pubvendors.json" at the ".well-known path" of their domain at: ?http://publisher.com/.well-known/pubvendors.json? similar to ads.txt and robots.txt ([https://tools.ietf.org/html/rfc5785](https://tools.ietf.org/html/rfc5785)). The publisher should use a CMP that supports "pubvendors.json". "pubvendors.json" may HTTP redirect (3xx) up to 5 hops ([http://www.ietf.org/rfc/rfc1945.txt](http://www.ietf.org/rfc/rfc1945.txt)), anything beyond this may be treated as if the file is not present. ## CMP integration -The CMP should check use the "pubvendors.json" as the base ruleset for what vendors to show to end clients and how to display them. The CMP should first check for the existence of the ?pubvendors.json?, if found the CMP should use the rules defined for notification to the end user, otherwise global consent or CMP specific configuration can be assumed. +The CMP should check use the "pubvendors.json" as the base ruleset for what vendors to show to end clients and how to display them. The CMP should first check for the existence of the "pubvendors.json", if found the CMP should use the rules defined for notification to the end user, otherwise global consent or CMP specific configuration can be assumed. ## SSP/DSP integration -An SSP/DSP only needs to support version 1.0 of the spec if they are interested in supporting legitimate interest. The GDPR Consent String contains a more restrictive set of information and downstream parties are compliant if they follow approved vendor/purposes in the protocol. +An SSP/DSP only needs to support version 1.0 of the spec if they are interested in supporting legitimate interest. The GDPR Consent String contains a more restrictive set of information and downstream parties are compliant if they follow approved vendor/purposes in the protocol. -If an SSP/DSP does want to support vendors relying on legitimate interest they can use "pubvendors.json" as an out of band solution to augment the Consent String. The vendor needs to build a system to crawl for the existence of the file building a database mapping between the publisher?s domain and rules/content within the file. If a publisher whitelists a vendor claiming legitimate interest then Legitimate Interest can take precedence over the information in the Consent String. The SSP/DSP should regularly sync the ?pubvendors.json? rules in order to stay up to date with publisher changes. +If an SSP/DSP does want to support vendors relying on legitimate interest they can use "pubvendors.json" as an out of band solution to augment the Consent String. The vendor needs to build a system to crawl for the existence of the file building a database mapping between the publisher's domain and rules/content within the file. If a publisher whitelists a vendor claiming legitimate interest then Legitimate Interest can take precedence over the information in the Consent String. The SSP/DSP should regularly sync the "pubvendors.json" rules in order to stay up to date with publisher changes. # Pubvendors.json Version 1.0 -This is a simplified version of the original "pubvendors.json" spec targeted for use by May 25th. Version 1.0 primary purpose to to achieve the following: +This is a simplified version of the original "pubvendors.json" spec targeted for use by May 25th. Version 1.0 primary purpose to to achieve the following: 1. Provide a standard way for publishers to declare a whitelist of vendors that they are working with. @@ -275,9 +275,9 @@ Going forward, and building on the foundations of pubvendors.json Version 1.0, t #### Expanded Purposes Controls -* vendors.purposes.id - The id of the purpose. This should reference the purposes id field +* vendors.purposes.id - The id of the purpose. This should reference the purposes id field. -* vendors.purposes.legalBasis - The legal basis for which the vendor uses the purposes. This can either be "consent" or ?legitimateInterest?. +* vendors.purposes.legalBasis - The legal basis for which the vendor uses the purposes. This can either be "consent" or "legitimateInterest". * vendors.purposes.required - An optional field that signals to external parties if a specific purpose is required for a vendor to operate. @@ -299,17 +299,16 @@ Going forward, and building on the foundations of pubvendors.json Version 1.0, t ### Change to Consent String protocol -The Consent String should be modified to pass the version of the pubvendors.json used when sending the request. The value 0 would indicate that pubvendors.json is not present. The file version can be used by downstream parties to determine if they have an up to date version of the file when processing requests. +The Consent String should be modified to pass the version of the pubvendors.json used when sending the request. The value 0 would indicate that pubvendors.json is not present. The file version can be used by downstream parties to determine if they have an up to date version of the file when processing requests. # FAQ ### Why does this spec not address the Consent String? -We could expand the consent string to support Legitimate Interest in the future. The idea behind "pubvendors.json" goes beyond the consent protocol, as a separate signal. We are simply suggesting starting with ?pubvendors.json? as a first step, to allow for continued adoption of the Consent String v1.1 specification before May 25th. +We could expand the consent string to support Legitimate Interest in the future. The idea behind "pubvendors.json" goes beyond the consent protocol, as a separate signal. We are simply suggesting starting with "pubvendors.json" as a first step, to allow for continued adoption of the Consent String v1.1 specification before May 25th. ### How do publishers create a list of their vendors? The goal of pubvendors.json is to publicly identify direct data processing relationships between publishers and ad technology providers. As such publishers should identify all DSPs, SSPs and DMPs who they have an agreement with to process data. Additionally this should include any partners who you feel comfortable gaining consent on their behalf. This list should include: programmatic partners and any third-party data providers you utilize to help build audience segments. This may exclude downstream third parties who you do not feel comfortable authorizing consent as their legal basis for data collection of your users. -As needed, Additional guidance will be created by the IAB Tech Lab GDPR working group. - +As needed, additional guidance will be created by the IAB Tech Lab GDPR working group. \ No newline at end of file diff --git a/v1.1 Implementation Guidelines.md b/v1.1 Implementation Guidelines.md index bf40a0fe..fbac60c1 100644 --- a/v1.1 Implementation Guidelines.md +++ b/v1.1 Implementation Guidelines.md @@ -16,30 +16,30 @@ Policy FAQ, webinars, and other resources are available at [http://advertisingco -## Publisher guidelines +## Publisher Guidelines **What is a Consent Management Provider (CMP) and why do I (as a Publisher) need one?** -A Consent Management Provider can read and/or set the user?s consent status for the vendors chosen by a website operator (either Publisher-specific through a first-party cookie or global through a third-party cookie). A CMP for the purpose of this document is not necessarily synonymous with a Content Management Platform which is a company that surfaces the content and interface to a user (although a Content Management Platform could provide the Consent functionality). +A Consent Management Provider can read and/or set the user's consent status for the vendors chosen by a website operator (either Publisher-specific through a first-party cookie or global through a third-party cookie). A CMP for the purpose of this document is not necessarily synonymous with a Content Management Platform, which is a company that surfaces the content and interface to a user (although a Content Management Platform could provide the Consent functionality). -In order for downstream partners such as a DSP, SSP or DMP to continue working properly where the GDPR applies on a site for EU users and be in compliance with the GDPR, they will rely on publishers to provide transparency and gain user?s consent. This consent will then be passed via a consent string within the CMP. This string will only provide consent information about vendors who have registered with the IAB Europe and are on the Global Vendor List. +In order for downstream partners such as a DSP, SSP or DMP to continue working properly where the GDPR applies on a site for EU users and be in compliance with the GDPR, they will rely on publishers to provide transparency and gain user's consent. This consent will then be passed via a consent string within the CMP. This string will only provide consent information about vendors who have registered with the IAB Europe and are on the Global Vendor List. **There are 2 ways in which the publisher can ensure there is an active CMP on their site.** -1.Develop an in-house CMP that achieves the criteria below: +1. Develop an in-house CMP that achieves the criteria below: a. Matches the technical specifications outlined in CMP JS API v1.1 -b. Register as a CMP with IAB Europe. To register,[submit this form](https://register.consensu.org/CMP). +b. Register as a CMP with IAB Europe. To register, [submit this form](https://register.consensu.org/CMP). -2.Implement a CMP on the[ registered list](http://advertisingconsent.eu/cmp-list/). +2. Implement a CMP on the [registered list](http://advertisingconsent.eu/cmp-list/). -In the event you already have a CMP implemented and the company is not found on the IAB Europe?s registered list, it is the publisher?s responsibility to work with their provider to meet the criteria outlined in Option 1?s sub-bullets. Provided below is template language to help communication efforts with your preferred cookie consent vendor. +In the event you already have a CMP implemented and the company is not found on the IAB Europe's registered list, it is the publisher's responsibility to work with their provider to meet the criteria outlined in Option 1's sub-bullets. Provided below is template language to help communication efforts with your preferred cookie consent vendor. "_We are currently in the process of ensuring compliance with the GDPR and ePrivacy Directive. In order for us to continue our current business practices, we will need an IAB Europe Registered Consent Management Provider. This CMP will allow us to manage consent on behalf of our downstream programmatic and data partners._ -_It?s my understanding you currently serve this function by being our cookie consent mechanism. In looking at the IAB Europe?s approved CMP list, I noticed you are not currently registered._ +_It is my understanding you currently serve this function by being our cookie consent mechanism. In looking at the IAB Europe's approved CMP list, I noticed you are not currently registered._ _Can you please advise if there are plans to register your CMP with IAB Europe?_" @@ -53,7 +53,7 @@ Upcoming Framework releases will provide additional publisher controls. More det **Other Considerations** -Publishers may have additional GDPR requirements that are handled outside of the Transparency and Consent framework. The "withdrawal of consent" requires to not process data *going forward on the basis of that consent.* +Publishers may have additional GDPR requirements that are handled outside of the Transparency and Consent framework. The "withdrawal of consent" requires to not process data *going forward on the basis of that consent*. Withdrawal of consent publisher considerations @@ -67,11 +67,11 @@ Withdrawal of consent publisher considerations * It is also possible that this UI/mechanism is provided by a 3rd party (CMP). (E.g. if the CMP provides the consent UI, then the CMP will provide the UI function for user to withdraw consent.) -## Buyer guidelines +## Buyer Guidelines -Agency and DSP guidelines are further detailed in the following sections. These buyer guidelines help media buyers understand how to check for consent, in accordance with the Framework. +Agency and DSP guidelines are further detailed in the following sections. These buyer guidelines help media buyers understand how to check for consent in accordance with the Framework. -1. Buyers should be listed as vendor if they want to use user data in compliance with GDPR or store and/or access information on an user?s device in compliance with the ePrivacy Directive. Any European buyer should be listed as a vendor in the Global Vendor List. +1. Buyers should be listed as vendor if they want to use user data in compliance with GDPR or store and/or access information on an user's device in compliance with the ePrivacy Directive. Any European buyer should be listed as a vendor in the Global Vendor List. 2. Buyers should check consent for European users. @@ -79,19 +79,19 @@ Agency and DSP guidelines are further detailed in the following sections. These The [OpenRTB GDPR Advisory ](https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf)should be used to communicate user consent. Buyers can use these two extension fields in OpenRTB to determine action. -**GDPR**- if 0 then no gdpr restriction or guideline is applied +**GDPR**- if 0, then no GDPR restrictions or guidelines are applied If missing then you may use user IP address to identify if user belongs to EU/EEA region. If the IP address indicates the request is coming from part of the EU/EEA then GDPR guidelines and restriction should be assumed and the consent string must be parsed to take any action. Absence of a consent string should be interpreted as absence of consent. -If 1 then GDPR guidelines and restriction are applied and look at consent string to take any action +If 1, then GDPR guidelines and restriction are applied and look at consent string to take any action -**Consent**- The binary encoding scheme that is passed in base64 url/web safe format known as ([daisybit](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/)). The Buyer should use the consent array information to know if the user gave consent and for which vendors it gave consent and for which purposes. +**Consent**- The binary encoding scheme that is passed in base64 url/web safe format known as ([daisybit](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/)). The Buyer should use the consent array information to know if the user gave consent and for which vendors it gave consent and for which purposes. -1. If user does not give consent then don?t respond with any ad which uses user information and don?t store any user information and don?t access and/or store information (cookies, IDFA, AAID, fingerprints) on a user?s device. +1. If user does not give consent then do not respond with any ad which uses user information and do not store any user information and do not access and/or store information (cookies, IDFA, AAID, fingerprints) on a user's device. 2. If user gives consent then identify all vendors and related purpose who have received consent from the user. Buyer should also only use and store user data if user has given consent to the buyer and for the purposes for which the user has given consent. Buyer should only allow third party direct or redirect links who have received consent from user. -3. If no consent is given, you cannot use personal data, and may not have the right to use cookies. Each party is responsible to determine what that means for their business.If user consent shows that user has not given consent, then don?t respond with any ad which uses user data, don?t store any user information, and don?t access and/or store information (cookies, IDFA, AAID, fingerprints) on a user?s device. +3. If no consent is given, you cannot use personal data, and may not have the right to use cookies. Each party is responsible to determine what that means for their business. If user consent shows that user has not given consent, then do not respond with any ad which uses user data, do not store any user information, and do not access and/or store information (cookies, IDFA, AAID, fingerprints) on a user's device. The aforementioned fields describing gdpr and consent will be passed through a bid request as follows [(as per the OpenRTB GDPR Advisory)](https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf); @@ -115,31 +115,27 @@ User.consent 4. If Buyer is not using OpenRTB then it should work with SSP to provide same information -5. Buyer can always respond with a Ad which is not using User data and not storing User data and for which no information is stored and/or accessed from the user?s device. +5. Buyer can always respond with a Ad which is not using User data and not storing User data and for which no information is stored and/or accessed from the user's device. -As a buyer, How do I find the consent string? +As a buyer, how do I find the consent string? * In case the impression is received server side (through openRTB for example), you should read the information from the consent payload. For openRTB, technical specifications were updated to provide information on where and how the information is passed. For other non standard server side, you should clarify with the partner how the consent payload will be passed. -* In case the impression is received client side (redirect, prebid, etc.) you should read the information by leveraging CMP on page. This information can be collected whether you are in top parent page (using __cmp("getConsentData") method) or from an iframe (using postMessage method as defined by the CMp technical specifications) +* In case the impression is received client side (redirect, prebid, etc.) you should read the information by leveraging CMP on page. This information can be collected whether you are in top parent page (using __cmp("getConsentData") method) or from an iframe (using postMessage method as defined by the CMP technical specifications) How do I send the consent string? * For any server side call, if using openRTB, the consent payload should be sent accordingly to the openRTB specs ([https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf](https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf)). -* For any client side call, once the consent payload has been obtained leveraging the CMP, you should pass it in the ad call as per below documentation in "URL-based Consent Passing" +* For any client side call, once the consent payload has been obtained leveraging the CMP, you should pass it in the ad call as per below documentation in "URL-based Consent Passing". What do I do with the consent string as a buyer? -As per [policies of the Transparency and Consent Framework](http://www.iabeurope.eu/tcfdocuments/documents/legal/currenttcfpolicyFINAL.pdf), A Vendor may choose not to transmit data to another Vendor for any reason, but a Vendor must -not transmit data to another Vendor without a justified basis for relying on that Vendor?s having -a legal basis for processing the personal data. +As per [policies of the Transparency and Consent Framework](http://www.iabeurope.eu/tcfdocuments/documents/legal/currenttcfpolicyFINAL.pdf), A Vendor may choose not to transmit data to another Vendor for any reason, but a Vendor must not transmit data to another Vendor without a justified basis for relying on that Vendor's having a legal basis for processing the personal data. -If a Vendor has or obtains personal data and has no legal basis for the access to and -processing of that data, the Vendor should quickly cease collection and storage of the data and -refrain from passing the data on to other parties, even if those parties have a legal basis. +If a Vendor has or obtains personal data and has no legal basis for the access to and processing of that data, the Vendor should quickly cease collection and storage of the data and refrain from passing the data on to other parties, even if those parties have a legal basis. ## Agency guidelines @@ -183,7 +179,7 @@ Although the term DMP is fluid, DMP in this document refers to enterprise softwa * When a visitor visits a publisher, who has implemented a IAB Europe Consent Manager-compliant CMP, the first javascript that loads should be the CMP.js library. - * The CMP will inspect the consumer?s cookie and on first instance display the enhanced notice and choices required by GDPR. + * The CMP will inspect the consumer's cookie and on first instance display the enhanced notice and choices required by GDPR. * For a consumer that has previously visited the publisher the CMP within a recent period of time, which is publisher configurable, does not redisplay the enhanced notice and choices required by GDPR. @@ -249,7 +245,7 @@ As a CMP, you will need to: **What does the framework say?** -The consent state of the user must be stored in a shared cookie with the "daisybit" format on the ?consensu.org? domain or a shared memory space in mobile apps to allow for device-wide consent sharing between CMPs. +The consent state of the user must be stored in a shared cookie with the "daisybit" format on the "consensu.org" domain or a shared memory space in mobile apps to allow for device-wide consent sharing between CMPs. CMPs are free to also store consent separately and with a different format if they need to (first-party cookies, long term proof of consent storage, etc.) provided that they keep the shared cookie up-to-date with their local changes. @@ -322,9 +318,9 @@ The current version does depend on the the consent data being stored in cookies. ## What is the long-term plan for consent storage? -A third-party cookie isn?t a long-term solution to auditable, permanent, user-keyed consent storage, and doesn?t work today for browsers that block 3rd-party cookies or mobile apps. CMP?s should work towards standardizing a more future-looking server-side consent retrieval mechanism as well, and can use this cookie as "consent caching" for that future implementation. +A third-party cookie is not a long-term solution to auditable, permanent, user-keyed consent storage, and does not work today for browsers that block 3rd-party cookies or mobile apps. CMP's should work towards standardizing a more future-looking server-side consent retrieval mechanism as well, and can use this cookie as "consent caching" for that future implementation. ## Note -These Framework implementation guidelines will continue to expand with the growing knowledge base of the GDPR Technical Working Group. +These Framework implementation guidelines will continue to expand with the growing knowledge base of the GDPR Technical Working Group. \ No newline at end of file