The ubiquitous presence of technology creates ever more urgency to account for privacy issues [13]. Considering and accounting for privacy during the design of information systems is often referred to as 'privacy by design' [1,10,12,16]. Privacy by design has become particularly prominent due to the European Union's General Data Protection Regulation (GDPR), that has gone into effect in May 2018, which requires meeting the principles of privacy by design when processing personal data [6].
One of the best-known works on privacy by design is by Cavoukian [1], introducing seven design principles to enable individuals to gain personal control over their information and to enable organizations to gain a sustainable competitive advantage. Cavoukian's principles are high-level guidelines that still need to be translated to actual system designs and engineering practices [8]. Currently, there exist no well-established approaches for translating the high-level privacy by design principles to practice [8,19,23].
One of the major challenges in applying privacy by design is that it requires the integration of perspectives from multiple stakeholders (user, designer, developer, etc.) and disciplines (HCI, software engineering, law, etc.) [4,5,8,15]. In the area of requirement engineering, a number of methods have been proposed that integrate multiple perspectives to elicit privacy-related system requirements, e.g. by using multiple information sources [15], questionnaires and scenarios [7], and workshops with multiple stakeholders [2,3,5,17].
Although the above works aim at taking into account multiple perspectives in eliciting privacy requirements, they do not elaborate upon how well the applied methods integrate these perspectives in practice. In this paper, we therefore investigate the potentials and shortcomings of using a workshop with multiple stakeholders as a method to surface privacy-related problems from multiple perspectives, by applying it to two design cases.
The workshop we use is suitable for the initial phase of a systematic privacy by design approach, aiming to identify privacy issues and trade-offs from multiple perspectives related to the (re-)design of an information system. A diverse participant group is key to the approach, as the participants represent multiple perspectives on privacy. The workshop centers around a timeline, which serves as a boundary object to bridge the participants' domains of expertise [21,22]. This timeline is used to capture the flow of data in the system to be (re-)designed. The use of a timeline with data is inspired by mappings as known from IT and HCI/UX, such as a customer journey map [11,14], threat modelling [18], and a typical data lifecycle (e.g., as considered by various spheres in [20]).
To gain practical experience with the workshop format, we organized two sessions with 6 stakeholders: a problem owner (domain expert), an end-user, and four privacy experts with a social, ethical, technical and legal perspective, respectively. The workshops were led by a moderator (a designer). The roles of moderator and privacy experts were fulfilled by researchers at Rotterdam University of Applied Sciences (RUAS), and those of problem owner and end-user by people outside of RUAS, associated to the respective domains. In an iterative design fashion, the results of the first session were used to inform the second.
The first case deals with the design of recording surgeries in the Operation Theater (OT) in a so-called OT Black Box. Data stored in this OT Black Box contain video and audio recordings of the OT, featuring the patient and the OT team, typically consisting of surgeons, anesthesiologists, nurse anesthetists and OT nurses. These recordings are later used by the OT-team to analyze and evaluate their performance, and by a quality and safety manager to detect potential safety issues and improve the OT procedure if possible. After two days, the recordings are anonymized (patient and OT-team are no longer identifiable) and used for medical training purposes. Recordings are then no longer available for the patient who underwent the surgery. Before the workshop, the moderator and problem owner prepared a timeline consisting of five steps (see Figure 1). For each step, a large (A0-sized) paper was put on the wall, on which the other workshop participants could write and add sticky notes. Each participant was provided with markers and sticky notes of a unique color, so that the contributions on the poster could be traced back to the different perspectives.
The four-hour workshop session consisted of five activities. First, the design case was introduced by the problem owner, explaining what happens in each timeline step. Second, data assets per timeline step were identified by the workshop participants (first individually, then in a group discussion), and added to the posters. Third, privacy violation risks per timeline step were identified (first individually, then in a group discussion), and added to the posters. Fourth, opportunities and risks of the information system as a whole were determined and trade-offs were identified (in a group discussion). Fifth, the workshop participants agreed on a set of design constraints, based on the identified trade-offs (in a group discussion).
Figure 1 shows some of the 'data' and 'privacy risks' that were identified per timeline step. The overview is not exhaustive but intends to provide a gist of the contributions from different participants. The results show that they bring in different perspectives. For instance, the social privacy expert mentions that the patient's dignity may be at stake, whereas the legal privacy expert points at the application of a privacy impact assessment. After identifying privacy risks, participants agreed that the most important trade-off was improved healthcare versus deteriorated privacy, i.e., recordings by the OT Black Box can enhance the quality of healthcare, but they introduce privacy violation risks for both the patient and the OT team. There was little time left to perform the last activity, identifying design constraints. Participants stressed that data should only be used for the purpose they were collected for.
The second design case involves the use of the mobile application WhatsApp for damage claims to an insurance company. The insurance company offers its customers the possibility to send text and pictures of car damage (including pictures of the location) via WhatsApp, when claiming the damage to the insurance company. These messages and pictures are encrypted by WhatsApp.
Although detailing the 'data' of all timeline steps in the first workshop brought forward deeply engaged participants, it also led to discussions in which domain-specific details were explored by non-experts. Moreover, it led to time shortage later on in the session. We therefore asked the problem owner in the second workshop to detail the data in each timeline step beforehand (Figure 2, 3rd column). The other workshop activities remained the same.
Figure 2 shows the results of the second workshop session. Again, these results are not exhaustive, yet indicative. Similar to case 1, privacy issues related to ownership, faulty data and function creeps were identified. In the discussions, a lot of attention was paid to the trustworthiness of the photos sent for a damage claim via WhatsApp, as they could easily be manipulated or uploaded from the internet. Thanks to the new setup of the workshop, it was possible to complete all workshop activities this time.
Participants identified a trade-off between ease of use and privacy. Using WhatsApp for reporting damage increases ease of use for customers but introduces privacy risks due to relying on a 3rd party service provider. Other trade-offs identified were knowledge versus privacy (collecting and storing information increases insurers' knowledge, but introduces privacy risks), costs versus privacy (building an in-house application protects customers' privacy, but increases costs), ease of use versus security (as the ease of using WhatsApp creates security risks due to relying on a 3rd party service provider).
The workshop participants identified the following design constraints and recommendations: 1) insurance companies should develop their own application rather than relying on 3rd parties such as WhatsApp, this should be done according to privacy by design principles, 2) customers should always be able to choose whether they want to make use of WhatsApp, 3) customers should be informed about their options and the implications of their choices, 4) as least data as possible should be collected, data should not be collected if they will not be used, 5) customers should be able to access their personal data stored by the insurance company, and 6) authorization of data access should be implemented carefully in the insurance company in order to avoid function creeps.
In both design sessions, stakeholders from different disciplines identified different (privacy) problems and high-level requirements. For instance, the technical expert focused on issues related to the processing of data, such as data leaks and de-anonymization of data, whereas the social expert brought up the issue of human dignity and the legal expert identified issues related to authorization of access. The number of identified issues of all stakeholders was larger than any of the individual stakeholders' contributions. Having multiple perspectives represented thus provided a richer view on the design case at hand. Besides helping the privacy by design of IT systems, the workshops were increasing awareness about privacy and its complexity among the participants, i.e., they learned from each other and gained more insight in the complexity of privacy by design.
A number of issues should be considered when combining perspectives of multiple stakeholders in a workshop in general, and in this workshop in particular. First, in a multiple stakeholder workshop, there is a risk that some perspectives are more dominant in the discussion than others. This could be countered by stricter time management by the moderator, making sure that all participants receive an equal amount of speaking time. Second, different perspectives, objectives and/or identified risks may not be of equal importance. In future work, guiding principles for weighing different perspectives should be developed. Third, the boundary object of a multi-stakeholder workshop, in our case the timeline, steers the discussion in the workshop. In future research, developing guidelines for preparing the timeline could help avoiding too directive descriptions. Fourth, in our workshops, a number of well-known tradeoffs did not surface (e.g., data-subject/user control versus central/system control, prevention versus mitigation, and technical versus procedural). This could be explained by a lack of expertise of the participants. Yet, the likelihood of overseeing important trade-offs can be lowered by providing more structure for discussing design trade-offs and providing design recommendations, for example by systematically holding design tradeoffs along various dimensions (e.g., data usage vs data privacy, data-subject control vs central control, prevention vs mitigation, and technical vs procedural).
In future work, we will take up the issues mentioned in this discussion and work on the subsequent steps of a privacy by (re)design approach. We foresee the need of developing a method that systematically translates the current workshop outcomes (i.e., design recommendations and constraints) into software requirements, e.g. by using bridging concepts such as value stories [9], turning privacy by design into privacy engineering. For giving more structure to the design thinking process, we foresee organizing the design discussions along three directions of security related aspects, usersbeing-in-control related aspects and data-minimalization related aspects. The outcome of these sessions should deliver a number of promising design options, which can be prototyped and improved in a number of iterations.
The authors thank all the workshop participants for sharing their expertise and for their valuable contributions.