Improving the Transparency of Privacy Terms Updates

Abstract

Updates are an essential part of most information systems. However, they may also serve as a means to deploy undesired features or behaviours that potentially undermine users’ privacy. In this opinion paper, we propose a way to increase update transparency, empowering users to easily answer the question “what has changed with regards to my privacy?”, when faced with an update prompt. This is done by leveraging a formal notation of privacy terms and a set of rules that dictate when privacy-related prompts can be omitted, to reduce fatigue. A design that concisely visualizes changes between data handling practices of different software versions or configurations is also presented. We argue that it is an efficient way to display information of such nature and provide the method and calculations to support our assertion.

Appendices

Appendix A Information Efficiency Calculation Example

We extend the material from Sect. 5 by providing another example. Consider the last term of the tuple, $\varPhi$, which represents the frequency with which data are sent. Suppose that in this case we express it as a choice among these options: $\{$multiple times per second, every second, every minute, hourly, daily, weekly, monthly, on-demand$\}$. Given that the set has 8 options to choose from, it means that a choice of a specific element yields $\lceil log_2 8\rceil =3$ bits of useful information.

Following the same principle, we quantify each component of a privacy term $\varTheta$, using terminology adapted from several sources: Platform for Privacy Preferences (P3P) [9], Data Privacy Vocabulary (DPV) [4], and Apple developer guidelines [3], summarized in Table 3. Note that different vocabularies provide a different level of granularity, for example, DPV distinguishes between 161 types of data, while P3P only 16. Since devising a vocabulary is outside the scope of this paper, we err on the safe side and take the maximum values (highlighted in bold) among the considered examples.

Table 3. Summary of discrete choices to indicate the type of collected data, purpose of collection and retention period, using notation proposed by DPV, P3P and Apple developer guidelines.

After substituting each component, we get: $\varTheta = 8 + 5 + 20\times 6 + 8 + 11 + 3 = 155$ bits. Therefore, the pure information required to express a term is 155 bits, this is how much we would transmit, if we could upload it directly into the conscience of a person. However, some overhead is added because the information is encoded into words, or other forms that have to be perceived by end users.

Fig. 7.

Annotated calculations that explains how the amount of information in each privacy term is computed, yielding a total of 155 bits.

We argue that the tabular representation is a highly efficient way of encoding privacy terms. This assertion is supported by the following calculation. Suppose that the notation consists of 26 small letters of the Latin alphabet, 10 digits, the , and symbols. The notation has a total of 39 characters, which means that a single character is worth $\lceil log_2 39\rceil =6$ bits. In addition, the following conventions apply: a company name is assumed to be a string of 20 characters, thus it is worth up to $20 \times 6=120$ bits.

We now apply this encoding to Fig. 7, ignoring the data type icons and the country flags for simplicity. Each line is 49 characters long, yielding $49 \times 6=294$ bits. At this stage we can compute the efficiency of this representation: $\eta =\frac{{info}_{useful}}{{info}_{total}}\times 100= \frac{155\times 2}{294\times 2} \times 100\approx 53\%$.

Armed with this number, we can consider various ways to improve efficiency and measure their impact. For example, we can remove the country names and leave only their flags, or use two-letter ISO codes instead of full names. Entries can also be grouped, e.g., all terms related to temperature can skip the word “temperature” in all but the first entry. In addition, search and filter functionality can be used to hide all the rows except the ones the user wants to focus on, thus reducing the total amount of displayed information. With such an efficiency metric at hand, one can argue in favour of one design over another, supporting the choice with hard data.

In addition, we can use the same metric to compare entirely different notations. For example, consider this hypothetical prose version of the terms expressed in Fig. 1: “We care about your privacy, therefore our smart indoor temperature and humidity meter only collects and shares your data with 2 companies. Temperature data are shared on a daily basis with Minerva LTD, located in Canada. The data are retained for a period of 1 year and are used for research purposes. Humidity is shared on an hourly basis with ThirstFirst LTD, and retained by them for 1 year, in the USA. Humidity data are used for marketing purposes”. It is 453 characters long, and for the sake of simplicity let us assume that it also uses an alphabet of 39 symbols: 26 lower case Latin letters, 10 digits, space, comma, period. As in the previous case, each symbol is worth 6 bits, therefore $\eta =\frac{{info}_{useful}}{{info}_{total}}\times 100= \frac{155\times 2}{453\times 6} \times 100\approx 11\%$.

The prose version is clearly a step down from an efficiency of 53%! While we acknowledge that this synthetic version of a prose policy could have been shorter, such laconic policies are not the norm [18, 19, 26].

Appendix B When to Display Consent Prompts

The following pseudo-code illustrates the logic defined in Sect. 4 in action:

A more granular approach enables us to tell whether a primary or a secondary filter matched, allowing more control (e.g. the GUI can display different prompts, depending on the magnitude of the difference):