In the first part of this series, I looked into the "layered approach" from the official EDPB transparency guidelines, mostly concerned with the where and how to present privacy information. This follow-up discusses the guidelines' suggestions for shaping transparency information itself: content, language, accessibility, intelligibility, etc.
I started to discuss the European Data Protection Board's (EDPB) "Guidelines on Transparency" - an interpretation of the relevant GDPR sections by the EU's independent data protection authority for practitioners - by highlighting the value of that document for design practice, and by stressing how transparency is key in any privacy design (and GDPR compliance) efforts.
"Part I: The layered approach" outlined a proposed solution to solve the intricate and seemingly contradictory requirement to provide comprehensive information in a concise format. Reducing complexity by dividing the information into two or more layers, the approach suggest, helps to provide users with an adequate level of data processing information in the use context (e.g. presented while filling in a form) and means to dive deeper into the details where desired:
On the primary layer, the user is informed about key facts regarding the processing of their data, along with an immediate and clear understanding of the most impactful and any potentially surprising consequences of proceeding;
the second layer (and, potentially, subsequent layers) then facilitates easy retrieval of all the information necessary - or demanded by law - for the individual to assess the processing in depth.
Designing content for transparency (this article)
Applying transparency design in practice (upcoming)
While representing a very effective way to make data processing less opaque, just layering information as described does not yet make it accessible for everybody. It is therefore, that the guidelines provide designers with a wide range of further instructions on how to ensure true transparency in the spirit of the GDPR's requirements (as the EDPB wants them to be seen interpreted).
Design drivers derived from the GDPR
N.B. This text does in no way constitute legal advice. I am not a lawyer, and not qualified to provide legal advice. All content, provided solely for informational purposes, has been researched with greatest care, but to create legally compliant solutions, you should always consult a lawyer or solicitor.Most of the requirements for the presentation of transparency information stem from Art. 12 GDPR. Since the regulation itself does not further elaborate on the details, the EDPB's guidelines provide an interpretation that can, once again, be used directly as design drivers .
"Concise and transparent"
As discussed in part I, even the EDPB acknowledges that being "concise" is not an easy task, given the amount of information required to ensure full transparency. But in their interpretation, and in combination with the term "transparent", "concise" does not so much relate to the volume of information itself, but to keeping it within reason and eliminating any undue excess. The guidelines provide some valuable hints:
"present [...] efficiently and succinctly in order to avoid information fatigue"; this is the exact opposite to a commonly observed dark pattern, where crucial information is deliberately wordily to tire the reader before they even have a chance to understand it
"clearly differentiated from other non-privacy related information"; by not mixing privacy information with general terms and conditions, or hiding it within unrelated information, it is ensured that users can digest it more easily
The document further repeats how layering the information into relevant chunks (ref. part I of this post series) and with direct links to applicable sections, plays a key role in achieving this goal.
"Clear and plain language"
The language requirements of the GDPR, even though not much further specified beyond "clear and plain language" in the law itself, are laid out rather specific as well.
The EDPB links to a European Commission publication on "How to Write Clearly", and summarizes some key points:
provision of the information "in as simple a manner as possible",
avoidance of complex sentence and language structures,
not phrased in "abstract or ambivalent terms",
not leaving room for different interpretations,
avoiding qualifiers like "may", "might", "some", "often", "possible", etc.,
use of indefinite language (expressions that leave open what exactly is referred to, e.g. "your data", "pseudonymized", etc.) only where it can be justified as unavoidable and "does not undermine the fairness of processing",
use of bullets, indents, and hierarchical indicators, for structure,
avoiding passive writing form and excess nouns, and
no "overly legalistic, technical or specialist language or terminology".
Last but not least it is suggested that transparency information should be provided in target-group specific languages, as for example indicated by the geographical or linguistic targeting of a website. In that, special care is advised to ensure that translations are clear as stand-alone documents.
This in itself is a complex task, but goes hand-in-hand with the other content requirements. If the language is not clear, how should any of the other goals be achieved? Looking at widespread practice, however, it appears there is a long way to go: it has traditionally been mostly lawyers writing out such information, using language with lots of "mays" and "somes", plenty of legalisms, and often more indefinite than definite language. I believe this to be one of the bigger changes the GDPR brought along, f.ex. compared to previous requirements in German law that did not specify such strict quality demands for information, but at the same time an often overseen one. The specificity of the EU regulation is hence an important and conscious step towards enforcing more transparency.
The guidelines expand this word into a definition of: "should be understood by an average member of the intended audience". This obviously includes using an appropriate level of language (see above), but goes beyond that. What is particularly interesting for the designer is that the EDPB explicitly expresses the expectation that a data controller knows their audience and are able to anticipate how they can be enabled to understand the information.
This means that for example the provider of a website with an academic target group can assume their readers to have a different level of understanding than a website for more general audiences. There is no one-size-fits-all solution for intelligibility; even if the applied data processing is the same, a presentation format that works on the academic website might fail to meet this requirement if used on the latter.
"No surprises"; information about consequences
In regards to any "complex, technical or unexpected" data processing, the document highlights the need to "separately spell out in unambiguous language what the most important consequences the processing will be" (emphasis in original). In other words: it is not only important to describe the processing itself, but to make the individual understand what this may lead to. This involves the need to make a careful assessment of the data subjects' risks, documenting it to fulfill accountability requirements, and evaluate the need to make the consequences known to the individual in advance.
This is at the same time a very vague, but a highly relevant consideration. While, for example, some may consider tracking for targeted advertising not an unexpected data use and the consequences negligible, there may be contexts or individuals where already the seemingly "harmless" display of targeted advertising can lead to real-life consequences of unforeseen magnitude. As with the previous points: the assessment is highly case and audience specific, and data processing not requiring a special note in one project may require a high-vis warning banner in another.
The guidelines further mention a few examples: e.g. positioning a "privacy" link oddly or with reduced color contrast cannot be considered "easily accessible", nor can hiding it so that the user has to search for it (it should be present and obvious on every page, at every stage).
Special provisions for "children and other vulnerable people"
The EDPB's interpretation of the GDPR contains some really interesting aspects when it comes to providing transparency for children. The guidelines state that, even though consent may in practice often be given by a parent or legal guardian, the "right to transparency" is an independent right and the requirements discussed above still apply considering the individual ultimately affected.
In other words: even though a parent may be considered to be involved in evaluating and approving the data processing policy of a service, the provider is still required to provide all transparency information in a format that checks all of the above boxes while considering the recipient to be a child. Only very young and pre-literate children are carefully exempt from that.
On that note: the BBC carried out an interesting experiment, letting children read the terms and conditions of YouTube and Instagram - the latter used by 80% of children between ages 5 and 15 - and determining that the website terms of the 15 most popular websites in the UK would all require a university degree to understand.
Referring back to the need to tailor transparency information to the target group, a similar requirement is made for goods/services used by "people with disabilities or people who may have difficulties accessing information". This is not further specified in the document, but it is stressed that also the potentially different level of vulnerability (ref. "No surprises; information about consequences" above) among such groups needs to be addressed.
It doesn't always have to be text
While textual information is likely to be the most common format, the GDPR in principle also allows for alternative formats. In the EDPB guidelines, videos, voice files, cartoons, infographics, flowcharts, pictograms, and animations are mentioned as examples. These are likely to complement textual information within a layered transparency system, and may come particularly handy when designing for children or limited-literacy target groups.
Even when using multi-medial content in a layered approach, the requirement to make the entirety of information available in one central place must, however, not be forgotten. On the other hand, some technologies may not even contain a screen to display textual information on (the guidelines mention IoT devices, but also voice-guided telephone systems come to mind).
The guidelines' mention of "pictograms" is interesting in that the development of a unified visual system to convey privacy information to individuals is an explicit suggestion contained in the GDPR (Recital 60). Yet, such system does not currently exist and there are only early developments underway; I would mention at least the work of Aza Raskin and Mozilla and the outcomes of a recent legal design workshop at Stanford Law School as ongoing efforts towards that goal. That, however, should not stop the designer of privacy transparency information to make use of pictograms/icons to ease the understanding of the information. Yet - as always - icons should never be used alone, without further indication of their meaning.
The information to be provided
In addition to being provided in a layered manner and being designed following the described rules, another design question is the decision of what information to provide. This is in parts dependent on whether the personal data is collected from the individual directly (Art. 13 GDPR applies) or from a third party (Art. 14 GDPR). Also timing of the information can play a role.
This article series discusses only selected design-relevant aspects of the EDPB transparency guidelines. Readers are advised to familiarize themselves with the full publication, as not all aspects are covered herein.Given that the table-formatted overview of required information alone takes up six pages in the EDPB document, discussing every detail is beyond the scope of this article series. I highly recommend to print out the table from the guidelines and use as a resource when designing the content.
_In the third and last article of this series (upcoming), I _aim to tie all these learnings together into thoughts about the practice of transparency design for privacy.
- With close to no court decisions existing on GDPR, yet, following guidelines of this level can be an important factor to minimize risk; even though courts may - and likely will - take a different perspective on certain aspects, a documented evaluation based on the EDPB guidelines can be a great means to prove best effort.↩
- §4 Abs. 3, §§33-35 BDSG-alt↩
- Easily skipped over when reading, this paragraph (15) of the document is actually one of the most revealing as to what importance the WP29/EDPB assign to transparency, not only under GDPR but from a human rights perspective.↩
- The document is not explicit about this, but just thinking about the sheer amount of detail to be documented on some level it is hard to imagine transparency information that does not contain a certain amount of written text.↩
- Along with potential solutions, the explorations also help recognize the inherent challenges. For a worthwhile discussion on the problems related to "privacy icons", read "Some comments on the EU's draft Privacy Icons" by Hugo Roy.↩