Use case 3b: Managing o ne s data pro tectio n settings

repetitive prom pting co nstantly putting into questio n a clear refusal they m ade is burdenso me. This clear actio n that users to ok during the registratio n process is now co nstantly put into questio n. The induced degradatio n o f the user experience significantly increases the pro bability that users will accept the targeted advertisement at some po int, just to avo id being asked again every time they lo g into their acco unt and wish to use the social media platfo rm. In this case, no t giving o ne s co nsent has a direct im pact o n the quality o f the service given to users and co nditio n the perfo rm ance o f the co ntract.

c . Best prac tic es

Cross-dev ic e c onsistency: When the so cial media platfo rm is available thro ugh different devices (e.g. com puter, sm artpho nes, etc.), settings and info rm atio n related to data pro tectio n sho uld be lo cated in the sam e spaces across the different versio ns and sho uld be accessible thro ugh the sam e jo urney and interface elem ents (menu, ico ns, etc.).

Change spotting and c omparison: see use case 1 fo r definitio n (p. 22).

Coherent wordings: see use case 1 fo r definitio n (p. 22).

Prov iding definitions: see use case 1 fo r definitio n (p. 22).

Use of examples: see use case 1 fo r definitio n (p. 22).

Stic ky navigation: see use case 2a fo r definitio n (p. 28).

Bac k to top: see use case 2a fo r definitio n (p. 28).

Notific ations: see use case 2c fo r definitio n (p. 32).

Explaining c onsequenc es: see use case 2c fo r definitio n (p. 32).

Use case 3b: Managing one s data protection settings

a. Description of the context

After co m pleting the sign-up pro cess, and during the entire life cycle o f their so cial m edia acco unt, users sho uld be able to adjust their data protectio n settings.

Whether users have prio r kno wledge o f data pro tection in general and the GDP R in particular o r no t, and whether they are attentive to the personal data they do o r do no t wish to share and o thers to see, they all are entitled to being info rm ed abo ut their po ssibilities in a transparent m anner while using a so cial m edia.

Users share a lot o f perso nal data o n so cial media platfo rms. They are o ften encouraged by the so cial media platfo rm s to keep sharing mo re o n a regular basis. While users m ight want to share m oments o f their life, to participate in a debate o n an issue o r to bro aden their netwo rks o f co ntacts, be it fo r pro fessional o r perso nal reaso ns, they also need to be given the to o ls to co ntro l who can see which parts o f their perso nal data.

b. Relev ant legal provisions

As m entio ned abo ve,49 as one o f the main principles co ncerning the pro cessing o f perso nal data, Article 5 (1) (a) o f the GDPR stipulates that perso nal data shall be pro cessed lawfully, fairly and, especially crucial in this regard, in a transparent manner in relatio n to the data subject ( lawfulness, fairness and transparency ). Acco rding to the acco untability principle as per Article 5 (2) GDP R, co ntro llers are required to sho w which measures they are taking to m ake their pro cessing activities no t only lawful and fair, but also transparent. In additio n, the principles o f m inim isatio n under Article 5 (1) (c) and data protection by design and default under Article 25 GDP R are relevant in this use case.

c . Dark patterns i. Content-based patterns

The first issue that users enco unter in this co ntext is where to actually find settings dealing with data pro tectio n. Users m ight read the data pro tectio n no tice and then decide to m ake changes related to the processing of their perso nal data. They co uld also wish to do so witho ut having read the notice, just thro ugh their regular use o f the so cial m edia, fo r exam ple when they realise that an info rm atio n po sted o n a social media platfo rm (e.g. a pho to at the beach with o ne s fam ily) is shared with an undesired gro up of peo ple (e.g. co-wo rkers). In any event, the principle o f transparency requires the setting o ptio ns to be easily accessible as well as to be available in an understandable way.

There are several design patterns related to this issue which m ake it hard fo r users to find the settings. Social m edia platfo rm designers therefo re o ught to be m indful to avo id these dark patterns.

Overloading Too many options (Annex checklist 4.1.3)

Data protectio n settings need to be easily accessible and o rdered lo gically. Settings related to the sam e aspect o f data pro tectio n sho uld preferably be lo cated in a single and pro m inent lo catio n. Otherwise, users will be facing to o m any pages to check and review which overburdens them in the settings o f their data protectio n preferences. Indeed, co nfro nted with Too many options to choo se fro m, it can leave them unable to m ake any cho ice or m ake them o verloo k some settings, finally giving up o r m issing the settings o f their data protectio n preferences. This go es against the principles o f transparency and fairness. In particular, it can go against Article 12 (1) GDP R as it either m akes a specific co ntro l related to data pro tectio n hard to reach as it is spread acro ss several pages o r m akes the difference between the different o ptio ns provided to users unclear.

Example 35: Users are likely to no t know what to do when a so cial m edia platfo rm s m enu co ntains m ultiple tabs dealing with data pro tectio n: data protection , safety , content , privacy , your preferences .

In this exam ple, the tab titles do not o bvio usly indicate what co ntent users can expect o n the asso ciated page o r that they all relate to data pro tectio n, especially when o ne o f the tab specifically bears this name. This can create the risk o f preventing users from m aking changes. Fo r exam ple, if they wo uld like to restrict o r bro aden the num ber o f perso ns who can see the pictures they have uplo aded, the tab names co uld lead them to either click o n safety , if users think there are som e

49 See abov e, para. 1, 8, 9, 13-1 5.

safety risks in having their data publicly accessible; co ntent , as users wish to set the visibility o f their po st; o r privacy , as this specific notio n directly relates to what peo ple want to share with o thers. This m eans that these titles are no t clear eno ugh in regard o f the actio n users wo uld like to achieve. In particular, the term s data protectio n and privacy are o ften used as syno nym s and are therefo re especially confusing if presented as different sectio ns.

Left in the dark Conflicting information (Annex checklist 4.6.2)

As already described in exam ple 12 and further illustrated in the fo llo wing exam ple, users can also be given Conflicting information within the framewo rk o f the data pro tectio n settings.

Example 36: User X switches o ff the use o f their geo lo catio n fo r advertisem ent purpo se. After clicking o n the to ggle allowing to do so , a message appears saying We've turned off your geolocation, but your location will still be used.

Overloading Privacy maze (Annex checklist 4.1.2)

When users change a data protectio n setting, the principle of fairness also requires so cial m edia pro viders to info rm users abo ut o ther settings that are sim ilar. If such settings are spread acro ss different, unco nnected pages o f the social media platfo rm , users are likely to m iss o ne o r several m eans to co ntro l an aspect o f their perso nal data. Users expect to find related settings next to each o ther.

Example 37: Related to pics, such as the settings o n data sharing by the so cial m edia provider with third parties and vice versa, are no t m ade available in the same o r clo se spaces, but rather in different tabs o f the settings menu.

There is no o ne size fits all appro ach when it co mes to the average num ber o f steps still bearable fo r users o f social media platfo rm s to take when changing a setting. At the sam e tim e, a higher num ber o f steps can disco urage users fro m finalising the change o r make them m iss parts o f it, especially if they want to m ake several changes. Hindering in such a way the will o f users go es against the principles o f fairness in Article 5 (1) GDP R. In additio n, changing the settings is closely related to the exercise o f data subject rights.50 Changing a data related setting, such as co rrecting o ne s nam e o r deleting one s graduatio n year, can be co nsidered an exercise o f the right to rectificatio n, respectively right to erasure, fo r these specific data. The num ber o f steps required sho uld therefo re be as low as po ssible. While it m ight vary, an excessive num ber o f steps hinders users and therefore go es against the fairness principle, as well as Articles 12 (1) and (2) GDP R.

Left in the Dark Language Discontinuity (Annex checklist 4.6.1)

With regard to transparent info rmatio n, so cial media platfo rm designers also need to be careful to avo id co ntent-based dark patterns listed in use case 2.a., such as Language discontinuity. No t m aking the setting pages (or parts o f them ) available in the language users cho se fo r the social m edia platfo rm m akes it harder fo r them to understand what they can change and therefore set their preferences.

50 See belo w, U se ca se s 4 and 5, i.e. parts 3.4. and 3.5. of the se Guid eline s.

Fickle Lacking Hierarchy (Annex checklist 4.5.2)

In this co ntext, ano ther issue o ccurs when so cial m edia platfo rm s o ffer data pro tectio n friendly cho ices to users, but do not info rm them abo ut it in a clear m anner. This can be the case when the so cial m edia platform suddenly differs from its usual design pattern.

Example 38: Thro ugho ut the so cial media platfo rm , nine o ut o f ten data pro tectio n setting o ptio ns are presented in the fo llo wing o rder:

- mo st restrictive o ptio n (i.e. sharing the least data with o thers)

- lim ited o ptio n, but no t as restrictive as the first o ne

- least restrictive o ptio n (i.e. sharing the mo st data with o thers).

Users o f this platform are used to their data pro tection settings being presented in this o rder. Ho wever, this o rder is not applied at the last setting where the cho ice o f visibility o f users birthdays is instead sho wn in the fo llowing o rder:

- Show my whole birthday: 15 January 1929 (= least restrictive o ptio n)

- Show only day and month: 15 January (= lim ited o ptio n, but no t the m ost restrictive o ne)

- Do not show others my birthday (= mo st restrictive optio n).

In the exam ple, the three cho ices in the last setting are presented in a different order than the previo us settings. Users who have previo usly changed their o ther settings are likely to be used to the usual o rder o f settings o ne to nine. At the last setting, they are so used to this o rder that they instinctively choo se the first o ptio n, assum ing that this m ust be the mo st restrictive o ne. Arranging the o ptio ns o f o ne data pro tectio n setting so differently from the o thers in the sam e so cial m edia platfo rm is Lacking Hierarchy as it plays with what users are used to and their expectatio ns. This can lead to co nfusio n o r leave users to think they to ok the cho ice they wanted when, in reality, this is no t the case.

ii. I nterfac e-based patterns

The seco nd issue o ne encounters in the co ntext o f data protectio n settings is that the settings m ight infringe o n the principle o f data protection by default. Article 25 (1) GDP R requires co ntro llers to take appro priate m easures designed to im plem ent data pro tectio n principles, such as data m inim isatio n (Article 5 (1) (c) GDP R). These pro visio ns are not respected when the settings o n sharing o f perso nal data are pre-set to o ne o f the mo re invasive o ptio ns rather than the least invasive o ne.

Skipping Deceptive Snugness (Annex checklist 4.2.1)

Example 39: Between the data visibility o ptio ns visible to me , to my closest friends to all my connections , and public , the m iddle o ptio ns to all my connections is pre-set. This m eans that all other users co nnected to them can see their co ntributio ns, as well as all info rm atio n entered fo r signing-up to the so cial media platfo rm, such as their email address o r birthdate.

So cial media pro viders m ight argue that the least invasive setting wo uld defeat the goal that users o f a particular so cial m edia platfo rm have, for exam ple being fo und by unkno wn peo ple to

find a new buddy, date o r jo b. While this m ight be true fo r som e particular settings, so cial media pro viders need to keep in m ind that the fact that a user uplo ads certain data o n the netwo rk does no t co nstitute co nsent to share this data with o thers.51 Where so cial media providers defer fro m data pro tectio n by default, they will need to be m indful to pro perly info rm users abo ut it. This m eans that users need to kno w what the default setting is, that there are less invasive o ptio ns available and where o n the platfo rm they need to go to m ake changes. In the given exam ple, it m eans that when the o ption to my closest friends is pre-set fo r co ntributio ns users actively po st o n the social m edia platfo rm , they sho uld be shown where to change this setting. Ho wever, presetting the visibility to all user connections (o r even the general public) co nstitutes Deceptive Snugness, especially when it is applied to data the so cial media provider required fro m users to create an acco unt, such as the email address o r their birthdate. As described in Use Case 1 para. 53, this practice infringes Article 25 (2) GDP R.

51 For example the ir birthdate, se e para. 54 above.

Stirring Hidden in plain sight (Annex checklist 4.3.2)

The Hidden in Plain Sight and Deceptive Snugness dark patterns can easily be com bined when it com es to the selectio n o f data pro tectio n related o ptio ns as illustrated in example 9 fo r the signup pro cess, and belo w when users want to change their data protectio n preferences while using the so cial m edia.

Example 40: In this exam ple, when users want to m anage the visibility o f their data, they have to go in the privacy preference tab. The info rm atio n fo r which they can set their preference is listed there. Ho wever, the way that inform atio n is displayed do es no t m ake it o bvio us how to change the settings. Indeed, users have to click o n the current visibility o ptio n in o rder to access a dro pdo wn menu from which they can select the o ption they prefer.

Even tho ugh changing o ne s preferences is available in this tab, it is Hidden in plain sight, as the dro pdo wn m enu is no t directly visible fo r users who have to guess that clicking o n the current o ptio n will o pen som ething. There is indeed no usual visual clue (underlined text, do wn arrow) abo ut the po ssibility o f interacting and o pening the dro pdo wn m enu. This specific practice is unfair to users and co uld participate in a general failure to m eet the principle o f fairness o f Article 5 (1) (a) GDP R. Additio nally, if the o ptio ns were pre-selected by default, the Deceptive Snugness dark pattern co uld be also o bserved, as described above in para. 128.

Fickle Decontextualising (Annex checklist 4.5.2)

Decontextualising happens when a data protectio n related info rm atio n o r co ntro l is located o n a page that is o ut o f context, so that users are unlikely to find it as it wo uld no t be intuitive to lo ok fo r it o n that specific page.

Example 41: The data pro tectio n settings are difficult to find in the user acco unt, as o n the first level, there is no m enu chapter with a nam e o r heading that wo uld lead in that directio n.

Users m ust loo k up o ther subm enus such as Security .

In this exam ple, users are no t guided to the data protectio n settings because no m eaningful and clear terms are used to indicate where these are on the so cial m edia platfo rm. Indeed, the term Security o nly covers a fractio n o f what can be expected o f data pro tectio n settings. It is therefo re no t intuitive fo r users to loo k up this m enu to find such settings. This lack o f transparency m akes access to info rm atio n harder than it sho uld and can be co nsidered as co ntravening Article 12 (1) GDPR, and po tentially Article 12 (2) GDP R if tho se settings relate to the exercise of a right.

Example 42: Changing the setting is hindered since in the so cial media platfo rm s deskto p versio n, the save butto n fo r registering their changes is not visible with all the optio ns, but o nly at the to p o f the submenu. Users are likely to overlo ok it and wro ngly assume their settings are saved autom atically, therefo re mo ving to ano ther page witho ut clicking o n the "save" butto n. This pro blem do es no t o ccur in the app and mo bile versio ns. Therefo re, it creates additio nal co nfusion fo r users m oving fro m the mo bile/ app to the desktop versio n, and can m ake them think they can o nly change their settings in the m o bile version o r the app.

Once users have fo und the data pro tectio n settings and set their cho ices, they m ay not be hindered from do ing so . Once users have m ade a change, the way to save it has to be o bvio us, whether this happens as so o n as users adjust a setting o r it needs a co nfirm atio n by clicking o n a specific elem ent o f the interface such as a save button. In additio n, the principle o f fairness under Article 5 (1) (a) GDP R requires social media providers to be co nsistent thro ughout their platfo rm , especially across different devices. That is no t the case when the interface uses a dark pattern as described in the exam ples abo ve.

d. Best prac tic es

Data protec tion direc tory: Fo r easy o rientatio n through the different sectio n o f the m enu, provide users with an easily accessible page fro m where all data pro tectio n related actio ns and info rm atio n are accessible. This page co uld be fo und in the social m edia provider m ain navigatio n menu, the user acco unt, thro ugh the privacy po licy, etc.

Shortc uts: see use case 1 fo r definitio n (p. 22) (e.g. when users are informed about an aspect of the processing, they are invited to set their related data preferences on the corresponding setting/dashboard page).

Coherent wordings: see use case 1 fo r definitio n (p. 22).

Prov iding definitions: see use case 1 fo r definitio n (p. 22).

Use of examples: see use case 1 fo r definitio n (p. 22).

Stic ky navigation: see use case 2a fo r definitio n (p. 28).