“I’m a CMP. Am I doing it right?” #2 CMP UI/UX Requirements / Part 3

CMPs must adhere to TCF Policies and UI/UX requirements

Last year’s enforcement decision by the CNIL against French mobile ad tech company Vectaury has sent shockwaves through the CMP community, due to Vectaury’s CMP being deemed by the French regulator to be in breach of GDPR requirements for valid consent. Key shortcomings of Vectaury’s CMP could have been easily avoided had it followed TCF Policies for CMPs more closely. We therefore urge all CMPs to ensure that they are implementing TCF Policies correctly. This is even more important given the responsibility CMPs have for the Publisher’s they work for, as well as for the Vendors who rely on the consent signals they create.

In addition to the need to register CMPs with the Framework in order to be able to send TCF-compliant consent signals, the signals CMPs generate are only reliable if they comply with the law. IAB Europe and its members have been making considerable efforts in understanding legal requirements of the GDPR with respect to consent and published a Working Paper on Consent since adoption of the GDPR in 2016. These efforts have been woven into the TCF Policies, notably into Appendix B on UI/UX Guidelines and Requirements. The TCF FAQs give further clarity on UI requirements (see p. 11-13 and p. 22).

In summary, these are some key elements of a compliant CMP UI under the TCF Policies:

  • Initial layer of the UI must be prominently displayed, covering all or substantially all of the content of the page or app. Information to be provided on this initial layer of the UI must at minimum include:
    • Multiple parties will be accessing and/or storing information, such as cookies, on the user’s device and process their personal data and examples of the type personal data.
    • A link to the enumerated list of named third parties (Vendors).
    • The Purposes for which the Publisher and its third party Vendors wish to access and/or store information, such as cookies, on the user’s device and process their personal data using the standard names provided in the Vendor List.
    • An explanation that the user is asked to provide their consent and can change their mind at any time and withdraw consent, as well as an explanation of how to do so (e.g. link at the footer of the page or in the privacy policy that allows resurfacing the CMP UI). A user should also be informed of the consequence of consenting and/or not consenting.
    • Calls to action of equal visual prominence that at a minimum include a way to consent and a way to access advanced options and information.
  • Options and information that must at minimum be provided in secondary layers of the UI includes:
    • Users must be able to review the Purposes, including their standard definitions, and (if applicable) exercise granular choices regarding these Purposes.
    • Users must be able to review the enumerated list of named third parties (Vendors), and have access to information made available on the Vendor List by Vendors. This information must at a minimum, include:
      • Vendor’s name
      • Link to Vendor’s privacy policy
      • The Purposes for which the Vendor processes personal data
      • The legal basis or bases relied upon by the Vendor by Purpose
      • The Features the Vendor relies on when processing personal data

Moreover, it should be noted that consent signals, by their very nature can only be created on the basis of a clear affirmative user interaction with the CMP that unambiguously signifies their consent to the processing. Creation of consent signals by CMPs or others absent such a clear user interaction is therefore not permitted.

“I’m a CMP. Am I doing it right?” #1 CMP Registration and CMP IDs – IAB Europe’s new blog series to help CMPs / Part 2

CMPs must register with IAB Europe and use their assigned ID

Last week, IAB Europe communicated to Vendors and CMPs registered for participation in the TCF a reminder that the Framework’s Policies requires that all CMPs register with IAB Europe, and that Vendors only work with CMPs in compliance with the Policies. The communication alerted TCF participants to the fact that any signals not associated with a valid CMP ID should be considered invalid for purposes of the TCF. This means that Publishers who operate or use CMPs that have not registered their CMP with IAB Europe, or have failed to tag their consent strings with their assigned CMP ID, will very likely see a change in Vendor behavior moving forward.

The requirement that CMPs register with IAB Europe is necessary because of CMPs’ importance in the TCF as the entity that provides transparency to users about how their data is processed and request users’ consent to data processing. Vendors rely on the signals created by CMPs to know whether information has been disclosed to users and whether users have given their consent to processing. These signals are only reliable when generated by CMPs in accordance with the technical specifications and Policies of the Framework, including UI/UX requirements. As originators of consent strings, CMPs must be clearly identified by their CMP IDs to enable Vendors reading consent strings to trace their origins. The CMP ID is only assigned to a CMP once registration is completed and approved by IAB Europe.

When CMPs register with IAB Europe, they contractually agree to adhere to the technical specification and Policies of the Framework, which allows IAB Europe to ensure and support CMP adherence to the Policies.

Without the Framework and its standardising function there is no scalable way of passing consent strings and other information in a reliable and interoperable way. Without registration, participation by CMPs in the Framework is not possible and CMPs cannot send TCF-compliant consent signals.

CMPs are therefore strongly urged to ensure that (1) they have completed registration with IAB Europe using the registration portal for CMPs; (2) they comply with the TCF’s technical specification and Policies; and (3) consent strings they generate include the CMP ID that has been assigned to them by IAB Europe. IAB Europe maintains a list of CMPs and their assigned CMP IDs, which can be consulted to determine which CMPs are registered and what their CMP ID is.

Introducing “I’m a CMP. Am I doing it right?” – IAB Europe’s new blog series to help CMPs / Part 1

Things are going well, but there are opportunities for improvement

Since its release in Spring 2018, the IAB Europe Transparency & Consent Framework (TCF) has seen significant uptake. Already, it is the largest collaborative effort by the advertising industry to programmatically provide users with notice and choice about how their data is processed. It has been a key pillar in the advertising industry’s General Data Protection Regulation (GDPR) and ePrivacy Directive (ePD) compliance efforts. More than 460 registered Vendors are receiving and responding to consent signals created by Internet users interacting with over 170 registered Consent Management Platforms (CMPs) spanning thousands of websites and apps. EU users have more transparency and control than ever before.

Despite its success, the TCF remains a relatively new standard with potential for improvement. This is why IAB Europe and its members have been working on a Version 2 since the TCF’s initial release. Version 2 will add new capabilities, including some intended to provide  Publishers with greater control over how Vendors collect and process the personal data of Internet users visiting their websites or apps. It will also provide more flexibility to Vendors in supporting Publisher and Advertiser needs. And, of course, TCF Version 2 will further enhance transparency and control for Internet users.

IAB Europe and its members have also been monitoring the way companies implement the TCF and continue to identify opportunities for improvement. As the TCF is relatively new, it is only natural that despite best efforts some companies and implementations fall short of expectations. For the TCF to be successful, it is critical that all involved implement it correctly, which is why IAB Europe’s first priority is to ensure that CMPs are educated about the proper use and implementation of the Framework. We want to achieve this by continuing and improving our education efforts in the market. But to ensure adherence to technical specifications and Policies and enhance trust in the reliability of the Framework we must ultimately do even more. That is why in the coming months IAB Europe will also be leading a CMP compliance review program, working closely with CMPs to support adherence and compliance with TCF technical specification and Policies.

But what do we mean by CMPs? When IAB Europe refers to CMPs it refers to a defined term in the context of the TCF. Specifically, we mean the entity responsible for providing transparency to users about which Vendors want to process their personal data and for which Purposes using information published on the Global Vendor List (GVL), requesting user’s consent to the processing of their personal data, and creating and sending signals about user choices to Vendors in the form of a consent string.

CMPs must register with IAB Europe, and agree to adhere to TCF technical specifications and Policies, including UI/UX requirements. CMPs within the TCF receive a unique CMP ID that identifies a consent string as having been generated by a specific, identified, registered CMP. IAB Europe maintains a public list of registered CMPs and their assigned CMP IDs, which can be consulted to determine which CMPs are registered and what their CMP IDs are. It is not possible for non-registered CMPs to send TCF-compliant consent strings.

While IAB Europe will be providing more detailed formal implementation instructions to CMPs in the coming months as it finalizes updates to the TCF, this blog series will focus on some of the most common issues we have identified with respect to CMPs.

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 5

On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the fifth and final blog in the series, covering some final policy questions.

Is there a standardisation of data subject rights and how to handle them, i.e. the Right of Access, portability, rectification, restriction of processing, withdrawal and erasure?

Currently we are not aware of any initiative to standardise these data subject rights, nor has IAB Europe undertaken such an initiative. While it would be helpful, it is difficult to standardise this process across various different company types which use different technologies to offer their services.

Earlier this year, we have drafted a guidance paper together with members of our GDPR Implementation Working Group on the topic, providing guidance about whether to respond and how to respond to these requests. This working paper can be found on IAB Europe’s website here: https://www.iabeurope.eu/policy/iab-europe-gig-working-paper-on-data-subject-requests/.

“Do we expect tech partners to turn off/remove all inventory that doesn’t gather consent using the Transparency & Consent Framework? A huge amount of inventory still available does not adhere to this framework. Right now, we get users who have consented, users who haven’t, and everyone else (who haven’t given consent as per the definition of the GDPR).”

The Framework is an ecosystem of parties which have all agreed to the same Terms and Conditions, as well as the same Policies. They make use of the same technical infrastructure to communicate consent (or other legal bases) to each other.

With that said, it is not mandatory to use the Framework; companies are free to make their own decisions on how they implement their requirements under the GDPR, and how they communicate with their tech partners. It is not a requirement for vendors to stop working with any partners who are not using the Transparency & Consent Framework.

However, to protect the integrity of the Transparency & Consent Framework’s Global Vendor List (GVL), it is a requirement that vendors surfaced in a consent interface who aren’t part of the GVL are made clearly distinct from GVL-registered vendors. Consent cannot be communicated to non-registered vendors through the Transparency & Consent Framework as they would not appear as a slot in the consent string.

Are the “revised purposes” simply updates to the text of the existing purposes or are there also new purposes being added?

The revision of the standardized purposes has the goal of simplifying the language for users, while allowing more specificity in specific business models. In answer to the question, this means that the current purposes are being expanded into more specific purposes. The current five purposes were more general and all-encompassing, whereas the new purposes will look to break down into more specific descriptions of processing activities.

The intention is that this will make it clearer to users what is happening to their data, whilst also allowing companies to more specifically elucidate the type of processing they undergo.

Will CMP’s and Vendors need to re-register when the new specs are rolled out, to demonstrate conformity?

Vendors and CMPs who are registered on the Global Vendor List will be notified directly of any technical and policy updates to the Framework but will not need to complete registration again if they are already registered.

“I understand the TCF is also open for Advertisers, who also collect data. Can you change the reference of “publishers” into “Website/app owners” to make that clear?”

The terminology of ‘publishers’ was chosen to reflect that publishers are the user-facing actors in the online advertising ecosystem. Advertisers who are collecting data would either do so on a landing page, in which they would be acting as a publisher, or as a third party on another publisher’s site, in which they would be considered a third-party vendor.

The Transparency & Consent Framework’s policies also provides the following definition:

“Publisher” means an operator of a website, app, or other content where digital ads are displayed or information is collected and/or used for digital advertising, and who is primarily responsible for ensuring the Framework UI is presented to users and  that legal bases, including consent, are established with respect to Vendors that may  process personal data based on users’ visits to the Publisher’s content.”

Have any questions? Please don’t hesitate to reach out! Contact us at framework@iabeurope.eu

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 4

On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency & Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the fourth and penultimate blog in the series, dealing with questions about the policies of the IAB Europe Transparency & Consent Framework.

How does the IAB Europe Transparency & Consent Framework support cross-publisher consent? What happens when a user consents to a vendor on one publisher, but doesn’t give consent for that same vendor on another publisher’s site?

The IAB Europe Transparency & Consent Framework’s policies do allow for the gaining of support across multiple publishers, which is called ‘global consent’ in the policies of the Framework. Server-specific (meaning for a particular site) disclosures and consent take priority over global consent. If a user makes a global consent choice first, and then later makes a service-specific choice, the service-specific choice will determine a user’s consent status for that service.

This means that for the second question, the consent that hasn’t been given on the other publisher’s site would take precedence over the first publisher’s site, because it is both more recent and more specific. The Consent Management Provider (CMP) has a duty to resolve any conflicts of this kind.

Do the companies collecting data on the basis of a legitimate interest also have to be called by name, i.e. in the privacy policy?

We believe that in order for processing of personal data to be lawful, the user must know who is processing their data and for what purpose.

Putting this information only in a privacy policy that the user is not directed to in the first instance runs the risk of not being considered a proper disclosure by data protection authorities. It would be more appropriate to surface this information in a CMP interface.

I’d like to understand what are the 6 co-equal legal bases [of the GDPR]? It wasn’t clear in the presentation

The GDPR provides for six co-equal legal bases which are enumerated in Article 6(1). The six legal bases are, in order:

  • The data subject gives their consent to the data processing.
  • Processing that is necessary to perform a contract that the data subject is party to, or it is necessary to provide pre-contractual information requested by the data subject. For example, an online shop processing payment information and a home address of the data subject to receive payment and to deliver the goods.
  • Processing that is necessary to comply with a legal obligation. For example, maintaining records of whether you have a legal basis to process personal data is in itself processing of personal data, but it is justified because the law requires this processing.
  • Processing necessary to protect the vital interests of the data subject. The common example is processing medical data for an unconscious person – they are unable to give explicit consent, but it is in their vital interest that a doctor gets access to it.
  • Processing necessary for the performance of a task carried out in the public interest, or in the exercise of official authority vested in the controller. This speaks to law enforcement.
  • Processing necessary for the purposes of a legitimate interest pursued by the controller or a third party. This is the ‘legitimate interest’ legal basis, which requires a balancing test conducted by the controller. The legitimate interest must be balanced against the individual’s rights and freedoms, so it has to be justified by the controller. Any legal goal pursued by a controller could qualify according to case law (these interests may not be pre-defined) and the GDPR calls out direct marketing as an example of a legitimate interest.

Would you say consent to cookies provided by users using the IAB Europe Transparency & Consent Framework equals that provided by a user when using its web browser? E.g., yes to all cookies, no to third parties, etc.

The IAB Europe Transparency & Consent Framework allows users to express their consent, or lack thereof, granularly to (a) the setting of cookies under the rules of the ePrivacy Directive; (b) the processing of their personal data for each of the purposes standardized by the framework; by (c) specific Vendors setting cookies and/or processing personal data. It is therefore significantly more granular than an “all or nothing” approach.  defined purposes

Is there a complete definition of how IAB Europe has interpreted the 5 purposes?

The current five data processing purposes are fully defined in the Transparency & Consent Framework Policies, and expanded on in the FAQs document. The descriptions used represent the standardized interpretation of the current processing purposes. These five purposes were defined by IAB Europe in conjunction with our members as part of the launch of the Framework.

As part of a large update to the Transparency & Consent Framework, we are working with our industry partners to define more granular and ‘user-friendly’ purposes.

There appear to be a few growing pains with the initiative. A fair percentage of “consents” are obtained via pre-checked boxes and/or are binary (i.e., yes/no without listing the types of parties). What do you see as the path towards raising the bar on consents overall? Timeline?

It is complicated to define where to ‘set the bar’ on gathering of consent, due to different approaches by different data protection authorities in Europe. While the GDPR is clear in what it requires for valid consent (an affirmative action, freely given, specific, and informed), there is still room for interpretation by data protection authorities on what each of these factors requires. An affirmative action may in some markets constitute scrolling down after being served a consent notice, whereas others require an obvious yes/no choice to be presented. Authorities may also have different interpretations of when consent is considered freely given, and what level of granularity is considered specific enough.

Due to these differences, the IAB Europe Transparency & Consent Framework leaves freedom for publishers and their CMPs to interpret how best to adapt their interface to their relevant market(s). In terms of specificity of purposes, the Framework draws a very clear baseline of requiring proper disclosure of the relevant defined purposes.

In future, it is foreseeable that a more precise legal understanding will be developed through interpretations from judicial bodies. An EU-wide understanding is only likely to arise from a judgment at the Court of Justice of the European Union. If a clear standard is developed, then the Framework will be adapted if necessary to uphold this.

The CNIL’s VECTAURY Decision and the IAB Europe Transparency & Consent Framework

On 30 October, the French data protection authority (CNIL) published a notice declaring that French start-up company VECTAURY failed to meet conditions for valid consent under data protection law and ordering the company to cease processing geolocation data for advertising purposes without an appropriate legal basis. VECTAURY has been ordered in particular to ensure it obtains GDPR-compliant consent from users of the apps from whom VECTAURY receives real-time bidding opportunities before processing these users’ data moving forward. In addition, the CNIL ordered VECTAURY to delete all data obtained on the basis of the invalid consent.

Some commentators have suggested that VECTAURY ended up in the CNIL’s cross-hairs because it built a Consent Management Provider (CMP) that implemented the IAB Europe Transparency & Consent Framework (TCF). VECTAURY registered itself as a TCF CMP in May of this year.

The suggestion is wrong: the CNIL’s investigation started prior to VECTAURY ever registering itself as a TCF CMP. In addition, on many of the points on which the CNIL considers VECTAURY’s conduct to have violated the General Data Protection Regulation (GDPR), it also violated the TCF’s policies. Indeed, had the company adhered to those policies, not only would it have been better-placed to meet its obligations under the law, but some of the most problematic of the concerns raised by the CNIL would have been addressed.

Why the CNIL found VECTAURY’s conduct to have breached the GDPR

In its notice, the CNIL finds that in two scenarios VECTAURY did not have a legal basis for the processing of personal data under the GDPR. First, where VECTAURY collected and processed geolocation data from mobile app users of mobile apps via its SDK, and a second where it collected and processed personal data received in real-time bids for inventory on mobile apps.

The legal basis claimed by VECTAURY was the consent of the users whose data was processed.  The CNIL’s notice declares that in both scenarios, VECTAURY and its partners failed to meet the conditions for valid consent – and as a result it could not serve as a legal basis for processing.

Conduct that failed to meet requirements of the GDPR

In the first scenario, where VECTAURY collected and processed geolocation data from mobile app users of mobile apps via its SDK, the CNIL noted that default Android OS or iOS notification windows asking for the user’s permission for geolocation data to be collected did not allow VECTAURY to obtain valid consent. VECTAURY then developed a CMP built on the basis of the TCF as a suggested way forward which it submitted to the CNIL. The CNIL opined that while VECTAURY’s CMP would improve transparency for users, it still did not meet the CNIL’s standard for valid consent, because it (a) failed to ensure that users were appropriately informed of the identities of companies that wished to process their data, and (b) failed to ensure that consent was expressed by a clear, affirmative action.

The notice states that in some circumstances, users were not made aware of the fact of VECTAURY (or other companies) seeking consent to process their data at all, and in a consent request UI developed by VECTAURY the default settings didn’t require users to toggle the settings or take some other action in order to convey their agreement.

In both cases, VECTAURY’s CMP also failed to meet its obligations under the TCF’s policies.

In order to be valid under the GDPR, consent must be “informed” and “specific”. Users need to know which companies wish to process their data, and for what purposes.  Other information disclosures must accompany this transparency about who is requesting consent, and why. If VECTAURY’s partners failed to disclose to their users the fact that VECTAURY was one of the companies seeking consent to process their personal data, the conduct of both the partners and VECTAURY was clearly non-compliant. The TCF’s policies require that a consent request conveys to the user both the identities of the companies who wish to seek to process a user’s personal data, as well as the purposes of the processing in a way that enables the user to appreciate that each purpose and company are distinct and separate from one another.

On the “affirmative action” item, the position is also unambiguous. VECTAURY appears to have implemented a consent UI in which a user would be considered to have consented to data processing despite taking no affirmative action of any kind to convey agreement.  This is a clear breach of the GDPR and of the TCF’s policies, both of which require a user to affirmatively consent.

Conduct that failed to reflect data protection authorities’ opinions

Some of the conduct that the CNIL interpreted as being in breach of the GDPR had to do with how information was presented in the UIs of the apps with whom VECTAURY partnered.  Here the CNIL relied on opinions from the Article 29 Working Party of European data protection authorities (DPAs) – and in some cases on its own interpretation of that guidance – to arrive at its finding of illegality.

For example, the CNIL found that the UI in the apps did not inform users of all the controllers who were seeking consent for data processing at the exact moment – or in the exact UI layer – as the request for consent.  Similarly, detailed information on the data processing for which consent was being requested was not provided simultaneously.  Also, the CNIL found the language used to explain to consumers why data needed to be processed to be hard to understand.

These are more subjective items on which reasonable people can disagree.  In the case of presentation to users of the details of the controllers seeking consent simultaneously with the consent request itself, CMPs need to make a judgement about how much information users can assimilate in a single screen.  It appears that the UI that VECTAURY implemented in the CMP it recommended to its app partners required the user to click on several links in order to navigate to the list of companies that wished to process their data (including VECTAURY).  Arguably a better implementation would have reduced the number of clicks required. Indeed, the TCF’s policies require a link to be provided to the list of companies and for the processing purposes to be disclosed on the first layer of a consent notice.

Helpful information for ongoing work of improving the TCF

In the case of the definitions of data processing purposes for which user consent was being sought, here the CNIL clearly has a point.  But striking the right balance between specificity and granularity, on the one hand, and simplicity and ease of comprehension, on the other, is not easy.  The definitions that seem to have prompted the finding of illegality include some of the five definitions currently included in the TCF. They are being revised, in a process that began during the summer following our first meetings with DPAs – including the CNIL – to present the Framework.  One objective of the revision is to make the definitions easier for users to understand.

Perhaps more importantly, we need to consider the best way forward for the Framework and for users on the points where the GDPR itself is silent or unclear, including how to reconcile the apparently conflicting imperatives of ease of user experience, on the one hand, and timely and complete information, on the other, when it comes to information disclosures to users in the context of consent requests.

The CNIL’s discussion of the second scenario where VECTAURY obtained and processed of data received through bid requests, has also made it evident that we will have to do more to support proper implementations by CMPs of the rules of the Framework and the GDPR. This is imperative if the TCF’s signals are to be trusted by the companies who rely on it to mean that appropriate transparency has been provided to users and valid consent has been obtained. The Framework’s signals need to be reliable since the CNIL confirmed that it expects a company to be able to ensure and demonstrate that the consent it relies on is valid at its source but putting in place contractual provisions does not meet the requirement of demonstrating that consent is valid. As it is entirely unfeasible for millions of websites and apps to be individually vetted by thousands of technology partners, we need a trusted Framework the proper implementation of which can ensure and signal that transparency and consent have been established in line with the GDPR.

Ongoing dialogue with DPAs

We welcome the prospect of discussing these issues with the CNIL and with other DPAs over the coming months.

VECTAURY is under review within the TCF

Having been made aware of a possible breach of the TCF’s policies by VECTAURY’s CMP, we will launch a review of the same. We expect to support the company in its efforts to adhere to the TCF’s policies, and accede to the CNIL’s order.

More info

For more information on TCF roll-out and GDPR legal compliance for the digital advertising industry, please write to us at matthiesen@iabeurope.eu or feehan@iabeurope.eu,  or check out http://advertisingconsent.eu.

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 3

On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the third blog in the series, where we deal with the technical questions about the Framework. Upcoming blogs as part of this Blog Series will cover both policy and legal questions.

What do you mean by disclosing vendor permissions and requesting user consent? How is this done via the publisher?

The IAB Europe Transparency & Consent Framework is designed to enable publishers to (i) disclose the vendors who will be processing personal data when a user accesses the site; (ii) disclose the data processing purposes and associated legal bases for which and under which the vendors are processing personal data; (iii) request consent on behalf of those vendors who are relying on consent  as their legal ground for processing for one or more data processing purposes; (iv) store the user’s consent choices; and (v) transmit the user’s consent choices to upstream vendors. We are moreover working on enabling publishers to send a specific signal about whether they have established transparency about a vendor’s processing of personal data on the basis of a legitimate interest. As lawful processing requires transparency and a lawful basis (such as consent), and publishers are responsible and therefore in control of who is permitted to lawfully process personal data consent signals, and other signals sent through the framework are in essence doubling as permissioning signals. Publishers provide transparency and request and obtain user consent through a user interface managed by a Consent Manager Provider (CMP), operated by either a third party on their behalf or by themselves.

To learn more about how CMPs work and how information is transmitted in the Framework read the FAQ here.

“I get that OpenRTB has a field, but what about 3rd party tags pasted into various ad servers? It seems like no ad server has macros for the DaisyBit. Are you working on this?”

Yes, the Tech Lab has developed a URL-based consent passing spec that can support some non-OpenRTB implementations, and this is an open area to improve options for downstream vendors. Join the IAB Tech Lab’s GDPR working group and help us solve this! In the absence of standardized methods of transmitting the Daisybit outside of OpenRTB and URL-based methods, vendors are responsible to ensure they can transmit the Daisybit through whatever means they have available.

Browsers such as Safari are limiting cookies – how does that affect the IAB Europe Transparency & Cosnent Framework?

The Transparency & Consent Framework does not dictate the way in which consent signals are stored. The specifications standardize the data format in which consent signals are stored as well as the interaction with the consent signal, e.g. how to obtain it using a standard API. As such, the Framework allows storing consent signals in any way suitable and does not depend on cookies. However, most implementations on desktop today rely on third-party (global consent) or first-party (service-specific consent) cookies to store a user’s consent choices. On mobile, a user’s choices are stored in local app storage.  Safari Intelligent Tracking Protection (ITP) may impact cookie-based implementations of the Framework, particularly global consent implementations that rely on third party cookies. Service-specific consent implementations that leverage first party cookies are less affected. Nevertheless,  the IAB Tech Lab will be looking into solutions and strategies to account for ITP limitations in future.

“For transmitting the Daisybit string from party to party, I often see the OpenRTB protocol referenced as the required specification, but oftentimes vendors communicate via direct URLs with query string parameters. Is the query string passing guidance an official component of the IAB Europe Transparency & Consent Framework or is it purely an implementation suggestion?”

The IAB Tech Lab has published a specification for URL-based passing of consent, available on the Framework specification repository here: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/URL-based%20Consent%20Passing_%20Framework%20Guidance.md. In situations where URL-based passing is used, it should be implemented with this guidance.

Is it correct that in the case of OpenRTB Exchanges, the Exchange is not expected to protect the requests and the responses based on the payload for consent being passed along?

This is not correct. The Framework Policies only permit a Vendor to transmit personal data to downstream Vendors, for example in the context of OpenRTB, if they have reasonable reliance on that downstream Vendor’s having an appropriate legal basis for processing that personal data. This may be done on the basis of a signal in the context of the Transparency & Consent Framework but Vendors may have other mechanisms to rely on one another’s legal bases.

Why can’t pubvendors.json and CMP be combined into a single code based to account for both?

Early working group discussion explored combining publisher controls and consent preference signals. We determined that the large payload this would require was not appropriate, considering that publisher controls would not change on a per-bid-request basis. Also, the meaning of the signals can be kept distinct between user-preferences (in the consent string) and publisher-preferences (in the pubvendors.json file).

How do interested parties or individuals come to the Lab Tech Group with suggestions?

Proposals, feature requests, and bug reports are very welcome! The GDPR Technical working group at IAB Tech Lab stewards the technical specifications for the Transparency and Consent Framework. IAB Tech Lab members are welcome to join this group. More information available at https://iabtechlab.com/about-the-iab-tech-lab/join-the-iab-tech-lab/

Is it a must to store consent string on `consensu.org` domain? In case if third-party cookies are disabled, what to do?

It isn’t a requirement to store the consent string on consensu.org. Consent can either be stored on a first party cookie (publisher-specific), or on the consensu.org domain as a third-party cookie. Indeed, it is possible to store them outside of cookies altogether! The publisher/CMP can thus choose. Where third-party cookies are disabled, the publisher will not be able to recognize the user, so it may create a user experience issue for that site visitor as the CMP would ‘forget’ that user’s consent status. Publishers could consider informing users about this possibility or, more drastically, refuse access to users who do not allow third parties since this would also impact the ability to leverage ad space on its site.

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 2

On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the second blog in the series, where we deal with the technical questions about the Framework. Upcoming blogs as part of this Blog Series will cover additional technical questions, as well as policy and legal questions.

What about processing batch file data and not real-time requests? Do you actually need the consent string in the batch data file or can you here rely on a DPA with the data provider?

The Consent String, or daisybit, should be read in each bid request for each unique impression opportunity when passed over real-time bidding (OpenRTB).

Do users of the IAB Europe Transparency and Consent Framework have to provide a specific cookie that they want to investigate for a consent status? Could you clarify how would the investigation work?

The individual will be presented with a user interface (operated by a CMP, displayed on a publisher website page). The individual will then select their consent preferences, and this information then gets stored as a cookie (either as a third-party cookie or site-specific cookie). The user is not expected to investigate the literal cookie itself, but a CMP should offer a way for the user (consumer) to re-select their consent preferences, thereby triggering an update to the cookie that has the consent string record.

Can you define what is covered by ‘open source standard’? Is it a tech standard or does it include language and contractual structure?

The IAB Europe Transparency and Consent Framework has open source technical standards managed by IAB Tech Lab and includes a process of registration (including agreement to terms and conditions), allowing a company to express that they adhere to expected policies.

Well known examples of purely technical ‘open source standards’ include OpenRTB, VAST, or MRAID (each without a “framework” that requires corresponding terms and conditions). These technical standards have a system of community and governance to maintain and upgrade specifications to meet industry needs. Participants contribute to implementation guides, provide use cases, or propose new features. A governing body is able to commit to formal iterations and new versions of the specifications, providing structured pathways to updates.

How does the vendor know that the other vendor to whom it is transmitting the data has received the users consent?

All vendors taking part in the Transparency & Consent Framework are obliged to accept the Terms and Conditions, as well as fully adhere to the policies of the Framework. The first vendor in this scenario has to pass the ‘daisybit’ down the chain upon receiving it themselves, and it is up to the vendor down-stream to appropriately respond to the information therein and pass it further down the chain where applicable.

There is currently no technical signal to indicate that consent has been read or applied, though it is a useful suggestion that could be considered as a feature to be included in future updates to the TCF infrastructure.

Is there any way for the signal of “legitimate interest” to be assessed by the IAB Europe Transparency and Consent Framework or will the signal be accepted as it was sent by the CMP?

Signaling of a ‘legitimate interest’ legal basis through the daisybit has been explored by the technical working groups. They determined at the time that the daisybit payload would be overloaded with this extra bit of information since it would effectively double the size. In turn this would add latency and mix intended signals in the Framework.

The Global Vendor List allows a vendor to declare their purposes and legal bases. The consent string should contain information about the user’s consent preferences, and separately, the pubvendors.json file can contain information about the publisher’s permissions for vendors, and for their vendor’s legal bases.

We are still exploring ways to consolidate all the information about whether the user’s data can be processed in future, but with the current iteration we have to rely on a solution which has a consent string on the one hand, and uses pubvendors.json to declare the reliance on legitimate interest on the other.

Is there a published technology roadmap? Is there going to be a defined update/release cycle for enhancements?

There are currently a few new feature updates that are being prioritized, and shared publicly, including pubvendors.json v1.1 finalization, adding security/authentication to the Framework, and efficiency updates. Members of the IAB Tech Lab GDPR working groups have full access to backlog and detailed roadmap of proposed features.

There seem to be many “private CMPs” who have not obtained their own CMP ID and are generating and transmitting consent strings with the invalid CMP id or 1 (what’s in the IAB source code”. Is there any effort underway to eliminate these invalid consent sources?

We have partnered with The Media Trust, who are developing a self-testing tool for CMPs to assess whether their CMP implementation is compliant with the policies of the IAB Europe Transparency and Consent Framework. This will allow current CMPs to improve their products to better fit the standards. This is the first step in a larger effort to validating CMPs, and in that process, we will more diligently update the list of CMPs on www.advertisingconsent.eu, including delisting CMPs that are found to be operating in a non-compliant way.

It should also be noted that, as a matter of the policies, vendors who receive a daisybit from an invalid CMP ID are required to ignore the signal and not act any further on the bid request it is appended to.

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 1

On September 25th, we held a 2.5-hour webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As it is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the first blog in the series, where we deal with the ‘big picture topics’ surrounding our Framework. The next blogs in the series will delve into the technical questions, and to conclude we will answer policy-related questions about the Framework.

Some of these questions have been edited for clarity, or we have answered to topics which were asked about several times

Please provide definitions for some of the acronyms and terms used:

TCF: Acronym for the Transparency & Consent Framework.

EDAA: The European Interactive Digital Advertising Association. This organisation adheres the self-regulatory framework for online behavioural advertising (‘the OBA Framework’).

OBA: Online Behavioural Advertising. The practice of making use of data about user behaviour online to determine more relevant advertising. The EDAA’s OBA Framework is a tool that allows users to get information about this practice and to opt-out of receiving this targeted form of advertising but does not equate to an objection to data processing as provided for under the GDPR’s data subject rights.

Daisybit: This is the information containing information about consent that is given (or not given) for the various purposes standardised by the Framework as well as for different vendors. The information is compressed into a ‘bit-string’ which is daisy-chained through the online advertising supply chain, hence the name ‘daisybit’.

SSP: Supply-Side Platform. Also referred to as the ‘sell-side’, these are platforms that facilitate the sale of ad space.

DSP: Demand-Side Platform. Also referred to as the ‘buy-side’, these platforms help brands and agencies buy ad space.

Publishers: A publisher in the context of our Framework is any consumer-facing website or application, also referred to as the ‘first-party’. It does not refer exclusively to news publishers.

On Google integration with the IAB Europe Transparency & Consent Framework:

Google has stated during the webinar that it plans to interoperate with the Framework once the current work on updating the Purposes, Policies, and introducing Pubvendors.json is complete. This is so that they avoid integrating with the current Policies and Purposes only to have to transition to the revised ones almost immediately.  Our expectation is that Google will make an announcement over the next 3-4 weeks and will actually be implementing the TCF as from January 2019.

IAB is supporting the Transparency and Consent Framework as well as OBA Framework (EDAA). How do these two initiatives talk to each other? Does the first make the later redundant?

The EDAA’s OBA Framework does not help companies achieve compliance with EU data protection law. It is a self-regulatory framework providing so-called “enhanced notice” through an icon and allowing users to “opt-out” of behavioural targeting. Neither the transparency provided through “enhanced notice” nor the “opt-out” meet the relevant requirements under European data protection law.

The IAB Europe Transparency & Consent Framework (TCF) is a Framework designed and intended to help companies comply with obligations arising from EU data protection law, such as transparency, lawful processing, and accountability. Using the TCF, first-parties can enable third-parties to process user data on one of the legal bases of the regulation. The Framework standardises the presentation to users’ third-party data processing requests that require “informed” consent for data processing. The Framework enables “signaling” of user choice across the advertising supply chain. It is open-source, not-for-profit with consensus-based industry governance led by IAB Europe with significant support from industry parties and the IAB Tech Lab, which provides technical management of the open-source specifications and version control.

The two Frameworks are entirely separate and do not interoperate.

On meetings with Data Protection Authorities:

We have been meeting with European data protection authorities to present the IAB Europe Transparency & Consent Framework and to engage in an open-ended conversation to aid in our joint goal of helping companies in the online media and advertising business to comply with European data protection law. Our meetings with the DPAs are private, meaning that we will not be sharing any specific responses or feedback publicly. We hold meetings with those DPAs where we have established contact and who show an interest in meeting with us. It is therefore possible we have not met with DPAs in your jurisdiction – to date we have met with five different DPAs in Europe.

Does the IAB Europe Framework align or reference to some of the key requirements as detailed in the WFA manifesto  earlier this year?

While the IAB Europe Transparency and Consent Framework does not make any direct reference to the requirements of the World Federation of Advertisers’ (WFA) Manifesto for Online Data Transparency, we believe that the TCF is a critical tool in achieving the manifesto’s view that a sustainable digital advertising ecosystem requires the engagement and commitment of all stakeholders to practices that put consumers’ needs first, providing transparency, control, and accountability.

I am a vendor that’s included in the Framework. Could you clarify – how is the framework supposed to benefit me as a vendor?

The Framework allows Vendors to be disclosed to users, establish a lawful basis for processing, and receive a signal that allows it to verify that transparency and/or consent have been established. It is unlikely that in absence of a technical framework Vendors would be able to reliable comply with the law.

Minor Update to the Policies of the IAB Europe Transparency & Consent Framework relating to CMPs

IAB Europe has published a minor change affecting the Policies of the IAB Europe Transparency & Consent Framework (“Framework”) on Wednesday, 3 October 2018.

The update exclusively addresses a paragraph under the heading “Working with Vendors” in the “Policies for CMPs”, that could have been understood as requiring CMPs to work exclusively with Vendors who participate in the Framework.

Such an exclusivity paragraph is inconsistent with the “Policies for Interacting with Users”, which stipulate that the UI must prominently distinguish between Framework participants and others and avoid confusing or misleading users about the Framework participation of any of the disclosed parties.

To resolve this inconsistency and address confusion it has caused, IAB Europe deleted the exclusivity language under the heading “Working with Vendors” in the “Policies for CMPs”, and replaced it with the following wording:

“If a CMP works with Vendors who are not registered with the MO, the CMP must make it possible for users to distinguish between Vendors registered with the Framework, and those who are not. CMPs must not mislead others as to the Framework participation of any of the Vendors who are not registered with the MO.”

No other changes have been made to the Policies at this time. The new Policies Version 2018-10-03.2a replace the previous Version 2018-04-25.2.