TY - JOUR
AU1 - Rubinstein, Ira, S
AU2 - Good,, Nathaniel
AB - Key Points In its simplest formulation, data protection by design and default uses technical and organizational measures to achieve data protection goals. Although privacy regulators have endorsed privacy-enhancing technologies or PETs for well over 30 years, Article 25 of the General Data Protection Regulation (GDPR) breaks new ground by transforming this idea into a binding legal obligation. But Article 25 as presently conceived is poorly aligned with privacy engineering methods and related PETs. This is especially true of ‘hard’ PETs that place limited trust in third parties (including data controllers) and instead rely on cryptographic techniques to achieve data minimization. In order to advance data protection in its own right rather than merely reinforce the general principles of the GDPR, Article 25 must be interpreted as requiring the implementation of privacy engineering and hard PETs. A bold way to achieve this is by mandating that data controllers use available hard PETs for data minimization. More gradual steps include data protection regulators insisting on a central role for privacy engineering and PETs in public sector projects; issuing guidance on Article 25 in very forceful terms that clearly require the implementation of ‘state of the art’ privacy technology; and using their enforcement powers to reward good examples of privacy engineering rather than to penalize failures. Introduction What requirements does the new European data protection law impose on regulated entities regarding the use of privacy technologies across all aspects of product development? When the European Union adopted the Data Protection Directive in 1995 it included a recital instructing data controllers to ‘implement appropriate technical and organizational measures’ for safeguarding personal data ‘both at the time of the design of the processing system and at the time of the processing itself’.1 Over the next quarter-century, this idea of designing in privacy from the outset took hold in both Europe and the USA. What then Ontario Privacy Commissioner Ann Cavoukian famously called ‘privacy by design’ (or ‘PbD’)2 progressed from a non-binding recital in Directive 95/46, to a recommendation of the European Commission (EC),3 the European Data Protection Supervisor (EDPS)4 and then the 32nd International Conference of Data Protection and Privacy Commissioners,5 to a proposed article in the General Data Protection Regulation (GDPR).6 The final text of the Regulation christened Article 25 as a new general obligation of controllers (and processors) to implement ‘data protection by design and default’.7 But what does this mean? In particular, does it require controllers and processors8 to embrace privacy engineering in full and adopt ‘state of the art’ privacy technologies and advanced cryptographic techniqes for protecting user data?9 Both privacy by design as originally conceived and the GDPR’s cognate idea of data protection by design and default have deep roots in privacy technology.10 This includes the early work of David Chaum on anonymous communications, unlinkable pseudonyms, and secure but untraceable payments.11 Chaum’s work is the foundation of what has come to be known as privacy-enhancing technologies or PETs. In developing a range of privacy protocols designed to shield users from various elements of online surveillance, Chaum and others relied on the recent invention of public key cryptography. In the 2000s, the privacy technology community expanded its focus and adopted a more general computer security character, considering the privacy properties of whole system rather than focusing primarily on cutting-edge privacy techniques using cryptographic primitives.12 More recently, privacy engineering has emerged as a discipline akin to but separate from security engineering. Thus, privacy by design as a regulatory initiative culminating in Article 25, and developments in privacy technology and privacy engineering, have progressed in tandem. Unfortunately, despite this similar trajectory, Article 25 offers little clarity about whether controllers and processors must implement privacy engineering and advanced privacy technologies or risk fines of up to €20M or 4 per cent of global annual turnover for failing to do so.13 Earlier privacy scholars criticized Cavoukian’s formulation of PbD as ‘vague’14 and ‘amorphous’.15 Similarly, scholars now bemoan the ‘extremely vague’ language of Article 2516 and the ‘legalese’ that both obscures its meaning and hinders its ability ‘to galvinize the engineering community to work in the direction wished’.17 In this article, we offer an interpretation of Article 25 that seeks to overcome these weaknesses by marrying it to privacy engineering and the consideration and adoption of ‘hard’ PETs (which are explained below).18 This reading of Article 25 is aspirational, emphasizing privacy engineering and technology rather than more policy- or process-oriented measures. Our claim is that only this interpretation of Article 25 ensures that it both accomplishes something useful in its own right, distinct from the general principles of the GDPR, and remains true to its roots in privacy technology. We offer three arguments in support of this claim. First, Article 25 as drafted has multiple shortcomings. It overlaps with several ‘accountability’ provisions in confusing ways; fails to define its scope; offers very few examples of relevant technical and organizational measures other than pseudonymization, which is a poor choice19; is written in vague and abstract language; and—probably in the name of technological neutrality—avoids any mention of specific privacy engineering methodologies, tools, or techniques, which only heightens the confusion over what the provision means or requires. Absent translation into engineering terms external to the GDPR or references to any relevant examples, Article 25 remains an empty abstraction that businesses will largely ignore except to claim credit for procedural measures. Secondly, Article 25 fails to address the crucial issue of trust assumptions. The PETs developed by Chaum and others place as little trust as possible in data controllers, or even treat data controllers as adversaries.20 This does not reflect a negative assessment of data controllers as ‘bad actors’ but rather an understanding that any information disclosure by an individual to a data controller represents a loss of control over personal information and thereby subjects the individual to a threat of persistent surveillance and other unwanted consequences (like tracking, profiling, sorting, and discrimination). Indeed, there is an ‘inner tension’ in the legal framework of data protection (the Fair Information Practice Principles or FIPPs and, by extension, the GDPR) ‘between principles that assume that data controllers are trusted entities, cognizant and respectful of individual rights (e.g., the principles of choice, purpose limitation, security and accountability), and principles that, …, treat data controllers with distrust (namely data minimisation and collection limitation)’.21 Thus, a key step in clarifying the meaning of Article 25 is spelling out its trust assumptions (which is also crucial to differentiating between ‘hard’ and ‘soft’ PETs). Finally, the mechanisms Article 25 relies on to ensure that it works in practice, namely, delegating and implementing acts, codes of conduct, and certification of IT products or services, have been removed from the final text of the Regulation or are ill-suited to the task. In fact, we argue that Article 25 as drafted is poorly aligned with privacy engineering methods and practices. This observation is central to everything that follows. Although other privacy scholars have debated the merits of Article 25,22 this article strikes out in a new direction by surfacing and analysing privacy engineering and relevant privacy technologies and realigning Article 25 with such measures, To this end, we develop a case study of online behavioural advertising (OBA) highlighting the differences between ‘privacy by policy’ and ‘privacy by architecture’.23 The former focuses on the implementation of notice and choice, a regulatory approach that many commentators have long rejected.24 The latter strives to minimize the collection of identifiable personal data mainly by technical means such as anonymization, client-side data storage and processing, and the use of hard PETs.25 The purpose of the case study is to show that unless regulators treat Article 25 as requiring privacy engineering and hard PETs, there will be no significant changes in the design of online advertising systems. More generally, if regulators use Article 25 to pivot from policy-based to architectural solutions, it seems far more likely that desired changes will occur in the design and development of products and services. This article proceeds as follows. We begin by analysing the text of Article 25 and its shortcomings along the lines spelled out above. Next, we offer a short primer on privacy engineering and PETs and then present the OBA case study. We also briefly consider newer challenges posed by artificial intelligence (AI) and automated decision-making and the potential contribution of PETs in resolving them. Finally, we take issue with the GDPR’s proposed methods for filling in the gaps in Article 25 and offer a few modest suggestions about steps regulators might take to ensure that Article 25 more fully aligns with privacy engineering and hard PETs. Article 25 and its deficiencies Article 25 does a poor job of telling system designers and developers what it requires or ensuring the adoption of privacy engineering methodologies and rigorous PETs.26 It has five main weaknesses. Before turning to them, it is important to consider whether ‘technology neutrality’ dictates the abstract and general language of Article 25. Technology neutrality arguably favours broad statutory language to avoid discriminating against certain technologies (and thereby stifling innovation) or becoming out of date too soon (and thereby requiring frequent amendment).27 As Koops and others have noted, technology neutrality is a starting point for regulating technology but more than one legislative approach may be required to achieve its objectives.28 For example, electronic signature laws have generally followed an implementation neutral approach that treats various ways of signing documents in a similar manner.29 On the other hand, protecting fundamental rights during a shift from offline to online technologies may require technology specific rules for the online environment.30 Anti-circumvention laws are a good example: they seek to protect copyright holders against circumvention of digital rights management systems that (attempt to) make it technically impossible to illegally copy a copyrighted digital work.31 Legislators have sometimes failed to heed the principle of technology neutrality with awful results. In Europe, this dubious honour belongs to the ‘Cookie Directive’ (2002/58/EC), which imposed consent requirements on cookies while ignoring a number of alternative technologies that track and trace online behaviour, thereby demonstrating that ‘overly specific regulation of a particular technology may miss its target precisely because of its specificity’.32 Article 25 avoids these pitfalls by taking a very broad view of ‘technical and organisational measures’ and ‘design’ and ‘default’ and by avoiding any mention of specific technologies or methodologies. And yet it suffers from an overall lack of clarity regarding the best techniques for achieving its goals. To be clear, we are not advocating that Article 25 abandon technology neutrality by endorsing specific privacy engineering methods, tools, or techniques. Rather, our claim is that technology neutrality is no excuse for inadequate drafting. Now to the five weaknesses. First, there is too much overlap between Article 25 and other parts of the GDPR. This results in confusion and uncertainty. Data controllers have always had to satisfy the general conditions for data processing set out in Directive 95/46 and necessarily have implemented technical measures to do so. In particular, Article 5 mandates that any processing of personal data should be lawful, fair and transparent, and subject to a set of familiar data protection principles. Articles 5(1)(e) (storage for archival purposes) and Article 5(1)(f) (security of personal data) already explicitly require ‘technical and organizational measures’ and Article 5(2) makes controllers responsible for demonstrating compliance with these requirements. Articles 24, 28, and 32 also require data controllers and processors to adopt technical and organizational measures. So, what is the specific contribution of Article 25 to these existing obligations? Nor is it helpful that Article 25 addresses both technical and organizational measures. Granted, Cavoukian conceived of PbD in terms of software or hardware design, business strategies and other organizational practices.33 But these measures are quite distinct and different actors implement them. System designers are responsible for incorporating technical measures into systems via technical choices that may include selecting and applying a specific design pattern or privacy protocol, while data protection officers are responsible for integrating management practices and operational processes into the structure of an organization.34 There are ample GDPR provisions addressing organizational measures including Article 30 (maintaining records); Article 35 (carrying out a data protection impact assessment); Article 36 (complying with the requirements for a prior consultation); and Article 39 (performing the many other tasks of a data protection officer). But these are all accountability measures and to that extent nothing new given that the revised OECD Privacy Guidelines covered similar ground.35 Article 25, on the other hand, is the only GDPR provision directly addressing design. At the very the least, the mixing of technical and organizational measures in Article 25 dilutes the force of this provision. It both undermines the longstanding connection between privacy by design and privacy technology and invites controllers to emphasize accountability measures (which they have voluntarily undertaken for many years) rather than embracing PETs and privacy engineering and hard PETs (which they have not). Secondly, Article 25.1 is not clear about its scope. The only data protection principle it mentions explicitly is data minimization. But Article 5 (‘Principles relating to processing of personal data’) is much broader. In particular, Article 5.1 requires that any processing of personal data should be lawful, fair and transparent, and subject to such general principles as purpose limitation, data minimization, accuracy, storage limitation, and integrity and confidentiality. Are these principles also within the scope of Article 25.1? Undoubtedly.36 What about the rights of data subjects identified in Chapter III such as the right to transparency, access, rectification and erasure, data portability, and to object to data processing and not to be subjected to a decision based solely on automated processing? Are controllers obligated to uphold these rights by implementing technical and organizational measures? What about the responsibilities and compliance obligations of controllers and processors as set forth in Chapter IV of the Regulation? Article 25 is only one of eight ‘General Obligations’ in section 1 of Chapter IV, or one of 14 such obligations if we also consider sections 2–4, which describe additional tasks related to data security, data protection impact assessments, and the designation and tasks of data protection officers.37 Do all of these obligations require technical and organizational measures too? Some commentators have argued that the weight of the entire Regulation rests on the shoulders of Article 25.1.38 Others view it as ‘a catch-all provision with no specific requirements on its own’.39 In any case, the scope of Article 25.1 remains uncertain. Thirdly, Article 25.1 offers only one example of a technical or organizational measure, namely, pseudonymization. But this is a very poor choice. During the debate over the GDPR, the behavioural advertising industry hoped that pseudonymized data would be left outside the scope of the Regulation, but many opposed their position.40 As then Commissioner Viviane Reding warned, ‘pseudonymous data must not become a Trojan horse at the heart of the Regulation, allowing the non-application of its provisions’.41 For its part, the Article 29 Working Party opposed the introduction of pseudonymous data as a new category of personal data and while it did not win that argument, it did ensure that in the final text of the Regulation, Article 4(5) and Recital 26 would treat pseudonymous data as a form of personal data. Most importantly, pseudonymization offers much weaker privacy protection than anonymization. So why use it as an example of data protection by design without mentioning anonymization or even alluding to the use of advanced cryptographic protocols associated with data minimization? Fourthly, Article 25.1 mandates that controllers implement ‘appropriate’ technical and organizational measures and do so ‘in an effective manner’ but this is quite vague.42 Some commentators have argued that these words impose on controllers a positive obligation to act and that this is ‘an obligation of result’.43 But which results? They also state that the use of the word ‘appropriate’ implies ‘the contextual and dynamic’ nature of Article 25 and that in practice this ‘changes and depends on the identified risk’.44 This is fine as far as it goes. (We discuss the risk-based approach in greater detail below.) But when data controllers face architectural and engineering choices such as those described in the case study, does Article 25 offer any guidance on policy versus architectural options? Granted, Recital 78 suggests a number of measures controllers might choose to adopt such as ‘minimising the processing of personal data, pseudonymizing personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features’. But these suggestions remain very high level and fail to resolve the ‘inner tension’ in the GDPR noted above between data protection principles that treat data controllers as trusted or untrusted entities. Fifthly, Article 25.1 is insufficiently prescriptive about the design process as applied to privacy. In other words, it fails to establish a clear baseline for what it means to design privacy controls.45 This objection will no doubt provoke a counterargument to the effect that Article 25.1 addresses design by requiring that controllers (i) adopt a risk-based approach that weighs all the elements listed in the multifactor test of its opening clause including the ‘state of the art’ and (ii) take appropriate organizational and technical measures ‘at the time of the determination of the means for processing and at the time of the processing itself’, ie throughout the data processing lifecycle.46 We discuss technical measures in the next section. Here, we focus on a narrow point—the meaning of ‘the state of the art’, which is the first element of the multifactor test, and a broader point—the failure of the ‘lifecycle’ approach to account for the practical realities of software development. Article 25.1 imposes a multifactor test requiring data controllers to ‘take account of the state of the art, the costs of implementation, the nature, scope and context of the processing, and the risks to rights and freedoms’. Some commentators read this as forcing controllers to implement available technical solutions if the cost is not prohibitive. ‘Once technical solutions for particular legal obligations are on the market at a reasonable price, data controllers will have to use them or implement their own equivalent or better solutions.’47 But this seems overly optimistic. In fact, Article 25 does not offer any guidance on what ‘state of the art’ means. For lawyers, this term calls to mind a doctrine in product liability law under which a producer is not liable if ‘the state of scientific and technical knowledge at the time when he put the product into circulation was not such as to enable the existence of the defect to be discovered’.48 The state of the art defence usually arises in respect of medical diagnoses and therapies, mass torts involving asbestos or chemicals, and drug manufacturers.49 Leading cases suggest that the doctrine only applies when it is impossible for the producer to discover the defect ‘on the basis of the objective state of the available scientific and technical knowledge including that at the most advanced level and not restricted to the relevant industrial sector’.50 However, it is not clear that product liability law has sufficient application to harms associated with privacy violations to offer much assistance in interpreting Article 25.1, at least not without a lot more elaboration. Waldman argues that in the context of US product liability law, the design defects doctrine clarifies what privacy by design could (and should) mean in practice.51 This is an important insight, but Waldman does not apply it to European product liability law. Nor shall we do so here. A second way of understanding ‘state of the art’ seems more immediately useful. As some commentators rightly note, state of the art is a quality requirement that serves as ‘a benchmark requiring controllers to explore the most recent developments and knowledge associated with data processing’.52 This includes standards, technology (both software and hardware), cybersecurity, and, research. While correct, this observation is insufficient. Designers of privacy controls also need a benchmark measuring the maturity of specific PETs. ENISA has sponsored research to develop a measure of PET maturity based on a combination of technology readiness and privacy enhancement quality.53 This approach generates a matrix of 30 possible maturity level values, thereby allowing comparisons of PETs with higher readiness/lower quality and those with lower readiness/higher quality. ENISA hopes to see an independent, transnational organization emerge to assess a wide range of PETs using this maturity scale. This group might also maintain a repository of assessments that would enable Data Protection Authorities (DPAs) and others to provide controllers with a catalogue of best available techniques in the field of PETs. This seems like an eminently practical way of communicating what state of the art means for purposes of technical measures under Article 25.1. Finally, we offer a few comments on the requirement that controllers implement data protection by design ‘at the time of initiating the processing and at the time of processing itself’. This phrasing emphasizes the ongoing nature of a controller’s obligations under Article 25.1, which start with the design of a product or service and persist throughout the entire lifecycle of any data processing. One problem with the lifecycle approach is that it applies to controllers (and indirectly to processors) but not to the developers of products and technology used to process personal data. Recital 78 encourages developers ‘to take into account the right to data protection when developing and designing … products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations’ but this falls short of a legal mandate. The EDPS recently suggested that in light of Recital 78, ‘the application of Article 25 would require the provider to design their products in such a way as to enable the controller to put in place all the necessary measures needed to protect the individuals and their data’ (emphasis added).54 Obviously, this is an overstatement—recitals do not impose legal obligations. Granted, developers may have an economic incentive to offer products they characterize in terms of privacy by design. But customer demand has long proven insufficient to create a robust market in PETs.55 The EDPS firmly believes that ‘a convincing and sustained commitment to privacy by design should be considered a competitive advantage’.56 As Bygrave notes, however, it remains unclear if controllers ‘have the necessary market power to stimulate the generation of PETs and PbD products/services’ or if Article 25 can overcome ‘pervasive methods of business and government that are fundamentally at odds with strong forms of privacy hardwiring’.57 A final problem is that the lifecycle approach seems out of date in view of what Gürses and van Hoboken call the agile turn, which dispenses with the regimented and lengthy phases, extensive documentation, and detailed planning and management associated with the ‘waterfall’ method of development in favour of continuous coding and testing, team communication and highly visible progress over much shorter periods (weeks versus years, or even multiple times a day).58 Thus, Article 25’s emphasis on the lifecycle approach seems out of touch with increasingly popular agile methods. A roadmap to privacy engineering and PETs How might controllers, processors and software developers go about translating the GDPR’s core principles into concrete design requirements and methodologies? This is the task of privacy engineering, which we explore below by briefly summarizing four important contributions to the field. We then examine hard and soft PETs. Privacy engineering In a classic article, Gürses, Troncoso, and Díaz emphasize the central role of data minimisation in privacy by design, arguing that only data minimization provides strong technical guarantees of privacy as opposed to policy commitments more honoured in the breach than in the observance.59 They provide case studies of e-Petitions and electronic toll pricing to show in concrete terms how a design process guided by the principle of data minimization can reduce privacy risks, avoid function creep, and limit the disclosure of sensitive information. Both case studies begin with a ‘straightforward’ implementation of the system and then contrasts it with a ‘privacy-preserving’ alternative that reduces privacy risks by embracing data minimization through the use of advanced cryptographic protocols. The OBA case study follows a similar approach. The authors also describe in general terms the five main steps followed in their two case studies to arrive at privacy-protective outcomes: functional requirement analysis (which elicits well defined and feasible goals); data minimization (which in most cases relies on privacy-preserving cryptographic techniques); threat modelling (which identifies potential attacks and subjects them to risks analysis); multilateral security requirements analysis (which helps ensures the compatibility of privacy measures and security objectives); and implementation and testing of the design (which is an iterative process that revisits earlier steps and revises them as necessary based on the risk analysis).60 Hoepman builds on and generalizes this early contribution by identifying eight privacy design strategies for achieving privacy protection.61 The eight strategies are: minimize, separate, aggregate, hide, inform, control, enforce, and demonstrate. For each design strategy, he then identifies appropriate PETs, which developers may utilize to implement ‘privacy design patterns’—ie commonly recurring structures that solve a general design problem within a particular context.62 For example, the most basic privacy design strategy is to minimize (ie restrict the processing of personal data to the minimal amount possible), and the common design patterrns that implement this strategy are select before you collect, anonymization, and use of pseudonyms.63 The second design strategy is hide (ie hide personal data and their interrelationships from plain view) and the common design patterns include encryption, mix networks, attribute-based credentials, and anonymization and use of pseudonyms (which partially overlaps with the minimize strategy). Thus, PETs are useful in implementing design patterns with concrete technology.64 Hoepman’s position is that privacy design strategies make explicit the range of approaches, methods, and tools now available to protect privacy when designing systems. For each privacy design strategy the appropriate privacy design patterns and related PETs can be leveraged to enable the implementation of a system that preserves privacy. Antignac and Le Métayer favour an architectural approach to privacy by design, thereby shifting attention from technologies and components (PETs) to architectures and methodologies.65 The authors define the architecture of a system as ‘the set of structures needed to reason about the system, which comprise software and hardware elements, relations among them and properties of both’.66 They suggest that architectures matter to privacy by design for several reasons. First, architectures are a carrier of the earliest and hence most fundamental design decisions; thus, overlooking architectural choices may ‘seriously hamper the integration of privacy requirements in the design of a system’.67 Secondly, architectures channel the creativity of developers, reducing design and system complexity. They make it possible ‘to abstract away unnecessary details and to focus on critical issues’, thereby helping privacy designers reason about privacy requirements and the combination of PETs which could be used to meet them’. Thirdly, a documented architecture enhances communication among stakeholders. Thus, documenting design choices is especially important in the context of organizations needing to satisfy the legal obligations arising from the Privacy Impact Assessments (PIA) and accountability requirements under the GDPR. Finally, architecture enables the creation of ‘a transferable, reusable model: architectures can therefore play a key role to increase the reusability of privacy friendly solutions, which could lead to significant cost reductions and better dissemination of knowledge and expertise among developers’.68 Finally, we consider PRIPARE, a method to integrate existing privacy engineering best practices into the design process.69 The PRIPARE Handbook captures and integrates existing privacy standards, practices and research proposals and describes in detail seven methodological phases of privacy engineering: analysis, design, implementation, verification, release, maintenance, and decommission.70 The two most important phases for present purposes are analysis and design. The former consists in deriving privacy requirements using a risk-based approach informed by applicable legislation and users’ privacy expectations and typically involves the controller conducting a PIA.71 The latter consists in two intertwined processes for developing privacy controls: a privacy enhancing detailed design that selects suitable techniques (including PETs) according to the system requirements and instantiates them based on specific system characteristics and a privacy enhancing architecture ‘capable of achieving the system’s business objectives but ensuring that privacy and security quality requirements are also fulfilled’.72 PETs In contrast to privacy engineering, PETs are the tools or techniques for achieving privacy by design. The following paragraphs explain the distinction between hard and soft PETs, provide some illustrations, and show why this distinction is so crucial to understanding—in engineering terms—what Article 25 requires. The set of currently available PETs is large and diverse. Moreover, there is no consensus about how to group them most effectively. Diaz, Tene, and Gürses limit the scope of PETs ‘to technologies designed to provide privacy protection from untrusted and potentially adversarial data controllers’.73 For present purposes, a two-part classification of PETs suffices depending on whether they seek hard privacy or soft privacy. As Le Métayer explains: ‘hard privacy tries to avoid placing trust in a third party (or to reduce this trust), while soft privacy is based on the assumption that the subject will lose control over his data and therefore has no choice but to place a certain amount of trust in the data controller’.74 Another difference between hard privacy and soft privacy is that they assume different threat models. As Deng and others further explain, ‘A stepping stone of security and privacy analysis is threat modeling, i.e., the “black hat” activity of looking into what can possibly go wrong in a system.’ Threats are crucial to the definition of the requirements and play a key role in the selection of the countermeasures’ including PETs.75 The threat model for hard privacy ‘includes service provider, data holder, and adversarial environment, where strategic adversaries with certain resources are motivated to breach privacy, similar to security systems’; for soft privacy, the system includes the data subject and the data controller responsible for data protection but ‘a weaker threat model applies, including different parties with inequality of power, such as external parties, honest insiders who make errors, and corrupt insiders within honest data holders’.76 PETs that share the trust assumptions and threat models of hard privacy—hard PETs—are mostly about data minimization.77 They seek to avoid any disclosure of personal data (or at least reduce it as much as possible) and to ensure this outcome by relying on a small but powerful set of cryptographic protocols. These protocols have seemingly contradictory—and to a layperson even magical—properties. They include anonymous communication channels (which hide users’ IP addresses from service providers yet allows communication); selective disclosure credentials (which allow users to authenticate themselves and prove that they are authorized to use a system without revealing additional information); zero-knowledge proofs (which allow one party to prove to another that a statement is true, without revealing anything other than the veracity of the statement); secure multiparty computation (which allows group computation where only the result is revealed); private information retrieval (which allows an individual to query databases without revealing the query); cryptographic commitments (which allow users to commit to a value without having to disclose it, while binding users to a value in such a way that they cannot claim having committed to a different value); and homomorphic encryption (a form of encryption that allows computation on encrypted data without requiring access to a secret key).78 Industry has mostly steered clear of hard PETs and there are few commercial implementations for various reasons: lack of familiarity and expertise with the relevant cryptographic protocols; implementation and switching costs; usability issues; performance trade-offs; and an inability to internalize these other costs by charging higher prices.79 Bygrave makes a similar point when he observes that strong PETs ‘can collide with the the basic logic of the “internet economy” …, which is based largely on the monetization of monitoring’.80 On the other hand, PETs that share the trust assumptions and threat models of soft privacy—soft PETs—are mostly about data management. They consist in tools that help users make good decisions about sharing their data with service providers while satisfying informed consent requirements (eg languages to express policy preferences like P3P, cookie management tools, privacy dashboards, and advertising icons). They also help data controllers enforce the rights of data subjects, such as the right of access or data rectification and erasure (eg technology that tags and deletes data when an expiration date has passed), while demonstrating compliance (eg auditable secure logs).81 Thus, soft PETs support the aims of data protection law by enforcing the rights of data subjects who must decide (or have already decided) to share their personal data with service providers but do not protect them from untrusted data controllers or strategic adversaries.82 Industry has embraced soft PETs and there are many commercial implementations. The reason is simple: soft PETs neither disrupt exisiting business models nor exhibt any of the detriments associated with hard PETs. Soft PETs are sometimes referred to as ‘privacy-friendly’ but they are also ‘business-friendly’ because their use tends to enhance a firm’s reputation for trustworthiness while imposing minimal restrictions on data collection and analysis. Consequently, many in the privacy engineering community insist that unless PETs ensure data minimization based on technical guarantees, they are unworthy of the name and should be rejected out of hand.83 Does Article 25 obligate data controllers to adopt not only soft PETs, but also hard PETs, assuming they are both available and suitable for the task at hand? The case for mandatory adoption rests on four pillars: first, Article 5.1(c), which unambiguously states that personal data shall be ‘adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (“data minimisation”)’; second, Article 25, which explicitly requires that data controllers shall implement ‘appropriate technical and organisational measures’ that ‘implement data-protection principles, such as data minimisation, in an effective manner’; third, the effectiveness of strong technical guarantees over vague policy commitments; and fourth, the availability of hard PETs satisfying this requirement. Le Métayer has demonstrated in exhaustive detail that hard PETs enforcing the data minimization principle are both available and highly suitable to a variety of tasks.84 He subdivides data processing into four main services—communication services (such as email), access services (which require users to show they are authorized to get access to a service), computation services (which encompass a variety of situations in which a user needs to get a service from a third party and this service requires a computation), and exploitation of databases, and then describes in detail the hard PETs associated with each of them. So a broad range of hard PETs do exist and they can provide strong privacy guarantees of data minimization (which suggests they should be mandatory under Article 25). Before concluding this primer, it is important to note that European data protection regulators are very familiar with both privacy engineering and PETs. In addition to relevant Commission reports and Article 29 Opinions, ENISA recently retained a group of EU experts in privacy engineering to write a study of how to implement privacy by design using engineering methods.85 The ENISA Report provides a detailed analysis of the technical aspects of privacy by design. It offers data protection authorities a guided tour of currently available technologies and methods.86 Both the Norwegian Data Protection Authority’s guidance on how to comply with Article 25 and the European Data Protection Supervisor’s preliminary opinion on Article 25 cite the ENISA Report.87 One of our recommendations is that regulators do even more to endorse and promote this work. OBA case study Why is OBA the inevitable choice for a case study of Article 25? For over 20 years, online profiling and targeted advertising have been at the centre of the debate over consumer privacy. This makes it a perfect test case for evaluating the efficacy of Article 25. Either it does more to protect data subjects against profiling than the GDPR absent a privacy by design mandate or Article 25 accomplishes very little. As developed below, the OBA case study presents two very different approaches to implementing and running OBA systems. To highlight the differences at the extremes, we contrast a self-regulatory approach that relies on procedural principles (mainly transparency and consent) with a privacy-preserving approach that relies on hard PETs. However, it is not our goal to determine the best way to design OBA systems or to defend the intrinsic merits of procedural versus architectural approaches. Rather, the case study helps illustrate the enhanced protection that privacy engineering and hard PETs offer as compared with systems that enhance transparency and consent without otherwise changing how OBA works in practice. OBA and privacy OBA’s business model is simple: monetize eyeballs on webpages. In the early days of OBA, there were few constraints on how OBA systems collected and used personal data. Moreover, OBA proved resistant to regulatory oversight. And its success created a vicious circle to maximize profits by amassing ever greater quantities of data. But as the industrial designer Charles Eames once stated, ‘design depends largely on constraints’.88 If this is correct, OBA systems developed in conformity with Article 25 should operate quite differently than those in which privacy is treated as a matter of procedural compliance. OBA enables advertisers to serve relevant ads to specific users based on how they browse the web and interact with a wide range of web sites. Advertising networks assist publishers in serving such ads by tracking and targeting users based on their web browsing habits, interests, and preferences across a wide range of websites. These ad networks engage in third-party tracking by assigning an identifier to a user (such as a third-party cookie) and tracking the attributes of viewed pages across all of the publishers that partner with the network.89 Thus, third-party web tracking amasses data on the blogging, chatting, dating, photo sharing, searching, shopping, social networking, and streaming activity of users at thousands of popular web sites. Because tracking and targeting rely on massive data collection and processing, these practices have obvious privacy implications. They also raise separate concerns about discrimination90 and manipulation (including voter manipulation).91 By tracking and monitoring consumer behaviour and activities, ad tech firms build digital profiles of surprisingly detailed and intimate information about our personal lives. OBA’s privacy-invasive practices are exacerbated by three additional trends. First, the proliferation of smartphones, which enable mobile data collection on a nearly constant basis including sensitive location data. Secondly, the integration of online data with offline data scooped up by data brokers including both public records (such as property records, court records, driver’s license and motor vehicle records, Census data, birth certificates, marriage licenses, divorce records, state professional and recreational license records, voter registration information, bankruptcy records, and so) and purchase histories (including the dates, dollar amounts, payment used, loyalty cards, coupons used, etc.). Third, the consolidation of major online services in a handful of dominant companies that have not altered their practices despite ever larger fines and growing public censure.92 Other intrusive OBA practices include retargeting (showing ads to consumers across the web after they leave an initial website without making a purchase) and cross-device matching (tracking users on multiple devices such as smartphones, laptop, tablets, smart TVs and so on, thereby enabling advertisers to profile specific individuals across all of their connected devices). Regulatory response Advertising firms in Europe and the US have sought to allay these privacy concerns through self-regulatory initiatives based on well-established data protection principles.93 In addition, the ad industry sponsors web sites like Your Online Choices to provide clear and understandable information to consumers about targeted ads, a mechanism to exercise choice and control over one’s advertising preferences, and a mechanism for filing complaints.94 Similar initiatives have gained traction in the U.S., where Congress has had little success enacting privacy laws regulating online advertising and industry groups and privacy advocates have failed in their efforts to reach agreement on Do Not Track (DNT) proposals (which differ depending on whether DNT blocks tracking or merely block ads based on tracking). The regulatory context is quite different under European data protection law, however. As compared with US privacy laws, the GDPR raises significant legal obstacles to targeted advertising.95 In preparation for the GDPR, commentators have asked whether GDPR compliance necessitates abandoning targeted advertising in favour of contextual and other non-targeted approaches.96 A recent decision of the Commission nationale de l’informatique et des libertés (CNIL) involving a French ad tech firm called Teemo indicates that firms using targeted advertising will have to modify their consent practices to avoid fines.97 On 12 September 2018, an Irish privacy group lodged a complaint with Irish Data Protection Commission seeking to trigger an EU-wide investigation regarding certain practices of the behavioural advertising industry.98 This sparked a heated rebuttal from industry lawyers.99 At the same time, European regulators are moving ahead with a draft ePrivacy Regulation. Advocates have criticized recent revisions for watering down various safeguards around OBA,100 and even industry lawyers have begun to express hope that the latest draft is not as ‘scary’ (ie restrictive) as it might have been.101 In the midst of this activity, IAB Europe, the leading European online advertising industry association developed (and recently revised) a ‘Transparency & Consent Framework’ (TCF) intended to support publishers, technology (or ‘ad tech’) firms, and advertisers in meeting the GDPR’s transparency and user-consent requirements.102 For the most part, the TCF standardizes the process of providing notice to users, obtaining their consent for data processing, and relaying this information from publishers to other vendors in the advertising supply chain (including ad tech firms with no direct customer relationship with users).103 Commentators have identified several weaknesses in the IAB framework.104 To begin with, users may be unwilling to consent to sharing their data with multiple unknown ad tech firms for behavioural advertising purposes. While users are in the habit of ignoring notices and clicking ‘OK’ to consent requests, they may balk at the IAB’s required transparency and consent UI (user interface), which displays rather detailed disclosures regarding the purposes for data processing, the features used by vendors to support the data processed by third parties, and the options for exercising choice/consent.105 Additionally, the framework offers limited controls over what happens to a user’s personal data once it enters a real-time bidding system. Nor is it clear that the framework complies with the GDPR. In particular, the TCF may not satisfy Article 5’s requirement that consent requests indicate a ‘specified, explicit’ set of purposes. And the CNIL’s Teemo decision suggests that the framework may violate Article 6 (lawfulness of processing) and Article 13 (information to be provided where personal data is collected from the data subject) by allowing publishers to bundle all consents under a single ‘OK’ button. As a result, several distinct purposes are combined without indicating exactly what will be done with the user’s personal data. Whether or not the TCF clears these legal hurdles, it may not change how consumers view OBA, especially if publishers or ad tech firms game the system by using an all or nothing approach to consent that gives them free reign over their use of consumer data. Research shows most people (roughly 60 per cent) find take-it-or-leave it choices ‘neither acceptable nor fair when websites use tracking walls’.106 In an EU-wide survey, 58 per cent agree that ‘[t]here is no alternative than to provide personal information if you want to obtain products or services’.107 Similarly, surveys in the US show that ‘a majority of Americans are resigned to giving up their data’ and believe it is ‘futile to manage what companies can learn about them’.108 Case study The case study contrasts two illustrative firms: Firm A, an ad tech firm that assists advertisers and publishers with targeted advertising and hopes to thrive in the GDPR era without modifying the OBA business model, and Firm B, a start up whose founders see the GDPR as a business opportunity based on their prior research into privacy-preserving forms of OBA. They illustrate two very different ideas of what it means to comply with Article 25. In keeping with IAB Europe’s Transparency & Consent Framework, Firm A plans to operate a consent management platform (CMP) that will collect consumer consents and pass them to participating advertisers and publishers. Consumers visiting sites that have implemented Firm A’s CMP will see various user interface (UI) options such as pop-ups or banners. These UIs provide transparency into the purposes and features of data collection and use and seek the consent of consumers to such collection and use for specific purposes and features while providing easy access to more granular privacy options from the same interface. Their consent choices will then be applied when consumers engage with the rest of the publisher’s website, and other sites and vendors using the IAB Europe Framework. The privacy researchers at Firm B have concluded that the GDPR consent requirements, in combination with the upcoming e-Privacy Regulation, spell the end of consent-based OBA.109 Nor does the IAB framework alter their analysis. Thus, they decide to commercialize and license ObliviAd, an OBA architecture ‘that preserves the privacy of user profiles, is compatible with the existing business model, supports arbitrary ad-selection algorithms, and provides high performance.’110 ObliviAd is available as a browser extension that allows ‘client-side’ targeting (the analysis of behavioural data for purposes of showing targeted ads) but does not require ‘server-side’ tracking (the collection and aggregation of behavioural data by advertisers, publishers or third-party intermediaries or ‘brokers’).111 The authors describe ObliviAd as ‘a provably secure architecture for privacy preserving OBA’ and identify its distinguishing features as ‘the usage of secure hardware-based private information retrieval for distributing advertisements and high latency mixing of electronic tokens for billing advertisers without disclosing any information about client profiles to brokers’.112 Although there are other privacy-preserving OBA solutions, the founders hope that advertisers and publishers will find ObliviAd attractive because it provides strong privacy guarantees and low computational overhead without disrupting the advertising ecosystem or unduly restricting the financial gains the industry associates with targeted ads. Lessons learned In response to the GDPR, controllers and their technology vendors may wonder if procedural solutions still suffice or whether Article 25 requires systems that implement privacy-preserving technology. The recent CNIL decision and Irish complaint provide some support for procedural solutions (assuming they satisfy the transparency and consent requirements of the GDPR). But this legal response has limited value to developers who must translate Article 25 into engineering terms. Parsing the principles set forth in Chapter II of the GDPR will not assist them. Nor does Article 25 provide the clear guidance they need to decide between procedural solutions along the lines of Firm A or privacy-preserving solutions along the lines of Firm B. Without such guidance regarding the constraints on the use of personal information, firms will predictably gravitate towards familiar procedural solutions that are less likely to disrupt existing business processes and revenue sources. Of course, the ad tech industry may perceive enough value in the ‘privacy by design’ slogan to treat a procedural solution based on the IAB TCF as granting them bragging rights. But this is misleading because ‘adopting technologies that can aid in auditing or enforcing policy compliance’ is just another form of privacy by policy; it is not privacy by architecture.113 And even though the TCF reflects the use of a design methodology, its fundamental design decision is to maintain business needs while adhering to some GDPR requirements and ignoring others such as data minimisation. The TCF grants users some choices about targeting but does not necessarily protect them from tracking. In sharp contrast, Firm B’s engineers explore the availability of PETs that can achieve the dual—and seemingly contradictory—goals of targeting without tracking. ObliviAd utilizes several cryptographic protocols and security techniques that reveal enough information to meet core advertising business requirements such as targeting, fraud detection, and accurate billing, while hiding personal information from those not requiring it. Thus, brokers are prevented from associating clicked ads with an individual’s personal data (including IP address) or linking separately clicked ads with a single user. There are undoubtedly costs to businesses that would adopt this solution, but the point of this case study is not to persuade firms that they ought to do so. Rather, it is to illustrate the differences between policy and architectural solutions, the feasibility of a privacy-preserving approach to OBA, and the lack of guidance in Article 25 as to which option it requires. Regulators implementing Article 25 face the difficult challenge of maintaining technology neutrality while still providing enough guidance to an enormous range of firms in diverse industries. In the OBA case study, Firm A may believe that its chosen direction achieves compliance and yet procedural solutions inevitably fall short of the spirit if not the letter of Article 25’s design requirement. Firm B offers a more rigorous technical solution that comprehensively addresses the privacy issues at hand, even if it exceeds the overt requirements of data protection law. In any case, the key point going forward is that regulators refrain from mandating any specific technologies while encouraging and rewarding firms that develop best-of-breed technological solutions that fit their industry, without completely disrupting existing business models.114 But if this is what regulators truly want, they will need to do much more to motivate business models that align with PETs and privacy engineering.115 Regulators must convey to firms the constraints and expectations under which they must design or adapt their products and services to conform with Article 25. Otherwise, firms will choose the path of less resistance, and few will adopt a privacy engineering or PET-based approach in the spirit of Chaum and his successors. The online advertising industry is currently undergoing a great deal of regulatory scrutiny. The UK ICO recently stated that ad networks will have six months to further address privacy concerns, after which the ICO will commence enforcement actions. The French DPA and the Irish DPA have stated that they will be looking at ad networks as well. The ICO explicitly refers to the need for changing the technology, processes and business models driving the ad industry. From a regulatory perspective, this signals an opportunity to move beyond procedural approaches to privacy engineering as a core concept in designing ad networks. Simon McDougal of the ICO implied as much when he recently stated: ‘There is a real opportunity for the industry to develop new practices and business models.’ 116 Confronting new challenges The OBA case study, which highlights the differences between procedural versus technical approaches to OBA, may have a slightly dated feel given that regulators have been thinking about cookie-based profiling for over 20 years without achieving much progress. Even architectural solutions such as ObliviAd seem like vestiges of former troubles rather than indications of solutions to current or future problems. In comparison, Big Data and Artificial Intelligence (AI) raise a much newer set of challenges. Data analytics and AI draw on highly diverse and feature-rich data sets to support a wide variety of inferences and predictions about the behaviours, preferences, and private lives of individuals.117 These inferences may result in discriminatory, biased or invasive decision-making. More than advertising and shopping are at stake but also credit, housing, employment, health care, social services, law enforcement and other highly consequential activities.118 There is an inherent tension, however, between Big Data and key GDPR principles such as purpose limitation, data minimization, sensitive data, and automated decision making.119 Although EU officials express confidence that the GDPR as is can both protect privacy as a fundamental right and promote the many positive aspects of data analytics,120 not everyone is persuaded. Thus, privacy scholars have called upon regulators to encourage the adoption of new business models premised on consumer empowerment;121 or proposed new ways of interpreting the GDPR emphasizing use-based regulation;122 or turned to the European Court of Justice to recognize a new ‘right to reasonable inferences’;123 or developed new ‘ethical’ approaches to AI accountability and justification.124 While all of these discussions express scepticism over the GDPR’s capacity to address emerging privacy concerns associated with Big Data and AI, for the most part they fail to consider the potential contributions of privacy engineering and PETs. We conclude this case study with a brief treatment of a new class of privacy-preserving tools that are well-positioned to address these concerns, even if GDPR principles prove incompatible with this new data environment. We begin by noting that businesses in the sharing economy as well as dominant industry players such as Google, Apple and Microsoft have lately begun experimenting with privacy-preserving approaches to data analytics. Most of these new techniques are based on differential privacy, a rigorous mathematical definition of privacy that seeks to maximize the accuracy of queries over statistical databases while minimizing the likelihood of exposing individuals’ information.125 Differential privacy is ‘rooted in the idea that carefully calibrated noise can mask an individual user’s data. When many people submit data, the noise that has been added averages out and meaningful information emerges’.126 In layman’s terms, differential privacy facilitates data analysis over aggregate trends without jeopardizing an individual’s data privacy. Many data analysis use cases are mainly concerned with aggregate trends making them good candidates for new techniques that introduce noise to protect individuals. Recent projects involving differential privacy include a system developed by Uber and UC Berkeley that allows statistical queries of a SQL database that enforce differential privacy on any output, thereby allowing Uber to analyze safely huge quantities of trip data;127 and systems developed by Google, Apple and Microsoft, respectively, using ‘local’ differential privacy to collect and analyse web browsing behaviour, usage and typing history and a variety of other device-related data without having to share any of this data with a centralized server.128 Researchers have also begun to develop privacy techniques for use with machine learning.129 In 2015, computer scientists at the University of Texas and Cornell University described the design of a system that ‘enables multiple participants to learn neural-network models on their own inputs, without sharing these inputs but benefitting from other participants who are concurrently learning similar models’.130 One application could be medical institutions applying machine learning methods to clinical data without having to share any data with researchers outside their respective organizations. In 2016, Google took this ‘collaborative learning’ concept and scaled it for use with smart phones and other personal devices. This new system, which they dubbed ‘Federated Learning’, enables mobile phones to ‘collaboratively learn a shared prediction model while keeping all the training data on device, decoupling the ability to do machine learning from the need to store the data in the cloud’.131 Both of these systems also rely on differential privacy. In short, privacy-preserving data analytics is advancing and seeing some commercial use even in the rarefied realms of machine learning. These new techniques provide the capacity to confront old and new challenges by looking beyond the core GDPR principles such as data minimisation and introducing additional privacy engineering tools that advance the privacy by design mandate of Article 25. Filling in the gaps in Article 25 We have argued so far that Article 25 offers few details about what it means to design products or services that would enable controllers and processors to satisfy its requirements. The obvious counterargument is that the drafters of the GDPR not only anticipated this objection but provided various measures to help flesh out the bare bones of provisions like Article 25. These measures included so-called ‘delegating and implementing acts’.132 Indeed, the proposed version of Article 25 empowered the Commission ‘to adopt delegated acts … for the purpose of specifying any further criteria and requirements for appropriate measures and mechanisms …., in particular for data protection by design requirements applicable across sectors, products and services’133 and to establish technical standards for the stated requirements using implementing acts.134 But the multi-year legislative review of the GDPR removed most of these delegated and implementing acts mainly for political reasons.135 The final text of Article 25 removed these acts but added two new mechanisms designed to demonstrate compliance with data protection by design and default requirements—certifications and codes of conduct. This section briefly reviews the suitability of either of these two mechanisms to fill in the gaps in the meaning of Article 25. The GDPR provides that adherence by a controller or processor to approved codes of conduct or certification mechanisms helps demonstrate data protection compliance. Although both mechanisms are voluntary, they are directly relevant to Article 25: Article 40(2)(h) states that one of the purposes of codes of conduct is to specify how the GDPR applies to the technical and organisational measures and procedures referred to in Article 25, while Article 25(3) indicates that an approved certification may be used as an element to demonstrate compliance with these requirements. Despite this, neither mechanism is likely to succeed in fleshing out what Article 25 requires in engineering terms. To begin with, codes of conduct represent a form of co-regulation or ‘collaborative governance’. They have been used extensively in the Netherlands to supplement data protection law.136 In his detailed study of Dutch codes of conduct, Hirsch found that Dutch industry considers such codes valuable because they help clarify the broad terms of the Dutch data protection act.137 Only one of the twenty codes Hirsch investigated addressed technical measures, however, and its main feature was just a security checklist.138 More recently, the European Data Protection Board (the Board) issued guidelines on codes of conduct describing them as ‘a useful and effective accountability tool’ providing a detailed description of a sector’s ‘most appropriate, legal and ethical set of behaviors’.139 As such codes of conduct seem much better suited to achieving policy goals than to supporting engineering objectives. What about certification mechanisms? Voluntary privacy and data protection certifications and seals have been used for decades in the US, Japan, Canada, Australia, Germany, and France. As commentators have noted, these seals are meant to ‘enhance transparency, facilitate consumer choice and urge providers to comply with legislation’.140 The self-regulatory nature of certification principles, procedures, and criteria in pre-GDPR programmes led to criticisms and a general lack of public trust and confidence. The GDPR seeks to overcome these shortcomings by providing for a detailed certification scheme (Articles 42) and laying out stringent requirements for accrediting certification bodies (Article 43). Programs have responded by updating their procedures and criteria to ensure that they will be recognized under the new GDPR certification scheme. One of the best-known programmes is EuroPriSe, a spin-off of the Schleswig-Holstein Data Protection Seal (also known as the ‘ULD’).141 EuroPriSe provides EU-wide privacy certifications to manufacturers and sellers of IT products and IT-based services. Its certifications rely on a two-step procedure: first, an evaluation of the product or service by accepted legal and IT experts applying extensive, published criteria based on relevant legal requirements; and second, a verification of the evaluation report by an accredited certification body.142 But programs such as EuroPriSe face several challenges. First, they seek to certify GDPR compliance overall and thus give short shrift to Article 25, devoting only limited attention to data protection by design and default. The relevant criteria mention data minimization but explore it solely in terms of anonymization and/or pseudonymization measures with no mention of other PETs or any broader consideration of privacy engineering.143 Secondly, over a 10-year period EuroPriSe completed only 75 certifications, including 42 initial certifications and 33 recertifications, relying on a panel of about one hundred accredited experts in eighteen countries.144 This is not a particularly high number although EuroPriSe might have certified many additional organizations if it offered an Article 25-only certification. In 2010, however, the Commission estimated the total number of European companies that could practically be considered as controllers as just under 8.8 million (and that’s ignoring GDPR-covered controllers outside the EU).145 So it is hard to imagine EuroPriSe (or even hundreds of such organizations) scaling up to certify more than a fraction of these companies. Thirdly, the evaluation period for forty-two initial certifications ranged from as short as 4 months to as long as 30 months and averaged about 13 months.146 Granted, this is a simple average that includes both legal and technical review and makes no allowances for differences in the complexity of the target of evaluation. Still, 13 months is rather a long time, especially when so many firms have made the agile turn, where sprints last a few weeks. If agile is the new norm, then a lengthy evaluation period is a non-starter that will either disincentivize the use of certifications by agile developers or result in costly and inefficient delays and changes to otherwise completed products. The focus on certifying technology also misses the opportunity to motivate business models and processes that can develop privacy preserving approaches and fit in better with the agile methodology. In addition to the two mechanisms discussed above, supervisory authorities and the EDPB over time will provide more detailed guidance on the GDPR, including the implementation of Article 25. To date, the Norwegian DPA and the EDPS have weighed in with preliminary guidance. The former is full of practical advice and includes a section on the use of privacy design patterns as discussed in the ENISA Report.147 The latter is a sophisticated overview of current trends in privacy engineering and draws heavily on the ENISA Report.148 It discusses privacy engineering, privacy design patterns, the PRIPARE methodology, PETs, and PET readiness and maturity. The EDPS guidance falls short mainly in its recommendations and commitments, which are a little half-hearted. Although it seeks to promote and support privacy by design generally, it fails to endorse or even encourage specific privacy engineering methods or to spell out concrete ways of identifying state of the art PETs (or mandating their use). The next section considers several ways to bolster the EDPS’s recommendations. Fixing Article 25 Public sector projects The EDPS opinion rightly suggests that public administration should lead privacy by design efforts by fully embracing Article 25.149 We agree. During the legislative deliberations over the GDPR, the European Parliament sought to make data protection by design ‘a prerequisite for public procurement tenders’ especially in the utilities sector (water, energy, transport and postal services) on the grounds that a public procurement requirement would foster the widespread implementation of data protection by design in different economic sectors.150 Although this language did not survive further review and is absent from the final text of the GDPR, its shadow survives in Recital 78, which encourages controllers to take into account data protection by design and by default in the context of public tenders. Despite this weaker language, there is ample precedent for the EDPB to play a role in promoting the use of PETs and privacy engineering in public tenders. For example, a 2004 directive establishing the technical, procedural, and legal requirements for the European Electronic Toll Service (EETS) mandates that any road charges collected electronically comply with applicable data protection laws.151 In 2017, the Commission proposed a revised directive and consulted with the EDPS on the text of a new article on data protection that would make the GDPR applicable to any data processed by such toll services.152 At this point, the EDPS could have seized the opportunity to recommend the use of privacy by design techniques in EETS systems (which is exactly what the Article 29 WP did in a recent opinion on peer-to-peer exchange of data between vehicles).153 Or it could go a step further and recommend the use of hard PETs like those identified in the electronic toll pricing (ETP) case study cited above. If the Commission followed these recommendations, new EETS systems would help show that hard PETs and privacy engineering are practical and effective in complex systems even with a very large user base. A successful project in the public utilities sector would also provide practical experience and necessary revenue (on a European-wide basis) to firms offering privacy-protective solutions. And, because the design methodology used in the ETP case study is applicable to other utility services that bill users depending on consumption—such as smart metering systems154—even one such project might jump start the use of hard PETs across the entire public utilities sector. A second example stems from a 2012 Commission recommendation on smart metering systems that directly calls for the incorporation of data protection by design and default in their development.155 This in turn triggered an initiative to identify ‘Best Available Techniques’ (BATs) for the privacy and security of smart metering systems. BATs are defined as ‘the most effective and advanced stage in the development of activities and their methods of operation, which indicates the practical suitability of particular techniques for providing the basis for complying with the EU data protection framework. They are designed to prevent or mitigate risks to privacy, personal data and security.’156 A task force subsequently produced a 211-page BAT reference document. 157 Although it mostly focused on security issues, future efforts like this could result in BATs focused on privacy by design. Indeed, the EDPS has already noted this overlap, stating that BATs correspond ‘to an indication of the state of the art for technical and organisational measures’ and that in the Article 25 context ‘BATs focusing (sic) on privacy may also be seen as PETs’.158 In short, there are sound reasons and ample precedent for the Board to weigh in on current and future public utility projects by urging the Commission to issue a new recommendation on the use of PETs and privacy engineering in both smart metering and smart electronic toll systems. Design guidance The Board plans to issues guidance on Article 25 as part of its 2019/2020 work programme.159 It should recommend PETs and privacy engineering in more forceful terms than are found in Opinion 5/2018. First, it should require the use of hard PETs to enforce the data minimisation principle. While ENISA completes its work on PET maturity assessments as described above, controllers would have to determine for themselves which PETs were appropriate in a given processing context.160 This would result in an ongoing dialogue between controllers (and processors) and DPAs in the form of various soft law measures like Board opinions, responses to DPIAs and prior consultations, speeches by regulators at conferences, and other forms of dialogue with interested parties. Secondly, the Board should be more forthcoming about endorsing existing privacy methodologies (such as PRIPARE or privacy design strategies) rather than merely mentioning them appreciatively. And, as discussed further below, DPAs should make it clear that the use of such methodologies qualifies as a mitigating factor in assessing penalties against controllers that violate the GDPR. Thirdly, the Board should take steps to reinforce Opinion 5/2018’s endorsement of ENISA’s current capacity and tasks including its research analysing the readiness and maturity of PETs. The Board could also advance this PET maturity assessment agenda in several ways. The ENISA maturity assessment report recommends a set of next steps including ‘assessment of other PETs, establishment of a structured assessment process, maintenance of a PET maturity repository, and analysis of utilisation venues, and dissemination’.161 The Board could advise the Commission to fund and support ENISA’s recommended next steps through an appropriate mechanism. More specifically, the Board could advise the Commission to mandate the establishment of an international body that would maintain a repository of best available techniques in the field of PETs. In the interim, the Board could use its powers under Article 70(1)(e) to issue an opinion on data minimisation techniques. This could build on Le Métayer’s existing research by describing the main techniques and identifying their strengths and weaknesses, thereby assisting controllers in choosing how best to design an adequate data minimisation process in a given context. The Board could model this opinion on the Article 29 Working Party’s review of anonymization techniques.162 An opinion along these lines would provide controllers with concrete guidance on their obligations under Article 25(1) pending the establishment of a PET maturity repository. Another advantage of moving forward with a PET maturity repository is that PET assessments are likely to be completed much faster than product certifications under Article 42. More importantly, a single PET may be deployed by many controllers in a variety of settings whereas a product certification is a one-shot deal. Thus, PET assessments are much more likely to scale as compared to product certifications. Additionally, if we think of PETs in modular terms as a component of a larger system, they are also a better fit with agile methods of development, which rely on ‘the implementation and reuse of system components’.163 PETs with a high maturity rating are likely to find their way into mainstream commercial products, provided the Board and DPAs signal to controllers that using such PETs weighs favourably in evaluating their compliance with Article 5 and hence with Article 25’s design mandate. Enforcement Much attention has already been paid in both academic scholarship and the popular press to GDPR’s huge penalties, which could cost the ‘FAANG’ companies billions of dollars in fines if the violate the law. Based on the preceding analysis, it seems preferable for regulators to pursue a more modest approach at least when enforcing Article 25. To begin with, imposing large fines on companies that violate Article 25 would seem improper given the lack of clarity over what Article 25 requires or how it relates to other more substantive provisions. Until the Board issues clear guidance on data protection by design and default, wouldn’t it be unfair to penalize a controller that meets the requirements of Article 5(c) (data minimisation) but somehow violates Article 25(1)? Or, if a controller fails to satisfy data minimisation requirements, to fine it twice for violating both Article 5(c) and Article 25(1)? Of course, there are some cases where fines might be warranted. A controller claiming to have anonymised personal data but taking none of the steps recommended in the relevant Article 29 WG opinion arguably violates Article 25(1) and deserves sanctions. For the most part, however, DPAs might do more to support Article 25 at this early stage by focusing on carrots rather than sticks. Article 83(2) grants DPAs considerable discretion in setting the amount of any fine, listing eleven relevant factors, one of which is ‘(d) the degree of responsibility of the controller or processor taking into account technical and organisational measures implemented by them pursuant to Articles 25 and 32’. By reducing penalties in cases where violators have implemented hard PETs or used privacy engineering methodologies, DPAs would send a strong signal incentivizing firms to devote more effort to implementing Article 25 in this manner. Of course, this assumes that the technical and organizational measures in question mitigate the harm resulting from the violation. Under this approach, regulators would delay imposing penalties for violating Article 25 until controllers know more about what is expected of them. In the meantime, regulators could also rely on soft law approaches to clarify what they have in mind by data protection by design and default. Finally, if regulators determine that fines are justified due to violations of Article 25, they might also take account of how, for legacy software, existing architectural choices impose constraints on the selection of appropriate technical measures notwithstanding the outcome of a risk-based analysis. Conclusion Article 25 requires every controller and processor (and indirectly all vendors) to implement data protection by design and default. This can mean business as usual in the form of procedural solutions or an explosion of innovative architectural solutions. We have argued that time for adopting privacy engineering and hard PETs is now, not later or never. This position depends a great deal on the readiness of privacy engineering and hard PETs to assume their assigned tasks. We have therefore identified one bold step (requiring that data controllers henceforth use ‘mature’ hard PETs for data minimisation) as well as several modest steps (encouraging the use of privacy engineering and hard PETs in public sector projects, issuing design guidance premised on the ENISA Report and PRIPARE Handbook, and emphasizing carrots rather than sticks in Article 25 enforcement actions). There is much to be done but we believe that the GDPR creates the opportunity to begin the necessary tasks in earnest. Thirty years after Chaum’s cryptographic breakthroughs and more than twenty years after regulators began incorporating design ideas into EU data protection law, it is time to implement technological measures that fulfil the early promise of PETs and the work of the contemporary privacy engineering community. Otherwise, Article 25 will be little more than an afterthought to ordinary GDPR compliance. Footnotes 1 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, OJ 1995 L 281/31. 2 See Ann Cavoukian, Privacy by Design: The 7 Foundational Principles (Information and Privacy Commissioner of Ontario, Toronto, Canada 2010). 3 See European Commission, ‘Promoting Data Protection by Privacy Enhancing Technologies (PETs)’ (Communication) COM (2007) 228 final. 4 European Data Protection Supervisor, Opinion of the European Data Protection Supervisor on Promoting Trust in the Information Society by Fostering Data Protection and Privacy (EDPS 2010) 8. 5 32nd International Conference of Data Protection and Privacy Commissioners, Resolution on Privacy by Design (Jerusalem 2010). 6 European Commission, Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), 2012/0011 (COD). 7 Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation), OJ 2016 L 119/1 (GDPR). 8 See Regulation, art 28.1 and Recital 81 (n 7). 9 The PRIPARE Handbook describes in detail seven methodological phases of privacy engineering including analysis, design, implementation, verification, release, maintenance, and decommission. See Alberto Crespo García and others, ‘PRIPARE Handbook - Privacy and Security by Design Methodology’ (2015), <http://pripareproject.eu/wp-content/uploads/2013/11/PRIPARE-Methodology-Handbook-Final-Feb-24-2016.pdf> accessed 8 October 2019 (the PRIPARE Handbook). See also European Union Agency for Networking and Information Security (ENISA), Privacy and Data Protection by Design–from policy to engineering (2014) <https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design/at_download/fullReport> accessed 8 October 2019 (the ENISA Report). For non-technical readers, these two reports are the best available treatments of privacy engineering, especially in the context of the GDPR. 10 See Lee A Bygrave, ‘Hardwiring Privacy’ in Roger Brownsword, Eloise Scotford and Karen Yeung (eds), The Oxford Handbook of Law, Regulation, and Technology (OUP, Oxford 2017) 757. 11 See David Chaum, ‘Security without Identification: Transaction Systems to Make Big Brother Obsolete’ (1985) 28 Comm of the ACM 1030. In the mid-1990s, Cavoukian and her colleagues in the Netherlands directly linked their work to Chaum’s. See Ronald Hes and John J Borking, Privacy-Enhancing Technologies: The Path to Anonymity (Information and Privacy Commissioner, Ontario 1995). 12 See George Danezis and Seda Gürses, ‘A Critical Review of 10 Years of Privacy Technology’ (Proc Surveillance Cultures: A Global Surveillance Society, 2010), <https://pdfs.semanticscholar.org/6efa/8b01b54249be75c98756a8811db8d8b9ad1b.pdf> accessed 9 October 2019. 13 Regulation, art 83(4)(a) (n 7). 14 Seda Gürses, Carmela Troncoso and Claudia Diaz, ‘Engineering privacy by design’, Paper presented at the Fourth Conference on Computers, Privacy Computers, Privacy and Data Protection, held 25–7 January 2011, Brussels. 15 Ira S. Rubinstein, ‘Regulating Privacy by Design’ (2011) 26 Berkeley Technology Law Journal 1409, 14221. 16 Michael Veale, Reuben Binns and Jef Ausloos, ‘When Data Protection by Design and Data Subject Rights Clash’ (2018) 8 International Data Privacy Law 105, 117 <https://doi.org/10.1093/idpl/ipy002> accessed 8 October 2019. 17 Lee A Bygrave, ‘Data Protection by Design and by Default: Deciphering the EU’s Legislative Requirements’ (2017) 1 Oslo Law Review 105, 117. 18 Rubinstein and Good distinguish two dimensions of privacy by design: privacy engineering and user experience (UX) design, which encompasses both usability and visual and aesthetic design. See Ira S. Rubinstein and Nathaniel Good, ‘Privacy by Design: A Counterfactual Analysis of Google and Facebook Privacy Incidents’ (2013) 28 Berkeley Technology Law Journal 1333, 1365–77. For simplicity of analysis, we omit the latter from this article and focus solely on data minimization and related privacy engineering strategies. Similarly, we omit any discussion of data protection by default because it is mostly a question of how to design user consent experiences. For a book-length study of designing for privacy that emphasizes UX design, see Woodrow Hartzog, Privacy’s Blueprint: The Battle to Control the Design of New Technologies (Harvard, Cambridge 2018). 19 See Khaled El Emam and Cecilia Álvarez, ‘A Critical Appraisal of the Article 29 Working Party Opinion 05/2014 on Data Anonymization Techniques’ (2015) 5 International Data Privacy Law 73, 85. 20 See Daniel Le Métayer, ‘Whom to Trust? Using Technology to Enforce Privacy’ in D Wright and P De Hert (eds), Enforcing Privacy: Regulatory, Legal and Technological Approaches (Springer, Switzerland 2016) 396. 21 Claudia Diaz, Omer Tene and Seda Gürses, ‘Hero or Villain: The Data Controller in Privacy Law and Technologies’ (2013) 74 Ohio State Law Journal 923, 929. Along similar lines, Lynskey argues that the vision of data protection law enhancing individual control over personal data faces practical obstacles that are best overcome by ‘structural safeguards, or an architecture of control’. See Orla Lynskey, The Foundations of EU Data Protection Law (OUP, Oxford 2015) 254. Rather than treating the control paradigm and privacy by architecture (which she associates with art 25) as distinct visions of data protection, Lynskey prefers to see them as ‘two sides of the same coin’. ibid 262. This is a useful framing but the GDPR fails to resolve this underlying tension. 22 See eg Lina Jasmontaite and others, ‘Data Protection by Design and by Default: Framing Guiding Principles into Legal Obligations in the GDPR’ (2018) 4 European Data Protection Law Review 168; Veale Binns and Ausloos (n 16); Bygrave (n 17); Bert Jaap Koops and Ronald Leenes, ‘Privacy Regulation cannot be Hardcoded. A Critical Comment on the “privacy by design” Provision in Data-protection Law’ (2014) 28 International Review of Law, Computers & Technology 159; Mireille Hildebrandt and Laura Tielemans, ‘Data Protection by Design and Technology Neutral Law’ (2013) 29 Computer Law & Security Review 509. 23 See Sarah Spiekermann and Lorrie Faith Cranor, ‘Engineering Privacy’ (2009) 35 IEEE Transactions on Software Engineering 67. 24 See Bert Jaap Koops, ‘The Trouble with European Data Protection Law’ (2014) 4 International Data Privacy Law 250. 25 Spiekermann and Cranor (n 23) 73–79. 26 For a similar line of criticism, see Bygrave (n 17) 119. 27 See Bert Jaap Koops, ‘Should ICT Regulation be Technology-Neutral’ in BJ Koops and others (eds), Starting Points for ICT Regulation: Deconstructing Prevalent Policy One-liners (T.M.C. Asser Press, The Hague 2006) 85–89. 28 Ibid. See also Hildebrandt and Tielemans (n 22); Christopher Reed, ‘Taking Sides on Technology Neutrality’ (2007) 4 SCRIPT-ed 263. 29 Reed, ibid 270–73; Koops (n 27) 93–94. 30 Hildebrandt and Tielemans (n 22) 510–11. 31 Koops (n 27) 96–98. 32 Hildebrandt and Tielemans (n 22) 513. 33 See Cavoukian (n 2). 34 See PRIPARE Handbook (n 9) 13. 35 See Organisation for Economic Co-operation and Development (OECD), Privacy Framework, Foreword (2013) 4; OECD, Revised OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (2013) ¶ 15. 36 See European Data Protection Supervisor (EDPS), Opinion 5/2018, Preliminary Opinion on privacy by design (31 May 2018), ¶ 30. 37 This excludes s 5 of Chapter IV, which describes several voluntary mechanisms that controllers may take advantage of including codes of conduct (art 40) and certifications (art 42). 38 See Jasmontaite and others (n 22) 10. 39 Ari Waldman, ‘Privacy’s Law of Design’ (2019) 9 UC Irvine Law Review 1239. 40 See Frederik J Zuiderveen Borgesius, ‘Singling out People without Knowing their Names–Behavioural Targeting, Pseudonymous Data, and the New Data Protection Regulation’ (2016) 32 Computer Law & Security Review 256. 41 Ibid 266. 42 See Bygrave (n 17) 117. 43 See Jasmontaite and others (n 22) 18. 44 Ibid 8. 45 See PRIPARE Handbook (n 9), § 6.3, which discusses the design of privacy controls in depth. 46 See Jasmontaite and others (n 22). 47 Hildebrand and Tielemans (n 22) 517. 48 Directive 85/374/EEC of the Council of 25 July 1985 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products, OJ 1985 L 210/29, § 7(e). 49 Cees van Dam, European Tort Law (2nd edn, OUP, Oxford 2013), § 810-4. 50 Ibid § 1410-2. 51 See Waldman (n 39). 52 Jasmontaite and others (n 22) 13. 53 European Union Agency for Networking and Information Security (ENISA), ‘Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies: Methodology, Pilot Assessment, and Continuity Plan’ (2015), <https://www.enisa.europa.eu/publications/pets> accessed 9 October 2019. 54 EDPS, Opinion 5/2018 (n 36) 8. 55 Rubinstein (n 15) 1431–44. 56 EDPS, Opinion 5/2018 (n 36) 19. 57 Bygrave (n 17) 119. 58 See Seda Gürses and Joris VJ van Hoboken, ‘Privacy After the Agile Turn’ in Evan Selinger, Jules Polonetsky and Omer Tene (eds), The Cambridge Handbook of Consumer Privacy (CUP, Cambridge 2018). 59 Gürses, Troncoso and Diaz (n 14). 60 Ibid § 3.3. These five steps also describe a ‘lifecycle’ but a very different one from the data processing lifecycle alluded to in art 25.1. 61 Jaap-Henk Hoepman, ‘Privacy Design Strategies’ in ICT Systems Security and Privacy Protection (Dordrecht, Springer 2014). 62 Ibid 448. 63 Ibid 452–53. 64 Ibid 449. 65 See Thibaud Antignac and Daniel Le Métayer, ‘Privacy by Design: From Technologies to Architectures’ in Bart Preneel and Demosthenes Ikonomou (eds), Privacy Technologies and Policy (Dordrecht, Springer 2014). 66 Ibid 3. 67 Ibid. 68 Ibid. 69 See PRIPARE Handbook (n 9). PRIPARE stands for ‘PReparing Industry to Privacy-by-design by supporting its Application in Research’. 70 Ibid 14. 71 Ibid 24–48. 72 Ibid 49–63. 73 Diaz, Tene and Gürses (n 21) 940. 74 Le Métayer (n 20) 397. 75 Mina Deng and others, ‘A Privacy Threat Analysis Framework: Supporting the Elicitation and Fulfillment of Privacy Requirements’ (2011) 16 Requirements Engineering Journal 3. 76 Ibid 4–5. 77 Le Métayer (n 20) 398–414. 78 See Carmela Troncoso, ‘Privacy Enhancing Technologies, PRIPARE Workshop’ (10 March 2015), <pripareproject.eu/wp-content/uploads/2014/12/Gradiant_PRIPARE_PETs.pptx> accessed 9 October 2019. 79 See Jonathan Mayer and Arvind Narayanan, ‘Privacy Substitutes’ (2013) 66 Stanford Law Review Online 89, 94–95 <http://www.stanfordlawreview.org/online/privacy-and-big-data/privacy-substitutes> accessed 9 October 2019. 80 Bygrave (n 17) 763. 81 Le Métayer (n 20) 414–29. 82 Ibid 397. 83 See eg Gürses, Troncoso and Diaz (n 14). 84 Le Métayer (n 20) 399–414. 85 ENISA Report (n 9). 86 Ibid. The authors of the ENISA report are George Danezis, Joseph Domingo-Ferrer, Marit Hansen, Jaap-Henk Hoepman, Daniel Le Métayer, Rodica Tirtea, and Stefan Schiffner. 87 See Datatilsynet, Guide: Software development with Data Protection by Design and by Default, <https://www.datatilsynet.no/en/about-privacy/virksomhetenes-plikter/innebygd-personvern/data-protection-by-design-and-by-default/> accessed 9 October 2019; EDPS Opinion 5/2018 (n 36). 88 Charles Eames, ‘Qu’est ce que le design?’ at the Musée des Arts Décoratifs, Palais de Louvre (1972), YouTube, <https://www.youtube.com/watch?v=3xYi2rd1QCg> accessed 9 October 2019. 89 Third-party cookies are the most common identifiers but there are ‘myriad … technologies that can be used to pseudonymously correlate web activities.’ See Jonathan R Mayer and John C Mitchell, ‘Third Party Web Tracking: Policy and Technology’ (Proc 2012 IEEE Symposium on Security and Privacy, 2012), <https://jonathanmayer.org/publications/trackingsurvey12.pdf> accessed 9 October 2019. 90 Siobhán Dunphy, ‘Women are Seeing Fewer STEM Job Ads than Men: Are Marketing Algorithms Promoting Gender Bias?’ European Scientist (28 July 2018) <https://www.europeanscientist.com/en/public/women-are-seeing-less-stem-job-ads-than-men-are-marketing-algorithms-promoting-gender-bias/> accessed 9 October 2019. 91 See David D Kirkpatrick, ‘Signs of Russian Meddling in Brexit Referendum’ New York Times (New York, 15 November 2017), <https://www.nytimes.com/2017/11/15/world/europe/russia-brexit-twitter-facebook.html> accessed 9 October 2019. 92 Although Facebook recently agreed to a $5 billion settlement with the FTC, opinion varies on whether this will bring about any meaningful changes in its data protection practices. See eg Adam Schwartz, ‘The FTC-Facebook Settlement Does Too Little to Protect Your Privacy’ EFF Deeplinks (24 July 2019), <https://www.eff.org/deeplinks/2019/07/ftc-facebook-settlement-does-too-little-protect-your-privacy> accessed 9 October 2019. 93 See Internet Activity Bureau (IAB) Europe, Online Behavioural Advertising (OBA) Framework, <http://www.edaa.eu/wp-content/uploads/2012/10/2013-11-11-IAB-Europe-OBA-Framework_.pdf> accessed 9 October 2019; European Advertising Standards Alliance (EASA) Best Practice Recommendation, <http://www.easa-alliance.org/sites/default/files/EASA%20Common%20Principles%20and%20Operating%20Standards%20of%20Best%20Practice.pdf> accessed 9 October 2019. 94 Your Online Choices, A Guide to Online Behavioural Advertising, IAB Europe <www.youronlinechoices.com/uk/about-behavioural-advertising> accessed 9 October 2019. 95 See eg Sundeep Kapur and Matt Savare, ‘Fear of Brave? An Analysis of GDPR Challenges to Behavioral Advertising’ (Lowenstein Sandler, 13 November 2018) < https://www.lowenstein.com/news-insights/client-alerts/fear-of-brave-an-analysis-of-gdpr-challenges-to-behavioral-advertising> accessed 9 October 2019. 96 See Dipayan Ghosh, ‘How GDPR Will Transform Digital Marketing’ Harvard Business Review (21 May 2018), <https://hbr.org/2018/05/how-gdpr-will-transform-digital-marketing> accessed 9 October 2019. 97 In July 2018, the CNIL issued two public notices against two marketing firms for failing to obtain valid consent to use location data for profiling and targeted advertising. See Allison Schiff, ‘French Startup Teemo Appeases GDPR Regulators, Avoids A Fine’ Ad Exchanger (8 October 2018), <https://adexchanger.com/privacy/french-startup-teemo-appeases-gdpr-regulators-avoids-a-fine/> accessed 9 October 2019. 98 See Ravi Naik, Grounds of Complaint to the Data Protection Commissioner 1 (12 September 2018), <https://brave.com/DPC-Complaint-Grounds-12-Sept-2018-RAN2018091217315865.pdf> accessed 9 October 2019. 99 See Kapur and Savare (n 95). 100 See EDRi, ‘Five Reasons to be Concerned about the Council ePrivacy draft’ (26 September 2018), <https://edri.org/five-reasons-to-be-concerned-about-the-council-eprivacy-draft/> accessed 9 October 2019. 101 See Elle Todd, ‘Five Things We Still don’t Know About the e-Privacy Regulation (which are getting very annoying!)’, Reed Smith (23 April 2019), <https://www.technologylawdispatch.com/2019/04/privacy-data-protection/five-things-we-still-dont-know-about-the-e-privacy-regulation-which-are-getting-very-annoying/> accessed 9 October 2019. 102 See IAB Europe Launches Public Comment for its GDPR Transparency & Consent Framework Version 2.0 (25 April 2019), <https://iabeurope.eu/all-news/iab-europe-launches-public-comment-for-its-gdpr-transparency-consent-framework-version-2-0/> accessed 9 October 2019. 103 See IAB Europe, Transparency and Consent Framework Implementation Guidelines (25 April 2018), <https://iabeurope.eu/?s=IAB+Europe%C+Transparency+and+Consent+Framework+Implementation+Guidelines> accessed 9 October 2019. The main changes for users in TCF v2.0 include a) expanding the indicated purposes for processing personal data from five to 12 categories; b) enabling users to express directly through a TCF Consent Management Platform their ‘right to object’ to a vendor processing their personal data on the basis of legitimate interest; and c) adding more controls over whether and how vendors may use certain features of data processing, including the use of precise geolocation data. See IAB Europe, ibid. 104 See eg Johnny Ryan, Risks in IAB Europe’s proposed consent mechanism (PageFair 20 March 2018) <https://pagefair.com/blog/2018/iab-europe-consent-problems/> accessed 9 October 2019. 105 See IAB Europe, IAB Europe Transparency & Consent Framework Policies (21 August 2019), Appendices A and B <https://iabeurope.eu/tcfdocuments/documents/legal/tcfpolicyFINALv2.pdf> accessed 9 October 2019. 106 European Commission, ‘Special Eurobarometer 431, Data Protection’ (Report, 2015) 29 http://ec.europa.eu/public_opinion/archives/ebs/ebs_431_sum_en.pdf> accessed 9 October 2019. 107 Frederik J. Zuiderveen Borgesius and others, ‘Tracking Walls, Take-It-Or-Leave-It Choices, the GDPR, and the ePrivacy Regulation (2017) 3 European Data Protection Law Review 353, 356. 108 Joseph Turow and others, ‘The Tradeoff Fallacy. How Marketers Are Misrepresenting American Consumers and Opening Them Up to Exploitation’ (A report from the Annenberg School for Communication, University of Pennsylvania, June 2015) 3 <https://www.asc.upenn.edu/sites/default/files/TradeoffFallacy_1.pdf> accessed 9 October 2019. 109 A prominent American publisher—the New York Times—seems to have reached a similar conclusion. See Jessica Davies, ‘After GDPR, The New York Times cut off ad exchanges in Europe — and kept growing ad revenue’ Digiday (16 January 2019) <https://digiday.com/media/new-york-times-gdpr-cut-off-ad-exchanges-europe-ad-revenue/> accessed 9 October 2019. 110 Michael Backes and others, ‘ObliviAd: Provably Secure and Practical Online Behavioral Advertising’ (Proc 2012 IEEE Symposium on Security and Privacy, 2012) 258. 111 Mikhail Bilenko and others, ‘Targeted, Not Tracked: Client-Side Solutions for Privacy-Friendly Behavioral Advertising’ (2011) unpublished manuscript <http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1995127> accessed 9 October 2019. 112 Backes and others (n 110) 257. For a more detailed overview of the protocol and a formal verification of its privacy properties, see ibid 259–68. 113 Spiekermann and Cranor (n 23) 79. 114 For more on how firms are responding to art 25 and what’s happening in the field with implementing a privacy by design approach to cloud services, see Nathaniel Good, Ira s. Rubinstein and Jared Maslin, ‘“When the dust doesn't settle” - GDPR compliance one year in’ (April 27, 2019), https://ssrn.com/abstract=3378874. 115 There are some examples of architectural solutions like ObliviAd occurring ‘in the wild’ but they seem few and far between. See eg Hoxton Analytics <https://www.hoxtonanalytics.com/> accessed 9 October 2019 (describing a start-up that monitors footfall and shopper’s demographics for retail stores by filming shopper’s shoes as they enter a store instead of using video surveillance); Cole Meiterman, ‘What Is Basic Attention Token And How It Will Change Ads’ Cryptocurrency News (2 May 2019) <https://usethebitcoin.com/what-is-basic-attention-token-and-how-it-will-change-ads/> accessed 9 October 2019 (describing a new browser and blockchain-based digital advertising platform that measures the attention of users and compensates them with tokens for interacting with the platform); Hessie Jones, ‘D-ID Is Altering Facial Recognition’s Path Towards Privacy’ Fortune (11 July 2019) <https://www.forbes.com/sites/cognitiveworld/2019/07/11/d-id-is-altering-facial-recognitions-path-towards-privacy/#1bcd4df035ae> accessed 9 October 2019 (describing a startup that uses advanced image processing and deep learning techniques to resynthesize any given photo so that the photo is recognizable to the human eye but looks different to facial recognition algorithms). We are not endorsing any of these systems but rather using them as examples of the kinds of privacy technologies that arise when designers adopt a privacy engineering approach to creating new technologies. 116 Simon McDougal, Keynote Speech at the Westminster Media Forum (11 July 2019) <https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2019/07/speech-the-future-of-online-advertising-regulation/> accessed 9 October 2019. 117 For a recent discussion, see Sandra Wachter and Brent Mittelstadt, ‘A Right to Reasonable Inferences: Re-Thinking Data Protection Law in the Age of Big Data and AI’ (2019) 2019 Columbia Business Review 494. 118 See eg Cathy O’Neil, Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy (New York, Crown Publishers 2016). 119 See Tal Zarsky, ‘Incompatible: The GDPR in the Age of Big Data’ (2017) 47 Seton Hall Law Review 995. 120 See eg Information Commissioner’s Office, ‘Big Data, Artificial Intelligence, Machine Learning and Data Protection’ (2017) <https://ico.org.uk/media/for-organisations/documents/2013559/big-data-ai-ml-and-data-protection.pdf> accessed 9 October 2019. 121 See Ira S Rubinstein, ‘Big Data: The End of Privacy or a New Beginning?’ (2013) 3 International Data Privacy Law 74, 74. 122 See Viktor Mayer-Schönberger and Yann Padova, ‘Regime Change? Enabling Big Data through Europe’s New Data Protection Regulation’ 17 Columbia Science & Technology Law Review 315 (2016). 123 Wachter and Mittelstadt (n 117). 124 See eg European Commission, High-Level Expert Group on AI, Ethics Guidelines for Trustworthy Artificial Intelligence (8 April 2019) <https://ec.europa.eu/digital-single-market/en/news/ethics-guidelines-trustworthy-ai> accessed 9 October 2019. 125 Harvard University Privacy Tools Project, Differential Privacy <https://privacytools.seas.harvard.edu/differential-privacy> accessed 9 October 2019. 126 Differential Privacy Team, ‘Learning with Privacy at Scale’ (December 2017) <https://machinelearning.apple.com/2017/12/06/learning-with-privacy-at-scale.html> accessed 9 October 2019. 127 See Katie Tezapsidis, ‘Uber Releases Open Source Project for Differential Privacy’ Medium (13 July 2017) <https://medium.com/uber-security-privacy/differential-privacy-open-source-7892c82c42b6> accessed 9 October 2019. 128 See Graham Cormode and others, ‘Privacy at Scale: Local Differential Privacy in Practice’ in Proceedings of the 2018 International Conference on Management of Data, SIGMOD Conference 2018 <http://dimacs.rutgers.edu/~graham/pubs/papers/ldptutorial.pdf> accessed 9 October 2019. 129 Machine learning has been defined as ‘a kind of learning by example, one in which an algorithm is exposed to a large set of examples from which it has been instructed to draw general lessons’. See Solon Barocas and others, ‘Data and Civil Rights: Technology Primer’ Data & Civil Rights Conference (October 2014) <https://ssrn.com/abstract=2536579> accessed 9 October 2019. Machine learning algorithms form the basis of artificial intelligence (AI) systems such as image and speech recognition, ranking and personalization of content, and recommendation engines, all of which rely on massive data collection and analysis to predict and classify with a high degree of accuracy by generalizing from experience. 130 Reza Shokri and Vitaly Shmatikov, ‘Privacy-Preserving Deep Learning’ in CCS (2015), Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (October 2015) <https://www.cs.cornell.edu/~shmat/shmat_ccs15.pdf> accessed 9 October 2019. 131 Federated Learning: Collaborative Machine Learning without Centralized Training Data, Google AI Blog (6 April 2017) <https://ai.googleblog.com/2017/04/federated-learning-collaborative.html> accessed 9 October 2019. 132 The Lisbon Treaty explains that delegated acts are designed ‘to supplement or amend non-essential elements of the legislative act’ (art 290, TFEU), while implementing acts are designed to help implement them, especially when ‘uniform conditions for implementing legally binding Union acts are needed’ (art 291, TFEU). 133 Proposed Regulation, art 23.3 (n 6). 134 Proposed Regulation, art 23.4 (n 6). 135 See Lynskey (n 21) 74. 136 See Dennis Hirsch, ‘Going Dutch? Collaborative Dutch Privacy Regulation and the Lessons It Holds for U.S. Privacy Law’ (2013) 2013 Michigan State Law Review 83. 137 Ibid 125. 138 Ibid Appendix, which lists the Association of Computing Services and Software Agencies (COSSO) as having developed a code of conduct. For a brief description of COSSO’s code, see Frank Kuitenbrouwer, ‘Self-Regulation: Some Dutch Experiences’ in Privacy and Self-Regulation in the Information Age (National Telecommunications and Information Administration 1997), <https://www.ntia.doc.gov/report/1997/privacy-and-self-regulation-information-age> accessed 9 October 2019. 139 EDPB, Guidelines 1/2019 on Codes of Conduct and Monitoring Bodies under Regulation 2016/679 (2019), 6. 140 Irene Kamara and Paul De Hert, ‘Data Protection Certification in the EU: Possibilities, Actors and Building Blocks in a Reformed Landscape’ in Rowena Rodrigues and Vagelis Papakonstantinou (eds), Privacy and Data Protection Seals (T.M.C. Asser Press, The Hague 2018) 8. 141 See Unabhängiges Landeszentrum für Datenschutz, Schleswig-Holstein, <https://www.datenschutzzentrum.de/> accessed 9 October 2019. 142 See EuroPriSe, Overview on the EuroPriSe Certification Scheme (August 2017) <https://www.european-privacy-seal.eu/AppFile/GetFile/6c5b46be-7fe2-4cc0-b22a-ba3cf218ef5e> accessed 9 October 2019. 143 EuroPriSe, EuroPriSe Criteria for IT products and IT-based services (2017) <https://www.european-privacy-seal.eu/AppFile/GetFile/6a29f2ca-f918-4fdf-a1a8-7ec186b2e78a> accessed 9 October 2019. However, the criteria driving the ULD seal addresses privacy properties such as unlinkability, transparency and intervenability, and therefore come much closer to addressing privacy by architecture than the EuroPriSe program. See Marit Hansen, ‘The Schleswig-Holstein Data Protection Seal’ in Rowena Rodrigues and Vagelis Papakonstantinou (eds), Privacy and Data Protection Seals (T.M.C. Asser Press, The Hague 2018) 46. We are unable to analyse the ULD seal programme because the relevant materials are available only in German. 144 EuroPriSe, Register of Awarded Seals (2008–2018), <https://www.european-privacy-seal.eu/EPS-en/awarded-seals> accessed 9 October 2019. 145 Commission, ‘Staff Working Paper: Impact Assessment’ 142 SEC (2012) 72 final, 142–43. 146 See EuroPriSe, Register of Awarded Seals (2008–2018) (n 144). 147 See Datatilsynet, Data Protection Authority, Guide: Software development with Data Protection by Design and by Default (28 November 2017) (n 87). 148 See EDPS, Opinion 5/2018 (n 36). 149 Ibid 18. 150 European Parliament and the Council, ‘Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)’ [2016] OJ L119/1, art 23(1a). 151 Directive 2004/52/EC of the European Parliament and of the Council of 29 April 2004 on the interoperability of electronic road toll systems in the Community (OJ L 166, 30.4.2004, p 124). 152 Proposal for a Directive of the European Parliament and pf the Council on the interoperability of electronic road toll systems and facilitating cross-border exchange of information on the failure to pay road fees in the Union, COM/2017/0280 final - 2017/0128 (COD), art 8. 153 See art 29 Working Party, Opinion 03/2017 on Processing personal data in the context of Cooperative Intelligent Transport Systems (C-ITS) (WP 252, 4 October 2017) 13–14. 154 See Microsoft Research, Privacy-Friendly Smart Metering (2010) <http://research.microsoft.com/en-us/projects/privacy_in_metering/> accessed 9 October 2019. 155 Commission, Recommendation of 9 March 2012 on preparations for the roll-out of smart metering systems (COM 2012/148/EU). 156 Ibid Part I.3(f). 157 See Smart-Grid Task Force Stakeholder Forum, Best Available Techniques Reference Document (11 July 2016) <https://ec.europa.eu/energy/sites/ener/files/documents/bat_wp4_bref_smart-metering_systems_final_deliverable.pdf> accessed 9 October 2019. 158 EDPS, Opinion 5/2018 (n 36) 10. 159 EDPB Work Program 2019/2020 (9 October 2019) <https://edpb.europa.eu/sites/edpb/files/files/file1/edpb-2019-02-12plen-2.1edpb_work_program_en.pdf> accessed 9 October 2019. 160 See Le Métayer (n 20). 161 ENISA, Readiness Analysis (n 53) 43. 162 See art 29 Working Party, Opinion 05/2014 on Anonymisation Techniques (WP 216, 4 October 2014). 163 Gürses and van Hoboken (n 58) 586. © The Author(s) 2019. Published by Oxford University Press. All rights reserved. For permissions, please email: journals.permissions@oup.com This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)
TI - The trouble with Article 25 (and how to fix it): the future of data protection by design and default
JF - International Data Privacy Law
DO - 10.1093/idpl/ipz019
DA - 2020-02-01
UR - https://www.deepdyve.com/lp/oxford-university-press/the-trouble-with-article-25-and-how-to-fix-it-the-future-of-data-CfQLybv9Es
SP - 1
VL - Advance Article
IS - 
DP - DeepDyve
ER -