Draft Guidelines on the scope of “cookie” rules: EDPB’s expansive interpretation could change the digital landscape

Written By

alex dixie Module
Alex Dixie

Partner
UK

I am a commercial partner and head up the adtech practice working for brands, agencies and tech providers. With a focus on advertising within the broader media, entertainment and sports and technology and communications sectors, I am based in London.

katerina tassi Module
Katerina Tassi

Senior Associate
UK

I am an associate in our London Privacy and Data Protection Group, advising organisations on UK and EU data protection law, including GDPR and ePrivacy rules.

On 14 November 2023, the EDPB issued draft guidelines on the technical scope of Art. 5(3) ePrivacy Directive (ePD). This is the provision in the ePD that regulates the use of cookies and similar tracking technologies. These rules were last revised in 2009 and since then the technological solutions used for online tracking have evolved, making it unclear to what extent certain solutions would fall under the scope of Art. 5(3) ePD. The draft guidelines aim to address this uncertainty and delve into the technical aspects of Art. 5(3) in order to delineate its scope.

The draft guidelines do not examine the requirement for consent and the consent exemptions established under Art. 5(3) – rather, they focus on its material scope.

Article 5(3) ePD applies to “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or a user”: the draft guidelines analyse each of these elements in turn. The EDPB looks at these elements in light of the scope of the ePD and Recital 24, which establishes that the terminal equipment forms part of an individual’s private sphere and the use of tracking technologies would intrude individuals’ privacy. The EDPB’s interpretation on the scope of Art. 5(3) is broad – this is not surprising. What was though perhaps less expected is that at some points the EDPB seems to follow an overly expansive interpretation, which could have far-reaching results (for example, regarding the notion of “gaining access to information already stored”).

Information

The EDPB reiterates that Art. 5(3) ePD does not apply only to personal data, but it covers any information stored in or being accessed from a terminal equipment – this is a well established position that has previously been recognised by the EDPB’s predecessor, the Article 29 Working Party (‘WP29’). The EDPB further clarifies that it is not a requirement for the application of Art. 5(3) that the information was stored by the same person who is gaining access it to it: it could be stored by another external party, the user, the manufacturer or any other person.

Terminal equipment

The EDPB directs to the legal definition of the term under the ePD. Based on this definition, the EDPB takes the view that a device would fall outside the scope of Article 5(3) if it acts solely as a communication relay – i.e. when it is not an endpoint of communication and only conveys information without performing any modification to it. At the same time, the EDPB recognises that multiple pieces of hardware may together form a terminal equipment (for example, connected devices). The draft guidelines further note that Art. 5(3) covers a terminal equipment associated with a user or subscriber: the latter may own or rent or otherwise have been provided with the terminal equipment, or multiple users or subscribers may share the same terminal equipment in the context of multiple communications (e.g. connected cars). This comment brings up known questions on how consent rules are to be applied in such instance where multiple subscribers or users use the same terminal equipment, which unfortunately the guidelines do not address.

Electronic communications network

Since the ePD applies to “the provision of publicly available electronic communications services in public communications networks” (Art. 3 ePD), the draft guidelines also examine the notion of electronic communications network and refer to the definition of the term in the European Electronic Communications Code (which is posterior to the ePD). In essence, the term covers any network system that allows transmission of electronic signals between its nodes, regardless of the equipment or protocol user. The EDPB notes that this concept does not depend on the way the network is managed or deployed: it could be managed by one operator, a group of operators or none; also, it could cover ad-hoc networks where a terminal equipment may dynamically join or leave a mesh of other terminal equipment using short range transmission protocol. Similarly, the number of terminal equipment present in the network at any time is not material: for example, some networking schemes rely on asynchronous information propagation to present peers in the network and can at some point have as little as two peers communicating – this will still be covered by Art. 5(3) as long as the network protocol allows for further inclusion of peers. The EDPB further clarifies that the fact that the network is limited to a subset of the public (for example, subscribers subject to eligibility conditions) does not make such network private.

Gaining of access

The EDPB reiterates here the objective of the ePD to protect the confidentiality of communications and the integrity of devices and it is in this light that it interprets the notion of gaining access. The EDPB aligns with the previous WP29 position that storage and access do not need to be cumulatively present: there is no requirement that these two operations are performed within the same communication or by the same party.

For the EDPB the criterion is that the accessing entity “wishes to gain access to information” and “actively takes steps” towards this end. This would cover the scenario where the accessing entity proactively sends specific instructions to the terminal equipment in order to receive the targeted information – which is what happens when cookies are used. The EDPB also includes in this concept the case where the accessing entity distributes software on the terminal equipment that will then proactively call an API endpoint over the network – for example, the use of JavaScript code where the accessing entity instructs the user’s browser to send asynchronous requests with the targeted content. The EDPB also considers that Art. 5(3) ePD may still apply in the scenario where the entity instructing the terminal to send back the targeted information and the entity receiving the information are not the same – however, it does not expand on this point and how consent requirements under Art. 5(3) would apply in this instance.

Stored information and storage

The EDPB explains that typically, the information will be stored by instructing software on the terminal equipment to generate specific information. This covers both the use of established protocols, such as browser cookie storage, and the use of customised software, regardless of who created or installed the protocols or software on the terminal.

The EDPB notes that the ePD does not place any upper or lower limit on the length of time that information must persist on a medium to be counted as “stored” or on the type of medium: this would include for example HDD, SSD, flash drives, RAM but also magnetic tape or CPU cache. However, the EDPB does not seem to recognise that the concept of ‘storage’ essentially implies a duration and should not intend to cover for example information generated on the fly purely for caching, or in a transient manner. This is also supported by the use of the wording “information already stored” in the ePD.

The EDPB finally clarifies that “stored information” is not limited only to information that has been stored pursuant to Art. 5(3): it may also cover information that is stored by the subscriber or user, by a manufacturer, or any other party; it could be the result of sensors integrated into the terminal; or could be produced through programs executed on the terminal.

Use cases

The second part of the draft guidelines examines a set of use cases regarding the applicability of Art. 5(3): these confirm the EPDB’s broad interpretation and a number of these use cases will undoubtedly cause concern for companies making use of technologies that previously have been interpreted as falling outside the scope of Art. 5(3).

The EDPB explains that usually network communication requires the use of identifiers – such as MAC or IP addresses of the terminal, session identifiers (SSRC, Websocket identifier) or authentication tokens. Similarly, the communication protocol can include several mechanisms to provide context data (e.g. HTTP header), caching mechanisms, or other functionalities (such as cookies). The EDPB notes that the abuse of those mechanisms (for example, in the context of fingerprinting) can lead to the application of Art. 5(3) ePD. “Abuse” is not defined or further elaborated upon – however, from the surrounding context, it could be interpreted that the EDPB considers any use of these types of information for a purpose outside the strict transmission of content between user and end-point to be “abuse”. Given the breadth of this list, and the prevailing wisdom that a number of these identifiers are inherent properties of the transmission (rather than information stored on or extracted from a device), this appears a significant expansion of the scope of Art. 5(3).

In addition, although the EDPB confirms that using information inside the device by a local application would fall outside the scope of Art. 5(3) ePD, this only applies as long as the information remains on the device and does not leave – if this information (or, importantly, any derivation of this) is accessed through a communications network, then Art. 5(3) ePD may apply.

URL and pixel tracking: the EDPB takes the view that tracking pixels (e.g. embedded in emails to track whether the recipient has opened or read the email) and tracking URLs (where an identifier is appended to the website address visited by the user) are subject to Art. 5(3) on the basis that they store information on the user’s terminal, at the very least through the caching mechanism of the client-side software. Explicitly including site-based (and not user-based or device-based) tracking URLs within the scope of Art. 5(3) ePD is another example of the EDPB’s expansive interpretation, which marks a significant deviation from market practice to date. This means that, for example, affiliate networks which rely on a unique identifier being appended to URLs (which identify the referring website, rather than the individual user) are now subject to Art. 5(3) ePD. The EDPB’s logic here also seems difficult to follow as it relies on the interpretation that “transitional storage” within a cache constitutes “storing” of information in the sense of Art. 5(3) ePD, despite the broad follow-on conclusion from this position being that all information on all web pages also falls within this same argument and hence would be subject to Art. 5(3).

Local processing: local processing involves instructions by software distributed on the user’s terminal, whereby the information produced is then made available to selected actors through client-side API. The EDPB notes that if this information that is made available is being sent back over the network (e.g. to a server), then this operation would constitute ‘gaining access to information stored’ and would fall under Art. 5(3).

Tracking based on IP only: certain advertising solutions rely only on the collection of IP addresses to track the user across multiple domains. The EDPB confirms that this activity will fall under Art. 5(3) only where the IP address originates from the terminal equipment of the subscriber or user. This is not typically the case, but the EDPB provides some examples where this would apply: the static outbound IPv4 originating from a user’s router, or IPV6 addresses (which are partly defined by the host). Based on the EDPB’s analysis of the term “terminal equipment”, all parts of a consumer’s overall network stack should be considered to be included within this definition. As such, although the user’s individual device may not originate the IP address, the user’s router may well have involvement in doing so in the manner noted within the draft guidelines – so there is a risk that collecting IP addresses even from network traffic rather than the device itself would be deemed to be covered by Art. 5(3) ePD. The EDPB acknowledges that there may still be situations where this is not the case but the relevant organisation relying on this would be responsible for ensuring that its operations fall outside the scope of Art. 5(3) – which raises the question of how one would do that and what standard would be required to meet this requirement.

Intermittent and mediated Internet of Things (IoT) reporting: the draft guidelines recognise that the modalities for the collection of information through IoT devices may differ. In principle, IoT devices may be instructed by the manufacturer to always stream the collected information, but locally cache the information first (e.g. until a connection is available); other IoT devices may not have direct internet connection and may be instructed to relay the information first to another device (e.g. smartphone), for example via Bluetooth, which will then send the information to the server. The EDPB finds that Art. 5(3) would apply in both instances, while the fact that the information is streamed or cached for intermittent reporting would not be material. In the second scenario, the transmission to the relay could fall outside Art. 5(3), but as soon as the relay is instructed to send the Information to a remote server, Art. 5(3) would be applicable. This example is slightly at odds with EDPB’s comments regarding whether a relay device constitutes a terminal equipment.

Unique Identifier: the EDPB finally examines the use of ‘unique identifiers’ that are usually derived from persistent personal data (name, email, phone number, etc.) hashed on the user’s device, then collected and shared amongst several controllers to uniquely identify a person. The persistent personal data is generally obtained in the context of authentication or subscription to newsletters. The EDPB seems to follow an overly expansive interpretation of Art. 5(3) in this case as well: it notes that even where the information in question is inputted directly by the user (e.g. contact details), it is stored temporarily on the terminal, and therefore Art. 5(3) is triggered. This risks implying that any information transmitted over the internet by the user would be viewed as subject to Art. 5(3).

Summary/Implications

The draft guidelines provide an interpretation of Art. 5(3) ePD that is, in places, much more expansive than these provisions have been interpreted and applied to date. Although these draft guidelines reaffirm certain key principles (such as “cookies” being only one narrow subset of the technical devices that are subject to Art. 5(3) ePD), the EDPB’s analysis of the concepts of gaining access to and storing of information is very broad, arguably going beyond a strict reading of the law.

This could have a significant impact on current practices for a significant number of companies in the adtech sector and more broadly, and potentially, it may inadvertently impact processing that the EDPB was not necessarily intending to cover in the scope of Art. 5(3) (see for example the use case of unique identifiers). In the adtech sector in particular, any new “cookieless” solutions will have to be carefully (re-)reviewed to ensure that their implementation remains valid under these new scope limits – many of these solutions may not pass the high bar set by the EDPB, especially considering the comments on the IP address use case. Similarly, the inclusion of tracking URLs within the scope of Art. 5(3) could have a significant impact for affiliate network operators and companies who rely on such schemes for revenue generation.

The draft guidelines are open to public consultation until 18 January 2024. If you would like our help in responding to the consultation or understanding what it means for your organisation, please get in touch with our team or reach out to your usual Bird & Bird contact here.

Latest insights

More Insights
Curiosity line pink background

A Deep Dive into China’s Network ID Proposal

Nov 06 2024

Read More
security camera

UK Data Reform: What’s Proposed

Nov 05 2024

Read More
featured image

KSA: Movement in Saudi Arabia’s cybersecurity regulatory regime

4 minutes Nov 04 2024

Read More