I forbindelse med vores overordnede opgave er vi blevet bedt om at gøre brugerne så anonyme som muligt. De havde på forhånd vurdere at intet data (eller så lidt som mulig) om brugerne ville være mest hensigtsmæssigt: dels fordi de gerne ville have en service der ikke krævede en masse registrering for at kunne komme i gang, og dels for at undgå cyber-bullying på baggrund af køn, seksualitet, hudfarve, navn, alder eller hvad man nu ellers kan finde på at bruge som basis for chikane.

For at opnå størst mulig anonymitet har vi delt vores brugere op i to grupper:

  1. Folk der stiller oversættelsesanmodninger
  2. Folk der besvarer oversættelsesanmodninger

Bemærk at gruppe 2 i virkeligheden er en udvidelse af gruppe 1. Det betyder at alt hvad der påvirker gruppe 1 automatisk også påvirker gruppe 2.

Og for at få et overblik over de typer af data vi gemmer, vil der nederst i dette dokument være en gennemgang med en beskrivelse af formål for data, samt en GDPR-risikoanalyse.

Gruppe 1

Første gruppe gemmer vi ikke noget om, kun et id som vores service genererer til brugeren. Det er meningen at brugeren skal sende dette id med når der laves forespørgsler op mod vores service. Reelt er det den klient som brugeren bruger der står for at håndtere dette id. Hvis brugere sender en anmodning fra en anden klient, vil servicen ikke kunne vide at dette er en bruger som allerede har brugt servicen, fordi denne klient har fået sit eget id. Med andre ord har brugeren nu data tilknyttet til to forskellige brugerId.

Så længe brugeren tilhører gruppe 1, gemmer servicen ikke bruger-id i en bruger tabel på databasen. Hvis en klient anmoder om et id, genereres der et og sendes tilbage. Alle anmodning “stemples” så med dette id, men i selve servicen kan man ikke slå op hvem brugeren er. Men man vil kunne finde alle anmodninger som kommer fra samme klient.

Gruppe 2

Ved den anden gruppe gemmer vi lidt information som brugeren selv angiver: et brugernavn/password og en liste over hvilke sprog brugeren kan hjælpe med. Rent teknisk er en bruger fra denne gruppe, det samme som ovenstående, men med udvidede rettigheder, nemlig muligheden for at lave besvarelser.

Grunden til at vi har valgt at denne gruppe i højere grad skal registreres er:

  • Et forsøg på at højne “ansvarsfølelsen” hos brugeren. Vi vil gerne have at brugerne giver gode besvarelser
  • Denne type bruger kan stemme på andres besvarelse hvis de finder dem gode. Dermed er der indbygget en form for brugerstyret vurderingssystem.

Datatyper

Request og Answer

Type: Request Påvirker: Gruppe 1
Type: Answer Påvirker: Gruppe 2
Formål: Requests og Answers er grundlaget for servicen. Begge dele sendes kun videre i anonym form (dvs. uden nogen form for personhenførbarhed).
Servicen kan dog identificere hvilket bruger-id requesten/answeret tilhører
Risiko: Risikoen er vurderet til mellem, da vi vurderer der ikke typisk at ville indgå i en oversættelsesanmodning, men, både requests og answers er underlagt GDPR da der er intet til hinder for at brugeren sender personlige oplysninger.
Persistering: Online i servicen

Bemærk at jeg har lavet en sammenskrivning af de to typer “Request” og “Answer”, da de i denne henseende er vurderet sammenlignelige.

Votes

Type: Votes Påvirker: Begge grupper
Formål: Gruppe 2 kan afgive stemmer på besvarelser.
Begge grupper får vist optalte stemmer pr svar.
Internt kan servicen identificere hvilken bruger der har stemt på hvad og forhindre at en bruger stemmer på sit eget svar, eller stemmer flere gange på det samme svar.
Risiko: Lav risiko, og ikke underlagt GDPR, da der med votes kun vises et aggregat af stemmer på et svar, helt afkoblet fra hvem der har afgivet disse stemmer
Persistering: Online i servicen

BrugerId

Type: BrugerId Påvirker: Begge grupper
Formål: Servicen uddeler dette id til en klient der forespørger at bruge servicen.
Klienterne bruger id'et til at stemple Requests, Answers og Votes når de sendes ind til servicen:
Requests stemples med BrugerID så de kan kobles til den bruger der stillede opgaven, og denne kan få vist relevante svar igen. (Begge grupper)
Answers stemples med BrugerID så afgivne votes kan tælle med i denne brugers ""gode karma"" score. (Kun gruppe 2)
Votes stemples med BrugerID så der holdes styr på at man kun kan stemme en gang på andres svar og ikke på sine egne. (Kun gruppe 2)
Risiko: Lav risiko.
BrugerId'et er en tilfældigt genereret GUID.
Gruppe 1 brugere er ""pseudonumiserede"" - dvs. ikke underlagt GDPR
Gruppe 2 brugere har et brugernavn og er umiddelbart underlagt GDPR
Persistering: Genereres af servicen online, men gemmes i klienten.
Ved brugergruppe 2 gemmes dette også online.

Brugernavn

Type: Brugernavn Påvirker: Gruppe 2
Formål: Brugernavne er, for mennesker, nemmere at huske end GUIDs.
Se Formålsbeskrivelse for Kodeord
Risiko: Mellem risiko - og underlagt GDPR
- Brugere kan vælge navne der kan identificere dem og bruge personlige oplysninger.
Der bør være en opfordring til at brugere vælger et helt tilfældigt brugernavn.
Persistering: Online i servicen

Kodeord

Type: Kodeord Påvirker: Gruppe 2
Formål: Kombinationen Brugernavn/kodeord giver brugeren mulighed for at tilgå sine requests på en anden enhed, end der hvorfra requests blev sendt oprindeligt.
Hvis han bare åbnede en ny klient, vil denne blive tilknyttet et nyt tilfældigt brugerID og brugeren vil derfor ikke få vist sine tidligere requests.
Risiko: Lav risiko
Kodeordet er krypteret inden det gemmes i servicen. Selv med direkte adgang til databasen vil man ikke kunne bruge oplysningen til at logge på servicen.
(Men med direkte adgang er dette måske også ligegyldigt)
Persistering: Online i servicen (krypteret og hashed)

Registrerede sprog

Type: Registrerede sprog Påvirker: Gruppe 2
Formål: Servicen skal bruge en liste af de sprog som en bruger kan oversætte imellem for at kunne sende ham relevante anmodninger.
Risiko: Lav Risiko.
Denne information bruges kun af servicen til at videresende anmodninger til de brugere der har angivet de korrekte sprog.
Denne information vises ikke til andre end brugeren der har angivet dem.
Persistering: Online i servicen

Foretrukne svar

Type: Foretrukne svar Påvirker: Gruppe 1
Formål: Brugeren som har send en request kan vælge den eller de svar han anser som "de bedste". Brugerne som har afsendt disse svar modtager "god karma" til deres rating
Risiko: Lav risiko.
Der findes kun en kobling imellem request og answer, men de brugere som står bag får stadig ikke noget information udleveret om hinanden.
Persistering: Online i servicen

Refleksion

Data er en interessant størrelse så snart den er brugergenereret. Man skal prøve at forholde sig til at man grundlæggende ikke har kontrol over typen af data en bruger kan finde på at bruge i et system. Det kan endda være at brugeren ikke selv er opmærksom på eller klar over at han sender personlige oplysninger på en uhensigtsmæssig måde.

Med en redegørelse som ovenfor, er der forsøgt at tage højde for både hvad formålet med dataindsamlingen er, men også hvornår vi som dataindsamlere bevæger os ind i et område hvor GDPR bliver relevant. Analysen klarlægger nogle scenarier, hvor det kan være hensigtsmæssigt at gøre brugerne opmærksomme på hvilken type data de bør (og især ikke bør) sende.

Når man laver sådan en oversigt skaber det også indsigt for udviklere og databehandlere. Man kan bedre snakke om der er en rimelighed i hensigten med indsamling af dataet og det giver et udgangspunkt til at diskurtere alternative data med afsæt i dette øjebliksbillede af de nuværende.

Denne tekst er poduceret i samarbejde med projektgruppen.