ePrivacy challenges – one cookie law to rule them all? [Part II]

Time to talk about what can be done to improve the “cookie” rule!

In Part I of this series on the opportunities and difficulties of today’s ePrivacy regime, I discussed the underappreciated and seemingly-easy-but-really-complex world of the anti-spam rule, Article 13 of the ePrivacy Directive (or ePD).

This Part II is about a provision that is very often discussed and even enforced: Article 5(3) of the ePrivacy Directive, a provision known colloquially as the “cookie” rule. Why “cookie” rule? Whether for the sake of simplicity, due to a lack of tools, or due to a lack of technical understanding, many have focussed on one particular technology, the visible part of the iceberg: web cookies.

Another part (or several, we’ll see) will deal with competence/jurisdiction, dark patterns, the Digital Fairness Act and certain other topics. Have any other ePrivacy-related topics you would like to see handled in this series? Suggest away in the comments!

Let’s first make one thing clear: Art. 5(3) of the ePrivacy Directive is not just applicable to cookies. It is very clearly applicable also to techniques known as local storage (HTML5 storage, app data files etc.). But does it apply beyond? That is one of the challenges – just one of the challenges, though, and this series aims at highlighting those challenges. As I wrote in Part I:

Take from it the lessons you desire – whether you are an in-house counsel or product owner trying to understand grey areas, a legislator considering what to do (more on the Digital Fairness Act in a further piece in this series) or a regulator seeking to identify positions that are likely to give rise to challenges. After all, if a law is not workable in practice or does not have the desired effect but rather the opposite, it isn’t a very good law, so this exercise can be useful in helping to identify ways to make ePrivacy rules workable for all.

Specifically on the “cookie” rule, readers of my publications will know that I have already published extensively on some of the challenges, but this part II is an attempt to cover more ground. So hopefully even those who have read everything I have published will walk away with a few new takeaways!

---

1. What the “cookie” rule actually says

Time for some fundamentals. Article 5(3) of the ePrivacy Directive requires EU Member States (= because it’s a Directive, it needs to be implemented in national law) to ensure that:

“the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user 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 [the GDPR], 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.”

Why “[the GDPR]”? The text refers to the Directive 95/46/EC (the Data Protection Directive), which was replaced by the GDPR, and all references to that Directive have to be read as references to the GDPR.

So in summary, the “storage” of information or the “gaining of access” to information already stored in terminal equipment of a subscriber or user is subject to consent unless such storage/access is:

1. strictly necessary for the provision of an information society service explicitly requested by the subscriber or user (the “service” consent exemption), or
2. for the sole purpose of carrying out the transmission of a communication over an electronic communications network (the “transmission” consent exemption).

Let’s break down those steps one by one and look at the challenges that they present – from the perspective of the legal text as well as how regulators and courts interpret them.

---

2. Storage of information

Art. 5(3) ePrivacy Directive applies as soon as there is storage of information in terminal equipment, whether as part of the actual storage process or the follow-up action, i.e. gaining of access to information already stored.

For years, there was little enforcement of this provision, leading to the emergence of two diametrically opposed views of its scope that never found their way into litigation:

• Either “storage” is meant to cover any saving of information on a computer or other device even for a fraction of a second, irrespective of where on the device the information is saved,
• Or “storage” requires some form of permanence, based on the distinction in computing between “storage” and “memory”.

This difference in viewpoints only truly became apparent when the European Data Protection Board (EDPB) published in November 2023 a set of Guidelines for public consultation, on the technical scope of Art. 5(3) of the ePrivacy Directive.

Side note: Why the EDPB? The EDPB is a group of data protection authorities. Some of them have the authority to enforce the national implementation of Art. 5(3) of the ePrivacy Directive, while others do not. This has led me to challenge the competence of the EDPB to adopt guidelines in this respect. The EDPB has ignored this argument, but I strongly believe that this needs to be brought before the Court of Justice one day. The issue of jurisdiction is an important one, and I will discuss it further in a later instalment of this series.

Back to the topic at hand:

2.a) EDPB: broad interpretation of “storage”

This set of Guidelines of the EDPB took the view that storage means pretty much every interaction with a computer.

In sub-section 2.6 on the “Notions of ‘Stored Information’ and ‘Storage’”, the EDPB stated 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 was 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).

This text has remained pretty much unchanged in the final version that the EDPB adopted further to the public consultation, with only the addition of EEPROM:

“37. 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.

“38. Similarly, the notion of storage does not depend on the type of medium on which the information is stored. Typical examples would include hard disc drives (‘HDD’), solid state drives (‘SSD’), electrically-erasable programmable read-only memory (‘EEPROM’) 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. The storage medium may be connected internally (e.g. through a SATA connection), externally (e.g. through a USB connection)”

The reference to RAM / random-access memory is extremely important, because RAM is computer memory, not computer storage. So what is that difference?

2.b) Computing terminology: memory vs storage

In law, the meaning of words is critical. If a term is defined properly, you understand the scope of the law. If a term is not defined, though, we have to look at what the ordinary meaning of a word would be, because laws have to be foreseeable (if not, that raises questions as to their validity and enforceability!).

In dictionaries such as the Cambridge Dictionary, the ordinary meaning of “store” is “to put or keep things for use in the future” – “future” being key (Merriam-Webster: “to place or leave in a location (such as a warehouse, library, or computer memory) for preservation or later use or disposal”). No ordinary meaning of “future” (or “later”) is “in a few microseconds”, though. In other words, the ordinary meaning of “store” necessarily includes a certain notion of time and should not be interpreted as covering ephemeral “storage”. In other words, gaining access to information stored requires that a certain amount of time has lapsed, at least more than immediacy.

So the ordinary meaning might not be entirely clear. In that case, it’s important to look at the context – and the context of Article 5(3) of the ePrivacy Directive is computing. So let’s look at the ordinary meaning of “store” in the world of computer science.

This notion is defined by various key stakeholders in the sector as not including “memory” – an essentially ephemeral mechanism.

Here is how IBM defines “storage”:

What is data storage?

Data storage refers to magnetic, optical or mechanical media that record and preserve digital information for ongoing or future operations.

IBM also drawn a distinction with RAM:

When a computer powers down, so does the RAM’s ability to retain data. The solution? Data storage. With data storage space, users can save data onto a device. Should the computer power down, the data is retained.

Here is how HP describes the differences between memory and storage:

***

How is memory different from storage?

Memory and storage are often confused with each other, but they’re actually quite different.

Memory

Memory is what your computer uses to store data temporarily, while storage is where you save files permanently.

When you save a file, it’s copied from the memory onto the storage drive. This is why your computer seems to run slower when it’s low on memory; it has to pull data from the storage drive in order to use it.

Storage

Storage, on the other hand, is permanent and holds all of your files, whether you’re using them now or not. That’s why most people consider storage to be synonymous with the hard drive. When you save a file, it’s actually stored on your computer’s storage drive.

***

In practice, memory and storage interact constantly:

• When you wish to save something on your device, it gets written to storage
• If you want to open that something, it moves into memory so you can read it and interact with it
• When you are done, that something gets written to storage again

That local Microsoft Word document you have open on your computer? A copy of it in storage, where you saved it; while it is open, a “live” version is kept in memory, allowing you to make changes on the fly; when you save it, the then current state of it is copied over from memory into storage.

The same happens with web content: when you load a webpage, the content itself that you can see on your screen, along with the underlying code and components (e.g. Javascript code for interaction or functions, the HTML and CSS for the structure and design, the images themselves, etc.), all of that is in “memory”. Some of that information may then be placed also into storage for later access, through the mechanism of caching (notably useful for static pages, for images etc.), so that you don’t have to download all of that again from the web server the next time you visit. But the actual live version of the webpage? Memory. If anything is cached, when you reload the page that cached content gets read… through memory.

But because memory is fleeting, ephemeral, it is constantly being replaced with other short-term data that becomes in use.

So imagine memory as the live, volatile version, and storage as the permanent, durable version.

2.c) “The legislator didn’t want to make any difference”

Is that so?

Recital 24 of the ePrivacy Directive is the only actual indication of what the legislator intended to cover through Article 5(3):

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

It’s far from an indication that the legislator intended to cover memory.

2.d) What if memory is covered?

Let’s assume for a minute that this is correct, though, and that the legislator intended for all interactions with memory to be covered.

What would then be covered by Article 5(3) of the ePrivacy Directive?

Some examples of situations that would then be covered include:

• Any part of a user interface of a website or app, as this gets written to memory, such as custom fonts or even just the design elements such as colours and button sizes
• Security checks, such as lockout countdowns (to check inactivity, for instance on banking websites or apps)
• Previews for video players (those little thumbnails that you see appear when you drag a progress bar to see where you want to pick up from when watching a video)
• Any calculations going on within a device, such as code that powers a user interface (for instance to show or hide a button
• Every bit of code that loads on the “client” side (i.e. on the device itself), even debugging code or even code comments

“So what?”, you might ask. Well, given that consent is required for any storage unless one of the two consent exemptions applies, and given that the “service” exemption is interpreted really strictly by some regulators (we’ll get to that below), that would basically mean that any possible interaction with any website or app would require consent. Every. Single. Interaction. That choice of size for your button in your interface? Consent. That nice animation to make the company logo seem alive? Consent. Even that comment in the code that no one will actually see would require consent, because it is part of what is being “stored” if “store” covers memory.

Perhaps even more importantly: a great number of privacy-enhancing technologies (also known as PETs) rely on operations happening in memory to de-identify information or to adapt it. So a broad interpretation of “storage” means that those PETs would also fall within the scope of Article 5(3) of the ePrivacy Directive – and potentially require consent. As we will see later, that surely cannot be the intent of the legislator – after all, if I need consent whatever I do, whether for a PET or for a less privacy-preserving technology, why go the extra mile (also financially) for a PET and not go with the less privacy-preserving technology instead?

2.e) Where to go from here with “storage”?

This shows that there is a problem with “storage”. Interpret it broadly, and Article 5(3) of the ePrivacy Directive becomes a law of everything digital, because it then applies to every single interaction with a computer. Truly. Recitals 24 and 25 of the ePrivacy Directive do not support this, but it is the current position of the EDPB. They are not alone in thinking this – the UK ICO has adopted a similar view (but with certain openings – more on that later).

My thoughts? Things would be much cleaner if regulators were to hold that storage has to be interpreted as covering only non-volatile, permanent storage. No RAM, no CPU cache (also volatile), but only hard drives, solid state drives and the like.

Would it mean that certain things fall through the cracks? Perhaps, but what precisely? Pixel tracking? If regulators want the law to cover certain practices, they shouldn’t in my view stretch the notion of “storage” to cover “memory” but should instead do things the way democracies normally work: let the legislator move the needle. After all, a regulator is not a legislator, and absent specific and explicit powers (see my earlier comment about the EDPB’s powers), it is best to let the legislator do its job – expanding ePrivacy rules just because no ePrivacy Regulation is coming isn’t in my view an appropriate approach. [Would the ePrivacy Regulation have changed anything? Yes, as “processing” would have been covered, not just storage, but the ePrivacy Regulation also came with a raft of consent exemptions to counter the broader scope.]

Is there an alternative? Perhaps – if the regulators want to make Article 5(3) of the ePrivacy Directive the law of every computer interaction, though, they need to admit that their approach to consent exemptions needs a revamp.

More on that hereunder.

First, “gaining of access”.

---

3. Gaining of access

Next to “storing of information”, the second type of interaction with a device that leads to the applicability of Article 5(3) of the ePrivacy Directive is the “gaining of access to information already stored” in the device.

Note the reference here again to “stored”, so all considerations above regarding memory vs storage are equally relevant here.

Our focus here: what constitutes “gaining of access”.

Once again, the legislator did not indicate anything in this respect, but the EDPB had a lot to say about its own interpretation.

3.a) EDPB: broad interpretation of “gaining of access”

In its aforementioned guidelines on technical scope of Article 5(3) of the ePrivacy Directive, the EDPB writes the following:

“Whenever an entity takes steps towards gaining access to information stored in the terminal equipment, 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. 32 of the final version of the guidelines)

The initial version of the guidelines included different wording: “Whenever the accessing entity wishes to gain access to information stored in the terminal equipment and actively takes steps towards that end”, read the beginning of the first sentence. “Actively” disappeared entirely from that first sentence.

The suppression is due to a clear intent by the EDPB to cover any possible gaining of access to information, whether active or passive, as illustrated by its consideration that the use of IP [Internet Protocol] addresses is “gaining of access” to information stored in terminal equipment:

“Some providers are developing solutions that only rely on the collection of one component, namely the IP address, in order to track the navigation of the user, in some case across multiple domains. In that context Article 5(3) ePD could apply even though the instruction to make the IP available has been made by a different entity than the receiving one.” (para. 54)

Why do I say that this shows that the passive gaining of access is covered?

Because IP addresses are transmitted automatically as part of the IP layer of every single Internet communication. No one that the EDPB seeks to target is actively asking a device for its IP address – instead, everyone receives the IP address, whether they want to or not.

The EDPB justifies this by suggesting that who causes the transmission is irrelevant:

“In some cases, the entity instructing the terminal equipment to send back the targeted data and the entity receiving information might not be the same. This may result from the provision and/or use of a common mechanism between the two entities. Instructing the device to send already stored information (for example, through the use of a protocol, or an SDK that imply the proactive sending of information by the terminal equipment) makes an intrusion into the terminal equipment possible, therefore such an access triggers the applicability of Article 5(3).) ePD.” (para. 34)

3.b) Issues with the EDPB’s view

The EDPB’s view raises concerns from various perspectives.

First, does it really not matter who gives the instruction to send information?

The examples given by the legislator in Recitals 24 and 25 of the ePrivacy Directive are all clearly misuses by a third party of active access to a device, where someone enters the device. Spyware? The surreptitious installation of malware to collect data regarding a user’s behaviour. Web bugs? Exploiting bugs to gain access to a system. Hidden identifiers? Actively placing information on a device in order to identify it, without the user being aware. Cookies? Nothing being transmitted automatically here either.

In other words, the legislator’s examples are ones of actual gaining of access, an action, not passive receipt of information. Even the 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).

The legislator does not talk about remote monitoring of server logs but about entering a user’s terminal – a clearly active access.

Next, if any use of a protocol instructed by someone else means that Article 5(3) of the ePrivacy Directive can apply (= what the EDPB says in para. 34, as illustrated by para. 54), then every Internet communication involving a user’s device triggers the application of Article 5(3) of the ePrivacy Directive. This is because the IP address, like much other information, is part of the information being transmitted automatically as part of TCP/IP, a generic protocol that was introduced in 1974, i.e. more than 50 years ago, and that forms the basis for Internet communications.

That this cannot have been the intent of the legislator should be obvious: while (HTTP) cookies (whose specification was standardised in 1997) are explicitly mentioned in the ePrivacy Directive, TCP/IP is never mentioned – and IP addresses are only mentioned in Recital 28, which relates to an entirely different provision of the ePrivacy Directive.

3.c) What if receipt, “passive gaining of access”, is covered?

Again, let’s assume that the EDPB’s position is correct, and that the legislator intended for all passive gaining of access to be covered.

What would then be covered by Article 5(3) of the ePrivacy Directive?

One fundamental issue is that if passive, automatic receipt is covered, every single Internet communication is covered, no matter whether any of the received information is actually used.

For instance, the following situations would then be covered:

• Any request from a device to a server to load a web page or app content
• Every single audience measurement, even the more privacy-friendly solutions that do not seek any device-specific information, simply by virtue of receiving the IP address
• Any connection made by security researchers / ethical hackers to a server, and conversely any use of IP addresses communicated by those researchers in advance to avoid the activation of countermeasures
• Any use of IP addresses by a video streaming provider to ensure that people outside an authorised country or territory do not get access to the content (which is nevertheless important to ensure that IP rights are protected)
• Any use of user agent information (= type of browser) or related information to make a website display content in a manner that is more appropriate to the device size and capabilities

Again, you might ask “so what?”. Once more, though, given that consent is required for any storage unless one of the two consent exemptions applies, and given that the “communication” and “service” exemptions are interpreted really strictly by some regulators (more on that hereunder), that would basically mean that any possible interaction with any website or app would require consent. Every. Single. Interaction. (Yes, again, and yes, worth stressing.) Imagine if a video service provider needs to ask for consent to limit the availability of a video to one territory – what if the user says “no”? Can they then stream a movie in breach of the relevant IP rights just by saying “no”?

As for privacy-friendly audience measurement, the same comments apply as above: if I need consent whatever I do, whether for a privacy-friendly audience measurement solution or for a less privacy-friendly technology, why go the extra mile (also financially) for the privacy-friendlier alternative?

3.d) Where to go from here with “gaining of access”?

The above also shows that “gaining of access” presents an issue. A broad interpretation of those terms makes Article 5(3) of the ePrivacy Directive a law of every Internet communication, because it then applies to every single request sent by a device, even automatically without any specific instruction on the part of the website operator but at the sole initiative of the user. Once more, Recitals 24 and 25 of the ePrivacy Directive do not support this, but it is the current position of the EDPB. The ICO has also adopted a similar view (again with with certain openings – more on that later).

Just like with “storage”, I believe that things would be cleaner if regulators were to hold – as in fact the German and French regulators did consider, as recently as 2021 – that “gaining of access” requires an active instruction on the part of the entity in question, and that reliance solely on automatic transmission based on communications protocols, such as TCP/IP, does not fall within the scope of Article 5(3) of the ePrivacy Directive.

Once more, would that allow some things to fall through the cracks? Perhaps, but what precisely? Abuse of IP addresses? Again, stretching the notion of “gaining of access” to cover passive receipt is not the way to go about this; regulators should instead leave that to the legislator. [Would the ePrivacy Regulation have changed anything? Yes, as “processing” would have been covered, not just storage & gaining of access to information already stored, but the ePrivacy Regulation also came with a raft of consent exemptions to counter the broader scope.]

Is there an alternative? Perhaps – but once more, that would require a rethinking of regulators’ approaches to consent exemptions.

But first, before looking at those consent exemptions, let’s tackle one issue relating to consent.

---

4. Consent & transparency under Art. 5(3) ePrivacy Directive

You might assume that the issue of consent and transparency is straightforward, but there is a fundamental issue in Article 5(3) ePrivacy Directive, in that it applies to any information, whether personal data or not, but requires GDPR-compliant consent.

Surely that isn’t an issue?

It is, if you look at the conditions for consent and transparency.

4.a) Mismatch between GDPR consent and cookie/… consent

The GDPR requires consent to be free, informed, specific and unambiguous. As such, not too much of an issue in theory… but do we then have to interpret the conditions of Article 7 GDPR by understanding any references to “personal data” as references to “information”? Or do the condition for consent only apply to the extent that a cookie/… involves the processing of personal data? It would have been better for the ePrivacy Directive to clarify this point.

Next, the notion of consent has been interpreted in a very broad manner by the EDPB, even requiring “informed” consent to mean that the consequences of processing must be understood by data subjects, in its Consent or Pay Opinion (see my analysis of that Opinion). Does that mean that before “cookie” consent can be valid, the user must actually understand how each technology used works? Or can we assume that the EDPB’s interpretation of what constitutes “informed” consent will require a less technical understanding in the context of Article 5(3) of the ePrivacy Directive?

4.b) Clear and comprehensive information about purposes – and what if a consent exemption applies?

Article 5(3) of the ePrivacy Directive requires information to be “clear and comprehensive, in accordance with [the GDPR], inter alia, about the purposes of the processing”. [The “inter alia” relates to the “purposes” part, as clearly follows from certain other linguistic versions of the ePrivacy Directive.]

Again, though, how do you ensure clear and comprehensive information “in accordance with the GDPR” if there is no processing of personal data? It would once more have been better for the ePrivacy Directive to clarify this point.

An additional difficulty in relation to this transparency obligation relates to its applicability in the event of a consent exemption. The ePrivacy Directive itself is not explicit one way or another, but its wording (“This shall not prevent…” introducing the consent exemptions, and that “This” follows the consent + transparency requirements) suggests that there is no transparency obligation if one of the consent exemptions applies. That, however, is not necessarily how national implementations have been worded, nor is it how many authorities interpret the requirement.

Again, the ePrivacy Directive could have been more explicit on this point, but I hope that one day regulators will show sufficient pragmatism: if a consent exemption applies, it makes no sense to require information. Sure, information can be handy to stave off potential complaints by individuals who might see a cookie or other file/tag being used and who might be tempted to file a complaint in the absence of a clear explanation as to why an exemption applies – but it should not be required, given the wording of the ePrivacy Directive.

So what about these consent exemptions?

---

5. Consent exemptions

As mentioned at the beginning, there are two consent exemptions in the ePrivacy Directive (the ePrivacy Regulation, had it been adopted, would have foreseen several more): the communication exemption and the service exemption.

5.a) The issues a broad interpretation of “storage” and “gaining of access” cause for the communication exemption

The communication exemption is relatively straightforward on the face of it: if something is used for the sole purpose of transmission of a communication, there is no need for consent.

The problems arise when you mix it with the EDPB’s broad interpretation of “storage” and “gaining of access”, though.

And IP addresses provide a great illustration.

As mentioned above, IP addresses are transmitted automatically as part of the way in which TCP/IP works. Every Internet communication in which your device takes part involves a transmission of an IP address. So that transmission of an IP address is “for the sole purpose of carrying out the transmission of a communication”, right?

Yet if the website operator already knows that it will be using the IP address to track household-related interactions with a website, that IP address is no longer being used “for the sole purpose of carrying out the transmission”.

So is consent then needed also for the transmission part?

If you interpret “sole purpose” strictly, then logically consent would be required for the entire operation, including the transmission of the communication itself, because the transmission of the IP address forms part of the transmission of the communication.

That can surely not have been the intention of the legislator, so the word “sole” is in fact one word too many, and it would have been better for the ePrivacy Directive not to include that word.

5.b) The problems raised by a strict interpretation of the service exemption

The biggest challenge that Article 5(3) of the ePrivacy Directive raises, in my view, is the very last point: the service exemption – or more specifically, a strict interpretation of the service exemption.

In fact, many regulators have an extremely strict interpretation of that exemption. The UK ICO, for instance, explicitly states that the service exemption under the UK’s ePrivacy implementation (PECR) only applies if “without it, the service couldn’t be provided on a technical level”, and that the strict necessity for the service should be assessed “from the point of view of the subscriber or user, not your own. For example, you might view the use of advertising cookies as ‘strictly necessary’ because they bring in revenue that funds your service. However, they are not ‘strictly necessary’ from the user’s perspective”. Few are as explicit, but many share this perspective.

Why do I consider it extremely strict? For various reasons.

First, one qualm is that unlike the GDPR, which explicitly references “legal obligation” as a legal ground for the processing of personal data, Article 5(3) of the ePrivacy Directive does not include any “legal obligation” exemption. It’s a very keenly felt problem in regulated sectors (such as the financial services sector and the telecommunications sector), where a number of technical operations are required for compliance with statutory obligations. If regulators were to adopt a broad interpretation of what is the “service”, that would be fine. However, if you focus on the fact that a service cannot be provided “on a technical level”, well, from a purely technical perspective legal compliance is irrelevant to delivery of a service. Do you need to check if someone is carrying out fraud? That doesn’t affect your technical ability to provide a service. Do you want to verify IP addresses to prevent access to financial services outside of the jurisdictions for which the provider has an authorisation to provide those financial services, because otherwise the service would be illegal? Who cares, that doesn’t affect the technical ability to delivery the service. [Trust me, these are not theoretical concerns.]

OK, so maybe legal obligations should be taken into account to assess strict necessity for the provision of a service.

But then, what about security and fraud verifications, even outside of legal obligations? Again, without them, the service could technically be delivered, right?

If you apply the logic of regulators, these measures – which are very obviously essential from the perspective of the provider – are not strictly necessary. But this is one scenario where regulators ignore their own position. For instance, the ICO explicitly recognises “ensuring the security of terminal equipment” and “preventing or detecting fraud” as capable of being exempt, and the EDPB’s predecessor, the Article 29 Working Party, stated in 2012 that “cookies set for the specific task of increasing the security of the service”, such as “cookies used to detect repeated failed login attempts on a website, or other similar mechanisms designed to protect the login system from abuses”, could be exempt from consent (p. 7).

A little bit of hypocrisy, perhaps? These security and anti-fraud measures are not needed in order to ensure the technical ability to deliver a service to a specific user; instead, they are there to (i) prevent delivery to a specific user based on non-technical considerations or to (ii) improve the service for the next user. There is no direct benefit to the user against whom anti-fraud checks are being made – only an indirect benefit to the next user, because (i) the service is not affected by (as much) fraud or (as many) security risks and (ii) this potentially means that the provider loses less money to fraud/insecurity (which indirectly means less cost for the user, whether in terms of cost to the user’s wallet or in terms of advertising).

This shows in my view one of the fundamental flaws of the service consent exemption:

• Regulators want to limit its scope, so they state that it is all about taking into account technical delivery, purely from the perspective of the user;
• Yet they do not wish to exclude security checks, which however are not done from the perspective of the user but from the perspective of the provider and only indirectly benefit the user.

The issue here is that if regulators were to adopt a pragmatic and consistent view of the service exemption (one that leaves behind the idea of “technical delivery” and focusses on what the ePrivacy Directive actually talks about, i.e. the provision of the service [a more wholistic term]), it would necessarily lead to the conclusion that financial compensation forms part of necessity for the provision of the service – something that regulators appear dead set on preventing.

I have argued at length in favour of a broader interpretation of the consent exemption, and I continue to believe that it is a pragmatic approach.

But until a regulator decides to adopt a more consistent approach, one that recognises that security and anti-fraud checks are not about the technical ability to provide a service but should be authorised without consent, we will be stuck with a system that is flawed, simply because Article 5(3) of the ePrivacy Directive only foresees two consent exemptions, neither of which is actually defined.

5.c) And PETs & privacy-friendly options in all that?

The wording of the consent exemption presents significant challenges for privacy-enhancing technologies, because the consent exemptions apply based on the actual purpose of the cookie/file/…, not based on the amount of data available through them. In other words, from a legal perspective, there is no distinction to be made under Art. 5(3) of the ePrivacy Directive between privacy-friendly options and privacy-intrusive ones.

A creative interpretation of the service exemption would allow one to consider that the “necessity” threshold for the service exemption is more easily met if you use privacy-enhancing technologies, and this is what certain national regulators or legislators have done in relation to analytics (e.g. France, Italy, Spain, the Netherlands)… but then again, why not cover monetisation as well? What makes analytics for service improvement (which allows the service to be provided in a better way to the next user) any different from monetisation (which allows the service to be provided – at all, let alone in a better way – to the next user)?

In the meantime, the uncertainty regarding the scope of the consent exemption means that there is little incentive to invest in privacy-friendlier alternatives, given that the law applies to both, and the law is applied very strictly by many regulators.

5.d) The ICO’s “non-enforcement” suggestion

In its “online tracking strategy” published in January 2025, the UK regulator, the ICO, wrote a very encouraging yet legally unusual statement:

We will explore where PECR requirements to obtain consent for non-essential storage and access technologies prevents an industry-wide shift towards more privacy-friendly forms of online advertising, such as contextual models, and publish a statement outlining low-risk processing activities (such as, potentially, privacy-preserving ad measurement), which are unlikely to cause damage or distress or result in enforcement sanction. We will work with government to explore how it could amend legislation to reinforce this.

Read it again: a statement will be published outlining “low-risk processing activities […] which are unlikely to […] result in enforcement sanction”. Basically, non-enforcement in a number of situations.

In my book, recognition by a regulator that they will not enforce a rule in certain cases means that the rule itself is flawed.

While the ICO is no longer part of the EDPB, its interpretation is obviously relevant, as PECR contains the same principles as EU national implementations of the ePrivacy Directive.

---

6. Closing thoughts, and a possible way forward

What the ICO’s position reveals is that if regulators insist on interpreting Article 5(3) of the ePrivacy Directive broadly and its consent exceptions restrictively, they have to add a new condition to its enforcement: only target actual abuses or harm.

“Abuse” or “harm” is not part of the scope of the provisions, but adding it to their enforcement criteria is in my view the only way to maintain a broad scope as regulators appear to insist.

Either that, or regulators should recognise that their interpretation is causing problems that the legislator didn’t intend to cause.

In practice, I believe that there are two ways forward to maintain the regime of Article 5(3) of ePrivacy Directive in a workable manner:

1. Recognition by regulators (perhaps forced by the courts?) that (i) the scope of Article 5(3) of the ePrivacy Directive does not cover computer memory AND that (ii) the “service” exemption cannot be interpreted purely from the perspective of technical delivery to the user but should take into account a reasonable definition of the whole provision of the service as intended by the provider, OR
2. Addition by regulators of a criterion of harm or abuse to their enforcement of the rules, so as not to penalise good actors who do their best to comply but face limits that the regulatory positions have caused.

[You can guess which one I prefer.]

I quite like the simplicity of Article 5(3) of the ePrivacy Directive on paper, but the interpretation issues that have arisen out of a lack of definitions are problematic – so either the legislator has to finally think about improving things, or regulators have to concentrate on making their approach workable. If they do not, strict enforcement of the “cookie” rule will just lead to more litigation and, in all likelihood, greater disregard for the rule.

---

Stay tuned for the next part(s) of this series – on competence/jurisdiction, dark patterns, the Digital Fairness Act and certain other topics.

Have any other ePrivacy-related topics you would like to see handled in this series? Suggest away in the comments!