Last week, I questioned the European Data Protection Board’s very authority to adopt its newly published Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive (i.e. the so-called “cookie” rule), guidelines according to which those rules should also apply to a broad range of other technologies and information, such as IP addresses, pixels and URLs.
In this second part, I examine the rules themselves and their technical and legal soundness. I already announced that this would be a negative review, because after analysis these guidelines leave the impression that they have been drafted with a particular intent in mind. Technical considerations are vaguely included in order to support a certain legal conclusion, rather than having an objective assessment of technical situations in order to determine which conclusion(s) to be drawn from them. In addition, the actual consequences of these guidelines are completely ignored, which suggests even more clearly that this was driven by a particular objective.
Note: if you are already very familiar with the new guidelines, focus on sections 1 [EDPB’s position] and 4+5 [critique], as sections 2 and 3 explain the EDPB’s reasoning. This is a long article to ensure all of the information is in here, so take your time.
[EDIT: On 16 October 2024, the EDPB published its final, “post-consultation” version. Most of the issues affecting the initial version continue to affect the final version. See comparison here.]
1. The core idea: broadening the concept of “gaining access” to information already stored in a user or subscriber’s terminal equipment
The new guidelines appear to centre around one key idea: the ePrivacy Directive’s “cookie” rule should apply to everything that is in any manner the reflection of an interaction – past or present, active or passive, direct or indirect – with a user’s “terminal equipment”.
The obstacle hindering such an idea is the very text of that “cookie” rule, Article 5(3) the ePrivacy Directive (Art. 5(3) ePD):
“Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user [emphasis mine] is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.”
With cookies, this provision is easy to understand: when a user visits a website, that website includes an instruction for the user’s terminal equipment – for instance, her laptop – telling that laptop (through the user’s web browser) to create a file (a cookie) with a specific name (e.g. “language”) and containing a specific value (e.g. “EN”). Clearly, that information is stored on the laptop.
If the user then visits the website later, the website content being delivered to the laptop includes an instruction asking the user’s terminal equipment to check whether a particular cookie (here, the one named “language”) already exists on the laptop and, if so, what the value is (here, “EN”). Clearly, the website operator is gaining access to information already stored (at that time) on the device.
With some other technologies or bits of information, though, the issue is more complex.
Take URLs, for instance. When a user visits the (fictitious) webpage company.com/pressreleases.php?language=en&orderby=newest, the website operator could look at connections to its server and see that someone (without yet knowing whom exactly) visited the page “pressreleases.php”, and that when visiting that page this user was sending additional information to the server, namely the fact that “language” had a value of “en” and “orderby” had a value of “newest”. Yet that information is not like a cookie – the web server of the website operator does not ask the user’s device to store information on the values for “language” and “orderby”, nor does the web server tell the device to give it access to such information. Instead, that information is transmitted automatically by virtue of the fact that the user is accessing the page. There is no instruction by the server to the device saying “give us this information” – the transmission is automatically initiated by the device, just because of the way the Internet (and more specifically the World Wide Web here) works. There is no instruction “store this information” either.
Yet this is precisely the type of situation that the new guidelines allege should be covered by the “cookie” rule.
I will examine hereunder the EDPB’s precise reasoning (and challenge it), but it is already important to stress that this marks a significant shift in the way that the ePrivacy Directive would be applied and enforced, at least in certain countries.
Indeed, until now, the position in Germany had been entirely the opposite.
On 20 December 2021, the Datenschutzkonferenz (German conference of data protection authorities) published guidance for “telemedia providers” in relation to the German implementation of the cookie rule, in which it stated the following (machine translation):
“An access requires a targeted transmission of browser information that is not initiated by the end user. If only information, such as browser or header information, is processed that is transmitted inevitably or due to (browser) settings of the end device when calling up a telemedia service, this is not to be considered “access to information already stored in the end device”. Examples of this are:
• the public IP address of the terminal device,
• the address of the called website (URL),
• the user agent string with browser and operating system version and
• the set language.
In contrast, it is already considered access to information on the end user’s terminal equipment if the properties of a terminal are actively read – for example, by means of JavaScript code – and transmitted to a server for the creation of a fingerprint.”
This position was also included by the local supervisory authority for the State of Baden-Württemberg in later guidance in March 2022, stating explicitly that (machine translation) “[the German implementation of the cookie rule] only covers “access” to information if this is targeted. Both IP address and user agent are information that the browser automatically sends when a website is called up, without the provider of the [digital] service being able to influence this”.
The new position of the EDPB appears, based on informal contacts, to have been the result of a push by the French authority, the CNIL, and it is unclear what led the German authorities to accept such a common position.
While authorities and companies had previously focussed on the issue of information being actively requested from a terminal’s storage, the EDPB considers in its new guidelines that storage of any duration – even ephemeral – is relevant and even the passive and automatic receipt of information at the user’s initiative should be covered.
2. How does the EDPB justify such a position?
The new guidelines start with a general section explaining the key concepts of Article 5(3) ePD, and then move on to examine specific use cases.
In their general section, they contain a sub-section 2.5 on the “Notion of ‘gaining access’”, in which they state the following:
“Whenever the accessing entity wishes to gain access to information stored in the terminal equipment and actively takes steps towards that end, Article 5(3) ePD would apply. Usually this entails the accessing entity to proactively send specific instructions to the terminal equipment in order to receive back the targeted information” (para. 31).
The guidelines then give a couple of examples:
- “this is the case for cookies, where the accessing entity instructs the terminal equipment to proactively send information on each subsequent HTTP (Hypertext Transfer Protocol) call” (para. 31)
- “That is equally the case when the accessing entity distributes software on the terminal of the user that will then proactively call an API (application programming interface) endpoint over the network.” (para. 32)
- “Additional examples would include JavaScript code, where the accessing entity instructs the browser of the user to send asynchronous requests with the targeted content” (para. 32).
The conclusion? “Such access clearly falls within the scope of Article 5(3) ePD, as the accessing entity explicitly instructs the terminal equipment to send the information.” (para. 32)
The EDPB closes off that sub-section by saying that “one entity may have used protocols that imply the proactive sending of information by the terminal equipment which may be processed by the receiving entity” (para. 33). While that sentence may seem innocuous, it is critical to the EDPB’s argument that e.g. IP addresses and URLs are covered and one of the most questionable statements in the new guidelines, as I will explain later.
In summary, it seems that the EDPB’s position is that because there is an instruction to the terminal equipment to send information, there is access.
Next, in a sub-section 2.6 on the “Notions of ‘Stored Information’ and ‘Storage’”, the EDPB states in summary that “The ePD does not place any upper or lower limit on the length of time that information must persist on a storage medium to be counted as stored, nor is there an upper or lower limit on the amount of information to be stored” (para. 36). One of the important aspects linked to that is that “Typical examples would include hard disc drives (HDD), solid state drives (SSD), flash drives and random-access memory (RAM), but less typical scenarios involving a medium such as magnetic tape or central processing unit (CPU) cache are not excluded from the scope of application” (para. 37). The reference to RAM and CPU cache is not innocent, as it lays the foundation for a broad application of the “cookie” rule.
In summary, if something is kept permanently or temporarily on the user’s device or other terminal equipment, that suffices for there to be “storage” in the meaning of Article 5(3) ePD, according to the EDPB.
3. The EDPB’s position applied to specific use cases
Put the two together, and the second part of the EDPB’s new guidelines, with specific use cases, appears at first glance to make sense:
• Tracking pixels & unique URLs including “identifiers”: These are cases where there is an “identifier” is used to help track activity, such as whether a recipient opens a link in an e-mail or on a website (note: we’re not necessarily talking about personal data – like I mentioned in Part I, there is virtually no reference to “personal data” in these guidelines and we are purely talking about the scope of the ePrivacy Directive). According to the EDPB:“The inclusion of such tracking pixels or tracked links in the content sent to the user constitutes an instruction to the terminal equipment to send back the targeted information (the specified identifier). In the case of dynamically constructed tracking pixels, it is the distribution of the applicative logic (usually a JavaScript code) that constitutes the instruction. As a consequence, it can be considered that the collection of the identifiers provided by tracking pixels and tracked URL do constitute a ‘gaining of access’ in the meaning of Article 5(3) ePD and thus the latter is applicable to that step as well.” (para. 51)
• “Local processing” – i.e. the case where the user’s device is carrying out a computation or other operation – can be “instructed by the entity producing the client-side code distributed on the user terminal” and then any dispatch of that information to even a third party would be “gaining of access [by that third party] to information already stored” (para. 53). Given the EDPB’s position on RAM and CPU cache and the fact that the “instructing party” can be just a random third party such as the developer or implementer of a communication protocol, this position is consistent with the principles set out in the first part of the EDPB’s guidelines.
• As mentioned above, IP addresses are sent automatically as part of the way in which communications take place over the Internet. Again, because of the EDPB’s position that the “instructing party” can be the developer or implementer of a communication protocol, the EDPB’s idea that IP addresses – which are known to the router, which forms part of the terminal equipment, even if they are not stored on the user’s actual device (such as a laptop or smartphone) – are in scope of Article 5(3) ePD seems consistent. After all, following that logic, the instruction to include the IP address within a specific layer of the communication to the server comes well before the actual sending of the information.
• “Intermittent and mediated IoT reporting”: the new guidelines contain a sub-section on Internet-of-Things / connected devices, saying that where information is collected by such a device (the EDPB doesn’t list any examples, but think about your smart light bulbs, your digital TV box, etc.), there is “gaining of access” to information as soon as a communication occurs whereby that captured information is transmitted to the manufacturer or operator’s server (whether directly by the device itself or through a relay, such as the user’s smartphone). Again, considering the position of the EDPB, this is consistent.
• User identifiers: the last sub-section relates to “unique identifiers” or “persistent identifiers”, which the EDPB says are “usually derived from persistent personal data (name and surname, email, phone number, etc.), that is hashed on the user’s device, collected and shared amongst several controllers to uniquely identify a person over different datasets (usage data collected through the use of website or application, customer relation management (CRM) data related to online or offline purchase or subscription, etc.” (para. 61). The EDPB’s logic is that “the fact that the information is being inputted by the user would not preclude the application of Article 5(3) ePD with regards to storage, as this information is stored temporarily on the terminal before being collected” (para. 62), which is consistent with the positions developed in the first part of the new guidelines. [Again, we are not talking about the scope of the GDPR here but about Article 5(3) ePD]
4. Issues raised by the EDPB’s new guidelines
Beyond the issue of whether the EDPB even had the authority to adopt these guidelines, the guidelines raise two significant issues:
a) Does it really not matter who gives the instruction to transmit certain information?
b) Is the transmission of information stored ephemerally in RAM or CPU cache really a form of access of information “already stored”?
As section 3 above showed, every use case listed by the EDPB depends on at least one of those two issues.
a) Does it really not matter who gives the instruction to transmit certain information?
The EDPB’s position on this point has very significant consequences – and it is also the point that marks the strongest divergence from previous (published) regulatory positions. [As mentioned above, the German supervisory authorities had an entirely different view even in March 2022.]
From a strictly legal perspective, the ePrivacy Directive only talks about “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user”. It never talks about who gives instructions to transmit information.
Yet those words “gaining of access” include “access” – and that word necessarily implies some form of active movement (you access a house by entering through a door; you access information by querying it), as opposed to for instance the verb “to receive”, which is passive (you receive information by virtue of the fact that someone sends it to you; you receive guests because they come to your house).
It is useful to look in this context at Recital 24 of the ePrivacy Directive, which talks about spyware and other means of accessing information on a terminal (“So-called spyware, web bugs, hidden identifiers and other similar devices can enter [emphasis mine] the user’s terminal without their knowledge in order to gain access to information, to store hidden information or to trace the activities of the user and may seriously intrude upon the privacy of these users. The use of such devices should be allowed only for legitimate purposes, with the knowledge of the users concerned”). No talk of remote monitoring of server logs but of entering a user’s terminal – a clearly active access.
Linguistically, therefore, there is already an issue with the EDPB’s position: it transforms the legislator’s choice of an active word into something that could also be passive.
In the case of IP addresses and URLs, the consequences are immediately obvious: if passive “access” was contemplated by the legislator, then of course it makes sense to consider that (i) reading the IP address that is part of the IP headers within the IP layer of a communication is “access” and (ii) reading the URL (and associated parameters) being requested by the device is “access”, even though the server is not in fact querying the device.
But does that make any sense? Can we allow regulators to twist the meaning of the word “access”?
The EDPB appears to have failed to consider that following that logic, every single communication over the Internet is “gaining of access” to information – as well as any follow-up use of that communication.
To provide one practical example, e-mails could following that logic be deemed to be passive “access” (= I am “accessing” the e-mail content and your e-mail headers such as the name you configured for your e-mail account, i.e. information that was stored even temporarily on your device you were writing and sending the e-mail, because the developers of the IMAP protocol made it so that when you send that e-mail, that information is sent to me), and any further use of their content would then be subject to Article 5(3) ePD (so I would need to prove that I have your consent to the use of the e-mail or that my use of that e-mail is strictly necessary to the provision of a digital service that you explicitly requested). You can probably imagine the consequences for the GDPR and in particular for Article 6 GDPR (which notably lists “legitimate interests” as one possible legal ground) where the “purely personal or household activity” exception does not apply.
Even beyond the issue of whether passive “access” can be “access” because a third party is the one providing the instructions (I strongly disagree with that allegation), I would argue that it is of paramount importance that the entity instructing the transmission of the information is not the party determining or implementing a general protocol but the party drawing a benefit from the transmission of that specific communication. Just like there is the notion of a “controller” under the GDPR and there needs to be some link with the controller (processing personal data directly or indirectly through a processor or through a joint controller) for data protection obligations to apply, it appears questionable (to say the least) to say that there is passive “access” thanks to the fact that a person designing or implementing a general communications protocol has foreseen technical instructions to transmit information in general.
Yet if that part of the EDPB’s reasoning falls, then IP addresses cannot be deemed to be “accessed” if they are purely read from the IP headers within the IP layer of a communication.
b) Is the transmission of information stored ephemerally in RAM and cache really a form of access of information “already stored”?
The reference by the EDPB to RAM and CPU cache is in my view an attempt to cover the fact that the ePrivacy Regulation (if ever adopted) would foresee that it applies not only to the use of the storage capabilities of terminal equipment but also to the use of the processing capabilities of terminal equipment.
Whether the ePrivacy Directive itself was ever intended to cover this is unclear, as RAM does in fact “store” short-term data currently in use by a device – in other words, it is “live” memory and is volatile, constantly being replaced with other short-term data that becomes in use. Unlike e.g. a hard drive or solid state drive, which clearly are there for storage of data, RAM is used only for information that is being used by the device.
CPU cache memory is similar, because it is also a temporary “storage” location for data and instructions that the CPU might need to access rapidly. RAM is for data currently in use, while CPU cache is for data frequently used (but we’re typically talking about less than 1 megabyte for L1 cache and just a few for L2 cache). This is not the same as for instance your web browser cache, which holds on your hard drive or solid state drive a downloaded version of the images, Javascript code, CSS style sheets, etc. and which can be several hundred megabytes in size.
The (native) app developer has some control over what goes into RAM (and honestly developers should do more to clean up their RAM usage), but for instance not regarding the CPU cache.
It is worth recalling here that Article 5(3) ePD applies “the storing of information” in terminal equipment as well as “the gaining of access to information already stored” in terminal equipment.
Note the word “already”, which introduces a notion of time. Is an instantaneous calculation, like the one shown by the EDPB in its example about user identifiers, really access to information “already” stored? Why would the legislator use the word “already” if the legislator intended for the rules to cover the use of information generated instantaneously and “stored” ephemerally in RAM?
In addition, if the legislator had really intended for such inherently processing-related situations of ephemeral storage to be covered, it would have used broader wording elsewhere because of the much more significant consequences. For instance, Recital 25 of the ePrivacy Directive focusses on cookies, a clear example of actual storage, and not of related scripts (e.g. in Javascript), which could have otherwise provided a clear example of something running on the computer and generating information on the fly.
Yet the legislator did not do so.
If one were to ignore the circumstances listed above (the choice of wording made by the legislator, plus the fact that they are purely used for ephemeral “storage”) and consider that the EDPB’s position is legally correct, it has far-reaching consequences, as it means that no use of RAM or of the CPU cache is permitted unless (i) the user (or subscriber) has given his/her GDPR-compliant consent to that use of RAM or of the CPU cache, (ii) that use of RAM or of the CPU cache is strictly necessary for provision of an information society service explicitly requested by the user/subscriber, or (iii) that use of RAM or of the CPU cache is for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
In other words, no interaction with a computer is permitted unless you can show that you benefit from one of those two exceptions.
This raises an additional pragmatic concern, rather than a new legal one, regarding notices. It is worth recalling that Art. 5(3) ePD has already led in practice to the proliferation of “cookie notices” even on websites that only use strictly necessary cookies, simply because many companies wish to limit the scope for any potential complaint or regulatory investigation and limit any potential fine if a complainant or regulator were to allege that the cookies in question are in fact non-necessary. You can argue that this is not required by law, but I have seen many cases where this ended up being very useful to help those companies justify their position. Because of this, I can only imagine the notices that would appear in every single piece of software and on every single website if we needed to start saying “Information from or related to this [app/website] may be included by your device in your system memory and cache, as required in order to be able to allow this [app/website] to function on your device” – in more detail. [Let’s not forget that some additional technical details would be needed based on the Planet49 judgment, such as information on duration, on the type of information that might be included in the system memory and cache, etc.]
While such practical considerations should not normally dictate a legal position, they show the (relatively absurd) consequences of the EDPB’s claimed position.
Yet if RAM and system cache fall outside of the scope of Article 5(3) ePD, then for instance the EDPB’s example of “local processing” is necessarily out of scope as well.
Most of the other use cases highlighted by the EDPB are equally questionable, from pixels (if no information is stored on the device as such, where is the issue from an ePrivacy Directive perspective?) to user identifiers (again, nothing is stored on the device).
For the sake of clarity, this has nothing to do with the issue of whether the GDPR applies. This is purely about the “cookie” rule, Article 5(3) of the ePrivacy Directive. And if any of the use cases identified by the EDPB involve the processing of (actual) personal data, the GDPR provisions might well apply to those use cases. But Article 5(3) ePD? Let’s say that I have my doubts.
5. Additional concerns with the new guidelines
The following are some additional points that I think merit consideration, even though they are less critical to the overall assessment of the new guidelines:
• The new guidelines do not tackle the issue of “user versus subscriber”, while this is extremely relevant regarding notably the issue of IP addresses and local processing. In practice, on B2B websites and in B2B apps, there may be an argument to say that many of the techniques described by the EDPB relate to the subscriber (i.e. a company) and not the user, which raises once more the question of whether a company’s policy to install a particular piece of software or to authorise access to a certain website is sufficient acceptance for compliance with the “consent” requirement (GDPR consent being an awkward thing to deal with when the subscriber whose consent is needed is a legal entity).
• The new guidelines “expand upon” certain Article 29 Working Party opinions that were not endorsed by the EDPB back in May 2018. Does the reference by the EDPB to the fingerprinting and cookie exemption opinions mean that they are now viewed as “endorsed”? If not, why should we care about any references to them?
• The wording in the guidelines is sometimes loaded, such as in para. 3: “The ambiguities regarding the scope of application of Article 5(3) ePD have created incentives to implement alternative solutions for tracking internet users and lead to a tendency to circumvent the legal obligations provided by Article 5(3) ePD”. This particular sentence is interesting, as “circumvent the legal obligations” implies that the legal obligations do not apply – which shows that the EDPB is now adopting a new interpretation of the ePrivacy Directive.
• The guidelines include inaccurate and misleading information regarding legal texts. For instance, para. 9 says that “scenarios that do intrude into this private sphere even without involving any personal data are explicitly covered by the wording of the Article 5(3) ePD and by Recital 24, for example the storage of viruses on the user’s terminal”. In reality, that Recital 24 talks about spyware and other means of accessing information on a terminal (“So-called spyware, web bugs, hidden identifiers and other similar devices can enter the user’s terminal without their knowledge in order to gain access to information, to store hidden information or to trace the activities of the user and may seriously intrude upon the privacy of these users. The use of such devices should be allowed only for legitimate purposes, with the knowledge of the users concerned”). It does not “explicitly” talk of viruses stored on a terminal.
• The parts about terminal equipment and IoT devices contain some contradictions.
First, para. 15 states that “Whenever a device is not an endpoint of a communication and only conveys information without performing any modifications to that information, it would not be considered as the terminal equipment in that context. Hence, if a device solely acts as a communication relay, it should not be considered a terminal equipment under Article 5(3) ePD”.Then, para. 16 states that “A terminal equipment may be comprised of any number of individual pieces of hardware, which together form the terminal equipment”.
Finally, in para. 60: “In the case of IoT devices connected to the network via a relay device (a smartphone, a dedicated hub, etc.) with a purely point to point connection between the IoT device and the relay device, the transmission of data to the relay could fall outside of the Article 5(3) ePD as the communication does not take place on a public communication network. However, the information received by the relay device would be considered stored by a terminal and Article 5(3) ePD would apply as soon as this relay is instructed to send that information to a remote server.”
Reading those paragraphs, it is entirely unclear to me what is the terminal equipment. Para. 60 says it should be the smartphone, para. 15 says it should be the IoT device, and para. 16 suggests they might be seen together as “the terminal equipment”. The contradiction may stem from the fact that paragraph 16 in particular appears to have been added with a specific goal in mind.
• On the notion of “gaining access” again, para. 30 states that “there are no restrictions placed on the origin of information on the terminal equipment for the notion of access to apply”. For all the reasons set out above, the origin of information and how it is obtained is critical, so this sentence appears to be inaccurate.
6. Can the public consultation help?
As mentioned in Part I, these guidelines are subject to a public consultation, running until 28 December 2023. [EDIT: deadline pushed back to 18 January 2024]
Past consultations have shown that the EDPB usually sticks to its position. One notable exception was its adoption of a slightly more pragmatic approach in (only some parts of) its recommendations on “supplementary measures” for data transfers, but more often the changes appear to lead to a slight hardening of the EDPB’s position (see e.g. the recent administrative fines guidelines, which were barely modified and in fact were modified to propose even higher fines).
It therefore appears unlikely that the EDPB will suddenly restrict the scope of these guidelines or to clarify why the legislator might have intended for both ephemeral processing and passive “access” to be covered, but it may see fit to at least clarify its legal reasoning – which may come in handy in case of (likely) litigation in relation to the enforcement of the positions it sets out.
From that perspective, it may remain useful to raise this question in any comments you make on the guidelines.
Would you like to send comments to the EDPB, but are you concerned about the fact that your name as responder will be made public? Get in touch – we have helped clients submit responses confidentially, by serving as the intermediary and signatory.
And reach out for any questions you have about how to deal with these guidelines and their impact on your business.
[EDIT: On 16 October 2024, the EDPB published its final, “post-consultation” version. Most of the issues affecting the initial version continue to affect the final version. See comparison here.]