Categories: transparency • access • inform • provide

Personal Data Table

Contents

Context

Controllers which maintain software systems that process user data, especially identifying or sensitive data, are subject to various laws. In the case of personal data, transparency about processing is particularly important. Users (the data subjects) also care to know about what data is used, and what might be done with that data, at various degrees. Users do not often want to be constantly notified or reminded, as many of them would rather spend their time actually using the system. Some users, however, care about more intricate detail, and are entitled to it. Nonetheless, if verbose information is provided, it should be sensible.

Problem

The controller wants to be upfront about what they know and can do with personal data which might be of importance to those users. They only want users to know about data and risks pertaining to them specifically.

Forces and Concerns

  • The controller wants to show the actual data they process, as well as what they do with it, as opposed to just describing policy
  • Users want full transparency, with detailed explanation as well as easily and quickly understood overviews
  • Controllers do not want this transparency to ruin trust, but to strengthen it
  • The controller wants to keep the data on their servers, while still allowing users to automatically view their own data

Solution

Keep track of the processing that occurs on personal data so that users can view the activities associated with their data and review their preferences in a tabular environment.

[Structure]

Which information A table that shows the overview. The overview could show: − Which data − Why collected − How used/for which purpose collected − Who has access to the data − Who the user authorized for access − Which consent the user has given for specific data − To which parties the data is disclosed − Who has seen the data − Whether the data can be hidden − Whether the data can be removed − How long the data is stored − How datasets are combined to create richer (privacy sensitive) information. Note that this may violate local laws and regulations − With which other information the data is combined

Where in the application flow Options are (not mutually exclusive): − At the service’s help section − At the service’s privacy section − Through a separate menu item − At a myData section of the service

Amount of information A table can show a lot of information or can be adjustable by the user to tweak which information to show, and which values (e.g. which range). From the table links to applicable other pages/screens can be given, to allow a user to easily change privacy settings (or possibly delete data) or visit websites of data buyers. A way to present more detail than visible at the overview table is to apply the Overview beside detail user interface pattern (Laakso 2003).

[Implementation]

Provide users with access to an interface which displays their data in useful dataset views, and give them the option for raw information. See the following table for an example.

|Type of Data|Data|Date Recorded|Accessed by| |--|--|--|--| |data type a|data itself|date a|person one| |data type b|data itself|date b|person one, person two|

To be really transparent, also show things like how and why data was used, who of your organization has access to the user’s personal data, what was downloaded or sent to a specific third party, and when all these events happened. The table can present all the data at once, or order it in categories, that may be further detailed when the user selects a category.

Consequences

Benefits: − Actual data: Users can see the actual personal information you have, real-time*. − Details: A table can show all the personal information at once, in a structured way. − Details: Users may see errors in their data and ask for rectification, thereby improving the data quality. − Security and Availability: Data can remain stored in a secure place and still be available to your users whenever they want to see it. − Usability: Users get a better understanding of the personal data your systems holds and how you handle their data. Users may even decide to better control access to their data (not part of this pattern), increasing their own privacy and limiting the risks of privacy incidents, caused by e.g. an external attack on the system. − Trust: Providing transparency in a user-friendly manner increases the trust that users have of you as an organization. − Automation: A table is relatively easy to implement and automatically generate, compared to for example graphic data visualisations.

Liabilities: − Actual data: Everything that happens to all user data must be logged. This may impose a privacy problem of its own. − Details: Users may be overwhelmed by the amount of data you have and decide to stop using your system − Security and Availability: Some users may want to have the data on their own systems, for example to run their own analyses. This pattern does not make that possible, but the functionality could be easily provided. − Trust: Users may decide to delete some of their data or otherwise restrict access to their data in a way that decreases the amount of data available for your systems. Or users may even decide that the privacy infringement is too large and stop using your system all together.

*Providing real-time insight in all personal data that a system contains is not common practice; currently people usually have to put in a formal request (e.g. by email) and wait for a couple of weeks until they receive a reply with zip-file attached.

Examples

[Known Uses]

Figure 1 shows the actual design of the personal data table pattern implementation for a Quantified Self data store, the Nutritional Research Cohort (NRC). The NRC is a cohort of researchers in nutrition and health sciences who gather self-assessment data on their lifestyle and their health. NRC gives access to information on personal health trajectory, and the effects of diet on personal health. For each column, a mouse overlay details the meaning of the column name. This solution implements an overview of which data is collected, whether data is private or shared with others, for which purpose the data is used, which external parties requested the data, and who downloaded the data and when. This overview is shown on a special page in a myData section of the NRC application.

See Also

This pattern complements Minimal Information Asymmetry. Like this pattern, it allows a user to see what personal data is acquired by the controller. It provides a better understanding of what data is processed and the policies surrounding that processing, including potential risks. Together these patterns show a clearer representation for the user to consider.

This pattern may be used by Privacy Mirrors. It keeps track of what is known, and allows for various configurations within this. It also stems from a multidisciplinary context. As such there exists a an extension of functionality in this. However, as the described problems are different, there is not an extends relationship.

Patterns that also show personal data within a user application are the Personal Data Infographic (showing data as infographic, not a table) and Viewable Personal Data Overlay (showing in an overlay which data is viewable by others)[.] Furthermore, the Digital File with Personal Data pattern allows a user to receive the personal data collected for a certain service in a digital file.

[Sources]

J. Siljee, “Privacy transparency patterns,” in EuroPLoP ’15, 2015, pp. 1–11. W. Kraaij, B. Hulsebosch, J. Siljee, M. Kooij, R. Kosman, and J. Janssen, “Privacy Tansparency,” SWELL, 2014. [Online]. Available: http://www.swell-project.net/dynamics/modules/SFIL0100/D4.9%20Privacy%20Transparency893d.pdf. [Accessed: 10-Oct-2017].