Adtech and Real-Time Bidding under European Data Protection Law

Abstract

This article discusses the troubled relationship between contemporary advertising technology (adtech) systems, in particular systems of real-time bidding (RTB, also known as programmatic advertising) underpinning much behavioral targeting on the web and through mobile applications. This article analyzes the extent to which practices of RTB are compatible with the requirements regarding a legal basis for processing, transparency, and security in European data protection law.

We first introduce the technologies at play through explaining and analyzing the systems deployed online today. Following that, we turn to the law. Rather than analyze RTB against every provision of the General Data Protection Regulation (GDPR), we consider RTB in the context of the GDPR’s requirement of a legal basis for processing and the GDPR’s transparency and security requirements. We show, first, that the GDPR requires prior consent of the internet user for RTB, as other legal bases are not appropriate. Second, we show that it is difficult—and perhaps impossible—for website publishers and RTB companies to meet the GDPR’s transparency requirements. Third, RTB incentivizes insecure data processing. We conclude that, in concept and in practice, RTB is structurally difficult to reconcile with European data protection law. Therefore, intervention by regulators is necessary.

A. Introduction

This article discusses the troubled relationship between EU data protection legislation, encompassing the EU General Data Protection Regulation (GDPR) and ePrivacy instruments, and the infrastructures of contemporary behavioral targeting. Behavioral targeting is the monitoring of online behavior, and the use of this to deliver personalized advertisements. Today, both on the Web and in packaged software, such as mobile apps, a complex, interwoven web of actors and technologies operate in concert to deliver the granular, and often uncanny, tailoring seen today. A main mode of online advertising today is known as real-time bidding (RTB). This article focuses quite simply on the following question: To what extent is real-time bidding compatible with EU data protection and privacy law’s requirements regarding a legal basis for processing, transparency, and security?

Addressing this question requires a synthesis of empirical work in computer science with a careful consideration of the current data protection regime and varying authorities. The answer is consequential, given that a majority of European citizens will have interacted with various RTB systems in recent years, if not in recent weeks or days alone. Section 2 introduces advertising technologies in a historical and technological context. It outlines the technologies and practices underpinning the RTB system. We then turn to the law. We argue that the GDPR generally applies to RTB. We show that the GDPR requires consent of the internet user as a legal basis for real-time bidding practices, while the ePrivacy Directive also requires consent. Next, we show that it would be extremely difficult to make RTB comply with the GDPR’s transparency requirements and security requirements. We briefly discuss the findings before we conclude by calling upon regulators to enforce the GDPR in the RTB sector.

B. Online Advertising, Adtech, and RTB

RTB is a system where pre-determined advertising space, such as a banner advert on a website, or a splash screen in an app, is allocated through an auction process carried out for each requested impression. The creation of markets does not directly engage privacy concerns. Advertising can be envisaged without the use of personal data. Potential advertising space can be auctioned on the basis of generic data which does not individuate a viewer, such as the time of day, the country of internet access, the content of the page the advert is shown on, and so on.¹

In practice however, those participating in auctions for online advertising do not only consider characteristics of the property—for example, the website’s content—but evaluate the personal data of the user. RTB is heavily entwined with individualized tracking and cannot be properly understood without it.² We therefore explain the underlying infrastructure, before elaborating further on the functioning of the RTB system.

I. Online Tracking

Tracking infrastructure can be split into two main types, explicit tracking and inferred tracking.³ These terms refer to the role of the user, their device, and unique identifiers, in the tracking process.

1. Explicit Tracking

Explicit tracking occurs when a user is identified by a tracking mechanism that assigns a unique identifier per user. A user’s device may emit a unique identifier for functional reasons which can be used to track them, or a tracking infrastructure may have caused the device to store and emit an identifier on request.

On the Web, cookies are one of the main methods used in explicit tracking. Cookies were invented in 1994 to provide an ability to retain state to the stateless HTTP protocol, and “[give] the Web a memory.”⁴ They consist of text, often encoded or even encrypted,⁵ that can be placed by a server in a user’s browser and examined later by a server. Cookies have a range of useful functions; without some ability for a website to store information in a browser, login status, for example, could not be reliably remembered the next time a user visits a site. It would also be challenging for e-commerce applications, such as retaining items in a basket online. However, the seamless and silent nature of cookies has also meant cookies can be used in ways that go beyond users’ expectations.

In the early days of the Internet—when nobody knew which users were dogs⁶—content on webpages usually only came from a single source. Netscape Navigator 2.0 introduced the function of rendering two HTML files in a single browsing window in 1996 through frames, and so security features were needed to determine which frame could access which information in the browser. The Same Origin Policy, broadly put, means that documents in the browser, such as cookies, can only be accessed by servers sharing their protocol, for example, HTTP or HTTPS, domain, and port.⁷ The intention for this was so that if one party places a cookie, another party cannot read it.

Driven by a desire to establish cross-site tracking, the advertising industry sought to circumvent the effects of the Same Origin Policy. Cookies that are not placed by the website publisher itself are often called third-party cookies. Say that somebody visits a website, www.A.com. It may seem that each element on that website comes from A.com. In reality, however, different elements of the website are often sourced from other domains. For example, a website may have a box for advertisements, or for recommended articles elsewhere on the web. In most cases, ads are shown on a website not by the website publisher itself—A, in our example—but by third parties. Those third parties can also place and read their own cookies, third party cookies. The website visitor usually does not see that their browser contacts these different domains; for the website visitor it seems like one website is being loaded from one domain. While a user may only see one URL in the address bar, visiting almost any site now entails querying tens or hundreds of other servers.

Some firms have spread their own tracking code with resounding success: Google calls home with unique identifiers for at least twenty-eight percent of all web page loads, while Facebook does the same for approximately fifteen percent.⁸ The proportion is significantly higher in certain sectors, such as news, compared to others, such as banking. Trackers also differ by country—U.K. users are tracked more in this manner than Chinese web users, for example.⁹

Yet firms with less infrastructure also established means to track users more broadly by using loopholes in the Same Origin Policy to combine the reach of their tracking. The prime mechanism this is carried out is through cookie syncing, also called cookie matching. In its most basic form, this involves a third-party with a cookie (“Tracker1”) making a user’s browser query a second third-party (“Tracker2”) with a URL which includes Tracker1’s identifier.¹⁰ Because the user’s browser is querying Tracker2, Tracker2 is able to look at its own cookies on the site. As the query includes the ID that Tracker1 just saw from its own cookies, this has the effect of enabling Tracker2 to possess both identifiers at once, associating their own cookie ID with Tracker1’s cookie ID. The two organizations can share data through a back-channel server-to-server transfer¹¹ to connect the profiles they have built so far. This cookie syncing significantly widens the scope of tracked activity online by pooling the reach of multiple trackers.¹² Even under conservative estimates of server-to-server transfers—based only on observed cookie syncing—fifty three firms observe more than ninety-one percent of users’ browsing behavior.¹³ This figure is likely an underestimation; a recent study found evidence that as many as twenty-seven percent of advertiser-tracker relationships may be undetectable through cookie syncing analysis.¹⁴

More recently, trackers have sought to evade restrictions on third-party cookies in a number of newer ways. In particular, they have been encouraging sites to edit their Domain Name System (DNS) records to effectively deliver third-party tracker resources from the same domain that is serving the website, making effectively blocking trackers without breaking the website a trickier task. This also creates a range of serious security risks, as first-party cookies often include cookies designed to log a user in to a website, and such configurations can mean that these cookies can be read by and sent to a third party other than the website operator.¹⁵ As a result, the terms “first-party cookies” and “third-party cookies” have less meaning in a legal context; a case-by-case analysis will be required to understand which actors are involved in any particular cookie, as the domain name-based identity of the server laying it may not be the same as the organization utilizing its tracking potential across websites.

On mobile devices, app developers, which are analogous to website publishers, have more freedom to execute arbitrary code. As the Web is accessed through a browser, the browser has power to limit the ways a website can function. In contrast, app developers can specify the way their software works without being required to cede rendering and execution decisions to the browser. Instead, looser limits are applied at the level of the mobile operating system—for example, limiting access to sensors such as the camera or GPS—and through any conditions placed upon apps allowed to be distributed through official channels such as Apple’s App Store and Alphabet’s Play Store, which for most users will be the only way they install custom software.

The fact that app developers have more freedom than Web developers to determine who is able to track individuals means that active tracking, rather than passive tracking, is the main issue in the mobile sphere. Third-party services are integrated in apps for a variety of purposes, including crash reporting, to provide usage or engagement analytics, to integrate agile development methods such as A/B testing, to integrate with other services such as social networks, and to deliver advertising. Almost all of these services, with the exception of advertising services, only operate in the background of applications, and users are in general unable to detect and understand the extent to which the app is communicating with both the developer’s server or third-party servers.

Empirical studies into tracking apps are challenging and are mostly limited to the Android platform due to the inability to examine the innards of the heavily restrictive Apple iOS system. Studies seeking to survey app tracking at scale take a few different approaches.¹⁶ Some researchers intercept traffic from hundreds of thousands of apps which are being either interacted with automatically by bots synthesizing real user input in a sandbox on a server,¹⁷ or by using real user interactions, with traffic captured via user-installed VPNs.¹⁸ One recent study identified 2,121 separate advertising tracking services in apps in the Android ecosystem, which can be grouped by ownership into approximately 292 parent organizations.¹⁹ Another study found that 88.4 percent of apps contained a tracker owned by Alphabet (Google), 42.6 percent by Facebook, 33.9 percent by Twitter, 26.3 percent by Verizon and 22.2 percent by Microsoft.²⁰ Thirty-percent of News apps, twenty-eight percent of Family apps, and twenty-five percent of Gaming & Entertainment apps contain trackers from more than ten distinct tracker companies.²¹

Mobile devices hold a variety of unique identifiers tied to their software and hardware with different levels of permanence, such as the IMEI, IMSI and SIM number, operating system number, phone number, device ID, MAC address, and operating system-specific advertising identifiers.²² Third-party plug-ins have a variety of direct and indirect ways to access these identifiers, and in practice access and transmit a wide variety of them.²³ Such identifiers are also linked through a variety of means to track individuals across different devices, although exactly how this occurs in-the-wild is unclear.²⁴

2. Inferred Tracking

Inferred tracking seeks to identify or profile an individual from observing their digital traces online and re-identifying a user through primarily probabilistic means. Unlike explicit tracking, these approaches are “stateless”—they do not change the behavior of user’s devices, nor store information on them directly. Inferred tracking is therefore substantially more challenging for an individual or device to defend against.

Fingerprinting is a core approach for inferred tracking. Early documentation of fingerprinting was provided by analysis from the Electronic Frontier Foundation’s Panopticlick tool, which uses modern fingerprinting techniques to determine how unique—and therefore how fingerprintable—your browser is.²⁵ Browser fingerprinting is a moving target, as sophisticated techniques can circumvent proxies, reveal the particular version of a browser, and repurpose new Web technologies for fingerprinting as they emerge.²⁶ Research has found evidence of fingerprinting on at least 4.4 to 5.5 percent of top websites, although these should be taken as lower bounds due to the difficult-to-observe nature of fingerprinting techniques.²⁷ These methods interplay with explicit tracking mechanisms—if the user clears their cookies, for example, fingerprinting approaches can be used to re-establish or “respawn” deleted identifiers.²⁸

Inferred tracking also plays an important role in cross-device tracking. Simulated cross-device tracking studies have estimated a significant ability to follow users from their mobiles to their desktops, even if they are not logged in to the same service—for example, if they are connected to the same router. Many companies advertise probabilistic cross-device tracking as a reason to install and use their trackers.²⁹ Despite scholarly interest, the covert, stateless nature of fingerprinting and inferred tracking makes its prevalence, scope, and affect unclear.³⁰

II. RTB and Programmatic Advertising

RTB is a form of programmatic advertising, where advertising placements are determined by algorithmic systems, rather than in human-mediated ways, such as through traditional negotiation and contracts. With RTB, advertisers—or their intermediaries—bid on an automated auction for the chance to target an ad to a specific internet user. RTB is also called audience selling or audience buying.

While early display advertising—the sale of “properties” such as banners, pop-ups or video segments—was largely conducted through manual deals, advertising is now predominately allocated automatically through programmatic methods, of which RTB is the prime system.³¹

RTB is a complicated system, with many different types of players. Below, we give a brief introduction to RTB. The reader might be a tad overwhelmed, but such a reaction is understandable. We return to the complexity and the opaqueness of RTB in section E.

In brief, RTB works as follows—and is illustrated in the companion Figure 1: A website or app publisher has a range of slots that it wishes to sell to advertisers, known in the industry as their “inventory.” Advertisers to fill these slots are sought through one or more supply-side platforms (SSPs) the publisher deals with.³² SSPs are technical intermediaries for publishers to work with complex advertising auction markets called advertising exchanges (AdXs), which serve as auction-houses for RTB. Demand-side platforms (DSPs) are the technical intermediaries that represent advertisers. Such DSPs place bids on AdXs.

Figure 1. Main actors and processes in RTB (diagram by authors).

These DSPs will be given a copy of the bid request, which represents information about the user to whom the advertisement will be delivered. This information varies slightly depending on the specification. On the Web, the contents of this bid request is determined by one of two specifications. The first is Authorized Buyers, a specification determined by Google. The second is OpenRTB/AdCOM, maintained by the technology division of the Interactive Advertising Bureau (IAB), a membership organization of large and small advertising firms ranging from Google, Facebook, and Twitter down to smaller actors.

A bid request contains a broad array of data about an individual, their device and the website there are visiting. Some of the data in Authorized Buyers and OpenRTB bid requests relevant to our regulatory discussion include:

• Site

  • URL of the site being visited

  • Site category or topic

• Device

  • Operating system

  • Browser software and version

  • Device manufacturer and model

  • Mobile provider

  • Screen dimensions

• User

  • Unique identifiers set by vendor and/or buyer.

    • AdX’s unique person identifier, often from their cookie.

    • The DSP’s user identifier, often taken from the cookie of the AdX which has been cookie-synced with a cookie from the DSP’s domain.

  • Year of Birth

  • Gender

  • Interests

  • Metadata reporting on consent provided

  • Geography

  • Longitude and latitude

  • Postal/ZIP code

Bid requests with some or all of this information have the potential to directly target individuals in quite granular ways. However, the economic incentives of an auction mean that DSP with more specific knowledge of individuals will win desirable viewers due to being able to target them more specifically and out-bid other entities. As a consequence, the bid request is not the end of the road. The DSP enlists a final actor, the data management platform (DMP). DSPs send bid requests to DMPs, who enrich them by attempting to identify the user in the request and use a variety of data sources, such as those uploaded by the advertiser, collected from other sources, or bought from data brokers. Cambridge Analytica was a notorious DMP, for example, although companies like Google also run DMPs. The DSP with the highest bid not only wins the right to deliver the ad—through the SSP—to the individual. The DSP also wins the right to cookie sync its own cookies with those from the Adx, thus enabling easier linkage of the data to the user’s profile in the future.³³

C. The GDPR applies to RTB

The GDPR applies to activities that fall within both its material and territorial scope. The GDPR “applies to the processing of personal data wholly or partly by automated means.”³⁴ There are exemptions which self-evidently do not apply in the case of RTB, such as whether the activity if processed “by a natural person in the course of a purely personal or household activity.”³⁵ Therefore the discussion of whether RTB falls within the material scope of the GDPR centers on the GDPR’s definition of personal data, relevant case law, and applicable guidance from the European Data Protection Board, where Data Protection Authorities (DPAs) from the twenty-seven EU Member States cooperate. Processing includes almost everything that can be done with personal data,³⁶ and the definition is so wide that it rarely leads to discussion.

As noted, the main relevant question for material scope is whether RTB involves the use of “personal data.” Personal data means

any information relating to an identified or identifiable natural person (data subject); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.³⁷

Scholarly work already exists explaining why behavioral advertising constitutes personal data processing under the GDPR and will only be summarized here rather than repeated.³⁸ Bid requests contain enough data to identify an individual or a device—in practice devices are now primarily individual and not shared—in a number of ways. They generally contain unique identifiers that relate to the AdX, which in turn are connected to different identifiers set by tracking infrastructure run by numerous adtech vendors. Indeed, the winner of a bid can, by design of the protocol, cookie sync and connect their own set of identifiers to the AdX’s.³⁹ It is additionally a common practice to cookie sync with other tracking firms outside of the RTB protocol.⁴⁰ Furthermore, the bid request contains such a wide array of personal data beyond explicit identifiers that it is likely to be unique in and of itself, and can serve to fingerprint users.⁴¹ This is even more apparent given the way that industry players collate bid request data.⁴²

Even if it requires multiple actors—such as publishers, DSPs, AdXs, and SSPs—to do so, data processing in RTB is designed to identify and profile individual users, and that brings it within the scope of data protection. The Court of Justice of the European Union (CJEU) determined in Breyer ⁴³ that the data necessary to identify a user need not all be in the hands of the same actor,⁴⁴ and that data would not be personal data only if it met the high barrier that “the identification of the data subject was prohibited by law or practically impossible on account of the fact that it requires a disproportionate effort in terms of time, cost, and man-power, so that the risk of identification appears in reality to be insignificant.”⁴⁵ In the case of adtech, that seems unlikely to apply, particularly given the ways that industry players rely on contractual controls between hundreds of entities,⁴⁶ as well as the prevalence of server-to-server data transfers between players which makes connecting data the norm, rather than the exception.⁴⁷

Furthermore, it is worth adding that some courts have utilized a further test to firmly ground such data as that processed in RTB as personal. The Court of Appeal in England and Wales notes that such “browser generated information” serves to “individuate” the user, in the sense they are singled out, proposing a route to determining whether information is personal data that sits alongside the above linkability analysis by the CJEU in Breyer.⁴⁸ The CJEU has not needed to consider this type of argument yet, but it is worth noting that “singling out” has entered EU law in the recitals to the GDPR.⁴⁹

The GDPR therefore applies to RTB. It is not the only regime to do so—the ePrivacy Directive has specific rules for tracking technologies, which we will discuss further in section D.I.4. below.⁵⁰ As the GDPR applies, we must turn to what it requires of those processing personal data to make such activities lawful.

D. Legal basis

In this section, we show that European data protection law requires consent of the internet user as a legal basis for RTB practices.⁵¹

I. The GDPR’s Requirement for a Legal Basis for Processing

Under the Charter of Fundamental Rights of the European Union, processing personal data is only allowed on the basis of the consent of the data subject or another legal basis laid down by law.⁵² The GDPR elaborates, and exhaustively lists six possible legal bases.⁵³ A data controller—an organization using personal data⁵⁴—may only process personal data on the basis of the data subject’s consent, or on one of the other five legal bases. These six legal bases were copied from the 1995 Data Protection Directive with only minor amendments;⁵⁵ the requirement for a legal basis has been a key part of EU data protection law for twenty-five years. For the private sector, three legal bases are most relevant: consent, necessity for contractual performance, and the legitimate interests provision. We discuss each of those legal bases in turn, and show that generally, only the data subject’s consent can provide a legal basis for personal data processing for RTB.

1. Consent

The GDPR states: “Processing shall be lawful only if and to the extent that at least one of the following applies: … [T]he data subject has given consent to the processing of his or her personal data for one or more specific purposes.”⁵⁶ The requirements for valid consent are strict under the GDPR. The GDPR’s consent definition says that consent of the data subject means any freely given, specific, informed, and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.⁵⁷ Article 7, on the conditions for consent, makes the requirements for valid consent even stricter.

The following elements can be deduced from the GDPR’s consent definition: Valid consent requires (i) an indication of wishes, which is (ii) specific and informed, and (iii) freely given. We discuss each element in turn.

1.1. Indication of Wishes

The most important requirement for valid consent is that a data subject gives an unambiguous indication of their wishes by which they, through a statement or by a clear affirmative action, signifies agreement to the processing of personal data.⁵⁸ The GDPR’s preamble gives a non-exhaustive list of examples of how a data subject can give an indication of wishes: “A written statement, including by electronic means, or an oral statement.”⁵⁹ The preamble adds that an indication of wishes “could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data.”⁶⁰

Under the 1995 Data Protection Directive, data controllers sometimes assumed that a data subject consented if he or she failed to object—an opt-out system.⁶¹ However, an opt-out system could generally not lead to a valid indication of wishes and could thus not lead to valid consent under the Data Protection Directive.⁶² The GDPR’s consent definition is more explicit than the Directive’s, as the GDPR requires “a statement or … a clear affirmative action” for valid consent.⁶³ Mere inactivity is not an indication of wishes.

In a case about cookies, the CJEU confirmed in 2019 that the GDPR “expressly precludes ‘silence, pre-ticked boxes, or inactivity’ from constituting consent.”⁶⁴ Other CJEU case law affirms that controllers cannot easily assume consent.⁶⁵ To sum up: Opt-out systems cannot be used to obtain valid consent; consent requires a clear expression of will.

1.2. Specific and Informed

The GDPR’s consent definition also requires that consent be specific and informed.⁶⁶ These two elements are largely overlapping.⁶⁷ Article 7 gives additional requirements. It is not acceptable to hide a consent request in the small print of a contract, privacy notice, or other document. The “request for consent shall be presented in a manner which is clearly distinguishable from the other matters.”⁶⁸ Article 7 also requires that a consent request is presented “in an intelligible and easily accessible form, using clear and plain language.”⁶⁹ Furthermore, consent must be informed to be valid. A consent request must, at a minimum, disclose the controller’s identity, and the processing purpose.⁷⁰

The GDPR’s preamble adds about the specificity requirement: “Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them.”⁷¹

Case law says about the specificity requirement that “consent must be specific, that is to say, connected with a processing operation (or series of processing operations) for precise purposes.”⁷² In the context of cookies, the CJEU says that specific means that consent “must relate specifically to the processing of the data in question.”⁷³ Moreover, the information provided by the controller must ensure that the “user is in a position to be able to determine easily the consequences of any consent he or she might give and ensure that the consent given is well informed.”⁷⁴

1.3. Freely Given

Only freely given—and thus voluntary—consent can be valid. Consent is only freely given if the data subject has a genuine choice. Article 7(4) gives guidance regarding this requirement: “When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.”⁷⁵

In short, a take-it-or-leave-it choice regarding personal data processing can make consent involuntary and thus invalid. A typical example of such a take-it-or-leave-it choice is a tracking wall, a barrier that visitors can only pass if they consent to tracking by third parties. In the spring of 2020, the European Data Protection Board clarified that tracking walls make consent involuntary and therefore invalid: “In order for consent to be freely given, access to services and functionalities must not be made conditional on the consent of a user to the storing of information, or gaining of access to information already stored, in the terminal equipment of a user (so called cookie walls).”⁷⁶

To summarize: Companies can obtain a legal basis for personal data processing if a data subject gives valid consent. In the following two sections, we show that a data controller cannot rely on other legal bases for RTB.

2. Necessity for Contractual Performance

Another legal basis in the GDPR is necessity for contract performance. Sometimes a controller can have a legal basis for processing if the processing is necessary for performing a contract.⁷⁷ In the words of the GDPR, a data controller can have a legal basis for personal data processing if “processing is necessary for the performance of a contract to which the data subject is party ….”⁷⁸ For example, a newspaper publisher does not need to obtain consent to process the name and address of a subscriber, as far as these personal data are required to deliver the newspaper to the subscriber’s home. The personal data is necessary to deliver the newspaper to the subscriber and thus to fulfil the contract.

Can a contract provide a legal basis for personal data processing for RTB? Almost certainly not. For this provision to apply, the processing must be genuinely necessary for performing the contract. CJEU case law has favored the data subject in interpreting necessity narrowly: “As regards the condition relating to the necessity of processing personal data, it should be borne in mind that derogations and limitations in relation to the protection of personal data must apply only in so far as is strictly necessary.”⁷⁹

The necessity requirement is related to proportionality, as confirmed in CJEU case law.⁸⁰ The CJEU has said that “the principle of proportionality requires that [measures] be appropriate for attaining the legitimate objectives pursued … and do not exceed the limits of what is appropriate and necessary in order to achieve those objectives.”⁸¹ In sum, one should not too easily assume that data collection for RTB and targeted advertising is necessary for performing a contract.

Apart from the necessity requirement, there are legal requirements for entering into a contract. It is dubious whether those requirements are met when somebody merely uses a website or an app. From a legal perspective, the main requirement to enter a contract is that both parties want to enter a contract.⁸² To illustrate, the Vienna Sales Convention says that “[a] statement made by or other conduct of the offeree indicating assent to an offer is an acceptance. Silence or inactivity does not in itself amount to acceptance.”⁸³ But somebody who visits a website or uses an app rarely intends the wish to enter a contract about tracking or RTB.⁸⁴

Therefore, in most situations, internet users do not enter a contract with companies about trading personal data for ad targeting against the use of a service. Especially if a company collects or uses information about people without them being aware, it is hard to see how those people could have entered a contract with the company.⁸⁵ Indeed, the European Data Protection Board says that the legal basis of “necessity for contract performance” is not an appropriate legal basis for data processing for behavioral advertising; consent is always required for such advertising.⁸⁶

3. Necessity for the Controller’s Legitimate Interests

Another legal basis that a controller can invoke for personal data processing is the legitimate interests provision.⁸⁷ Roughly summarized, a controller can rely on this provision when personal data processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, and those interests outweigh the data subject’s interests or fundamental rights. In the words of the GDPR:

Processing shall be lawful only if and to the extent that at least one of the following applies: … (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.⁸⁸

The CJEU says that the legitimate interests provision implies three cumulative requirements: “[F]irst, the pursuit of a legitimate interest by the data controller or by the third party … ; second, the need to process personal data for the purposes of the legitimate interests pursued; and third, that the fundamental rights and freedoms of the person concerned by the data protection do not take precedence.”⁸⁹

First, are RTB and targeted advertising legitimate interests? Recital 47 gives “direct marketing purposes” as an example of legitimate interests.⁹⁰ The recital thus gives an argument in favor of accepting RTB and targeted advertising as legitimate interests. Moreover, RTB companies can invoke their “freedom to conduct a business in accordance with Union law and national laws and practices,” as protected by the Charter of Fundamental Rights of the European Union.⁹¹ The Advocate General of the CJEU confirms that online marketing relates to the freedom to conduct a business.⁹² The European Data Protection Board emphasizes, logically, that only lawful practices can form a legitimate interest.⁹³ If RTB brings serious risks for people’s privacy and data protection rights, its lawfulness could be questioned. But for now, let us assume that the controller—a company doing RTB—has some legitimate interest.

The second question is: Is the processing necessary to pursue those interests? As noted in the previous section, the necessity hurdle is difficult to overcome. Whether RTB is necessary is debatable. Suppose that the company’s interest is making money with online advertising. In that case, there are many other ways of online advertising that do not entail much personal data collection. For example, contextual advertising does not require collecting data about people. Contextual advertising is the practice where ads are adapted to the context, or content, of a web page, exploiting the notion that content preferences may reflect consumer preferences.⁹⁴ For instance, ads for local hotels on a website about tourism in Madrid.

However, a company might also argue that it specializes in behavioral advertising or in RTB. A counter argument could be that behavioral advertising is possible without large-scale data collection. Several systems have been developed for, in short, confidential ad targeting.⁹⁵ Already ten years ago, researchers developed Adnostic, a browser plug-in that does not involve sharing one’s browsing behavior with a company. Adnostic builds a profile based on the user’s browsing behavior and uses that profile to target ads—all within the user’s device. Minimal information leaves the user’s device, as the behavioral targeting happens in the user’s browser.⁹⁶ Such techniques are entering practice, such as Google’s Federated Learning of Cohorts (FLoC) system for microtargeting within Chrome.⁹⁷

Seeing that behavioral advertising is possible without sharing much data with companies, one could argue that large-scale data collection for behavioral advertising is disproportionate and thus not necessary. The requirements for necessity are indeed strict. However, DPAs rarely, if ever, follow that line of reasoning, perhaps because it risks prescribing certain means of processing.⁹⁸ Furthermore, current proposals, such as FLoC, require large-scale infrastructural control and coordination, such as shaping a browser and orchestrating a protocol through it, which is not within the power of all data controllers to achieve.⁹⁹ Let us then assume, for argument’s sake, that some companies engaged in RTB can, in some situations, pass this necessity test.

That would bring us to a third question: Do the data subject’s interests outweigh the company’s interests? Few, if any, companies engaged in RTB could overcome this hurdle. The data subject’s interests include the fundamental rights to privacy and data protection.¹⁰⁰ Case law of the European Court of Human Rights confirms that people have a reasonable expectation of privacy regarding their Internet use.¹⁰¹ Moreover, surveys consistently show that people see online tracking and related practices as a privacy invasion.¹⁰²

Indeed, the European Data Protection Board suggests that data controllers cannot rely on the legitimate interests provision for personal data processing for targeted advertising: “[C]onsent should be required, for example, for tracking and profiling for purposes of direct marketing, behavioral advertisement, data-brokering, location-based advertising, or tracking-based digital market research.”¹⁰³ Several authors agree.¹⁰⁴

The ICO confirmed in a 2019 report that “the nature of the processing within RTB makes it impossible to meet the legitimate interests lawful basis requirements.”¹⁰⁵ The DPA adds that “the only lawful basis for ‘business as usual’ RTB processing of personal data is consent (i.e. processing relating to the placing and reading of the cookie and the onward transfer of the bid request).”¹⁰⁶ Regardless of this array of explicit regulatory guidance on the inappropriateness of this lawful basis, empirical research finds that many RTB vendors in Europe still claim legitimate interest as a lawful ground.¹⁰⁷

In conclusion, in almost all cases, the data subject’s consent is the only available legal basis for personal data processing for RTB and behavioral advertising under data protection law. Even in the far-fetched case that a company can rely on another legal basis for RTB, separate EU law still requires the company to ask consent, namely for the cookies and similar technologies. That cookie consent requirement is the topic for the next section.

4. e-Privacy Directive and Consent for Tracking

Apart from the GDPR, the e-Privacy Directive requires consent for the use of tracking cookies and similar technologies. The European e-Privacy Directive says—roughly summarized— that cookies may only be placed after a website visitor has given his or her informed consent, unless those cookies are necessary for communication or to provide a requested service.¹⁰⁸ A website must also ask the visitor consent if third parties—such as advertising networks or social media companies—place cookies on the visitor’s computer via the website.¹⁰⁹

There are two exceptions to this consent rule. First, a website does not need to ask consent if a cookie is placed for the sole purpose of sending communication. For example, if a cookie is needed for the login procedure of an online bank, no consent is required. Second, consent is not required if a cookie is necessary to provide a service requested by the visitor. No consent is therefore required for cookies that are used, for example, for a virtual shopping cart. And no consent is required for a cookie that is placed when a visitor sets his or her language preferences for a website.

For the sake of readability, we speak of cookies, but the e-Privacy Directive applies to many more technologies. The rule applies as soon as a party places information—such as a cookie—on a user’s device or reads information from a user’s device. The rule therefore also clearly applies to, for example, flash cookies—also called local shared objects—and some forms of device fingerprinting.¹¹⁰

Consent in the e-Privacy Directive must be interpreted as consent in the GDPR.¹¹¹ Therefore, consent for cookies must comply with the GDPR’s strict requirements for consent, for instance, regarding sufficient information.

The CJEU adds that the information provided by the company operating cookies “must be clearly comprehensible and sufficiently detailed so as to enable the user to comprehend the functioning of the cookies employed.”¹¹² Moreover, “the information that the service provider must give to a website user includes the duration of the operation of cookies and whether or not third parties may have access to those cookies.”¹¹³ The disclosure “must enable the data subject to be able to determine easily the consequences of any consent he or she might give and ensure that the consent given is well informed.”¹¹⁴

The CJEU confirms that opt-out systems do not lead to valid consent for cookies: “[C]onsent … is not validly constituted if, in the form of cookies, the storage of information or access to information already stored in a website user’s terminal equipment is permitted by way of a pre-checked checkbox which the user must deselect to refuse his or her consent.”¹¹⁵

If somebody gives consent for the placing of a cookie—as required by the e-Privacy Directive,—he or she does not automatically give consent for related personal data processing.¹¹⁶ So even after a company obtained consent for dropping a cookie on someone’s device, the company still needs a legal basis for personal data processing if the company wants to use personal data for RTB or targeted advertising. If a company wants to use a tracking cookie for personal data processing for RTB or targeted advertising, both the privacy’s consent requirement and the GDPR’s requirement for a legal basis apply. In practice, a company could ask for consent for a cookie and consent for personal data processing in one consent request.¹¹⁷

5. Lifting the Ban on Using Sensitive Data

In many cases, there is yet another reason why RTB requires the consent of the data subject. As the UK’s Information Commissioner’s Office (ICO) notes, RTB often concerns the processing of special categories of data, also called sensitive data.¹¹⁸ Special categories of data are data about, for instance, someone’s political opinions, health, or sexual preferences. In principle, the processing of such data is prohibited. The GDPR defines special categories of data as follows: “Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, … data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.¹¹⁹

RTB can lead to the processing of special category data in several situations. For instance, visits to certain websites—like Muslim news or Kosher recipes, for example—can suggest somebody’s likely religion. Visits to certain online newspapers can suggest someone’s political opinion, and visits to certain sites can give an indication of someone’s sexual preferences.

Determining whether special category data is being processed can be a nuanced task under data protection law. At one end of the spectrum, a controller might argue that they never intended to use such categories, nor made any specific variables to capture them, and therefore should be free of the obligations they entail. On the other end, processing of Web browsing data might result in different advertisements for those in groups that the special categories of data represent. Insofar as processing of high-dimensional data such as Web history should be expected to have the potential to reveal latent special category data, there is an argument that it should be treated as such, as were such data to leak, be transferred or misused, it has similar damaging properties to obviously special category data. However, such a view would see special category safeguards—often explicit consent—apply to a huge variety of datasets as, for example, religion may be inferred from names with relatively high accuracy. The challenges in navigating this trade-off are navigated warily by regulators. The ICO in recent guidance appear to indicate that they believe that special category conditions are triggered (i) where the use of a dataset is intended to infer such categories; and (ii) where a proactive assessment, “part of [a controller’s] obligation to implement data protection by design and by default,” reveals that, in practice, a model “learns to use particular combinations of features that are sufficiently revealing of a special category.”¹²⁰

The ban on using special categories of data can only be lifted under certain specific exceptions. For instance, hospitals can process medical data.¹²¹ For adtech and RTB, the only available exception is the data subject’s explicit consent.¹²² Regulators have struggled to distinguish explicit consent from bog-standard GDPR consent. Implicit consent—as a contrast to active consent—is already prohibited under both the GDPR and the previous Data Protection Directive 1995.¹²³ So what is left? The European Data Protection Board leans towards written consent, such as a signed or digitally signed document or statement, or a two-stage process with email verification, but do not provide clarity on the matter.¹²⁴ At the very least, the consent obligations discussed in this article apply in the case where special category data is, or may, be processed.

In conclusion, for several reasons, a company doing RTB can only legally do so after the data subject’s consent. To avoid misunderstanding, we are not arguing that informed consent is a panacea, nor that consent requirements are the best way to regulate RTB and adtech. Under what conditions less consent-focused privacy and data protection law might protect privacy remains an interesting question—albeit one that falls outside the scope of this article.¹²⁵

II. Can RTB Comply?

As we argue that the lawful basis for RTB can only be consent, it is relevant how companies might go about obtaining consent. An important feature of consent is that is has to be established in relation to categories of data processed for a particular purpose by a particular controllership arrangement. So far, we loosely used the word ‘controller’ to refer to organizations using personal data, but we must rectify that sloppiness.

The GDPR is more precise: The controller is the “body which, alone or jointly with others, determines the purposes and means of the processing of personal data.”¹²⁶ If “two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers.”¹²⁷

Lawful bases in general cannot be transmitted between controllers; they must be established by the controller(s) who are undertaking the processing. For example, the CJEU has stated that even where controllers’ processing activities are aligned, such as in cases of joint controllerships, each must establish, justify, and pursue their own legitimate interest in order for processing to be lawful.¹²⁸ For consent, this is doubly true, as consent is only valid if it is informed. The required information must include “at least … the identity of the controller and the purposes of the processing for which the personal data are intended.”¹²⁹ The nature of the consent required has led to a particular institutional innovation in RTB systems—the consent management platform (CMPs).

1. Consent Management Platforms

This understanding is part of the driver behind a recent trend within web tracking—the emergence of CMPs. Using these code libraries, which are embedded within webpages and, less frequently, within apps, a large number of third parties—the industry prefers the term ‘vendors’—simultaneously seek consent from a data subject in one action. Consent management platforms facilitate this single transactional moment, usually through user interface resembling a banner or a barrier. They emerged in early 2018 as the GDPR came into force, with the market characterized by a handful of major players.¹³⁰

The attempt to get simultaneous consent can and does end up with consent sought for hundreds of vendors at once. A recent study used web scraping to look at the five largest CMPs in the field and found a median number of 315 vendors from whom consent is requested at once.¹³¹ At the time of the study in late 2019, the largest CMP by market share, QuantCast, was nearly always configured to request consent for 542 vendors with a single click.¹³² The identity of these vendors changes and fluctuates over time.¹³³

The CMP approach has several problems which result in questions around its legality, which we will discuss below.

2. Inability to Withdraw Consent as Required by Law

CMPs seem to breach the GDPR’s requirement that consent be “as easy to withdraw as to give.”¹³⁴ Let us have a look at the common standard for CMPs across the industry: The Transparency and Consent Framework (the “Framework”) coordinated by the IAB. The IAB is the industry body who coordinate the actors in much of the RTB ecosystem, enabling the processing to be carried out through the standardization, monitoring, and continued negotiation of the OpenRTB protocol. The IAB also seeks to assure DPAs that RTB is compliant with the law through contractually limiting and shaping the means and purposes of processing for actors within the ecosystem using the Framework. The latest version of the Framework is 2.0, and it is this version that is being analyzed here.

The Framework sets up a system whereby CMPs can be automatically queried by vendors embedded on a website to get the current data protection status of a visitor to that page, such as whether they have been disclosed the identity of that vendor, whether they have expressed their consent to that vendor, and similar variables. The idea is that if such a query to the CMP indicates the vendor is permitted to access and place information on the user’s terminal device and process their personal data, the vendor can proceed to do so.

There is a flaw with this system, however. Imagine a user who consents to the processing of personal data of TrackerA and TrackerB on Website1. TrackerA and TrackerB query the CMP embedded on the website, which informs them that consent has been established, and as a consequence, cookies are laid and read from their browser by TrackerA and TrackerB, and personal data that is collected linked to these identifiers is processed server-side. The user later revisits Website1, and altering their settings, refuses tracking by TrackerA and TrackerB. Again, both trackers query the CMP, which this time tells them they are not permitted to read data from the browser, nor permitted to process personal data on the basis of consent. Neither tracker therefore links the user who withdrew consent to the same, original time that user gave it.

Such a scenario does not pose problems in relation to the ePrivacy Directive, as, in accordance with the law, the trackers did not store or access data on the terminal device following the withdrawal of consent. It does, however, create a problem with the GDPR, as despite the consent being withdrawn, both trackers have not had this result actively communicated to them in relation to that user. They continue to—now illegally—process personal data despite the withdrawal of consent by the user.¹³⁵

Another related problem can be observed when the user moves between websites. Assume the user has consented to TrackerA processing data on Website1, but on Website2, refuses consent to TrackerA. Under the Framework, Website2 can store this refusal locally, in its own cookie, rather than updating the global consent string that is stored across websites on a cookie linked to the IAB-managed consensu.org server. As a result, the later refusal of consent elsewhere does not pass across websites. Even if it did, it still suffers from the problem described above where the consent refusal in practice only relates to the accessing and reading of data on the terminal device, rather than the server-side processing in the tracking ecosystem.

The European Data Protection Board notes that “[i]f the withdrawal right does not meet the GDPR requirements, then the consent mechanism of the controller does not comply with the GDPR.”¹³⁶ Consequently, it seems questionable whether the CMP consent mechanism has provided lawful consent since its introduction by the IAB in 2018 in its first Framework.

3. The Impossibility of Global Consent to RTB Infrastructure

The IAB, as part of its coordination function, has put its weight behind a global consent mechanism. Under these proposals, a cookie placed by a CMP via a subdomain of the IAB-controlled consensu.org would contain a global consent signal that a CMP accepts as valid across all websites. There is also the recently introduced notion of an “out-of-band” lawful basis, which supposes the possibility of a tracker to obtain a lawful basis outside of the Framework’s CMP system.¹³⁷

An analysis of the interaction of consent and joint controllership gives reason to question the legality of this arrangement. The CJEU has held that in the context of embedded Web trackers, key technologies for RTB, a webpage will be a joint controller with the entity processing personal data using this tracker.¹³⁸ The predecessor of the European Data Protection Board, the Article 29 Working Party, has said since 2010 that a website publisher and a tracking company are generally joint controllers, if the company operates tracking cookies via that website.¹³⁹

At the time of writing, compliance with the CJEU ruling seems questionable, as companies such as Google still insist they operate independent controllership operations—an interpretation that seems hard to square with the CJEU judgment.¹⁴⁰ Given that the facts specifically concern the technologies and commercial situations of the tracking infrastructures discussed in this article, it seems difficult for companies to question the applicability of the CJEU judgment to online tracking and RTB.

A consequence of the CJEU judgment is that every webpage–tracker combination constitutes a distinct controllership arrangement, even where the tracker company operates across multiple websites in relation to the same data subject. Consent necessary to legitimize this personal data processing—and the interaction with devices under the ePrivacy Directive—relates at least in part to a joint controllership situation. For example, two companies running a research project jointly on the basis of consent could not swap a joint controller out for another, which may not be trusted by the data subject, without re-establishing a lawful basis. If this were possible, it could even be envisaged in stages that a joint controllership arrangement would contain none of the original controllers that established consent in the first instance.

Global consent would hold that a publisher would, instead of collecting consent itself, look to an inherited cookie read by a third-party—the IAB domain consensu.org—and assume that consent as applicable to its own joint controllership operation. This, firstly, would directly contradict the finding of the CJEU in Fashion ID, which stated that “it is for the operator of the website, rather than for the provider of the social plugin, to obtain that consent, because it is the fact that the visitor consults that website that triggers the processing of the personal data.”¹⁴¹ Furthermore, it would be invalid to equate the consent of one joint controllership operation with another, as in the former, the data subject was informed about a different set of controllers. In this new, separate controllership operation, different controller(s) are in play, and consequently the previous consent is not informed in relation to this operation.

Santos, Bielova, and Matte argue—on the basis of the judgments in Deutsche Telekom ¹⁴² and Tele2 and Others ¹⁴³—that consent can be transferred between publishers.¹⁴⁴ They do not elaborate on this argument in detail, but the difference in circumstances and legal context between those judgments and the issue at hand make the argument unconvincing. Both cases relate to a specific aspect of the e-Privacy regime in a telecommunications context where consent is mandatory, relating to whether fresh consent is required to republish the information of a telephone subscriber in a public telephone directory owned by a news organization. The Court leans heavily in Deutsche Telekom on the Advocate General’s opinion. In teleological analysis, the Advocate General notes that a purpose of the public directory elements of the e-Privacy Directive is to ensure the existence of a comprehensive public directory, and that the provisions on transfer of consent must be interpreted in this context such that this purpose is not “severely compromised.”¹⁴⁵ There is no equivalent EU legislation aiming at comprehensive online tracking—indeed, the GDPR specifically highlights online advertising as an example of an application where the “proliferation of actors and the technological complexity of practice” make it hard for data subjects to understand “by whom” data is processed.¹⁴⁶ Taking an opportunity to inform data subjects of this away would appear to go against the specific aims of the law, rather than act in concert with it.

Lastly, it would be unwise for publishers to accept this situation, as they would incur significant liability for invalid consent gathered elsewhere. Global consent IAB cookies can—and are—forged, as the empirical study by Matte, Bielova, and Santos has demonstrated.¹⁴⁷ The publisher accepting global consent would have no proof that consent was ever obtained. The publisher would also be liable as part of a joint controllership operation for a legal action undertaken on the basis of accepting this unverified consent signal, even were it to be theoretically possible to accept as valid. As a recent development, and since this article was initially accepted for publication, the Interactive Advertising Bureau appear to have rolled back their rush towards global consent by deprecating part of the required functionality.¹⁴⁸

4. Too Many Parties for Valid Consent

Modern CMPs operate as to make even “the identity of the controller and the purposes of the processing for which the personal data are intended” too much information to feasibly expect the data subject to be able to read. This is problematic, as consent must be informed—a distinction that is clearer in the French text of the GDPR, which states that consent must be éclairée (enlightened or illuminated) rather than simply informé, which places the emphasis on the mental state of the data subject rather than the act of having provided information, regardless of its eventual use. Not including the time to operate the interface, or to click on nested privacy policies, a recent empirical study estimated that reading the basic data for all vendors would take on average forty minutes per website.¹⁴⁹ This is clearly not conducive to placing the average data subject in an enlightened position. The Court has stated that information “must enable the data subject to be able to determine easily the consequences of any consent” and “ensure that the consent given is well informed.”¹⁵⁰

Moreover, the overarching fairness principle of the GDPR places a focus on creating an enabling environment for autonomous choice and the exercise of data rights, conscious of information asymmetries in the digital environment.¹⁵¹ Clifford, Graef, and Valcke argue that the fairness principle, and its corresponding manifestation in Article 7, “appears to establish a burden of care on controllers regarding their responsibility to ensure data subjects have been informed and understand the provided information.”¹⁵² This is reinforced by the way the EU legislator specified—separately from Article 13 information requirements—the minimal information needed for consent to be informed comprise “at least of the identity of the controller and the purposes of the processing for which the personal data are intended.”¹⁵³ This seems to be designed assuming that this information, at minimum, must be feasible for the data subject to assess before a consent choice.

As a consequence, with the number of vendors the RTB system requires, CMPs cannot be used to obtain valid consent. This view has recently been echoed by the U.K. Competitions and Markets Authority:

[I]t is challenging for intermediaries that do not offer user-facing services to obtain consent. At the extreme, this could mean that third-party intermediaries would need to radically reduce the number of other parties they shared a consumer’s personal data with to a level the consumer could realistically understand so as to give valid consent to targeted personalised advertising.¹⁵⁴

In conclusion, the GDPR and the ePrivacy Directive require consent for RTB. Current practices by companies engaged in RTB rarely, if ever, lead to valid consent. Indeed, it seems questionable whether it is possible at all to obtain valid consent for RTB.

E. Transparency

I. The GDPR’s Transparency Requirements

The first of the six overarching principles of EU data protection law is the lawfulness, fairness, and transparency principle. It says that “[p]ersonal data shall be … processed lawfully, fairly, and in a transparent manner in relation to the data subject.”¹⁵⁵ Case law of the CJEU and the European Court of Human Rights confirms the importance of transparency.¹⁵⁶ Since the 1970s, transparency has been seen as a core principle for data protection law.¹⁵⁷ It has been suggested that mitigating the abuse of information asymmetry is the data protection law’s main goal.¹⁵⁸

Articles 13 and 14 of the GDPR list information that the data controller must give to the data subject to ensure transparency. The data controller can provide the information, for instance, in a privacy notice on a website.¹⁵⁹ The data controller must give this information regardless of the legal basis for processing.¹⁶⁰ The information that is always required includes: The processing purpose,¹⁶¹ “the identity and the contact details of the controller,”¹⁶² and “the recipients or categories of recipients of the personal data, if any.”¹⁶³ Article 12 says that “[t]he controller shall take appropriate measures to provide [such] information to the data subject in a concise, transparent, intelligible, and easily accessible form, using clear and plain language.

The preamble adds that information about personal data processing should be “easily accessible and easy to understand” and “natural persons should be made aware of risks, rules, safeguards and rights in relation to the processing of personal data and how to exercise their rights in relation to such processing.”¹⁶⁴ Recital 58 adds that clear information is especially important in the context of online advertising, where the number of actors and the complicated technology may confuse the data subject:

The principle of transparency requires that any information addressed to the public or to the data subject be concise, easily accessible and easy to understand, and that clear and plain language and, additionally, where appropriate, visualisation be used. Such information could be provided in electronic form, for example, when addressed to the public, through a website. This is of particular relevance in situations where the proliferation of actors and the technological complexity of practice make it difficult for the data subject to know and understand whether, by whom and for what purpose personal data relating to him or her are being collected, such as in the case of online advertising.¹⁶⁵

The European Data Protection Supervisor has also given guidance regarding the GDPR’s transparency requirements.¹⁶⁶

II. Can RTB Comply?

Do current RTB practices comply with the GDPR’s transparency requirements? And if not, would it be theoretically possible for RTB practices comply with the GDPR’s transparency requirements? We suggest that the answers are no in both instances. Currently, all RTB practices seem to be too opaque, and therefore in breach of the GDPR. The ICO notes that “in RTB the privacy information provided often lacks clarity and does not give individuals an appropriate picture of what happens to their data.”¹⁶⁷ More worryingly, it seems almost impossible to make RTB comply with the GDPR’s transparency requirements.

We start with the clearest transparency requirements of the GDPR. As noted, the controller must always provide “the identity and the contact details of the controller.”¹⁶⁸ We recall that website publishers and cooperating RTB companies are joint controllers. If somebody visits a website, the publisher must tell that web user the identity of each joint controller—hence, of each company engaged in RTB concerning that website visit. However, with RTB it is often impossible for the website publisher to predict who will win an auction. Therefore, the publisher does not know in advance which companies—such as advertising networks—will show ads on the site. Neither does the publisher know which companies will collect data via the site.

Indeed, the IAB confirms that it is impossible to tell website visitors in advance which companies will collect his or her data in an RTB scenario. The IAB sent a lobbying document to the European Commission, outlining why the IAB thinks that proposals for a new ePrivacy Regulation—that is supposed to replace the ePrivacy Directive—would mean the end of RTB. The document became public after a freedom of information request.¹⁶⁹ The IAB writes: “

As it is technically impossible for the user to have prior information about every data controller involved in a real-time bidding (RTB) scenario, programmatic trading, the area of fastest growth in digital advertising spend, would seem, at least prima facie, to be incompatible with consent under GDPR.”¹⁷⁰

Sometimes, website publishers were surprised themselves about which parties were present on their sites. The chairman of the US Association of Online Publishers said, “As a publisher we feel we’ve been raided by the ad industry. We’ve done site audits and been flabbergasted by how many third-party cookies have been dropped on our site by commercial partners—they were stealing our data.”¹⁷¹

In sum, currently, it appears that a website publisher who partners with RTB companies cannot inform visitors about who will collect data about them. Moreover, it appears that it is impossible to inform website visitors about the identity of RTB companies who will collect visitors’ data. As noted previously, companies engaged in RTB through a website are generally joint controllers with the website publisher.¹⁷² If the website publisher cannot tell the website visitor the identity of the joint controllers, the publisher cannot comply with the GDPR’s requirement to provide “the identity and the contact details of the controller.”¹⁷³

“Given the complexity and opacity of the RTB ecosystem,” notes the ICO, “organizations cannot always provide the information required, particularly as they sometimes do not know with whom the data will be shared.”¹⁷⁴ The ICO further notes that “RTB also involves the creation and sharing of user profiles within an ecosystem comprising thousands of organizations.”¹⁷⁵

But suppose that one doubts whether all RTB partners must indeed be seen as a joint controller; would such an interpretation make a difference? Probably not. The GDPR requires each controller to tell the data subject “the recipients or categories of recipients of the personal data, if any.”¹⁷⁶ If an RTB company cooperates with a website publisher, but should not be seen as a joint controller, the company is a recipient.¹⁷⁷ Following the same logic as above, the publisher cannot tell the data subject who the recipients are, as the publisher does not know in advance who will receive data about the web user. Could a publisher tell the data subject merely the categories of recipients?¹⁷⁸ A publisher might argue that it could comply by saying something like: “We may share your personal data with advertising networks, supply-side platforms, supply-side platforms, and advertising exchanges.” It is unlikely that such a statement would comply with the GDPR. As noted, controllers must provide information in a “transparent, intelligible and easily accessible form, using clear and plain language.”¹⁷⁹ Further, the GDPR’s preamble says that user-friendly information is particularly important “in situations where the proliferation of actors and the technological complexity of practice make it difficult for the data subject to know and understand whether, by whom and for what purpose personal data relating to him or her are being collected, such as in the case of online advertising.”¹⁸⁰ Presumably, most website visitors do not know what SSPs are, and do not understand what RTB entails. Indeed, a study on RTB commissioned by the ICO and Ofcom on how users’ perceptions of the acceptability of RTB advertising online changed after it was briefly explained to them how it worked. Acceptability initially stood at 63% pre-explanation yet fell to only thirty-six percent after an explanation was provided.¹⁸¹

In theory, a publisher could set up a system in which the publisher cooperates with only five companies for displaying ads. In theory, an RTB-like system could be developed, in which those five companies compete in an automated auction. In such a situation, the website publisher could tell the visitor which five companies could collect data about the visitor. Assuming that the publisher can explain for which purposes those companies process the personal data, such a system could perhaps comply with the GDPR’s transparency requirements. But for the moment, we are not in this situation.

All in all, it appears that website publishers and companies engaged in RTB generally do not comply with the GDPR’s transparency requirements. Moreover, complying with the GDPR’s transparency requirements would only be possible if changes were made to RTB practices. Such changes would have to limit, dramatically, the number or parties involved in RTB.

F. Security

I. The GDPR’s Security Requirements

The GDPR’s integrity and confidentiality principle could also have been called the security principle. It obliges data controllers to ensure appropriate security for personal data, “including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures.”¹⁸² Since the early 1970s, data protection laws emphasize the importance of security and confidentiality of data.¹⁸³ The CJEU has suggested that security is part of the essence of the fundamental right to the protection of personal data.¹⁸⁴

The GDPR does not require absolute security; the level of security must be “appropriate.”¹⁸⁵ When assessing which level of security is appropriate, controllers and processors should consider “the state of the art, the costs of implementation and the nature, scope, context, and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons.”¹⁸⁶ When assessing the appropriate level of security, the GDPR accounts in particular for “the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data transmitted, stored or otherwise processed.”¹⁸⁷ Costs may also be considered when deciding what level of security is appropriate.¹⁸⁸

CJEU case law also gives some guidance on what should be considered when deciding how much security must be ensured.¹⁸⁹ The CJEU mentions a number of factors to consider when assessing which level of security is appropriate: (i) The quantity of personal data; (ii) the data’s sensitivity; and (iii) the risks. The CJEU suggests that a higher level of security is needed “where personal data is subjected to automatic processing;” and “where there is a significant risk of unlawful access to that data.”¹⁹⁰

II. Can RTB Comply?

Can RTB companies comply with the GDPR’s security requirements? For several reasons, the security requirements for RTB are high. We apply the CJEU’s elements to assess what level of security is needed.

First, RTB concerns personal data of millions of people. As the ICO notes, “Thousands of organizations are processing billions of bid requests in the UK each week with—at best— inconsistent application of adequate technical and organizational measures to secure the data in transit and at rest.”¹⁹¹

Second, the data can be sensitive. For instance, the data can show which websites people visit and when. Case law of the European Court of Human Rights confirms that people have a reasonable expectation of privacy regarding their internet use,¹⁹² and that “information derived from the monitoring of a person’s internet use” is covered by the right to private life in article 8 of the European Convention on Human Rights.¹⁹³ As noted, someone’s website visits may even suggest special categories of data, suggesting one’s medical condition, political opinion, or religion, for example.¹⁹⁴

Moreover, RTB usually involves storing or accessing cookies—or similar files—on the user’s device, such as a computer or smart phone. The CJEU says that the right to privacy protects the contents of people’s devices: “[A]ny information stored in the terminal equipment of users of electronic communications networks [is] part of the private sphere of the users requiring protection under the European Convention for the Protection of Human Rights and Fundamental Freedoms.”¹⁹⁵

Third, the risks are high. One risk is data leakage. Another risk is that bad actors publish ads, distributed through RTB, to spread malware. Indeed, there are several examples of ads spreading malware, ads that were placed on well-known websites. In sum, the legal security requirements are high in the context of RTB.

Fourth, RTB concerns automated processing, which, according to the CJEU, is a factor that calls for higher security.¹⁹⁶ Fifth, there is a risk of unlawful access to the data. The adtech industry, let alone the data subject, has hardly any control about what happens to people’s data during RTB. As the ICO notes in a report on RTB:

The nature of the processing is what leads to the risk of ‘data leakage’, which is where data is either unintentionally shared or used in unintended ways. Multiple parties receive information about a user, but only one will ‘win’ the auction to serve that user an advert. There are no guarantees or technical controls about the processing of personal data by other parties, e.g. retention, security etc. In essence, once data is out of the hands of one party, essentially that party has no way to guarantee that the data will remain subject to appropriate protection and controls.¹⁹⁷

Many RTB companies could argue, however, that they implement at least one security measure. The GDPR says that controllers—and processors—must implement security measures and gives four examples of possible measures.¹⁹⁸ One of the examples is pseudonymization. If a company processes data about individuals but does not know their names, the company can reasonably argue that it only processes pseudonymous data.¹⁹⁹ However, merely pseudonymizing data is not sufficient to comply with the GDPR’s security requirements. As the ICO concludes about RTB, “[i]ndividuals have no guarantees about the security of their personal data within the ecosystem.”²⁰⁰ In sum, currently, most RTB practices are breaching three core GDPR requirements, namely the requirements for a legal basis, transparency, and security.

G. Discussion

So far, this article focused on positive law: Asking what the law says. We showed that RTB breaches several aspects of the European data protection law. Now we take a step back and explore whether the law makes sense.

In theory, two scenarios are possible. In scenario A, many companies engaged in RTB breach the GDPR. RTB practices are wrong, and the law is right.

In scenario B, RTB illustrates drafting mistakes in the GDPR. In other words, the law is wrong and RTB practices are right. In this scenario, the EU forgot to pay sufficient attention to the adtech industry while drafting the GDPR and adopted rules—the requirements for a legal basis, transparency, and security—that are outdated or otherwise wrong.

In our opinion, we find ourselves in scenario A. Each of the three rules discussed in this article—the requirements for a legal basis, transparency, and security—make sense. For instance, the requirement of a legal basis for processing has been part of EU data protection law for twenty-five years. Apart from the that, the requirement is included in the Charter of Fundamental Rights of the European Union, so there is no serious chance that the requirement is abolished.

RTB companies might try to argue that they should be able to rely on the legitimate interests provision rather than on consent. As explained in section D above, however, we think that argument will not work. In an earlier paper, one of us showed that under the 1995 Data Protection Directive, behavioral advertising can only be based on the legal basis consent.²⁰¹ If our claim back then was correct, surely RTB can only be based on consent. RTB is generally riskier and more privacy-invasive than behavioral advertising. Therefore, a claim that RTB can be based on the legitimate interests provision is even more implausible than a claim that behavioral advertising can be grounded on that legal basis.

Is the GDPR’s transparency requirement unreasonable? Again, we think not. With good reason, the requirement of transparency regarding personal data usage has been a staple of data protection law since the 1970s. Data protection law aims, among other things, to impede abuse of information asymmetry. Some RTB companies might claim that while transparency in general is a laudable goal, the requirements as specified in the GDPR are too burdensome. We saw that the GDPR requires data controllers to tell their identity to data subjects.²⁰² In many RTB scenarios, website publishers cannot tell which RTB companies will collect or use data about the website visitors. However, it seems unwise to abolish the requirement that data controllers must disclose their identity. Apart from that, it seems implausible that the EU would abolish that rule in a revision of the GDPR.

Lastly, are the GDPR’s security requirements unreasonable? Again, we think not. Data security has been a core tenet of data protection law since the 1970s, and rightly so. It would be ill-advised to abolish or lower the GDPR’s security requirements. Apart from that, it is unlikely that the EU would do so. In sum, in our opinion, the non-compliance of RTB with the GDPR is not the fault of the GDPR.

As an aside, RTB companies should not have been surprised that their practices run afoul of the GDPR. The requirements for a legal basis, transparency, and security were included in the 1995 Data Protection Directive too. So, also under the old regime, any data protection lawyer could have told RTB companies that they were on thin ice from a compliance perspective.

I. Enforcement

How is it possible that such a large breach of the GDPR exists? We briefly highlight a few possible explanations. The compliance deficit in the RTB sector can be largely explained by an enforcement deficit. DPAs have hardly enforced the law in this sector. True, there are exceptions. For instance, the French DPA has given a fine of fifty million euros to Google for not properly explaining what it does with people’s personal data.²⁰³ Nevertheless, enforcement against RTB companies is rare. Why is there a lack of enforcement? We suggest a few possibilities.

First, DPAs are understaffed and overwhelmed. The GDPR applies to uncountable situations in which personal data are used, and DPAs are supposed to oversee compliance in many sectors.

Second, when the 1995 Data Protection Directive still applied—until May 2018—there was more ambiguity about several data protection rules. For instance, RTB companies could— back then—try to argue that the nameless, pseudonymous, data they used fell outside the scope of data protection law. Similarly, RTB companies could have tried to argue that opt-out systems could be used for consent. Such arguments would not have been convincing, but the old rules were vaguer than the GDPR’s. Perhaps some DPAs were hesitant to impose sanctions in cases that were likely to lead to long and costly litigation. Several players in the RTB sector have deep pockets and can afford lengthy litigation.

Third, until the GDPR was applicable, many DPAs did not have the power to impose serious fines. Therefore, some companies may have decided that it was rational to make profits in breach of data protection law—after all, the chance of enforcement was low, as was the maximum fine. Alternatively, DPAs may have thought that investigating this complicated sector was not worth the effort.

Fourth, some RTB companies may be established outside Europe, which makes enforcement harder. The GDPR does often apply to companies established outside the EU, but nevertheless, enforcement may be harder than enforcement against a company established in the EU.

Fifth, some companies engaged in RTB are formally established in Ireland. The DPA in Ireland, however, is understaffed and the Irish DPA is sometimes accused of preferring a light touch approach over hard enforcement. Some commentators speak of the “Ireland loophole” in EU data protection law.²⁰⁴

Sixth, the GDPR is applicable since May 2018, so perhaps it should not be too much of a surprise if certain sectors are not fully compliant yet.

Seventh, the RTB ecosystem has been left to illegality for so long, it has formed a large, interwoven system that is difficult to regulate using the toolbox of data protection. Data protection legislation draws its heritage from the regulation of databanks, where the controller was clear. In the RTB environment, it is unclear that removing or applying sanctions to any one actor would drive the system into a different state, given the reinforcing effects of the current structure on data collection and sharing practices. Any DPA must act at scale—potentially in relation to many actors at once—which brings daunting issues of capacity, both inside the regulator and in relation to a slow justice system, given the likelihood of appeals in such existential cases for the industry.

While such factors might help to explain the lack of enforcement, the situation is not acceptable. In the long term, alternative business models are needed online to fund journalism, websites, and other services. In the short term, enforcement action must be taken for the sake of the entire legal regime. We note further that some commentators argue that the advertising industry online is unreliable and risks collapse²⁰⁵—something which perhaps speaks to the role of data protection principles more broadly, such as accuracy, and the role of data protection in supporting many rights and freedoms online.

DPAs do not have to enforce the law against all companies engaged in RTB. A couple of serious fines against a couple of companies may already help compliance. If one company gets fined, others see that non-compliance can be costly. In many sectors, compliance improved dramatically with data protection law, because the GDPR—unlike the previous law—enabled serious fines. But if DPAs continue non-enforcement, many companies—including those in other sectors—might think that they can break the law with impunity. Some companies may choose to break the law if the expected profit from breaking the law is higher than the chance of being fined multiplied by the expected fine. Therefore, the possibility of high fines is not enough. There must be a credible chance of enforcement.

Without enforcement, data protection law risks significant inconsistencies. To take just one, allowing the field of online advertising to get by with significantly problematic practices of consent might have knock-on effects on other sectors who see poor consent practices as legitimate. As a horizontal instrument, enforcement in all areas of the GDPR interact through both regulatory practice and case-law development. Failing to remedy concerns with adtech creates serious risks to the fundamental right of data protection in its entirety. As Lynskey states, “the alternative [is] that data protection becomes part of the problem—a legitimizing framework for exploitative processing practice.”²⁰⁶

II. ePrivacy Regulation

The EU has debated additional rules for privacy on the internet, including rules for the adtech sector. In 2017, the European Commission presented a proposal for an ePrivacy Regulation, which should replace the ePrivacy Directive. Especially after amendments by the European Parliament, the proposed ePrivacy Regulation included promising ideas to regulate adtech. For instance, the Parliament suggested to make compliance with Do Not Track and similar signals obligatory for all parties. In such a scenario, people could choose a “do not track me” setting once, in their computer browser, on their phone, or on another device.²⁰⁷ Through this mechanism, people would not have to give or withhold consent to many different consent requests. But at the moment, it is unclear whether, when, and in what form an ePrivacy Regulation will be adopted—something made more challenging by its close connection to the ongoing and parallel data protection enforcement saga in the area of data retention.²⁰⁸

H. Conclusion

In conclusion, we assessed whether adtech and real-time bidding (RTB) complies with three rules from the GDPR: the requirements for a legal basis, transparency, and security. We showed that for each of the requirements, most RTB practices do not comply. Indeed, it seems close to impossible to make RTB comply.

First, the EU Charter of Fundamental Rights and the GDPR require data controllers, organizations that use personal data, to have a legal basis, such as consent, for that data use. We showed that in virtually all situations, the only available legal basis for RTB is the data subject’s prior consent. Moreover, the ePrivacy Directive requires consent for cookies and similar tracking techniques. In practice, RTB companies rarely obtain valid consent. We also showed that it is hard for companies to obtain valid informed consent for RTB. One of the problems is that it is difficult for companies to explain to internet users what will happen to their data in an RTB scenario.

Second, the GDPR requires that data controllers are transparent about what will happen to the data subject’s data, regardless of they want to obtain the data subject’s consent. Controllers must provide clear, plain, and intelligible information. Here, data controllers run into similar problems as under the requirements for informed consent. The data controller must disclose, among other things, its identity to the data subject. If a website publisher cooperates with RTB companies, CJEU case law shows that those companies must be seen as joint controllers. The website publisher must also disclose the identity of all the RTB partners. However, with RTB, a website publisher often does not know in advance who will collect data on its site. The publisher thus cannot disclose the identities of the joint controllers to website visitors. More generally, it seems doubtful whether publishers can ever explain RTB to visitors.

Third, the GDPR requires appropriate security for personal data processing, including protection against unauthorized or unlawful processing. Appropriate security is extra important, as RTB concerns intimate data about millions of people. It seems doubtful whether RTB companies could meet de GDPR’s security requirements.

In sum, RTB is difficult to reconcile with core tenets of the GDPR. We call upon DPAs to enforce the GDPR in the adtech sector.

I. Afterword

During typesetting of this article, in February 2022, the Belgian DPA handed down a decision, supported by the EDPB, concerning the Transparency and Consent Framework, the name for the mechanism IAB Europe design and promote which aims at bringing RTB into compliance with the GDPR.²⁰⁹ In this decision, the DPA explicitly, and on occasion with reference to this article, agrees with many of the points raised here, including around impossibility of relying on legitimate interest; the inability to consent to so many actors; inability to secure data; and the inability to withdraw consent.²¹⁰ Several other DPAs, including the Dutch and Danish authorities, have acknowledged the decision in press releases, indicating that further national enforcement around actors in real-time bidding may soon follow.²¹¹ IAB Europe states it intends to appeal the decision.²¹²