Today, IAB Tech Lab and IAB Europe released the Transparency and Consent Framework’s Mobile In-app Specifications as a final version ready for widespread industry adoption. No significant changes were made to the specs in the process of finalization. Tech Lab’s GDPR Mobile Subgroup reviewed the specifications and public comments, considering their own implementation strategies in applying the Framework for in-app.
Early adopters of the mobile specs should be sure that their implementation complies with the final mobile in-app specifications and adheres to the Framework policies.
Released for public comment at the same time earlier this quarter, pubvendors.json will also be finalized in the coming weeks. Pubvendors.json provides granular controls to publishers, allowing them to whitelist vendors, addressing publisher liability concerns, and the ability for publishers to express if they support a vendor using Legitimate Interest as a legal basis. For mobile app inventory use of pubvendors.json, please review the Mobile Guidance for Ads.txt out for public comment until July 6th.
The Transparency and Consent Framework has over 350 registered vendors on the Global Vendor List, over 100 registered CMPs (Consent Management Providers), and potentially tens of thousands of publishers. This rapid adoption will be strengthened with the addition of finalized mobile in-app specifications.
To join the Transparency & Consent Framework, register at: http://register.consensu.org/
A recurring theme in the feedback we are getting from the market on the Transparency & Consent Framework (TCF or “the Framework”) is that it increases the degree of legal liability that publishers bear under EU data protection rules, notably by forcing them to assume full liability for actions by third parties that are beyond their control.
In fact, nothing could be further from the truth. The TCF does not create new rules on liability, nor does it alter existing ones. Those rules are regulated by law and by contract, neither of which is affected by the Framework. The GDPR states that controllers are responsible, and therefore liable, for the processing of personal data they control. A controller is also liable for processing done on its behalf by processors under its control, unless the processor acted against the instructions of the controller.
In addition, liability is regulated through other law, such as tort law, and contract law. In many cases companies will contractually stipulate where liability lies – agreeing amongst themselves how to share it out as part of a normal commercial negotiation. Such contracts are typically concluded between publishers and their third-party partners, something that will not change under the GDPR or the TCF.
The Framework allows publishers to provide consumers transparency into the third-party partners they work with, and to obtain and transmit user consent signals to those partners. Indeed, the reason we need these signals is that third parties must comply with the GDPR’s transparency requirements and, where they are leveraging the consent legal basis, must be able to demonstrate that the user has indeed consented. These things are only possible if there is a signal.
For example, if a publisher lets a third party know that it has not provided transparency into on behalf of a third party, and has not obtained consent on behalf of a third party (maybe because the publisher doesn’t work with that third party), and that third party starts processing personal data regardless, the publisher is now able to demonstrate that it has duly informed the third party of all relevant facts allowing blame and liability to be established clearly with the third party that has engaged in unlawful processing despite better knowledge.
If anything, publishers are in a better position implementing the Framework than they were pre-GDPR. This is because thanks to the audit trail it creates in order to convey information up the delivery chain, the Framework will make it possible to detect what parties were acting without the necessary legal basis, so that liability can be correctly apportioned.
In this Friday’s weekly webinar on IAB Europe’s GDPR Transparency & Consent Framework, we will be discussing the feedback we have received to date from publishers in the public consultation we launched on 8 March. Since the law and the technology to which it applies are complex, some confusion has arisen in relation to what the Framework actually does (and does not do). The webinar should be a good opportunity to respond to what publishers have already told us, and give you the opportunity to ask any other questions you may have “live”.
Here are some examples of the feedback so far:
1.Publishers would like more control over which third parties receive and are able to process the data, including personal data, of their audiences, or what those third parties are able to do with the data
The Framework currently provides publishers with full control over which third parties – whether technology vendors or other data controllers – are disclosed on their websites, and which third parties the publishers solicit user consent for. The Framework also allows publishers (and their users) to prescribe the purposes for which the approved third parties may process data. While in Version 1.0 the Framework is limited to controlling whether a given purpose is toggled on or off for all approved vendors, we are actively exploring technical solutions that would enable purpose-by-vendor controls for publishers and users.
2. Publishers are concerned about legal liability in the event of non-compliance by vendors
The Framework does not change rules on liability, which are defined by the law, including the GDPR, and contractual arrangements. The Framework increases accountability by allowing a publisher to signal relevant information to technology vendors. These signals create an audit trail that provides readily available evidence for identifying non-compliance and responsibility.
3. Publishers want user consent to be specific.
The version of the Framework put out for consultation foresees four different data processing purposes that websites would disclose – and could offer granular control for – accessing a device (ePrivacy Directive); advertising personalisation; analytics; and content personalisation. The proposed approach is a good-faith attempt to balance the conflicting imperatives of transparency and comprehensibility to the consumer, on the one hand, and ease of use for both publisher and user, on the other.
The Framework does not impose on users a take-it-or-leave it choice to accept or reject all third parties disclosed by the publisher, though some publishers may opt to present users with a take-it-or-leave-it choice. Version 1.0 of the Framework will allow users to consent to some, all, or none of the data processing purposes disclosed, and to data processing (for those purposes) by some, all, or none of the third parties disclosed. Moreover, publishers have complete control as to which third parties and which data processing purposes they solicit user consent for.
4. Publishers want to leverage the privileged relationship they have with their audiences
The Framework depends on publishers leveraging their direct relationships with their users to provide transparency and control over the data processing that occurs on their services. Publishers have complete freedom to define the user interfaces on their sites; they may create their own CMPs, or enlist a commercial CMP. The Framework is deliberately not prescriptive in relation to the look and feel and ownership of the user experience.
The Framework empowers publishers to be more transparent and to offer more controls over the data processing undertaken by various technology providers for various purposes when users access a publisher’s content services, but entrusts publishers with deciding how best to leverage its possibilities.
No publisher-user relationship, whether privileged or otherwise, can exist if the production of content cannot be financed in a way that enables the creation of a compelling proposition for users. The Framework has been created to enable publishers and the suppliers of other online services to continue to be able to choose how they finance their activities, and to enable users to choose how they access them.
We’ll keep surfacing the most recurrent queries and any misconceptions over the next few weeks. Above all, we are looking forward to further input from all stakeholders, and an outcome that everyone can converge on as from May.
In our last blog ‘To be or not be’ we presented the duality of the ‘processor’ and ‘controller’ and how the Global Vendor & CMP List (List) could best serve them. Concluding that the primary value of the List is for companies, irrespective of their controller or processor status, to provide transparency into a legal ground for processing personal data and obtain consent in accordance with their own assessment of when that is needed.
This brings us to a second important state of duality that the Framework is tackling – the declaration of the two allowable legal states, under GDPR, of consent and legitimate interest against a purpose.
Participation in the Framework requires that the consent manager provider (CMP) or publisher acting as a CMP must disclose every vendor they wish to work with alongside the purpose and the legal basis of their data processing – they must not signal that consent has been obtained for a vendor and purpose that has not been disclosed to the user. This is not optional but a hard requirement under the policies as well as the law. Publishers who refuse to make disclosures on behalf of a vendor will not be able to work with that vendor under the Framework.
Currently the Framework also supports the disclosure of legitimate interest as a legal basis by a vendor who processes data toward a specific purpose. The publisher or CMP must not attempt to obtain consent for that vendor and purpose combination or make it appear as though a vendor is operating on the basis of consent for that purpose.
When a vendor declares consent as their legal basis against a purpose the publisher or CMP must provide transparency and obtain consent on behalf of the vendor. Therefore, when consent is the legal basis a publisher must pass information about consent (or the lack thereof) to its vendors.
When a vendor declares legitimate interest as their legal basis, it only needs the publisher to provide transparency. Since legitimate interests are claimed, rather than given, no signal about the existence of the legitimate interest is necessary.
BUT currently it is not possible for a publisher or CMP to pass onto a vendor, information that they have provided transparency to the end user that legitimate interest and vendor and purpose is the claimed state for personal data processing. They can only pass to the vendor that they have requested and obtained consent. The only way for a vendor to know that transparency has been provided is when receiving a positive consent signal. If no consent is ‘signalled’ this means that consent has not been given – in the dual world of legitimate interest and consent this could mean that the publisher or CMP have either disclosed a legitimate interest, attempted but failed to obtain consent, or chosen not to work with a vendor. The vendor has no way of knowing which of these cases is causing this transmission and would therefore be conflicted by the signal. However, since under the ePrivacy Directive consent is generally required for storing and/or accessing information on a device, Vendors can rely on their consent status for ePrivacy Directive purposes to infer the remainder of their disclosure status.
However, in future the recently announced Pubvendors.JSON extension to the Framework, which is currently subject to public consultation will address this information transmission conflict by giving publishers a mechanism by which they can inform vendors of the disclosures they have provided on their behalf. As a result, Pubvendors.JSON will allow vendors to declare consent or legitimate interest against purposes provided that they adhere to the Pubvendors.JSON implementation.
Public comment concludes on June 1, 2018. IAB Tech Lab and IAB Europe participants will evaluate and incorporate feedback received and release a final version of each of these specifications. If the dual challenge of legitimate interest and consent resonates with your company then you can adopt the pubvendors.json technology as a beta implementation now, even before the specifications are finalized.
We look forward to hearing from you.
As the adoption of the IAB Europe Transparency & Consent Framework gains momentum we are seeing increasing and exciting levels of engagement from the industry. Our Friday Webinar series on the Framework is attracting over 300 participants each week – sign-up for the next one here.
After each webinar we have received numerous questions about what was covered during the session. They ranged from detailed technical questions about how the Framework works, to queries about the registration process, cookies, consent policy, legal liability, and the user interface.
One of the common questions is the declaration dilemma of processor and controller and the place for each in the Framework. Our List of registered vendors does not differentiate between controller and processor namely because for different processing activities vendors may be controllers and/or processors in the same transaction, or between different transactions. Being on the list doesn’t make a representation about a company’s legal status as a controller/processor in a given situation under the GDPR. The primary value of the List is for companies, irrespective of their controller or processor status, to provide transparency and obtain consent in accordance with their own assessment of when that is needed.
As a controller under GDPR companies are responsible to ensure that transparency is provided and a legal basis established where personal data is processed, which makes the value of the List apparent for controllers.
However, even if you are a processor who may not need to provide transparency into a legal ground for processing personal data, because you are acting on the instruction of and under the legal basis of a controller, you may still need to obtain consent for information storage or access under the ePrivacy Directive and therefore can leverage the Framework exclusively to that end.
Therefore: If you are a vendor and consider that you are a processor that does not need to provide transparency as a legal ground for processing personal data, but still like to obtain consent for the placement of cookies, then the declaration of one of five purposes the Framework enables “information storage and access” (described as ‘the storage of information, or access to information that is already stored, on your device such as advertising identifiers, device identifiers, cookies, and similar technologies’) would be the minimum you should consider.
With this thought in mind do not delay in signing up to the Global Vendor List here and join the growing number of vendors (over 130 at the last count) that to date have joined the Framework. This will ensure that you can continue to maintain and work closely with the publishers that you support now and in the future.
Available for 30-Day Public Comment, New Specs Will Enable Seamless Communication Among Publishers, Buyers, and Vendors on Approved Interactions and GDPR Settings & Provide Mobile In-App Support
BRUSSELS, BELGIUM & NEW YORK, NY (May 2, 2018) – On the heels of releasing the final technical specifications for the Transparency and Consent Framework last week to address user choice and other aspects of compliance with the notice, transparency, and choice requirements set forth in the GDPR (European General Data Protection Regulation), IAB Tech Lab and IAB Europe are introducing an additional supporting tech spec—pubvendors.json (a publisher’s list of vendors)—and the much awaited mobile in-app support for the Framework is also being released for public comment. Both tech specs build upon initial adoption of the Framework, with over 120 vendors registered on the Global Vendor List.
The pubvendors.json tech spec is intended to:
- Provide a standard for publishers to publicly declare the vendors that they work with, and their respective data rights/configuration
- Allow vendors to verify publishers’ GDPR settings and verify/audit Consent Management Provider (CMP) consent strings
- Establish a standard way for publishers to white-list vendors
- Enable publishers to limit purposes and features (consistent with the Framework) on a per-vendor basis
Mobile in-app enables app developers to access and honor the Framework’s consent and legitimate interest mechanisms as a supporting standard to assist with GDPR compliance. CMP API endpoints and app developer local storage are specified, which enables the mechanism of collecting and propagating consent, so third-party vendors can operate in respect of users’ and publishers’ choices. App developers continue to have flexibility in defining user experience for exposing purposes and controls, as per the Framework.
“The feedback from publishers since we launched the public consultation on the first version of the specs for the Transparency and Consent Framework included a couple of strong messages,” noted Townsend Feehan, CEO, IAB Europe. “First, publishers wanted even more control with respect to data processing purposes, notably to be able to authorise different partners to leverage different purposes. Second, they wanted more control over which legal bases their partners could adduce. The pubvendors.json solution is a rapid response to accommodate these requirements.”
“These additional tech specs are a direct reflection of our commitment to the flexibility and adaptability of the Transparency and Consent Framework, to ensure that it meets the needs of publishers and other parties in the supply chain,” said Dennis Buchheim, Senior Vice President and General Manager, IAB Tech Lab. “The continued dominance of apps in mobile environments made supporting tech specs on that front particularly vital, and we’re pleased that our working group moved quickly to close that gap.”
After public comment concludes on June 1, 2018, IAB Tech Lab and IAB Europe participants will evaluate and incorporate feedback received and release a final version of each of these specifications. Companies with urgent transparency goals are invited to adopt the pubvendors.json technology as a beta implementation, even before the specifications are finalized.
To review the proposed pubvendors.json technology specification and the mobile in-app specification, please visit here. Technical feedback can be sent to firstname.lastname@example.org and general feedback can be sent to email@example.com.