PaperlayerView exact revision on arXiv

Source-linked AI summary

Privacy and Data Protection by Design - from policy to engineering

George Danezis, Josep Domingo-Ferrer, Marit Hansen, Jaap-Henk Hoepman, Daniel Le Metayer, Rodica Tirtea, Stefan Schiffner

arXiv:1501.03726v2cs.CR

TL;DR

Embedding privacy values and legal obligations into systems remains challenging as technology creates new privacy and data-protection risks. The report bridges legal requirements and engineering by presenting design approaches and methodologies, while identifying open issues and limitations.

  • Problem

    New information and communication technologies have created privacy and data-protection challenges, while transparency and valid consent remain difficult in practice.

  • Method

    The report inventories privacy design strategies and technical building blocks, and describes methods using data-flow diagrams, threat patterns, and trust assumptions to guide design choices.

  • Results

    The report provides a first step toward guidelines for privacy-friendly and legally compliant products and services, while identifying issues for which no effective technology or method exists.

  • Takeaways & Limitations

    Privacy-friendly system design requires bridging policy, law, engineering, implementation, and service provision rather than relying on technology alone.

  • Takeaways & Limitations

    The lack of a general, intuitive privacy metric limits the practicality of data minimisation, and privacy-by-design methods may reduce system utility.

Abstract

from arXiv · show

Privacy and data protection constitute core values of individuals and of democratic societies. There have been decades of debate on how those values -and legal obligations- can be embedded into systems, preferably from the very beginning of the design process. One important element in this endeavour are technical mechanisms, known as privacy-enhancing technologies (PETs). Their effectiveness has been demonstrated by researchers and in pilot implementations. However, apart from a few exceptions, e.g., encryption became widely used, PETs have not become a standard and widely used component in system design. Furthermore, for unfolding their full benefit for privacy and data protection, PETs need to be rooted in a data governance strategy to be applied in practice. This report contributes to bridging the gap between the legal framework and the available technological implementation measures by providing an inventory of existing approaches, privacy design strategies, and technical building blocks of various degrees of maturity from research and development. Starting from the privacy principles of the legislation, important elements are presented as a first step towards a design process for privacy-friendly systems and services. The report sketches a method to map legal obligations to design strategies, which allow the system designer to select appropriate techniques for implementing the identified privacy requirements. Furthermore, the report reflects limitations of the approach. It concludes with recommendations on how to overcome and mitigate these limits.

About ENISA

The report translates privacy-by-design principles into engineering guidance by surveying design strategies, technologies, implementation limits, and recommendations for stakeholders.

  • About ENISA: The report bridges legal privacy requirements and technological implementation measures through an inventory of approaches, design strategies, and technical building blocks.It includes technologies with different maturity levels from research and development.
  • About ENISA: It describes a process for mapping legal obligations to design strategies so system designers can select techniques for identified privacy requirements.
  • About ENISA: It identifies limitations of privacy by design and recommends measures for developers, providers, authorities, and policymakers.
  • About ENISA: The report provides a state-of-the-art basis and reference for system developers, data protection authorities, and regulators.Its intended uses include integrating privacy principles, monitoring data-protection-law application, and improving future policy.

1 Introduction

Privacy is a fundamental individual and democratic value increasingly challenged by intensive digital data processing. The report presents privacy-enhancing technologies and engineering approaches as ways to address these challenges, while documenting gaps in implementation and practice.

  • 1 Introduction: Privacy protection is framed as both a fundamental human right and an essential element in democratic societies.
  • 1 Introduction: Digital technologies intensify privacy risks through expanded storage, processing, networking, mobile use, cloud computing, and big-data analytics.
  • 1 Introduction: Privacy-enhancing technologies can minimise personal-data processing, but their effectiveness has not translated into widespread standard use beyond exceptions such as encryption.
  • 1 Introduction: Privacy by Design requires privacy consideration throughout system development, yet the approach lacks mechanisms for integrating privacy into development processes.
  • 1 Introduction: Traditional engineering and development tools often prioritise functional requirements because developers lack awareness, understanding, and practical privacy tools.
  • 1 Introduction: The report aims to make engineering privacy by design concrete through lifecycle guidance, design strategies, technology overviews, policy context, limits, and recommendations.

2 Engineering Privacy

Engineering privacy requires more than general principles or PETs: it is a multifaceted process combining technological and organisational components, legal objectives, methodologies, and evaluation.

  • 2 Engineering Privacy: Privacy by design is neither only a set of general principles nor reducible to privacy-enhancing technologies.The report treats it as a process involving technological and organisational components.
  • 2 Engineering Privacy: The proposed privacy-by-design process defines context and objectives, methodologies, and evaluation means.
  • 2 Engineering Privacy: Privacy and data protection address human beings, personal rights, and democratic values, not merely protection of data.
  • 2 Engineering Privacy: Privacy engineering faces unresolved terminology and measurement issues, including the absence of a general intuitive privacy metric.
  • 2 Engineering Privacy: Privacy-relevant data includes information that enables linkage or inference of sensitive information, even when it is not directly associated with an individual.Timestamps are given as an example of data that may support linkage.
  • 2 Engineering Privacy: Multilateral security incorporates the privacy and security interests of all parties and seeks to empower end-users in decisions about data processing.
  • 2 Engineering Privacy: Privacy mechanisms include data avoidance, context separation, encryption, different identifiers, access control, anonymisation, pseudonymisation, and early erasure.

Consent

Consent requires informed, specific, and explicit agreement, but complex requests and limited attention often undermine these conditions in practice.

  • Consent: Valid consent requires a specific, informed, and explicit indication of an individual’s intentions regarding personal-data processing.Consent can be withdrawn with effect for the future.
  • Consent: Transparency is a prerequisite for consent because individuals need understandable information about processing.
  • Consent: Consent is often not sufficiently informed or freely given because requests are too complex or presented when attention is focused elsewhere.The report cites take-it-or-leave-it applications and legalistic contracts as examples.

Purpose binding

Purpose binding requires personal data to be collected for a specified, explicit, legitimate purpose and not reused for incompatible purposes. This principle contrasts with approaches that encourage multipurpose data use and linkage.

  • Personal data must not be processed for purposes incompatible with the original purpose.
  • The original purpose must be legitimate, specified, and explicit before personal data is collected.
  • Outside Europe, purpose limitation is unknown in many countries, where multipurpose data use is instead encouraged.
  • Big Data trends incorporate multipurpose data linkage and analysis rather than keeping data in separated domains.

Necessity and data minimisation

Necessity and data minimisation limit processing to personal data needed for the respective purpose, with reduction or removal beginning as early as possible.

  • Only personal data necessary for the respective purpose may be processed.
  • Personal data should be fully avoided or minimised during collection and subsequent processing whenever possible.
  • Data should be erased or effectively anonymised as soon as it is no longer needed for the given purpose.
  • Early-stage data minimisation is identified as a core concept of privacy-enhancing technologies.

Transparency and openness

Transparency and openness require stakeholders to receive enough information about data collection and use to understand risks and control processing. Transparency supports fair processing but may be limited by law-enforcement requirements and business secrets.

  • Stakeholders should receive sufficient information about the collection and use of their personal data.
  • They should understand processing risks and the actions available to control processing.
  • Transparency enables individuals to exercise rights, controllers to evaluate processors, and authorities to monitor their responsibilities.
  • Current transparency is inadequate as data processing and system interaction become more complex.
  • Full transparency may be neither possible nor desirable because of law-enforcement requirements and business secrets.

Rights of the individual

Individuals hold rights to access, rectify, block, erase, and withdraw consent regarding their personal data, and systems should make these rights effective and convenient to exercise. Privacy by design and privacy by default support implementing or assisting these rights.

  • Individuals can access and rectify their personal data and, with constraints, block and erase it.
  • Individuals may withdraw consent with effect for the future.
  • Systems should support effective and convenient exercise of individual rights.
  • Privacy by design and privacy by default promote implementing or supporting these rights.

Information security

Information security protects confidentiality, integrity, and availability, all of which also matter for privacy and data protection.

  • Confidentiality, integrity, and availability are the three protection goals addressed by information security.
  • Privacy and data protection require preventing unauthorised access, processing, manipulation, loss, destruction, and damage.
  • Personal data must also remain accurate, while processes should support appropriate handling and individuals’ exercise of their rights.

Accountability

Accountability requires organisations to demonstrate compliance through defined responsibilities, audits, controls, and impact assessments, with independent authorities providing national oversight.

  • Accountability requires ensuring and demonstrating compliance with privacy and data protection principles or legal requirements.
  • Clear responsibilities, internal and external auditing, and controls over data processing support accountability.
  • Data Protection Officers may conduct internal audits and handle complaints, while data protection impact assessments can demonstrate compliance.
  • Independent Data Protection Authorities support accountability by monitoring and checking organisations as supervisory bodies.

Data protection by design and by default

Privacy and data protection by design embeds privacy features from the outset, while privacy by default protects users through the system’s initial settings.

  • Privacy/data protection by design: Privacy and data protection by design prefers building privacy features in from the beginning rather than adapting systems later.
  • Privacy/data protection by design: Early involvement in design supports consideration of the data’s full lifecycle and usage.
  • Privacy/data protection by default: Privacy and data protection by default means users are protected against privacy risks in the default setting.
  • Privacy/data protection by default: Designers decide which system parts are wired-in or configurable, and privacy-respecting defaults may restrict extended functionality unless users explicitly choose it.

2.3 Definition of the context and objectives

Privacy by design requires explicit contextual objectives, risk analysis, recommendations, and iterative implementation, but remains difficult because privacy goals and technical requirements are complex and may conflict.

  • 2.3 Definition of the context and objectives: Privacy is complex, multifaceted, and contextual, and may conflict with functional or non-functional system requirements.
  • 2.3 Definition of the context and objectives: PIAs are required in certain GDPR situations, and their results should inform privacy by design across the personal-data lifecycle.
  • 2.3 Definition of the context and objectives: PIAs range from lightweight to extensive processes involving organisational, decision-making, and technical tasks.
  • 2.3 Definition of the context and objectives: A PIA process identifies stakeholders and risks, formulates solutions and recommendations, implements them, and conducts reviews, audits, and accountability measures.
  • 2.3 Definition of the context and objectives: Privacy by design uses risk-analysis outputs and recommendations as inputs, contributes to implementation, and operates as an iterative, continuous process.
  • 2.3 Definition of the context and objectives: LINDDUN systematically uses data-flow diagrams and privacy-threat-tree patterns to structure privacy analysis.
  • 2.3 Definition of the context and objectives: Risk analysis should define context assumptions, privacy objectives, and potentially privacy-enhancing technologies at the process’s beginning.
  • 2.4 Methodologies: Designers must select and combine PETs and protocols despite conflicts among requirements and the subtle, error-prone complexity of PET specifications.

3 Privacy Design Strategies

Privacy design strategies express higher-level approaches for achieving privacy goals across early development phases, while design patterns and PETs operate at more concrete levels. The section distinguishes these concepts and introduces their relationship to software development and data protection principles.

  • Development phases: Software development uses privacy design strategies in concept and analysis, design patterns during design, and concrete PETs during implementation.The concepts therefore correspond to different phases and abstraction levels in the development cycle.
  • Design patterns: A design pattern provides a recurring structure of communicating components that solves a general design problem within a particular context.Patterns help designers decompose problems and assess the consequences of a proposed subdivision without implementation details.
  • 3.1.2 Design strategies: Privacy design strategies guide fundamental approaches to privacy goals and can be applied during concept development and analysis.They constrain possible structural realisations without necessarily imposing a specific system structure.
  • Privacy-enhancing technologies: PETs are concrete ICT measures that minimise personal-data processing while preserving information-system functionality, implementing privacy design patterns.Idemix and U-Prove are examples of PETs implementing the anonymous-credentials pattern.
  • Privacy design strategies: The report distinguishes eight privacy design strategies into data-oriented and process-oriented groups, with four data-oriented strategies supporting unlinkability and data minimisation.The MINIMISE strategy restricts processed personal data to the minimal amount possible.

4 Privacy Techniques

Privacy techniques span authentication, federated identity, anonymisation, private computation, and privacy-preserving storage, each offering specific protections alongside important trade-offs. The report emphasizes matching techniques to privacy goals while recognizing limits in scalability, flexibility, utility, and adversarial coverage.

  • Authentication: State-of-the-art authentication protocols conceal participants’ identities from passive third parties and protect at least one party against active adversaries.Secret handshake protocols can protect both parties against active adversaries, but are technically expensive.
  • Authentication: End-to-end authentication bootstraps secure user channels that cannot be compromised by the trusted third-party server in the alternative architecture.The report therefore recommends that services provide or support end-to-end authentication between users.
  • Federated identity: Federated identity systems such as Shibboleth support selective attribute disclosure and partial anonymity, but identity providers and traffic observers may still monitor sessions.Selective disclosure is presented as state of the art, while protocols exposing all authentication sessions should generally be avoided.
  • Anonymisation: Anonymisation methods protect low- to moderate-dimensional datasets against re-identification through database linkage, whereas high-dimensional data remains vulnerable and may incur substantial utility loss.The Netflix Prize example shows that limited auxiliary knowledge can identify records in high-dimensional datasets.
  • Privacy-friendly computation: Secure multi-party computation is practical for simple, high-value scenarios, while cryptographic privacy-preserving data mining is computation-specific and random perturbation trades accuracy for flexibility.Examples include private auctions, smart-meter aggregation, password protection, and simple statistics or regression.
  • Privacy-friendly computation and storage: Homomorphic encryption enables computation on ciphertexts, but current schemes do not generally match cleartext performance; encrypted cloud storage also leaks access patterns and can reduce functionality.SHE is recommended for additions and limited-depth multiplication, while oblivious-transfer techniques remain insufficiently scalable or flexible for general-purpose storage.

5 Conclusions & Recommendations

The report offers an initial bridge from legal privacy obligations to engineering practice, while concluding that privacy by design faces technical, conceptual, organisational, and policy limits. It recommends coordinated incentives, standards, procurement, funding, and enforcement to promote privacy-friendly systems.

  • Conclusions: The report is a first step toward guidelines for privacy-friendly and legally compliant products and services, bridging policy, law, engineering, and service provision.It inventories design strategies and technical building blocks, and sketches a method for mapping legal obligations to implementation choices.
  • 5.1 Limits of privacy by design: The report identifies immature techniques, unresolved issues, absent universal metrics, privacy–utility trade-offs, user friction, and increased system complexity as practical limits.These limits make risk assessment harder and can complicate responsibility, usability, and deployment decisions.
  • 5.1 Limits of privacy by design: Privacy by design cannot address every privacy issue because technology is only one part of broader social and fundamental-rights questions.Technical measures remain necessary where system design creates the ability to invade privacy.
  • 5.1 Limits of privacy by design: Privacy properties may fail under system composition, so individually protective components do not guarantee protection in the combined system.The report calls for further work on privacy-preserving composition.
  • 5.2 Recommendations: Privacy by design needs active promotion because developers often lack awareness and tools, while research remains loosely connected to practical engineering.Traditional approaches and current frameworks can make non-compliant systems easier to build than compliant ones.
  • 5.2 Recommendations: The report recommends incentives, audits, seals, independent assessments, procurement requirements, funding conditions, and stronger data-protection authority powers.It also urges legal and technical standards to embed privacy, default data minimisation, accessible information, and support for individual rights.

Annex A: The policy context

The EU has promoted “by design” and “by default” principles for security, privacy, and data protection through recent policy documents. These documents provide context and expectations for implementing those principles.

  • Recent EU policy documents promote “by design” and “by default” principles for security, privacy, and data protection.

A.1 Strategic policy documents related to ICT and cyberspace

European policy documents connect privacy by design with legal reform, system security, and practical controls over personal-data processing. They identify objectives including minimization, controllability, transparency, confidentiality, quality, and use limitation, while acknowledging that privacy by design may require more specific measures.

  • EU strategic documents connect privacy by design with modernising the personal-data protection framework and strengthening cybersecurity.
  • The ePrivacy Directive can be interpreted as calling for terminal equipment to support users’ rights to protect and control personal-data use.
  • Policy proposals call for privacy to be incorporated into ICT at the planning stage and for products and services to minimise processed personal data.
  • Privacy by design is associated with PETs, privacy-by-default settings, access controls, encryption, and tools that help users protect personal data.
  • The identified implementation objectives include data minimization, controllability, transparency, user friendliness, confidentiality, data quality, and use limitation.Use limitation requires secure segregation of data and processes serving different tasks or purposes.
  • The policy context acknowledges that privacy by design may not always ensure appropriate technological data-protection principles and may require context-specific regulation or a hands-on approach.

A.3 Other international conventions relevant for Europe

International instruments relevant to Europe increasingly describe privacy by design as embedding privacy protections into system architectures and data-processing operations. The reviewed policy context is limited to the EU perspective and does not cover all potentially relevant instruments.

  • The revised OECD Guidelines describe privacy by design as building privacy-protective technologies, processes, and practices into system architectures rather than adding them later.
  • The Council of Europe modernisation proposal includes privacy by design and calls for data-processing operations to prevent or minimise interference with rights and freedoms.
  • The proposal also expects products and services intended for data processing to consider data-protection implications from design and facilitate legal compliance.
  • Across the reviewed documents, privacy and data protection by design and by default share a focus on incorporating privacy principles throughout data-processing design and use stages.
  • The policy context covers only the EU perspective and excludes other potentially influential documents, opinions, working papers, and court rulings.
Loading 1501.03726v2…