5

Before proceeding with the allocation of responsibilities, it is crucial to identify whether there is a processing of “personal data”. Article 4(1) GDPR defines personal data as “any information relating to an identified or identifiable natural person […]”. Data that do not relate to an identified or identifiable individual will be considered anonymous and fall outside the scope of the GDPR. While other elements of this definition can also potentially pave the way for an extensive interpretation of personal data, [8] we limit the scope of our analysis to the controversial notion of “identifiability”.

6

Recital 26 GDPR provides that “to determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly”. In turn, according to Recital 26 GDPR, “to ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors such as the costs of and amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments”. As already discussed at length by several authors, [9] there is considerable legal uncertainty on the standard of identifiability set forth by the GDPR. This uncertainty concerns, among others, the perspective from which the nature of the data is to be assessed (the so-called “absolute” versus “relative” approach to personal data) [10] and the risk of (re-)identification that can be tolerated without data being considered as relating to an “identifiable individual” (the so-called “zero-risk” versus “risk-based” approach). [11]

7

Under the absolute approach, if anybody is theoretically able to identify a data subject on the basis of the data at issue (potentially combined with auxiliary information), that data would qualify as personal data. [12] Under the relative approach, the likelihood of re-identification would only be assessed from the perspective of a more limited number of parties, i.e. the controller or a third party that is reasonably likely to approach or be approached by the controller. [13] Under a zero-risk approach, data would be personal as soon as there is a risk of re-identification, no matter how negligible, whereas, under a risk-based approach, this would be the case only if identification is considered to be reasonably likely in light of the efforts it would require in terms of factors such as costs, time, technological means and expertise. [14] Although the reasonably likely means of identification standard set out in recital 26 GDPR seems to imply a risk-based approach to personal data, the interpretation of the identifiability criterion by the relevant authorities does not unequivocally point in this direction. [15] Below, we present a selection of the main interpretative guidance on identifiability. [16]

8

In its 2007 opinion on the concept of personal data, the WP29 stated that the “mere hypothetical possibility to single out the individual is not enough to consider the person as ‘identifiable’” and stressed that the possibility of identification should be (re-)assessed on a continuous basis, throughout the expected lifetime of the data. [17] What is to be considered “reasonable” is context-dependant. [18] This seems to plead in favour of a risk-based approach. The WP29 also stressed that identifiability should be assessed not only from the perspective of the controller but from the perspective of “any other person”. [19] While this might appear as advocating for an absolute approach—and therefore in contradiction with the above—the WP29 clarified that statement in an example related to key-coded personal data used for clinical trials, where the re-identification of patients is explicitly envisaged in the scope of the trial. According to the WP29, key-coded data would be considered personal data for the controllers involved in re-identification, but not for “any other data controller processing the same set of coded data […], if within the specific scheme in which those other controllers are operating, re-identification is explicitly excluded and appropriate technical measures have been taken in this respect”. [20] This, again, seems to favour a relative and risk-based approach.

9

In its later opinion on anonymization techniques, the WP29 appears to have adopted a more radical stance towards the identifiability threshold. There, it stated that the outcome of anonymization—i.e. the process through which data becomes anonymous and a fortiori non-identifiable—should be “as permanent as erasure” with the aim to “irreversibly” prevent re-identification. [21] Like in 2007, the WP29 stressed that identifiability must be judged from the viewpoint of the controller or any other third person. [22] In a much criticized example, [23] however, it clarified that if a controller provides a dataset with individual travel patterns at event level to a third party after having removed or masked the identifiable data, such a dataset would still qualify as personal data “for any party, as long as the data controller (or any other third party) still has access to the original raw data”. [24] Here, the absence of any reference to the likelihood of such re-identification happening seems to imply an absolute and zero risk approach to personal data. [25]

10

Later, the CJEU interpreted the notion of “reasonably likely” means of identification in the Breyer case, where it held that a dynamic IP address held by a content provider was personal data, even if that provider was not able, by itself, to link the address to a particular individual. The Court considered that, since German law allowed the content provider to combine the dynamic IP address with the information held by the internet service provider under specific circumstances such as cyberattacks, the content provider had a legal possibility to identify the data subject. This legal possibility was considered a “reasonably likely” means to be used. Conversely, the likelihood test would not have been met if identification was “prohibited by law or practically impossible on account of the fact that it requires disproportionate efforts in terms of time, cost and man-power, so that the risk of identification appears in reality to be insignificant”. [26] As such, it seems that the CJEU has embraced a risk-based approach to personal data, since it investigated the actual means of re-identification that were at the disposal of the content provider. [27]

11

As to the perspective from which “identifiability” should be assessed, the opinion of Advocate General Campos Sánchez-Bordona in Breyer points to a relative approach. According to him, a reference to “any third party” must be understood as referring to third parties “who, also in a reasonable manner, may be approached by a controller seeking to obtain additional data for the purpose of identification”. [28] Otherwise, “[…] it would always be possible to imagine the hypothetical contingency of a third party who, no matter how inaccessible to the provider of services on the Internet, could — now or in the future — have additional relevant data to assist in the identification of a user”. [29]

12

Like others, [30] we believe that the relative and risk-based approach is the only sensible way to interpret the identifiability criterion. In light of the increasing amount of publicly available information which could potentially be used to re-identify a data subject and the growing body of research disputing the possibility to irreversibly anonymize data, [31] favouring an absolute and zero-risk approach to personal data could de facto amount to admitting that almost all data could potentially qualify as personal. This would lower legal certainty and increase the burden on controllers to make sure that the data they collect do not, at any point in time, lead to the potential re-identification of individuals. [32]

13

As highlighted by the EDPB, “the assessment of joint controllership should mirror the assessment of ‘single’ control […]”. [33] Before analysing the criteria used to establish joint control, it is therefore crucial to first identify which entities qualify as controllers in their own right. Only then is it possible to examine whether they would qualify as joint, or rather sole, controllers vis-à-vis certain processing operations. As such, the EDPB breaks down the definition of controller into the following building blocks. [34] A controller is the:

14

The first building block is self-explanatory for the purposes of this contribution. What needs to be highlighted is that a natural person can also qualify as a controller under the GDPR. As detailed in section C Tom Nichini TN , this also opens up the possibility for natural persons to rely on the so-called “household exemption” to avoid falling under the Regulation’s scope of application.

15

Second, the capacity to “determine”, stresses the EDPB, refers to “the controller’s influence over the processing, by virtue of an exercise of decision-making power”. [35] As already clarified by the WP29, [36] the EDPB emphasises that such influence can stem from either legal provisions or an analysis of the factual elements surrounding the circumstances of the case. In the case of legal provisions, where a piece of domestic legislation lays down the purposes and the means of a specific (or set of) processing operation(s), the legislator can also appoint the controller or the criteria for its nomination (Article 4(7) GDPR). This seems to suggest that the possibility for the legislator to allocate responsibilities is conditional upon the determination of the purposes and means of the processing. Those purposes must be explicitly and legitimately specified (Article 5(1)b GDPR). However, the legislator also has the possibility to add specific provisions for the type of data to be processed and the data subjects concerned, where the processing is based on the performance of a task carried out in the public interest (Article 6(3) second indent GDPR). Collectively, this prevents the legislator from allocating responsibilities in a vacuum. It also means that the legal designation only covers the processing operations that pursue a set of pre-defined purposes.

16

Where the law does not explicitly or implicitly allocate responsibility to a certain entity, a factual assessment is required “in order to reach a conclusion as to whether a particular entity exercises a determinative influence with respect to the processing of personal data in question”. [37] The wording used by the EDPB therefore seems to suggest that such a factual assessment is not necessary where the controller or the criteria for its determination have been laid down by law. [38] In that case, the EDPB underlines that the legal designation “will be determinative for establishing who is acting as controller”. [39] Nonetheless, the EDPB also states that the designation of the controller by law presupposes that the appointed entity “has a genuine ability to exercise control”. [40] This seems to be a safeguard against overly artificial schemes allowing to challenge the allocation of responsibilities put in place by the legislator, should there be major discrepancies between the factual reality and the legal fiction.

17

Third, it appears from the wording of Article 4(7) GDPR—“alone or jointly with others”—that more than one entity can determine the purposes and the means of the processing operations. This can lead to a situation of joint control, which will be extensively discussed below.

18

Fourth, as already pointed out by the WP29, [41] the EDPB states that determining the “purposes and means” amounts to “deciding respectively the ‘why’ and the ‘how’ of the processing.” [42] It is necessary to exert influence over both those elements to qualify as a controller, although “some margin of manoeuvre may exist for the processor also to be able to make some decisions in relation to the processing”. [43] In short, one should distinguish between the essential means—which have to be determined by the controller—and the non-essential means—which can, to a certain extent, be delegated to another entity without shifting (or sharing) the burden of control to or with that entity. The essential elements of the means concern matters such as which data shall be processed, which third parties shall have access to the data or how long the data shall be processed. [44] The non-essential elements relate to more “practical aspects of implementation” such as which software or hardware to use. [45]

19

Fifth, when detailing the notion of “processing”, the EDPB emphasises that control is to be allocated with regard to specific processing operations. In other words, the assessment described above “may extend to the entirety of the processing at issue, but may also be limited to a particular stage in the processing”. [46] In that sense, the EDPB accommodates both a macro and a micro-perspective when it comes to the identification of the relevant processing operations. [47] It fails, however, to provide any specific guidance as to the criteria to be used to identify the relevant set or stages of the processing operations. Moreover, as will be detailed below, the EDPB does not consider access to the data being processed as a determining factor when qualifying an entity as a controller. [48]

20

In its latest Fashion ID judgment, the CJEU was asked by the referring court whether the operator of a website like Fashion ID could qualify as a controller under the DPD when embedding a Facebook ‘like’ plug-in on its website. The plug-in caused the visitor’s browser to transmit personal data to Facebook, regardless of whether that visitor had a Facebook account and whether they had clicked on the ‘like’ button or not. The personal data at issue consisted of the visitor’s IP address and the browser string to which Fashion ID did not have access. The CJEU was not asked to rule on whether the data at issue were personal. Like Advocate General Bobek, who delivered the opinion in that case, [49] the Court probably took it as a given that they were. The Court did, however, specify that “joint responsibility of several actors for the same processing […] does not require each of them to have access to the personal data concerned” (emphasis added). [50] When it comes to identifying the relevant processing operations in relation to which control has to be assessed, the Court stated that “the processing of personal data may consist in one or a number of operations, each of which relates to one of the different stages that the processing of personal data may involve” (emphasis added). [51] The Court deemed the “collection and disclosure by transmission” [52] of the website visitors’ personal data by Fashion ID to Facebook as the relevant processing operations in relation to which Fashion ID’s controller role should be assessed. Subsequent stages in the processing were, by contrast, deemed irrelevant.

21

After having stressed that the concept of controller is to be defined broadly in order to ensure “effective and complete protection”  [53] of data subjects, the CJEU held that a “natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller within the meaning of Article 2(d) of Directive 95/46” (emphasis added). [54] As to the means, the Court concluded that Fashion ID, by embedding the social plugin on its website, while being fully aware that it served as a tool for collection and transmission of personal data to Facebook, “exerts a decisive influence over the collection and transmission of the personal data of visitors to that website” to Facebook, “which would not have occurred without that plugin” (emphasis added). [55] As to the purposes, the CJEU considered that the collection and transmission of personal data to Facebook were “performed in the economic interests of both Fashion ID and Facebook Ireland, for whom the fact that it can use those data for its own commercial purposes is the consideration for the benefit to Fashion ID” (emphasis added). [56] The CJEU concluded that Fashion ID can be considered to be a joint controller with Facebook in respect of the “collection and disclosure by transmission of the personal data of visitors to its website”. [57]

22

Earlier, in the Wirtschafstakademie case, the CJEU had to determine whether the administrator of a Facebook fan page, i.e. Wirtschafstakademie, could be considered a joint controller with Facebook in relation to the processing of personal data of the visitors of that fan page. When considering the role of the administrator of the fan page in relation to that processing, the Court attached importance to the fact that, by creating the fan page, the administrator “gives Facebook the opportunity” to carry out such processing (emphasis added). [58] It further held that the fan page administrator “contributes to the processing of the personal data of visitors to its page” by defining the criteria in accordance with which the statistics of the visits of the fan page were to be drawn and designating the categories of persons whose personal data would be made use of by Facebook. [59] The CJEU therefore considered that the fan page administrator was taking part in the determination of the purposes and the means of the processing of personal data of visitors of that fan page, “by its definition of parameters depending in particular on its target audience and the objectives of managing and promoting its activities” (emphasis added). [60] Like in Fashion ID, the CJEU stressed that it was not necessary for each controller to have access to the relevant personal data and that various operators may be involved at different stages of the processing of personal data and to different degrees. [61]

23

Similarly, in Jehovah’s Witnesses, the CJEU confirmed that access to the personal data was not a necessary prerequisite for an actor to qualify as a (joint) controller.  [62]Concretely, the CJEU considered that, although the Jehovah’s Witnesses Community did not have access to the personal data and did not know the specific circumstances in which its members collected and further processed such data, it nonetheless “organized, coordinated and encouraged” the preaching activities in the framework of which the processing was taking place. [63] Moreover, “the collection of personal data relating to the persons contacted and their subsequent processing” was carried out to “help achieve the objective of the Jehovah’s Witnesses Community, which is to spread faith”. [64] The CJEU considered this to be sufficient to conclude that the Jehovah’s Witnesses Community determined, jointly with its members, “the purposes and means of processing of personal data of the persons contacted […]”. [65]

24

Compared to the assessment of control in general (see section 2.3.1), when it comes to assessing joint control, the EDPB appears to stress more the importance of a factual, rather than a formal analysis. Indeed, in the case of joint control, states the Board, it might be that “the formal appointment [laid down by the law or in a contract] does not reflect the reality of the arrangements, by formally entrusting the role of controller to an entity which actually is not in the position to ‘determine’ the purposes and means of the processing”. [66]

25

According to the EDPB, “the overarching criterion for joint controllership to exist is the joint participation of two or more entities in the determination of the purposes and means of a processing operation”. [67] The EDPB further states that two or more entities can be seen to jointly participate in the determination of the purposes and the means of a given (or set of) processing operation(s), when they take “common” or “converging” decisions. [68] A common decision means “deciding together and involves a common intention in accordance with the most common understanding of the term ‘jointly’ referred to in Article 26 of the GDPR”. [69] Converging decisions, on the other hand, “complement each other and are necessary for the processing to take place in such a manner that they have a tangible impact on the determination of the purposes and the means of the processing”. [70] Echoing the CJEU’s finding in Fashion ID, the EDPB adds that an important criterion to determine that the entities take converging decisions, is “whether the processing would not be possible without both parties’ participation in the sense that the processing by each party is inseparable, i.e. inextricably linked” (emphasis added). [71] Moreover, like the CJEU in Fashion- ID, [72] the EDPB stresses that the “existence of joint responsibility does not necessarily imply equal responsibility of the various operators involved in the processing of personal data.” [73] As correctly remarked by other scholars, [74] there are, however, no clear criteria according to which responsibility should be apportioned among joint controllers.

26

The EDPB subsequently clarifies the meaning of a jointly determined purpose, i.e. a purpose that is either identical, common, closely linked or complementary to the purpose pursued by another entity. [75] Echoing the reasoning developed in both Fashion ID and Wirtschafstakademie, the EDPB states that this could be the case “when there is a mutual benefit arising from the same processing operation, provided that each entity involved participates in the determination of the purposes and means of the relevant processing operation”. [76] At the same time, however, the EDPB also specifies that “the mere existence of a mutual benefit (for ex., commercial)” is not sufficient to establish joint control, as the entity involved in the processing must “pursue [a] purpose of its own”. [77]

27

The EDPB moreover points out that jointly determining the means does not imply that the entities need to determine the means to the same extent. With reference to the abovementioned Fashion ID and Wirtschafstakademie cases, the EDPB clarifies that the joint determination of means can follow from a situation in which a given entity makes use of a technology developed by another entity for its own purposes. In that sense, “the entity who decides to make use of [the means provided by another entity] so that personal data can be processed for a particular purpose also participates in the determination of the means of the processing”. [78]

28

The processing operation in relation to which joint control should be assessed could be defined at a micro-level, looking at one specific processing operation, or at a macro-level, with respect to a set of processing operations. As mentioned above, the EDPB’s opinion seems, like the earlier WP29 opinion it replaces, [79] to accommodate both approaches. By contrast, as already noted in literature, the CJEU appears to have adopted a micro-level and so-called “phase-oriented” [80] approach to joint control in its recent case-law, and most recently in Fashion ID.

29

Remarkably, as noted by other scholars in relation to the CJEU’s ruling in Fashion ID, [81] both the CJEU and the EDPB fail to provide any objective criterion on the basis of which the relevant phases of the processing should be identified. According to some commentators, [82] the key element to define the relevant processing operation would be the unity of purposes. [83] As explained below, this introduces an additional layer of uncertainty as to the level of detail with which the purposes should be defined. Indeed, the degree of precision with which the purpose is scoped will directly impact the granularity of the processing operations, and vice-versa. Intuitively, the more general the purpose, the higher the likelihood to find that several processing operations share the same purpose and the larger the set of the processing operations in light of which control is to be assessed. Conversely, the more specific the purpose, the lower such likelihood. [84] The EDPB did not provide any explanation on this point in its recent guidelines. The WP29 did, however, briefly touch upon this issue in its Opinion 03/2013 on purpose limitation, where it stated that the purpose “must be detailed enough to determine what kind of processing is and is not included within the specified purpose, and to allow that compliance with the law can be assessed and data protection safeguards applied. For these reasons, a purpose that is vague or general, such as for instance 'improving users' experience', 'marketing purposes', 'IT-security purposes' or 'future research' will – without more detail – usually not meet the criteria of being ‘specific’”. [85] It remains uncertain, however, whether a consideration made in relation to the principle of purpose limitation also applies to the definition of purposes when delineating the relevant processing operation for assessing control. [86] As a consequence, the delineation of the relevant processing operations and consequent allocation of responsibilities might end up being an arbitrary, fluid exercise, as will be further illustrated in the second part of this paper.

30

Another key question emerging from the findings outlined above is whether the perspective through which identifiability is assessed under Article 4(1) GDPR predefines the candidates for the role of controller. In other words, whether the assessment as to the existence of “personal data” happens independently from the one conducted to identify the entity that “determines” the “purposes” and the “means” of the processing.

31

Since access to the data at stake is a de facto requirement for an entity to be able to “reasonably likely” (re-)identify the individuals, by clarifying that access is not a prerequisite for “joint responsibility” (which in the cases at hand, implied joint control), the CJEU seems to have (at least implicitly) accepted that a party may qualify as a joint controller of data that from that party’s perspective, are in fact anonymous. Interestingly—although they were not issued under the GDPR—the European Data Protection Supervisor’s (“EDPS”) Guidelines on the concepts of controller, processor and joint controllership under Regulation (EU) 2018/1725 seem to endorse this approach. Indeed, the EDPS states that: “The fact that a party only has access to information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or not longer identifiable […] does not influence the joint controllership situation.” [87] However, the EDPS adds, “this may nonetheless matter when establishing the degree of responsibility of the parties involved”. [88]

32

To the contrary, if one were to adopt a relative approach to personal data and consider that the perspective from which identifiability is assessed predetermines the potential candidates for the role of controller, it would not even be necessary to assess the role of the parties lacking access to the data as possible (joint) controllers. In that case, the data at stake would not be personal to these parties, as, by lacking access, they would a fortiori lack the means reasonably likely to be used to identify the individual.

33

An alternative explanation could be that, by stating that access to data is not a prerequisite for joint control under the GDPR, the CJEU meant actual access to data at the time of the processing, as opposed to potential and reasonably likely future access. This interpretation would reconcile the CJEU’s statement on access to personal data when assessing joint control with the relative and risk-based approach to personal data. However, it would still be incompatible with the less nuanced position of the EDPB on the topic, which, as already mentioned, stated that “someone who outsources a processing activity and in doing so, has a determinative influence on the purpose and (essential) means of the processing […] is to be regarded as controller even though he or she will never have actual access to the data” (emphasis added). [89] Thus, the question that remains unanswered is whether lacking potential—as opposed to actual—access could preclude an entity from being regarded as a controller.

34

The analysis carried out in section 6 illustrates a major implication of this loophole: potentially, an actor could qualify as a (joint) controller of data that, from that actor’s perspective, are not personal.

35

Next to assisting in the delineation of the relevant processing activities in light of which control is to be assessed, identifying the “purpose” of the activity is also necessary to determine whether the entity(ies) at issue can be said to jointly participate in their determination. As seen above, determining the purposes means ascertaining “why” data is processed. In Fashion ID, the key criterion to conclude that the entities at issue jointly determined the purposes seems to have been that the processing operation commercially benefitted both entities. Fashion ID benefitted from an “increased publicity for its goods” and Facebook was able to use the data collected for “its own commercial purposes”. [90] The EDPB, however, clarified that mutual (commercial) benefit is only an example of, but not a sufficient condition for, two or more entities to be said to jointly determine the purpose. According to the EDPB, what is required is that each entity pursues a “purpose of its own”, which is defined negatively: an entity which is “merely being paid for the services rendered” would not pursue a purpose of its own and hence be a processor, not a joint controller. [91] This explanation seems to suggest that “own purpose” is to be interpreted as the motivating factor driving the entity to engage in a certain processing activity. This interpretation could, again, leave the door open to a wide array of situations where a party could qualify as a joint controller. Indeed, depending on how granularly the purpose is defined, it would in theory always seem possible to attribute a distinctive commercial or other purpose to the entities involved in the processing operations at stake.

36

As to the “means”, whereas the EDPB makes a clear distinction between essential and non-essential means when discussing sole control and unambiguously states that the controller must determine the essential elements of the means, this clear-cut demarcation seems to become less relevant in the case of joint control. [92] With reference to Fashion ID, the EDPB indeed states that the joint determination of the means could follow from an entity’s choice to use a tool developed by another entity for “its own purposes”. Again, this raises the same interpretative questions and ensuing potential broad interpretation as to the meaning of processing for “its own purpose” as set out in the preceding paragraph.

37

Finally, the meaning of “determining” also suffers from a lack of clarity in at least two ways. First, it is unclear whether the legal designation of a controller should supersede factual reality. On the one hand, when assessing control (in general), the EDPB seems to imply that a factual analysis should only be performed in case of major discrepancies between the law and the fact. On the other hand, as mentioned above in section 2.3.3, when assessing joint control, the EDPB seems to be more nuanced, by presumably requiring a higher degree of factual scrutiny when analysing whether two or more entities could act as joint controllers. This raises the specific question analysed in section 6 as to whether a situation of joint control is possible between a legally designated controller, on the one hand, and a factual controller, on the other. More specifically, the question is whether the designation of one controller by law as such excludes a situation of joint controllership between that legally designated controller and a factual controller. Again, although not applicable to the case at hand, the aforementioned EDPS’ Guidelines can provide some partial guidance in this respect. They indeed state that “joint controllership may also occur between an EUI [European Union Institution] and an external actor (such as an external provider of a management portal or a national public authority etc.).”  [93] Nevertheless, the EDPS discourages this scenario and encourages EUIs to make sure that private companies act as processors. [94]

38

Second, if we perform a factual assessment, what seemed to have played a crucial role in the aforementioned CJEU case law, particularly Fashion ID, was not as much the capacity to determine “why” and “how” personal data were processed, but merely “if” personal data were processed at all. This approach, focusing on enabling the processing of personal data by another party, [95] is confirmed in the EDPB guidelines, which stress that joint determination arises in the case of converging decisions or, in other words, when the “processing would not be possible without both parties’ participation” (emphasis added) (see section 2.3.3 Tom Nichini TN ). The perils inherent to such a broad interpretation of the term “determining” are eloquently explained by Advocate General Bobek in its opinion in Fashion ID. There it states that, if one looks at the joint control test critically, “it seems that the crucial criterion after Wirtschafstakademie Schleswig-Holstein and Jehovah’s Witnesses” seems to be “that the person in question ‘made it possible’ for personal data to be collected and transferred, potentially coupled with some input that such a joint controller has on the parameters (or at least where there is silent endorsement of them)”. “If that is indeed the case”, he adds, “then in spite of a clearly stated intention to that effect to exclude it in Wirtschafstakademie Schleswig-Holstein, it is difficult to see how normal users of an online (based) application, be it a social network or any other collaborative platform, but also other programmes would not also become joint controllers”. [96]

Table 1 – Ambiguities regarding the legal test for joint control

55

As a preliminary step, it is necessary to identify the processing operations in light of which the allocation of responsibilities is to be performed. Article 4(2) GDPR defines processing as “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation, or alteration, retrieval, consultation, use disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction”. To keep the scope of the investigation manageable, and since we want to assess the role of the app user in relation to the processing operations on other app users’ personal data (not their own personal data), we limit ourselves to considering the processing operations that are performed on the other app users’ EphIDs. [125] This narrows the scope of the analysis down to the following processing activities (Figure 3 Tom Nichini TN ):

Figure 3 - Processing operations relevant for the analysis

56

It is crucial to determine whether all these processing operations are relevant when assessing control. This shows a first difficulty stemming from the application of the criteria for joint control mentioned above. On the one hand, if we approach the individual processing operations from a macro-perspective and adopt the unity of purpose as a criterion for identifying the relevant processing operations, it is plausible to argue that these operations all share the same purpose, namely notifying the app user of an exposure to a diagnosed user. This is the case in both the centralised and decentralised approaches. Such purpose serves both a public interest (i.e. preserving public health) but also a private one (i.e. preserving each individual user’s health). As a result, all these processing operations would be considered as a set of operations and, provided they concern personal data, would all be relevant to assess the role of the app user under the GDPR.

57

On the other hand, it would be equally plausible to define the purpose of the processing operations more granularly, at a micro-level. For instance, in a centralised scenario, the purpose of the collection and storage of other app users’ EphIDs (phase 2) is the transmission of these EphIDs to the backend server, should the user at issue become infected (phase 3). Similarly, in a decentralised protocol, the use by an app user’s phone of the diagnosed user’s EphIDs aims at matching these EphIDs with the observed ones and, should a match occur, calculating the risk-score (phase 4).

58

In short, it always seems possible to reduce the purpose of each processing operation to the subsequent stage of the processing that that operation is intended to enable, thereby losing sight of the overall purpose that connects each stage of the processing. [126] This exemplifies the problem identified in section B.IV.1 Tom Nichini TN and table Tom Nichini TN Pierre Dewitte PD Done. 1 above as to the level of granularity with which the purpose(s) of the processing should be defined.

59

The identification of the relevant processing operations is likely to become even more unpredictable if we abandon the unity of purpose as a criterion and adopt a “phase-oriented” [127] approach to identify the relevant processing operations, like the CJEU seems to have done in Fashion ID. In that case, limiting the relevant processing operations to any phase of the processing runs the risk of leading to an artificial representation of the processing operations that lacks any objective rationale.

60

Next, it is crucial to determine whether the processing activities identified in the preceding paragraph are performed on “personal data”. For the purposes of this contribution, we only focus on the identifiability criterion and hence assume that EphIDs can qualify as “any information relating to a natural person” (Article 4 (1) GDPR). Since, as highlighted in section B.II.2 Tom Nichini TN , we consider the relative and risk-based approach as the most sensible approach to personal data, we assess the nature of the EphIDs under this approach. We do so on the basis of the criteria provided by the privacy and security risks analyses performed by the members of the ROBERT and DP-3T consortia, namely:

61

Based on these criteria, and without questioning the exactitude of the findings of the two consortia, the following EphIDs could qualify as personal data for the purposes of this analysis (see Table 3 below).

62

Since we are interested in knowing whether the app user could qualify as a joint controller with the legally designated controller, we first consider the perspective of the app-user.

63

From this perspective, the diagnosed users’ EphIDs could qualify as personal data. The ROBERT and DP-3T consortia point out that, in both the centralised and decentralised protocols, diagnosed users’ EphIDs are vulnerable to re-identification attacks performed by other app users. The ROBERT consortium lists the following risks. [132] First, there is a risk that a “tech-savvy user” identifies “all infected individuals among encounters”, which occurs “when the adversary is able to find diagnosed users among all persons he has encountered during [the] contagious period”. [133] In this scenario, the attacker proceeds “by collecting pseudonyms of each person encountered, and then correlating this list of pseudonyms with the list of infected users’ pseudonyms published by the authority to determine when she was in contact with an infected person and use this information to reveal the identity of the infected”. [134] This attack, the members of the ROBERT consortium add, “only concerns the decentralised approach and is not possible in the centralised approach”. [135] Second, there is a risk that a “regular user” identifies “a targeted infected individual”. [136] This risk is materialised “by turning on the Bluetooth interface when in presence of the targeted individual, alone, then turning it off”. [137] It is described as being “also possible in centralised approaches when the set of encounters of the user is limited to the target only” [138] or in other more costly scenarios, such as when the attacker creates “an instance of the application (registered on the server) for each encountered person”. [139]

64

Similarly, although they do not explicitly assess the likelihood of this attack and define it as a risk inherent to proximity tracing systems that notify users that they are at risk, the members of the DP-3T project state that there is a risk that a “motivated attacker identifies the infected people that he has been physically near”. [140] This could be done by “combining two pieces of information: (1) who [he] interacted with at each time, and (2) that [he was] in close proximity to an infected person at a specific time”. [141] To learn who he interacted with, “the attackers keep a log of personal interactions. To learn “at which time he interacted with an infected person, the attacker proceeds in two steps: first, [he] creates multiple accounts in the proximity tracing system and uses them only for a short time […]; second, if a notification arrives, he examines the corresponding account. Since the account was only used during a fixed time window, the attacker now knows that he was in close proximity to an infected person during that period”. [142] Then, “by combining information from multiple time windows, the attacker can narrow down their list to a small group of people and, in some cases, single out infected individuals”. [143] In some cases (such as for example when the user had contacts with a very limited number of people), re-identification of the infected individual is even possible “without additional data gathering” . [144]

65

Since the ROBERT consortium rates the aforementioned attacks as “significantly likely” to be performed, [145] the diagnosed users’ EphIDs could be considered as personal data from the perspective of both the exposed and the at risk app users, under both a centralised and a decentralised approach. Exposed app users, as discussed in relation to the Breyer case in section 2.2.2, are actually able to perform the re-identification attacks outlined above given that they have received a notification of exposure. At risk app users, in turn, could potentially be notified of an exposure, thereby becoming an exposed app user and thereby acquiring the means to identify diagnosed users on the basis of their EphIDs. The functioning of digital proximity tracing indeed makes the latter possibility “reasonably likely” to happen, even though the EphIDs of diagnosed users would only actually become identifiable to the at-risk app users after they have received that notification (Table 3 below).

66

By contrast, since both the re-identification attacks described above can only be performed once an individual has been diagnosed positive to COVID-19, [146] the EphIDs of other app users would not qualify as personal data from the perspective of the app user.

67

It follows that, from the perspective of the app user, the following processing operations would qualify as processing operations on personal data:

68

While the backend server (as explained above) is usually appointed by law as the controller, and the rest of the analysis considers the backend server’s role as a controller as a given, in this paragraph we go beyond that legal fiction, to assess whether the users’ EphIDs would also qualify as personal data from the backend server’s perspective. We do so to illustrate one of the implications of combining the assessment of the “identifiability” of personal data with the one concerning (joint) controllership: potentially, an actor could qualify as a (joint) controller of data that, from that actor’s perspective, are not personal.

69

We first consider the diagnosed users’ EphIDs. When it comes to the centralised approach, it seems that the two consortia disagree on whether the backend server would be reasonably likely to re-identify the diagnosed individuals. According to the authors of the DP-3T protocol, the backend server can associate the EphIDs with their corresponding permanent identifiers, which could then “easily be related back” to their real identities. [148] Although the DP-3T members do not assess the likelihood of this event occurring, it follows that diagnosed users’ EphIDs would qualify as personal, albeit pseudonymous, data. [149] The ROBERT consortium does not specifically discuss the likelihood of such re-identification attacks in a centralized protocol. However, it estimates the likelihood of attacks that could potentially lead to indirect re-identification (e.g. linkability of identifiers on the server or location tracing through access to the sever) as “limited”, [150] in which case the diagnosed users’ EphIDs would not qualify as personal data. By contrast, while this contribution does not intend to assess the exactitude of the claims made by both consortia, it seems that, in a decentralised approach, the backend server is not in a position to link the diagnosed users’ EphIDs back to their identifiable form, since those are generated pseudo-randomly using the secret key created and stored on the app user’s phone itself. [151] As such, they would not qualify as personal data vis-à-vis the backend server. [152] While, one might argue that such a conclusion has been implicitly endorsed by the recent case law of the CJEU according to which access to the personal data is not a prerequisite to qualify as a controller, this nonetheless raises the issue as to the relationship between the entities through which the risk of re-identification must be assessed and the ones that determine the purposes and the means of the processing. As hinted in section 2.4.2, the findings of the CJEU and the EDPB seem to indicate that the question of the allocation of responsibilities should be dissociated from the one related to the existence of a processing of personal data. As a result, one might end up in a situation—like here—where a given entity determines the purposes and the means, and therefore acts as controller, of a processing of data that qualify as personal from the perspective of another entity, but not its own.

70

Second, the other app users’ (i.e. the non-diagnosed users’) EphIDs could qualify as personal data from the perspective of the backend server. Indeed, the conclusion drawn above as to the qualification of diagnosed users’ EphIDs would be equally applicable to other app users’ EphIDs.

Table 3- EphIDs as data relating to an identifiable individual