Data Privacy: Research

Recherche

1. Anforderungen an dem App recherchieren

   Wir haben uns erstmal mit den drei möglichen Ansätzen zu Entwurf und Verwirklichung einer solchen App beschäftigt. Damals war das offizielle App Repository fast leer und das Einzige, was zur Verfügung gestellt war, war die Dokumentation. Wir wussten schon, dass es drei Konzepte zur Implementierung gab, nämlich :

   • PEPP PT
   • DP-3T
   • DCTS

   Wir wussten schon damals, dass der gewählte Ansatz zur Verwirklichung DP-3T war, trotzdem hat die gegebene Dokumentation nicht so detailliert das Erreichen einiger Datenschutz- und Sicherheitaspekte beschrieben. Wir haben die Dokumentation der drei Ansätzen gelesen und dann sollten wir die verschiedenen Aspekten der Ansätze vergleichen (die jeweilige Dokumentation ist als Hyperlinks in der oben gegebenen Liste verlinkt). Danach haben wir mehrere Tabellen zu dem Vergleich der Ansätze vorbereitet. Dazu haben wir auch die Konzepte bezüglich ihrem Datenschutz und Sicherheit verglichen.

   Hier kann man die ganze Recherche finden, die wir mit Hilfe einiger unserer Kommilitonen von den anderen Teams gemacht haben.

   Unsere Tabellen zum Vergleich der Datenschutzaspekt und die Transperenz:

   Privatsphäre und Transparenz

   Allgemein

   Kriterium	PEPP-PT	DP3T	DCTS	Corona Warn App
   Welche Daten sieht der Server-Betreiber	User-IDs und Push-ID + Status (Infiziert/Kontakt) Der Status Infiziert/ Kontakt mit Infiziertem ist nur bekannt, falls der Infizierte ihn hochgeladen hat.	Seeds infizierter Nutzer Nach Bestätigung durch den Arzt läd der Infizierte seine Seeds hoch.	BLE-IDs infizierter Nutzer + Zweitkontakte Nach Bestätigung durch Arzt kann der Infizierte seine BLE-IDs hochladen. Wenn ein Kontakt mit einem Infizierten bestand, kann der Nutzer entscheiden auch seine BLE-IDs als "potenziell infiziert" hochzuladen.	Seeds infizierter Nutzer Nach Bestätigung durch den Arzt läd der Infizierte seine Seeds hoch.
   Welche Daten sieht die App	BLE-IDs (eigene + Kontakte)	Seed, BLE-IDs (eigene + Kontakte) Aus dem Seed, der jeden Tag gewechselt wird, werden BLE-IDs erzeugt werden.	Seed, BLE-IDs (eigene + Kontakte) Der Temporäre Seed wird täglich gewechselt, daraus werden die BLE-IDs erstellt, die ausgetauscht werden.	Seeds infizierter Nutzer Die App erhält die Seeds infizierter Nutzer vom Server. Die BLE-IDs sind in Framework von Apple/Google versteckt und die App/der Nutzer hat keinen Zugriff.
   Wie lange werden die Daten gespeichert Die Datenspeicherung auf dem Server kann der Nutzer nicht prüfen, aber lokale Daten könnten z.b. per modifizierter App regelmäßig gelöscht werden.	keine Angabe	keine Angabe	2-3 Wochen Ausgehend von der möglichen Inkubationszeit. Kann angepasst werden.	14 Tage
   Wer entscheidet über Datenübertragung bei Infektion? siehe auch Bestätigung der Infizierung	Infizierter nach Authorisierung	Infizierter nach Authorisierung	Infizierter nach Authorisierung	Infizierter nach Authorisierung
   Wer entscheidet über Datenübertragung bei Kontakt mit Infiziertem? bei DCTS für Zweitkontaktverfolgung	Infizierter nach Authorisierung Der Infizierte lädt seine Kontakte hoch, dies ist nicht optional wenn man sich für hochladen entscheidet.	Daten werden nicht erhoben	Kontaktperson entscheidet Wenn man Kontakt mit einer infizierten Person hatte, so wird man darüber informiert und hat die Option seine eigenen IDs hochzuladen (siehe Zweitkontaktverfolgung)	Daten werden nicht erhoben
   Haltung gegenüber Open Source	negativ Wird vorgeworfen, nicht nach Transparenz zu streben.	Abspaltung von PEPP-PT	Unterstützt komplett Open-Source	positiv Quelltext von Client uns Server werden successive veröffentlicht

   Identität

   Kriterium	PEPP-PT	DP3T	DCTS	Corona Warn App
   Pseudo- / Anonymisierung	Pseudonymisierung die User-ID ist permanent und auf Server gespeichert, damit + Push-Notification-ID ist eine Identifikation möglich	Anonymisierung der Seed ist der einzige konstante und zur Identifikation nutzbare Datenwert, dieser ändert sich jedoch täglich und wird dem Server nur bei Infizierung bekanntgegeben	Anonymisierung der Seed ist der einzige konstante und zur Identifikation nutzbare Datenwert, dieser ändert sich jedoch täglich und wird dem Server nur bei Infizierung bekanntgegeben	Anonymisierung Authentifizierung zum Upload der Keys geschieht nur durch eine TAN, die auf Serverseite gelöscht wird
   Wer kann aus der BLE-ID eine User-ID zurückrechnen?	Server Die BLE-ID ist eine symmetrisch verschlüsselte User-ID	es gibt keine User-ID und die Seeds sind nicht zurückrechenbar	es gibt keine User-ID und die Seeds sind nicht zurückrechenbar	es gibt keine User-ID und die Seeds sind nicht zurückrechenbar
   Identifizierung der App-User durch Server (Zuweisung von ID's) Die Zuweisung und Anzahl der temporären und nichttemporären ID's und die Methode, die auf dem Server angewendet wird, um den Benutzern ihre Appdaten zuweisen zu können, ohne die als Person indefizieren zu können.	1 User-ID/mehrere BLE-IDs/ein Push-ID Der Nutzer bekommt eine einzigartige User-ID (Permanent pseudonym of the app), womit er auf dem Backend indentifizert werden kann, die Push-ID wird nur auf dem Backend gespeichert. Dazu bekommt der Nutzer auch mehrere BLE-ID, die er bei dem BLE-Broadcasting schickt, zusammen mit einem Timestamp, sodass er danach mithilfe dieser BLE-ID und dem Timestamp auf dem Server indentifiziert werden kann und von dem Push-Notification Service mit Hilfe seiner Push-ID benachrichtigt werden kann. Der Nutzer bekommt niemals sein User-ID, aber die BLE-IDs werden ihm zugeteilt und zur Nutzung für einem bestimmten Zeitraum gestellt, danach werden neue BLE-IDs für den selben Nutzer vom Server erstellt (bei vorhandener Internetverbindung) und das widerholt sich, sodass es nicht möglich ist, dass der Nutzer von anderen Nutzer mithilfe des BLE-IDs indentifizert wird.	Nein Die BLE-IDs werden nicht vom Server generiert bzw. wenn der Server die erhält, ist schon eine neuer Seed auf der Userapp generiert worden	Nein Die BLE-IDs werden nicht vom Server generiert bzw. wenn der Server die erhält, ist schon eine neuer Seed auf der Userapp generiert worden. Beim Abfragen der infizierten ID's hat eine App jedes mal eine andere ID, ist also vom Server aus nicht zu identifizieren	Nein Authentifizierung zum Upload der Keys geschieht nur durch eine TAN, die auf Serverseite gelöscht wird
   Kontakt-Graph-Generierung möglich	ja Alle Nutzer haben permanente User-IDs, bei hochladen der Infizerung kennt der Server die permanten User-IDs der Infizierten + aller seiner Kontakte	Nein weil nur eigene IDs hochgeladen werden.	Nein weil nur eigene IDs hochgeladen werden. Bei Zweit-Kontakt-Verfolgung wird durch Zero-Knowledge-Proof verhindert, dass Rückschlüsse auf den Begeneten Infizierten gemacht werden können.	Nein

   Wir haben auch dazu noch die offene Frage gestellt, was man noch zu der Privatsphäre und Transperenz Tabelle als Anforderung und Vergleichspunkten noch hinzufügen könnte. Dafür haben wir ein Email an einige Professoren (Expertenpanel) geschickt mit der Bitte, dass die uns da unterstützen. Den beschriebenen Umgang damit kann man in diesen Issues finden: #12, #70, #73.

2. Recherche bei vorhandenem Code Danach kam es zu dem Zeitpunkt, an dem ein Teil vom Code veröffentlich wurde.

   Nach der Veröffentlichung eines Teils des Codes, gab es von vielen Experten einige Fragen an dem Datenschutzaspekt. Dann haben wir einige Artikel bezüglich die verschiedenen Ansichten auf die möglichen Lücken im Bereich Datensicherheit gelesen. Hier sind einige aufgelistet. Wir haben auch versucht die Kritik zu verstehen und zu geregeln oder widersprechen:

   • #223
   • #273

   Einige Nutzer haben auch nach mehr Transparenz bei der Risikoberechnung gebeten:

   • #338

   Ein anderes sehr wichtiges Problem mit dem Datenschutz und Transparenz Aspekten war, dass obwohl die App als "open source" bezeichnet wurde, war es bis zu dem Zeitpunkt des Veröffentlichens nicht möglich, diese zu testen, da es eine GMS Exposure API Whitelisting gab.

   • #214

   Dazu könnte man mehr Information bei dem Team "Exposure API" finden.

3. Recherche nach der Veröffentlichung des Apps.

   Nach der Veröffentlichung wurde unser "Datenschutz Team" gegründet. Wir haben uns als erstens viel mit dem Datenschutzerklärung des offiziellen App beschäftigt.

   Erstmal haben wir:

   • Dominique Machuletz* and Rainer Böhme, Multiple Purposes, Multiple Problems: A User Study of Consent Dialogs after GDPR
   • Ghazinour, K. and Albalawi, T., 2016, August. A usability study on the privacy policy visualization model. In 2016 IEEE 14th Intl Conf on Dependable, Autonomic and Secure Computing, 14th Intl Conf on Pervasive Intelligence and Computing, 2nd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress (DASC/PiCom/DataCom/CyberSciTech) (pp. 578-585). IEEE.
   • Clarke, N., Furnell, S., Angulo, J., Fischer‐Hübner, S., Wästlund, E. and Pulls, T., 2012. Towards usable privacy policy display and management. Information Management & Computer Security.

gelesen und darauf die Erkentnisse mit dem offiziellen Datenschutzerklärung (DE Version,EN Version) des Corona Warn Apps verglichen. (#149)

""

Current Implementation

Many users are still struggling with privacy concerns when using the app. However, current visualization and structure of the privacy policy feel like "infinity scrolling" and the overall plain visualization does not attract user to read the privacy policy in its full length. Status now, there are no unfoldable areas, highlighted areas, supporting links for explanation, icons or even images/models are used.

Suggested Enhancement

Make the the dry text of privacy policy more appealing in order to gain more transparency, trust and understanding towards the user. Research showed that the usage of a variety of "telling" icons, models and diagrams can help users to understand PP better and let users recognize which service providers are requesting which kind of data. Also adding the author`s credentials or links to the legal texts of the General Data Protection Regulation (GDPR) can have a positive impact.

Expected Benefits

Create a better understanding for the user and thus increase acceptance for the app. Furthermore, increase willingness (of people who are still sceptical) to install the app by by advertising and pre-reading the privacy policy directly on the website.

""

Hier könnte man unsere Zusammenarbeit nachvollziehen #149. Daraus ist diese Issue in der offizielle Repository entstanden als Verbesserungswunsch #16.

Wir haben uns entschieden, unsere Vorschläge mit einem Prototyp zu erstellen. #185

Wir hatten auch die Anmerkung, dass die Datenschutzerklärung zu lang gemacht wurde, was eigentlich dazu führt, dass die Größe des Texts den Nutzer erschreckt. Wir haben dann uns entschieden eine Alternative vorzubereiten und haben uns geeinigt, dass das Aufklappen von verschiedenen Aspekten der Datenschutzerklärung (sodass der Nutzer nur die Aspekten sehen könnte, die ihn interessieren). Unsere Arbeit dazu kann hier nachgefolgt werden #168.

Noch ein Verständnisaspekt der Datenschutzerklärung ist die verwendete formale Sprache und die Gelegenheit das Text in verschiedenen Sprachen zu implementieren, da es auch von den verschiedenen in Deutschland lebenden Nationalitäten verstanden wurde. Diese wurde in dem vorherigen "Team Technik" besprochen und es gibt auch für die Sprachenunterstützung eine offizielle Issue in dem offiziellen Repository, dass in der Zukunft für die Erweiterung mit mehreren Sprachen verantwortlich ist. #22. Momentan gibt es EN, DE, TR Version zu dem App.