Webseite aktualisieren

[Erdnaf]

Bounty

Scope

• Einbinden des Prototyps + Beschreibung @julizet
• Textanpassung @Erdanf
• How to Implement Anleitung @linuxhelf
• Recherche Findings (wie bereitet man Data Privacy Information ordentliche auf) UND Aktivitäten in dem offiziellen Repo @molpremotone & @kraleva (bitte selbstständig einteilen)

Deliverables

• siehe oben --> eine zusammenhängende Übersicht, über unsere Teamleistung

Gain for the project

• Anpassung der Website: https://fub-hcc.github.io/20-SWP-CodingOpenness/corona-warn-app

Roles

bounty worker: @julizet @Erdanf @linuxhelf @molpremotone @kraleva review erfolgt am Dienstag im Meeting

Issue creation checklist

• [x] I have attached one of the team labels Fragebogen, Technik, Projektwebseite, Vergleich, Organisation to this bounty
• [x] I have attached one of the priority labels Blocker, High, Medium, Low to this bounty
• [x] I have attached one of the size- labels to this bounty
• [x] I have added this bounty to bounty board here https://github.com/FUB-HCC/20-SWP-CodingOpenness/projects/1

[julizet]

Bitte die Fortschritte in die Kommentare hier posten. Habe die Beschreibung angepasst, damit die Aufgaben klar verteilt sind

[Erdnaf]

Ich hab einen Entwurf für die Webseite gemacht und dabei die Rechtschreibfehler berichtigt und den Prototypen eingebunden (siehe PR #219 ) Die Änderungen können auf dem Branch website/feat/cwa-privacy angeschaut werden

[Erdnaf]

Ich denke direkt auf der Webseite zu arbeiten ist bei den ganzen Themen wahrscheinlich nicht so sinvoll, da wir doch ziemlich viel Inhalt haben. Was haltet ihr von einer Wikipage, wo wir das niederschreiben und die wir dann verlinken? Die könnten wir auch in der Abschlusspräsentation (#217) verwenden, damit wir uns nicht doppelte Arbeit machen

[kraleva]

Ich werde die Recherche-Findings beschreiben ,wobei ich auch Informationen von unserem Vergleich der Ansatze verbinden werde. @molpremotone dann willst du die Beschreibung der Aktivitaten im offiziellen Repo ubernehmen? Ich dachte, dass es auch eine gute Idee waere, dass wir die Data Privacy Tabelle aus dem Vergleich der Anstaetze in der Recherchebeschreibung hinzufuegen. Was denkt ihr daran ? Wir waren quazi fast dieselben Menschen in der Gruppe "Vergleich" so ich glaube es waere kein Problem aus dem Grund, dass wir eigentlich die Tabelle vorbereitet haben ?

[kraleva]

Mein Vorschlag für die Recherche als Markdown. Wenn es Verbesserungsvorschläge gibt, bitte hier schreiben. Nach Abstimmung, kann ich dieses sollte dieses Markdown auch in der Webseite fließen.

Data-Privacy Research

Recherche

1. Anforderungen an dem App recherchieren

   Wir haben uns erstmal mit den drei möglichen Ansätzen zur Entwurf und Verwirklichung eines solchen Apps beschäftigt. Damals, war das offizielle App Repository fast leer, 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 detailiert das Erreichen einiger Datenschutz und Sicherheit Aspekten 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 obengegebene Liste verlinkt). Demnächst 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, die wir mithilfe einiger unserer Komillitonen 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 einigen Professoren (Expertenpanel) geschickt mit der Bitte, dass die uns da beibringen. Den beschriebenen Umgang damit könnte man in diesem Issue finden.

2. Recherche bei vorhandenem Code Demnächst 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 auf mehr Transperenz bei der Risikoberechnung geboten:

   • #338

   Ein anderes sehr wichtiges Problem mit dem Datenschutz und Transperenz Aspekten war, dass obwohl, dass das App als "open source" bezeichnet wurde, war es bis zu dem Zeitpunkt des Veröffentlichens nicht möglich, dies getestet zu werden, 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.

   Dann war unseres "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.

Damit haben wir die Hauptaspekte unserer Recherche erledigt und besprochen.

[linuxhelf]

Ich finde Wiki-Page(s) einen guten Vorschlag und nur die Zusammenfassung mit Links auf die Webseite. Ich habe mal ein paar Seiten erstellt und auch rechts in der Wikistruktur verlinkt:

• Data Privacy
  • Research
  • Prototype
  • Implementation

den Implementationsvorschlag + die Researchzusammenfassung von @kraleva habe ich schonmal reinkopiert

[linuxhelf]

ich habe die Übersichts- und Prototypseite mal mit ein paar Sätzen befüllt, damit sie nicht so leer sind.

[julizet]

Ihr habt ja schon einen Menge getan!

Ich lese nochmal Lektorat für die bereits veröffentlichten Wiki-Pages und würde schauen, dass die Formulierungen und die Formattierung passt. Zudem: da Felix sich noch nicht gemeldet hat und Claas/Linux den Prototypen schon auf der Website eingebunden haben und wir nur noch auf den confirm des PR warten, würde ich mich über eine kleine Doku der Aktivitäten im offiziellem Repo kümmern.

So ist auch direkt klar, wer was zur Präsentation sagt

[Erdnaf]

Plan für die Präsentation:

• Vergleich mit Einleitung (Webseite mit Vergleich der Ansätze zeigen) / @molpremotone
• Recherche (Wiki Seite zeigen) / @kraleva
• Prototyp / @julizet
• Implementierung / @linuxhelf
• Ausblick / @Erdanf

Screensharing: @julizet Ersatz: @linuxhelf