Pattern Systems for Data Protection: Informed User Control

Software, programs, applications (or 'apps'), on any device, are information systems. System developers (programmers) use various tools to create these systems [1]. Some of the tools help to form the basis of the system, and some improve it. A non-functional improvement is often called a software quality [2]. Unlike functional requirements, software quality is less 'does it work?', and more 'how well does it work?'.

Stakeholders in a company give varying attention to different software qualities [3], [4]. Some care more about certain qualities than others. Some qualities, for example, are more marketable. It is typical for such aspects to take priority. At first, security was not profitable, though over time its benefits became clear. Privacy is following suite [5]. The potential benefits to public image, and financial loss otherwise, are now evident.

One of the strong drivers for the adoption of privacy is the law. In the European Union, the General Data Protection Directive (GDPR) mandates it [6]. Data protection is the Union's flavor of privacy. Unlike privacy, the GDPR defines clear rules around it, which makes it more explicit. Neither data protection nor privacy have true definitions, though [7]. This is because both have deliberate vagueness. What one person may consider to be invasive, varies from another, and depends on context. Handling such a flexible concept is difficult when you constrain it to a definition [7].

It would be normal for this to affect enforcement. How do we protect something so subjective as privacy? The GDPR provides data protection principles to help with this [6]. When creating a system, developers must use Data Protection by Design and by Default. This requires developers to consider impacts which their systems might have on privacy [3]. If something poses a high risk, they need to give it due consideration [6]. This entails a formal Data Protection Impact Assessment. It also includes various special requirements, depending on context. Even with low risk, there are rules which developers must follow.

These rules are all verbose and complex, despite also needing to be broad [6], [7]. Often lawyers tailor laws for lawyers, not for developers. Yet these developers still need to adhere to the principles contained in the GDPR. So instead of giving them legal texts, we sought an alternative.

Developers are more familiar with development. Some of the more common development tools are software design patterns. These are recipes for solutions to recurring problems in software development [2]. They are not very prescriptive, though. They provide advice for experienced developers to consider given a specific context. They describe the various forces and potential consequences that developers must weigh. With these, good developers can create better solutions from the experience of others.

The pattern domain catering to privacy was slow growing. A few efforts considered privacy for its benefits, rather than risks of its absence [8]–[10]. This mere quality metric was the traditional way of viewing privacy. With the GDPR, though, privacy benefits are not only software qualities [6]. Through data protection, they are necessary functional requirements. As they can make or break GDPR adherence, their proper usage important. Undermining them may result in losses of both trust and finance.

We thus set out to refine privacy patterns so that they can help developers protect privacy. There were many of these privacy patterns, both disconnected and inconsistent [11]–[13]. Together with others in the field we collected these, and unified their representation [11]. We categorized them, making them easier to filter through and traverse. And finally, we set out to rewrite them [14], [15]. We did so with close adherence to data protection principles.

We sought to elevate the patterns to a high standard as regarded by the pattern community [2], [16]. A such, we utilized their recommendations on pattern writing. We selected a standardized relationship scheme, and began to identify privacy pattern relations. This enabled us to present the patterns in a pattern system [15]. Such a system is important in selecting appropriate patterns and understanding their requirements. It aids developers in best approaching a given problem [2].

We have created two pattern systems thus far. One supports informing users, and is currently under review. The other pattern system maximizes user control [15]. Together, the systems permit informational self-determination. These systems shall both reside in privacypatterns.org [11] and GitHub [14]. As such, they are open to extension. This is in line with the requirements of a pattern system, supporting its improvement.

Michael Colesky

[1]     M. Hamilton, Software Development: Building Reliable Systems. 1999.

[2]     F. Buschmann and R. Maunier, Pattern-Oriented Software Architecture, A System of Patterns. 1996.

[3]     A. Cavoukian, “Operationalizing Privacy by Design : A Guide to Implementing Strong Privacy Practices,” pp. 1–72, 2012.

[4]     M. Hansen, M. Jensen, and M. Rost, “Protection Goals for Privacy Engineering,” in International Workshop on Privacy Engineering, 2015.

[5]     J. Lenhard, L. Fritsch, and S. Herold, “A Literature Study on Privacy Patterns Research,” SEAA 2017, 2017.

[6]     European Parliament and Council of the European Union, “General Data Protection Regulation,” Official Journal of the European Union, 2015.

[7]     D. J. Solove, “Understanding Privacy,” Harvard University Press, 2008.

[8]     N. Doty and M. Gupta, “Privacy Design Patterns and Anti-Patterns Patterns Misapplied and Unintended Consequences,” pp. 1–5, 2003.

[9]     M. Hafiz, “A collection of privacy design patterns,” Proceedings of the 2006 conference on Pattern languages of programs - PLoP ’06, p. 1, 2006.

[10]    C. Boesch, F. Kargl, H. Kopp, and P. Mosby, “privacypatterns.eu - collecting patterns for better privacy,” 2013. [Online]. Available: https://privacypatterns.eu/. [Accessed: 18-Jul-2017].

[11]    N. Doty, M. Gupta, and J. Zych, “privacypatterns.org - Privacy Patterns,” privacypatterns.org, 2018. [Online]. Available: http://privacypatterns.org/. [Accessed: 05-Feb-2018].

[12]    “privacypatterns.eu - collecting patterns for better privacy,” privacypatterns.eu, 2013. [Online]. Available: https://privacypatterns.eu/. [Accessed: 20-Oct-2015].

[13]    O. Drozd, “privacypatterns.wu.ac.at - Privacy Patterns Catalog,” privacypatterns.wu.ac.at, 2016. [Online]. Available: http://privacypatterns.wu.ac.at:8080/catalog/. [Accessed: 25-Jan-2017].

[14]    N. Doty and M. Gupta, “privacypatterns,” github.com, 2018. [Online]. Available: http://github.com/privacypatterns/patterns.

[15]    M. Colesky, J. Caiza, J. Del Álamo, J.-H. Hoepman, and S. Martín, “A System of Privacy Patterns for User Control,” in 33rd Symposium on Applied Computing, 2018.

[16]    N. B. Harrison, “Advanced Pattern Writing,” Pattern Languages of Program Design 5, 2006.