Giter Site home page Giter Site logo

corona-warn-app / cwa-documentation Goto Github PK

View Code? Open in Web Editor NEW
3.3K 199.0 345.0 19.81 MB

Project overview, general documentation, and white papers. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:

Home Page: https://coronawarn.app/en/faq/#ramp_down

License: Apache License 2.0

TeX 100.00%

cwa-documentation's Introduction


About this ProjectWho We AreCreditsData PrivacyCode of ConductWorking LanguageOur DocumentationLicensingHow to ContributeWebsite


Corona-Warn-App: Documentation

NOTE: This README is also available in German. Thank you for understanding that the German version might not always be up-to-date with the English one.

HINWEIS: Diese README ist ebenfalls auf Deutsch verfügbar. Bitte haben Sie Verständnis, dass die deutsche Version nicht immer auf dem gleichen Stand wie die englische Version ist.

About this Project

We are developing the official COVID-19 exposure notification app for Germany, called "Corona-Warn-App". This project has the goal to develop an app based on technology with a decentralized approach - heavily inspired by the DP-3T (Decentralized Privacy-Preserving Proximity Tracing, see this comic for concept explanation) and TCN protocols and based on the Privacy-Preserving Contact Tracing specifications by Apple and Google. Like DP-3T and the TCN Protocol, the apps and backend infrastructure will be entirely open source - licensed under the Apache 2.0 license! The apps (for iOS and Android) will collect pseudonymous data from nearby mobile phones using Bluetooth technology. The data will be stored locally on each device preventing access and control over data by authorities or anyone else. We will meet the applicable data protection standards and guarantee a high level of IT security. By doing so, we are addressing people's privacy concerns and thereby aiming to increase the adoption of the app.

Who We Are

The German government has commissioned SAP and Deutsche Telekom to develop the Corona-Warn-App for Germany as open source software. Deutsche Telekom is providing the network and mobile technology and will operate and run the backend for the app in a safe, scalable and stable manner. SAP is responsible for the app development, its framework and the underlying platform. Therefore, development teams of SAP and Deutsche Telekom are contributing to this project. At the same time our commitment to open source means that we are enabling -in fact encouraging- all interested parties to contribute and become part of its developer community.

Credits

We'd like to thank all the partners who have been involved in this enormous project from the beginning. The project would not be where it is today without all the exploration and great work that had already been done around the PEPP-PT approach by partners on a European and national level. We will build on top of some of these components and appreciate how everyone is dedicated to making this new approach successful. Moreover, we would like to thank GitHub for their great support.

Data Privacy

In this project we are strictly observing the principles of the General Data Protection Regulation (GDPR) to protect the users’ privacy. We are processing necessary data only - exclusively for the purpose to let users know if they have come into close contact with other infected users, without revealing each other's identity. The compliance with these regulations is safeguarded by several procedures, e.g. by implementing technical and organizational measures adhering diligently to the high standards of the GDPR. Of course, the app will provide users with a comprehensive privacy statement to be as transparent and clear as possible. As we are developing the app as an open source project, the community can review it. We appreciate your feedback!

Code of Conduct

This project has adopted the Contributor Covenant in version 2.0 as our code of conduct. Please see the details in our CODE_OF_CONDUCT.md. All contributors must abide by the code of conduct.

Working Language

We are building this application for Germany. We want to be as open and transparent as possible, also to interested parties in the global developer community who do not speak German. Consequently, all content will be made available primarily in English. We also ask all interested people to use English as language to create issues, in their code (comments, documentation etc.) and when you send requests to us. The application itself, documentation and all end-user facing content has - of course - been made available in German. Apart from the initial release in English and German, other languages have been added over time including Bulgarian, Polish, Romanian and Turkish. See the FAQ available languages entry for more details. We also try to make developer documentation available in German, but please understand that focusing on the Lingua Franca of the global developer community makes the development of this application as efficient as possible.

Our Documentation

This repository contains the developer documentation and related content.

Project Scope

The project scope has been agreed on jointly by Deutsche Telekom AG and SAP SE as contractors and the German Federal Government and the Robert-Koch-Institut as clients. The project scope might change over time as new requirements need to be included or existing ones change. We appreciate feedback to all elements of this project scope document. However, additional features or any other content changes beyond fixes to grammatical issues or typos need to be aligned on by these partners before they can be included in the document. Thank you for your understanding!

Technical Documentation

The technical documents are intended for a technical audience and represent the most recent state of the architecture. The solution architecture and concepts might change over time as external dependencies (e.g. the framework provided by Apple/Google) are still changing and new requirements need to be included or existing ones change. We appreciate feedback to all elements of these technical documents.

To be published:

  • System Operation

Glossary

For an easier understanding of the used acronyms and special terms in our documents please see our glossary.

Repositories

Repository Description
cwa-app-android Native Android app using the Apple/Google exposure notification API.
cwa-app-ccl Common Covid Logic (CCL) for Android and iOS.
cwa-app-ios Native iOS app using the Apple/Google exposure notification API.
cwa-dcc-server Backend implementation of the process to issue EU Digital Covid Certificate.
cwa-documentation Project overview, general documentation and white papers.
cwa-event-landingpage Landing page for CWA which opens if the user does not have the app installed.
cwa-event-qr-code Utility to generate QR codes for Event Registration.
cwa-hotline Contains all issues reg. the hotlines of the CWA.
cwa-icao-transliteration A simple transliteration of non-latin letters into latin for the CWA.
cwa-kotlin-jfn JsonFunctions Engine - DCC Logic.
cwa-log-upload Counterpart of the log upload in the app.
cwa-parent Repository containing Maven files for parent project and dependency building blocks.
cwa-map-backend Backend of map.schnelltestportal.de.
cwa-map-operators-frontend Frontend for test center operators to manage their test centers in a simple way.
cwa-map-public-frontend Public frontend of map.schnelltestportal.de.
cwa-ppa-server Backend implementation for the privacy-preserving analytics server.
cwa-quick-test-backend Backend implementation of the rapid antigen test portal and API for participating partners.
cwa-quick-test-frontend Frontend implementation of the rapid antigen test portal for participating partners.
cwa-quicktest-onboarding Documentation about onboarding procedure for rapid antigen test partners.
cwa-registrierung Registration portal for the rapid antigen test portal
cwa-server Backend implementation for the Apple/Google exposure notification API.
cwa-testresult-server Receives PCR test results from connected laboratories.
cwa-verification-iam The identity and access management to interact with the verification server.
cwa-verification-portal The portal to interact with the verification server.
cwa-verification-server Backend implementation of the verification process.
cwa-website The official website for the Corona-Warn-App.
cwa-wishlist Community feature requests.
dcc-rule-translation Translations of Booster Notification Rules.

Licensing

Copyright (c) 2020-2023 Deutsche Telekom AG and SAP SE or an SAP affiliate company.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the LICENSE for the specific language governing permissions and limitations under the License.

The "Corona-Warn-App" logo is a registered trademark of The Press and Information Office of the Federal Government. For more information please see bundesregierung.de.

How to Contribute

Please see our CONTRIBUTING.md for details on how to contribute, our team setup, the project structure and additional details which you need to know to work with us.

cwa-documentation's People

Contributors

benekuehn avatar benzlerj avatar christianneu avatar daniel-eder avatar dependabot[bot] avatar dsarkar avatar ein-tim avatar emmetsap avatar eric-bratter avatar eykkny avatar heinezen avatar henningfemmer avatar jensjensenjens avatar kreincke avatar kripton avatar larswmh avatar mikemcc399 avatar mlenkeit avatar mtb77 avatar raethlein avatar rugk avatar sabineloss avatar sebastianwolf-sap avatar suplanus avatar svengabr avatar thomasaugsten avatar tiagofilipesilva avatar tklingbeil avatar tkowark avatar tmechen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cwa-documentation's Issues

Travelling in other countries

What is missing

An explanation of what happens when someone goes to another country. Will the application interact only with other german mobile phones?
Should an international traveler install one application per country?

Why should it be included

Because there are people who travel a lot in different countries for personal / professional reasons

Where should it be included


Internal Tracking ID: EXPOSUREAPP-2888

Clarification of open-source status of the project

Where to find the issue

README.md

Describe the issue

Strong emphasis on "open-source" and sentences like this:

Like DP-3T and the TCN Protocol, the apps and backend infrastructure will be entirely open source - licensed under the Apache 2.0 license!

led me initially to believe that entire app, including implementation of core contact tracing mechanisms will be open-source (like current implementation of DP-3T). To my best current understanding (please correct me if I'm wrong) core part of Android implementation will be closed-source (deployed through Google Play services) and accessed by open-source part through the API. The split seems to go like this (based on https://static.googleusercontent.com/media/www.google.com/en//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.1.pdf):

Closed-source:

  • identity key generation
  • identity key storage
  • broadcasting and scanning for identity keys using Bluetooth Low Energy
  • calculating exposure risk

Open-source:

  • fetching identity keys uploaded by covid-positive participants from the server and feeding them to closed-source part using API
  • getting identity keys from closed-source part using API and uploading them to the server (after permission from covid-positive person)
  • fetching exposure configuration provided by RKI and configuring closed-source exposure risk calculator using API
  • graphical user interface

Suggested change

Not sure what would be the best way to clarify it. My personal impression after reading README.md was that entire app, including implementation of proximity tracing core mechanisms will be fully open-source. After getting more into details the impression is that the app will be more like a front-end to closed-source proximity tracing engine running inside Google Play services.

Perhaps one approach to clarify it could be using "open-source" term only when referencing open-source components of the app (e.g. communication with a server which provides covid-positive identity keys, or fetching exposure configuration), but avoid it when referencing app as a whole - this would lead to easier understanding of the concept.

Can I as a user see statistics, about my bluetooth contacts?

What is missing

I did not see a user story/epic that shows me as a user, what the app collected during the days. I could envision a statistical view, how many devices have been close to me within a certain range for a certain amount of time.

Why should it be included

This gives transparency to the user, what the app is doing and collecting.

Where should it be included

In the user stories during the 'Nutzung im Regelprozess'

Development Process not consistent with BSI TR-03161 and OWASP Application Security Verification Standards

German BSI developed an technical advisory for digital health applications BSI TR-03161 "Sicherheitsanforderungen an digitale Gesundheitsanwendungen" (Direct Link: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161.pdf?__blob=publicationFile&v=2)

The BSI TR is intended to serve as a guide to assist healthcare mobile application developers in creating secure mobile applications following Confidentiality, Integrity and Availability "Vertraulichkeit, Integrität und Verfügbarkeit" and makes strong reference to common known OWASP Application Security Verification Standards.

The developing process of the German Corona App is initially not following these targets in using an unsecure 3rd party platform and violating basic assumptions made in OWASP Application Security Verification Standard, Section 1.1.1 from which I quote:

Verify the use of a secure software development lifecycle that addresses security in all stages of development.

To give you an example: Recent Commits of this Corona App are made by the user named "rathlein" but with different GPG signatures. How can a commit validated when even GitHub marks his GPG signatures as "not verified"?

Screenshot

Not to mention that I need to trust Microsof/ Github at all, what I don't. The fact that even Microsofts' own GitHub Account was hacked recently (see https://www.heise.de/security/meldung/Angreifer-verschafft-sich-Zugang-zu-Microsoft-GitHub-erbeutet-nichts-Wertvolles-4717415.html) makes the choice of GitHub as Secure and trustworthy Development platform at least questionable.

Missing user story: show warning if bluetooth was turned off

Where to find the issue

user story is missing

Describe the issue

In case of disabling bluetooth, a user didn't get a warning / notification that bluetooth is turned off and therefore the app is dysfunctional.

Suggested change

Show a banner on the main screen if bluetooth is turned off.

PrivateTracer

I am one of the contributors to PrivateTracer, a NL-based non-profit foundation with the goal to find out if a contact tracing app can be an effective tool in battling the COVID-19 virus and provide healthcare organisations with support in their contact tracing activities, that will allow our societies to be opened up responsibly. We have developed a fully open source end-end solution based on the DP-3T approach, hosted on Gitlab.

We would be happy to share our code, learnings and experiences with your team.

Is data traffic excluded from a user's data plan?

I am just digging in and would love to hear if there are discussions with mobile operators to exclude the data consumed for retrieving the list of infected people/ids from their data plans.

What is the expected daily data volume? What are ways to compress the data pulled by each device. I guess we cannot use a differential pull as no "known" ids shall be uploaded for privacy reasons.

I really think this is an important topic. Many would immediately uninstall the app if it eats their data allowance.

Missing code

Hey devs,
I cannot see a single line of code in any repository. Did I missed something, are you developing in internal repositories (shouldn't it be Open Source and therefore developed in public repos?), or is there not a single line written yet?

Best wishes

Premature closure of issues without having understood their relevance.

I've described an issue #23 how this app is discriminating by mixing functions.

The fast notification of test results over non-App users is such an act of discrimination. Such incentives making the voluntary use to a farce. Unfortunately this issue was closed prematurely without understanding the relevance.

2nd Corona-App renders some User Stories obsolete

Today a golem.de article reports that Germany is working on another Corona App aiming to support local health authorities ("Gesundheitsämter") and Users with information.

https://www.golem.de/news/coronapandemie-quarantaene-app-soll-gesundheitsaemter-entlasten-2005-148475.html

This renders many of the "User Stories" in current documentation obsolete, esp. those ones where additional incentives like test notifications, information and dynamic content could be misused for nudging.

The User Stories in question are:

  • E02.06
  • parts of E04.01
  • E04.02
  • E05.02
  • E06.02
  • E10.01

Will this be considered in current documentation, the soon to published code and further development?

Please open source pretty early to gain trust

Open source way before publishing would help to build up trust which ist the most important thing for the app. At least that is what I think. Do others have different experiances? Does an uncomplete app destry trust? In which steps should the code published?

How do you ensure security for the use of Bluetooth low-energy technology in older Android versions and on old chips?

How do you ensure security for the use of Bluetooth low-energy technology in older Android versions and on old chips that are no longer supported by the manufacturer?

Keyword: SweynTooth vulnerabilities. Recently discovered. Is this technology suitable to create such an app? Doesn't that open the door to hackers ? Older chips even have more and other vulnerabilities.

I can already see 22 forks here and there will surely be many more. How do you want to prevent everyone from writing their own compatible Corona app, that does send what ever they want, e.g. "I have Corona" just for fun?

Leseprobleme bei SAP und Telekom

Sehr geehrte Damen und Herren,

aufgrund des Satzes

Aus Gründen der einfachen Lesbarkeit wird auf die geschlechtsspezifische Differenzierung verzichtet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für alle Geschlechter.

kommt ich zu der Schlussfolgerung, dass es Lese-Probleme bei Mitarbeiter:innen von SAP und Telekom gibt. Haben Sie sich diesbezüglich schon medizinischen Rat eingeholt?

Wann werden Sie die Texte zeitgemäß auch an nicht-männliche Personen richten?

Mit freundlichen Grüßen

Johannes Filter

Will ein App Nutzer diese Dinge wirklich?

In verschiedenen User Stories werden Bedürfnisse eines App Users unterstellt. Zum Beispiel in den folgenden beiden.

E01.04 Als App-Nutzer möchte ich bei erstmaliger Nutzung der Applikation gefragt werden, ob die Applikation auf die Bluetooth-Funktion des Smartphones zugreifen darf, damit ich die mobiltelefonseitige Nutzung der Applikation kontrollieren kann.
E01.05 Als App-Nutzer möchte ich bei erstmaliger Nutzung der Applikation gefragt werden, ob die Applikation mir Benachrichtigungen schicken darf, damit in verschiedenen Situationen Push-Notifications ausgespielt werden können.

Ich als potentieller Benutzer bin mir ziemlich sicher, dass ich nicht gefragt werden will.
Diese ständigen Popups und Abfragen sind eigentlich eher nervig.

Ich denke die Wünsche oder/die Akteure hier sind andere, z.B:

  • Als rechtlich Verantwortlicher möchte ich das Gesetzte, wie z.B. DSGVO eingehalten werden, damit keine Kosten durch Beschwerden und Klagen entstehen.
  • Als App-Nutzer möchte ich nicht, dass die App Kommunikationsmechanismen meines Handies nutzt, ohne dass ich darüber und über die Gründe dafür informiert bin, damit ich dies sinnvoll und fundiert kontrollieren kann.

Eventuell macht es Sinn, die User Stories in diesem Sinne zu reviewen. Bisher lesen die sich mehr wie klassische Anforderungsspezifikationen die sich als User Stories tarnen ;-)
Das kann natürlich auch gewollt sein, ich kenne euren Entwicklungsprozess ja nicht.

By using the App Terms of Use are accepted

Regarding to the Onboarding process in User Story ID # E01.02 of documentation https://github.com/corona-warn-app/cwa-documentation/blob/master/translations/scoping_document.de.md#anbahnung-und-installation-onboarding-prozess, the answer is too unspecific and misleading, I quote:

Mit Nutzung der App akzeptiert der App-Nutzer die Nutzungsbedingungen und Datenschutzbestimmungen. (in English: By using the app the user accepts the terms of use)

This is not legal due to the fact that such consent must always be an active act.
The documentation should be more precise about this.

Prevent forwarding of TANs/QR-codes to other users

Regarding E06.04, E06.05 & E06.06:
It is proposed to allow a user to activate the notifications of other users also via a TAN obtained from a call center.
I want to point out the danger of misuse: A positive tested user can obtain this TAN and forward it to another (non-infected) user, who could then trigger false notifications. (Think about people who want to undermine the system by carrying extra smartphones in densely populated city centres, and activating their false notifications with such a TAN code)
Hence, it should be ensured that there is a proven link between the person, smartphone/app and test, e.g. by having the user to scan the QR-code (or acquire a TAN) in attendance of a health official. (Of course, there is still the risk of users carrying not their normal smartphone)

Regarding E06.01:
Of course, it has also to be ensured the the QR-code can't be forwarded to another user. (This can also be achieved by having the user to scan the code in attendance of a health official)

It would in general be good to also see the documentation of the health centre and server-side user stories.

Deletion of App and Data Retention

Abbildung 5: User Journey

This image gives an schematic overview how the app is working.

The last step in the app lifecycle "Deinstallation" says "ggf. Löschen sämtlicher Daten auf dem Gerät". This means "eventually" or "maybe" and is quite unspecific. When deleting the app the user expects all data is deleted. This includes system logs, crash reports, browser history and all system-wide locations that could be used to track and trace a user.

In addition to this User Story ID # E03.02 says that

Die App kann über eine Einstellung in den Auslieferungszustand zurückgesetzt werden, die gespeicherten Traces der letzten Tage bleiben aber erhalten.

This means that data won't be deleted entirely even when a user is requesting a reset to the delivery status of the App.

The documentation is not clear in this matter. How will the App guarantee, that all data is removed entirely from a device?

Manual process with TANs

User Stories ID # E06.04, E06.05 and E06.06 describe a manual process. Honestly I wonder how this should work if by then the user is not known and still anonymous and therefore not identifiable? Does this mean, that there is some kind of manual key exchange with a call-center agent? Assuming there will be 82 Mio users how long must a key be to maintain entropy and to prevent replay-attacks? How to ensure that the caller triggering the manual process is the person he/she claims to be?

Clarification: Complete Data Deletion on Deinstallation?

Where to find the issue

https://github.com/corona-warn-app/cwa-documentation/blame/cb991f6d5d103130a448ae728919b0109ef0bd06/translations/scoping_document.de.md#L78 states that "all data [of the app] is being deleted" when de-installing it from the device.

At the very right block of https://github.com/corona-warn-app/cwa-documentation/blob/cb991f6d5d103130a448ae728919b0109ef0bd06/translations/user_journey.de.png it is written "ggf.", which roughly means "if applicable".

Describe the issue

Usually "ggf." indicates that there are conditions where a complete deletion of data would not take place. If that was the case, the statement would be in contradiction with https://github.com/corona-warn-app/cwa-documentation/blame/cb991f6d5d103130a448ae728919b0109ef0bd06/translations/scoping_document.de.md#L78 .

Suggested change

I assume that all data is expected/planned to be deleted. That is why I suggest to remove the "ggf." from the picture.

Note

This is similar to #29 but not entirely identical.

Include Blue Tooth signal strength information in ID emission

This concerns a missing feature. Due to very different signal strength ability varying between different Smartphont types and even differnt Smartphones of equal type, it might be neccessary to send a reference value of the own blue tooth signal strenght together with the personal token to get valuable distance measures by strength of blue tooth signal.

Where to find the issue

The issue should be added distibuted to the concerning user stories

Describe the issue

A blue tooth receiver is only able to detect the received signal strength it is getting. To figure out the distance of an emitter the source signal strength must be known. There might be some less reliable methods by detecting singnal strength of the sender by time curve analysis whilst approach of the sender - but more reliable is a direct information of the emitters sending strength. This should be sent within the exchange of IDs to the approached smartphone. The signal strenght information should only be used for the distance detection and must not be saved to the contact list.

Suggested change

add this to concerning user stories

We already have a working prototype of an app

We already have a working prototype with the following features:

  • recognises people with and without smartphones around the user using a sophisticated neural network
  • works offline and 100% p2p, without the need of a back end
  • data is persisted on the device and can only be shared with the consent of the owner
  • data format is universally known, only needs translation of date-format and the word "contact"

We shared some images of the UI here: https://twitter.com/zenturee/status/1260830223546961920?s=20

Contact me, if you are interested.

Fehlende Worst-Case-Betrachtung der Komplexität der Hintergrundabfragen

In Phase Anwendung 1) Hintergrund heißt es:

In regelmäßigen Abständen holt sich die App vom Server eine Liste der Pseudo-IDs der sich freiwillig infiziert gemeldeten Nutzer und vergleicht diese mit den gespeicherten Pseudo-IDs im Gerät, um einen möglichen Kontakt zu ermitteln.

Sollte das Infektionsgeschehen trotz App wieder stark anwachsen und die App wird stark genutzt, dann ergibt sich ein hoher Traffic.

Wenn

n die Anzahl der User ist
m die Anzahl der neu infizierten User

Dann überträgt man regelmässig n * m Datensätze. Ist m klein, dann wird über einen längeren Zeitraum die Last verteilt. Steigt aber die Infektionsrate an, dann wird sehr viel Traffic in kurzer Zeit erzeugt.

Im Endeffekt würde bei 100%iger Infektionsrate am Ende ein Gesamttraffic von n^2 entstehen. Nicht gut, wenn die App ein Erfolg wird, es aber keinen Impfstoff gibt.

App and backend prototype implementing blind signatures

We want to contribute a mechanism for health authorities to report positive tests with minimal effort, so that app users get notified without any delay. To facilitate this we build an app and backend prototype that also implement the authorization mechanism. It uses blind signatures so that only authorized users can upload their tracking keys, while it is still impossible to link user identities to their keys.

We describe our approach in more detail at https://github.com/think-cell/corona where you can also find our app / backend prototype. We would be glad if used (parts of) this as the basis for your reporting mechanism.

How to avoid creating fake data?

There might be a security issue / design issue.

Given two devices e.g. Samsung Phones (A and B) where you can have multiple accounts.

  1. Create a new Account on A
  2. The app A behaves like a "fresh install"
  3. Create a new Account on B
  4. The app B behaves like a "fresh install"
  5. Trigger "tracking" event between A and B
  6. Wait for some server event that A and B was queried by the server and the IDs are known (unclear at this moment if an "health server" is required)
  7. Remove Account on B (the Server event might occure not very often - so we might have to keep the account for 1-2 days)
  8. Loop 3-6 for multiple times
  9. Remove Account on A
  10. Loop 1-9 for multiple times

This can be easily done by Appium or Selenium.

Since the App doesn't track the BT Mac or the Device Id.

How will the App avoid (by design) such ID flooding?

Unprotected sneeze when passing other person

Additional to the default contact warning (15 minutes near 1 m or whatever will be defined)
the App must have an short contact mode
to visualze when I had short contact to an (later on detected) infected person,
e.g. when walking around and getting some virus via unprotected sneeze when passing other person, and so I am
probably infected as well (or at least should contact Gesundheitsamt to become tested).

Is traffic routed through TOR?

What is missing

Is the communication between the app and the backend routed in a way that will prevent leaking IPs by design for example using the TOR network?

Why should it be included

Since there is no way (Im aware of) to audit the backend and ensure the logs are deleted an app users should not have to "trust" it to use it.
At least for things like remote updating the configuration.

Where should it be included

In the codebase and documentation.

To contribute to this project I am forced to share my behavioral data with Microsoft

To contribute to this project I am forced to register to Microsoft/ GitHub and create an account and I am forced to share my behavioral data. Microsoft knwo what system and dev tools I am using or at which times I am working and with whom I am connected or for which projects I am interested.

This is not Privacy by Design and Default. Is SAP or Telekom not fit and capable to run an own instance of GitLab or Gitea? Every small Developer can do this. Big projects like GNOME do this aswell. Why not SAP or Telekom?

Please clarify use of "Device attestation API"

What is missing

The recently published open source reference implementation of an Exposure Notifications
server
includes the use of a "device attestation API", such as the SafetyNet Attestation API.
The purpose would obviously be to validate TEKs, i.e. prevent hacked devices from reporting fake TEKs as Diagnosis Keys.
The SafetyNet ToS state that this "works by collecting hardware and software information, such as device and application data (...), and sending that data to Google for analysis". I think that's fine in general, but the corona-warn-app should either not invoke this API, or at least not only when a user has been infected, but independently of this - so that the device data cannot be linked to this sensitive information.
What is missing is a clear statement about not using such API, or if it's used, how and when.

Why should it be included

Including this information increases the trust that privacy is really preserved.

Calculating infection risc in case of multiple contacts of same person

This concerns a new feature. As i have read the evaluation function for the exposed state comes from RKI. This evaluation function should also concern that multiple contacts with the same person increase the infection risk. It also depends on the environment. For instance contacts outside cause much less infection risk than inside contacts.

Where to find the issue

This feature is new

Describe the issue

The application should be prepared to evaluate environment facts and to cumulative calculate the exposed risk as probability value. In case of infection all contacts with a significant exposure probability should be informed.

Suggested change

describe possible input values of the rki Function, describe risk calculation, and decision of IDs to warn

Document the estimated effectiveness of this app.

I am using the numbers of corona dashboard:

https://experience.arcgis.com/experience/478220a4c454480e823b17327b2bf1d4

2020-05-13
Total cases: 171.306
Recovered: 148.700
Infected: 22.606

So as far we don't know any estimation for the the unrecorded cases - my assumption is 0 (this can be fixed by assuming the Infected to any higher number you want).

So we have 83.000.000 people in Germany and 22.606 Infected. This is a 83.000.000 / 22.606 = 1 / 3.672 chance of meeting an infected person. (Or 2,7 promille) - assuming an equal distribution.

Number of installations of the App Chance 1:x of actually recording an infected person
100.000 3.047.421
200.000 1.523.710
500.000 609.484
1.000.000 304.742
2.000.000 152.371
2.500.000 121.896
5.000.000 60.948
8.000.000 38.092
10.000.000 30.474
20.000.000 15.237
25.000.000 12.189
50.000.000 6.094
83.000.000 3.671

Question: Are we measuring and tracking "the void"?

A 2,7 promille chance if everybody has the app on the phone! This is very very accurate measuring (considering this technology)!

However if we just have 5 mio installation it's 1:60.948 it is only 0,02 promille chance of recording an infected person!

I assume 0.02 promille this is almost as high as the rate people changing or upgrading their phones on a daily/weekly basis.

Please explain - how effective IS this app?

App availability in English

Hello,

Thank you for your efforts in this. Since I did not find any documentation about this I wanted to ask early on: will the app be available in English for the end user?

There are many people working in Germany who do not speak German (such as myself), and since you are developing everything in English to promote globalisation, I would like to request you to keep in mind to have the app available in English to the end user.

Thank you and good luck!

Publish app code

According to media reports, the apps are going to be published soon. The documentation states that the code will be available under the Apache v2 license. It is in public interest that reviewing the code is possible early, ideally before the apps go live. So, the projects source code should be published as soon as possible.

Until the code gets published, the documentation should elaborate in more detail on when and to what extent the code will be available as open source.

Enhancement/Idea: Indicate Tracing Data not being Deleted on Factory Reset

I am always unsure myself in similar situations: What portion of data is deleted, if I trigger the "Reset" (you call it "Delivery Default") button?

The documentation already clearly states that the tracking data should not be deleted in such an event.
In that case, I suggest to also explicitly state in an (own item of the) acceptance criteria that the app user will be informed about the limited scope of deletion upfront. I.e. I could think of the the safety question shown before to read something like

Do you really want to reset all configuration settings to defaults (Note: your tracking data will not be affected)?

User consent for notifying contacts

Situation:
It is planned to obtain user consent on sending IDs, activating bluetooth, push-notifications when using the app for the first time only. (E01.03, E01.04, E01.05)
Later, and in case of a positive test, user have to give another consent to notify (warn) their contacts. (E06.03)

Resulting behaviour:
This means that a user can use the app, but can still refuse to notify contacts in case of a positive test. (E06.03)
Just by having this option, I'd expect a certain fraction of users aborting the process at this step for whatever reasons. Please consider that the user has already entered his positive test result in the app at this stage, which probably shows his/her intention to notify (warn) all relevant contacts.

Suggestion:
Wouldn't it make sense that the user gives this consent already when starting the app for the first time? (Along with the other consents?)

Ensure privacy by not accessing network resources if not required

The documentation as well as the requirements list multiple features like

  • pulling of proximity calculation parameters
  • content download (help hotline number / informational pages and so on)

which would trigger network requests from the App to backend servers.

This violates the users privacy IMHO as the IP of the user and potentially an user-agent string is transmitted to the backend-servers. If there are special information pages for "infected" or "potentially infected" people and these pages are pulled on demand, this would de-anonymize the users.

Deutsche Telekom is one of the projects stakeholders, as they are a big ISP in germany used by a lot of people, they have the capability without any external control, to de-anonymize users which are their customers. I think this is an issue and should be avoided.

I would suggest that the app does not "pull" or "push" any additional information from an backend.

The only time this is required: If someone is marked "infected" and their token set needs to be uploaded to the Cloud.

"Infected Token download" could be implemented by means of public mirrors by trusted 3rd parties. Validity of the tokenset can be checked by a digital signature. The app should contain a list of public mirrors which are choosen at random on initial application start.

Remote access is violating integrity, anonymity and data protection

The Scoping Document (only in german) https://github.com/corona-warn-app/cwa-documentation/blob/master/translations/scoping_document.de.md describes "supporting processes" in #User Story ID E07.01.

The RKI wants to manipulate tresholds directly on the devices. So forth the API is accessing and manipulating locally stored data directly on the device. It is intended to do this without any App Updates (ref. to 2: "Die Anpassung wird auf den Endgeräten vorgenommen, ohne dass ein Update der App erforderlich ist.")

It is not clear when and under what circumstances this will be done. The context of these supporting processes is not described in detail. Whether and how users are informed about this access is also not specified.

User Story E10.01 describes further changes of dynamic contents that are to be controlled centrally. A content management system is therefore updating elements within the App or the App is loading ressources from the web. In both cases this makes everybody identifyable.

Conclusion:

At least some "supportive processes" are violating basic privacy goals of data Integrity and anonymity due to the fact that certain tresholds and dynamic contents can be manipulated remotely.

Contact Tracing Unterstützung

Ich würde mir wünschen in der App mit dem örtlichen Gesundheitsamt kommunizieren zu können.
Im Falle einer Benachrichtigung möchte ich eine lokal personalisierte Nachricht bekommen, welche Handlungsanweisungen, Lageeinschätzung und sonstige Informationen angepasst an meine Stadt enthält.
Ich möchte nachdem ich eine Kontaktnachricht bekommen habe in der App angeben können,

  • bin ich ein bekannter Kontakt eines anderen Covid positiven
  • ein Arbeiter im Kontakt mit vielen Mensch und wo (Pflegeinrichtung, Supermarktkasse etc...)
  • was habe ich in der Exposure Zeit gemacht und wo war ich.
  • meine Daten wie Name, Telefonnummern und Adresse
  • habe ich bereits selbst Symptome (fall eskalation, covid positiv Meldung auch ohne Testergebnis, bei engem Kontakt)
  • Wenn ich positiv bin, die Namen und Telefonnummern meiner mir bekannten Kontakte
    • gegenüber diesen sollten Kontakt Benachrichtigung deanonymisiert werden damit sie nicht im dunkeln tappen müssen.

Mit diesen Daten kann das Gesundheitsamt die Verdächtigen vorfiltern, in Gruppen einteilen, falsch positive aussortieren und relevante Ereignisse ausfindig machen die besondere Aufmerksamkeit benötigen.
Eventuell ist diese Vorfilterung auch absolut essentiell, weil sonst die App dazu führt dass die Gesundheitsämter mit Anrufen überflutet werden und sie dort den Überblick verlieren?

Use a static site generator for better UX

I'm the author and maintainer of Material for MkDocs, a theme for the static site generator MkDocs which generates a static site from a set of Markdown files. The UX is much better than browsing GitHub pages, it includes a client-side search, TOC and great mobile UX. There are also features like callouts, tabbed content, footnotes, syntax highlighting and many more.

Screenshot

It's also already used by SAP.

I'm happy to help and can submit a PR. Otherwise feel free to close this issue.

How discrimination can be ruled out?

A landlord sets up several smartphones and positions them in his houses full of tenants. The device always stays on same location acting as static beacon in order to collect IDs of all his tenants. From time to time the landlord will conduct a test or claiming he as symptoms triggering exchange of IDs or recieving notifications of possible infected peoples on this devices.

a) how can the app prevent usage of many devices by a single user?
b) how can the app prevent abnormal usage with static positioned devices?
c) how can the app rule our discrimination of people, in this case the tenants of the landlord?

This scenario of course can be expanded to company owners tracing employees, shop owners etc.

App discriminates users by mixing functions

By mixing the functions a) contact tracing and b) communication and dealing with test results the app violates the voluntary nature of its use. I am referencing to User Story ID # E06.02

Der App-Nutzer erhält eine Benachrichtigung, sobald ein verifiziertes Testergebnis vorliegt.

By nudging and offering additional functions the app usage is not voluntary anymore.
The recieved data recordsets might be biased.

Conclusion

Remove any additional functions that might be discriminating or nudging users

F-Droid support

Many Android users, e.g. those using LineageOS or Replicant, do not use Google Play Services for privacy reasons. In order to achieve broad adoption of the app and enable anyone to use the app it is inevitable to have the possibility to use the app without proprietary Play Services installed.

Please make sure it is possible to compile the app without any non-free dependencies. This would allow the app to be included in F-Droid. See F-Droid's inclusion policy for details:

We cannot build apps using Google’s proprietary “play-services”. [...]
We cannot build apps using proprietary tracking/analytic dependencies like Crashlytics and Firebase. [...]
We cannot build apps using proprietary ad libraries. [...]
We cannot build apps requiring Non-Free buildtools, including Oracle’s JDK or some pre-release toolchains. [...]

Thanks in advance!

Dialog to enter preferred smartphone carrying position of user

Where to find the issue

New requirement

Describe the issue

The distance between two smartphones is not everytime the same as the distance between noses or mouths of two persons. To calculate the real distance as exactly as possible the application needs a hint, where the user normally wears his smartphone.

Suggested change

Therefore a dialog needs to be created to enter this information and also a corresponding User-story

Include the comic explaining DP-3T in the README of this repository

Several issues created on this repository leave me with the impression they are based on a fundamental misunderstanding of the basic concept of the application.

Presenting that comic on the front page of this repository (and possibly all other repositories for the app) might help to spread the knowledge about how the application is supposed to work.

I'm referring to this comic: https://github.com/DP-3T/documents/tree/master/public_engagement/cartoon

More information about technology stack

What is missing

Information about the technology stack (native / cross platform) and why you chose it (if not native).

Why should it be included

Just out of curiosity.

Where should it be included

Probably inside a new document?

How shared devices are treated?

How's the App dealing with multiple users on shared devices esp. when used in low-income households where devices are often shared between family-members?

How privacy and data protection is ensured between partners when one partner gets the knowledge how many other people his or her other partner meets?

How does this affect the handling of transfered TANs or even test results? When the device is used by children for e.g. homework?

This use-case is not mentioned in the documentation at all.

Availability in F-Droid

Dear ladies and gentlemen,

since the app is going to be OpenSource software, are there any plans to make it available on alternative platforms, for instance on F-Droid (https://f-droid.org)? That would enable users of alternative or modified Android images to use and regularly update the app.

Best regards
Henry

Choose a Platform that Supports Private Downstream Forks in Syria

Disclaimer:

I am not a lawyer and this topic touches on international law, so verify before making a decision.

User Story:

As a user located in Syria, I want to fork CWA and work on it in private, while downstreaming changes from this repository.

GitHub does not allow that:

[...] due to U.S. trade controls law restrictions, GitHub is unable to provide private repository services [...] to accounts in [...] Syria [...].

Source: https://help.github.com/en/github/site-policy/github-and-trade-controls

In contrast to the US', the EU' sanctions on Syria are more narrow in scope:

The [...] export of arms [...], as well as equipment which might be used for internal repression, to Syria [...] shall be prohibited [...].

Source: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02011D0273-20111114

The EU regulation allows anything that is not immediately an arm to be exported:

[The restriction] shall not apply to [...] non-lethal military equipment or of equipment which might be used for internal repression, intended solely for humanitarian or protective use [...].

Source: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02011D0273-20111114

Thus, granting users in Syria access to a code hoster located in the EU seems (IANAL) legal. Since paid GitHub instances are sold by the same company, they still restrict access from Syria.

© 2020 GitHub, Inc.

Source: https://github.com/enterprise

Instead of GitHub, fulfilling this user story would require using a code hoster based in a EU member state without additional export restrictions prohibiting access from Syria. The Netherlands for example have not decreed any sanctions against Syria on their own:

[Absence of a statement at the relevant page.]

Source: https://www.government.nl/topics/international-peace-and-security/compliance-with-international-sanctions/sanctions-against-syria

In the Netherlands, there is GitLabHost, which is a hosted GitLab service:

Fully managed GitLab hosting

Source: https://gitlabhost.com/

GitLab endorses GitLabHost by naming them in their documentation:

Some 3rd party vendors also offer a single-tenant managed offering, such as GitLabHost.

Source: https://about.gitlab.com/gitlab-hosted/#as-an-existing-githost-user-what-options-do-i-have

GitLab is open source and can therefore be hosted by anybody:

GitLab [...] the leading collaboration tool for DevOps

Source: https://about.gitlab.com/

Workaround:

A user based Syria who wants to work downstream to this repository in private could use GitLabHost on their own like this:

[                     GitHub.com                        ]
user@github/cwa-public  <-- mirror-fork -- cwa@github/cwa

                  ↓                  mirror using a personal access token of GitHub's API

[email protected]/cwa-documentation-public --- fork + merge request --> user/cwa-documentation-private
[                                          GitLabHost.com                                               ]

Note that GitLab supports this, but it does not actually work currently, due to a bug. See:

https://gitlab.com/gitlab-org/gitlab/-/issues/217571

However, such a workaround requires the user to switch between code hosting platforms.

Fix:

Please consider using a platform which supports this user story on its own.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.