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.
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.
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.
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.
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.
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.
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).
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/
It isn’t a requirement to store the consent string on consensus.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.