├── .gitignore
├── .github
├── ISSUE_TEMPLATE
│ ├── config.yml
│ ├── 04_other.md
│ ├── 03_questions.md
│ ├── 01_doc_issue.md
│ └── 02_bugs.md
└── workflows
│ └── checks.yml
├── images
├── CWA_title.png
├── user_journey.png
├── evreg-tam-block.png
├── ui_screens
│ ├── ui_screens_ios.png
│ ├── ios
│ │ ├── cwa_home_ios.png
│ │ ├── cwa_detail_ios.png
│ │ ├── cwa_onboarding_ios.png
│ │ └── cwa_risk_calculation_ios.png
│ ├── ui_screens_android.png
│ ├── android
│ │ ├── cwa_home_android.png
│ │ ├── cwa_detail_android.png
│ │ ├── cwa_onboarding_android.png
│ │ └── cwa_risk_calculation_android.png
│ └── Outdated.md
├── risk_calculation
│ ├── server_encoding.pdf
│ ├── client_interpretation.pdf
│ └── risk_calculation_enf_v2_overview.pdf
└── solution_architecture
│ ├── CWA_Components.png
│ ├── EFGS_overview.jpg
│ ├── dsos-date-range.png
│ ├── dsos-no-symptoms.png
│ ├── dsos-date-unknown.png
│ ├── dsos-no-information.png
│ ├── EFGS_Autonomous_Backend.jpg
│ ├── dsos-specific-date-known.png
│ ├── exposure_windows.svg
│ ├── upload_schedule.svg
│ ├── ios_releases.svg
│ └── key_flow_receiving.svg
├── transmission_risk.pdf
├── translations
├── user_journey.de.png
├── LANGUAGE_STYLE.de.md
├── pruefsteine.de.md
├── README.de.md
└── cwa-risk-assessment.de.md
├── 2020_06_24_Corona_API_measurements.pdf
├── backend-infrastructure-architecture.pdf
├── .markdownlint.json
├── package.json
├── backend-infrastructure-architecture.md
├── CODEOWNERS
├── cwa-versioning.md
├── INSTALL.md
├── ui_screens.md
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── transmission_risk_references.bib
├── glossary.md
├── pruefsteine.md
├── event_registration.md
├── LICENSE
├── cwa-risk-assessment.md
└── README.md
/.gitignore:
--------------------------------------------------------------------------------
1 | .DS_STORE
2 | node_modules
3 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/config.yml:
--------------------------------------------------------------------------------
1 | blank_issues_enabled: false
2 |
--------------------------------------------------------------------------------
/images/CWA_title.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/CWA_title.png
--------------------------------------------------------------------------------
/transmission_risk.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/transmission_risk.pdf
--------------------------------------------------------------------------------
/images/user_journey.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/user_journey.png
--------------------------------------------------------------------------------
/images/evreg-tam-block.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/evreg-tam-block.png
--------------------------------------------------------------------------------
/translations/user_journey.de.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/translations/user_journey.de.png
--------------------------------------------------------------------------------
/images/ui_screens/ui_screens_ios.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/ui_screens_ios.png
--------------------------------------------------------------------------------
/2020_06_24_Corona_API_measurements.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/2020_06_24_Corona_API_measurements.pdf
--------------------------------------------------------------------------------
/backend-infrastructure-architecture.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/backend-infrastructure-architecture.pdf
--------------------------------------------------------------------------------
/images/ui_screens/ios/cwa_home_ios.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/ios/cwa_home_ios.png
--------------------------------------------------------------------------------
/images/ui_screens/ios/cwa_detail_ios.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/ios/cwa_detail_ios.png
--------------------------------------------------------------------------------
/images/ui_screens/ui_screens_android.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/ui_screens_android.png
--------------------------------------------------------------------------------
/images/risk_calculation/server_encoding.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/risk_calculation/server_encoding.pdf
--------------------------------------------------------------------------------
/images/ui_screens/ios/cwa_onboarding_ios.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/ios/cwa_onboarding_ios.png
--------------------------------------------------------------------------------
/images/solution_architecture/CWA_Components.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/CWA_Components.png
--------------------------------------------------------------------------------
/images/solution_architecture/EFGS_overview.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/EFGS_overview.jpg
--------------------------------------------------------------------------------
/images/ui_screens/android/cwa_home_android.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/android/cwa_home_android.png
--------------------------------------------------------------------------------
/images/risk_calculation/client_interpretation.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/risk_calculation/client_interpretation.pdf
--------------------------------------------------------------------------------
/images/solution_architecture/dsos-date-range.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/dsos-date-range.png
--------------------------------------------------------------------------------
/images/solution_architecture/dsos-no-symptoms.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/dsos-no-symptoms.png
--------------------------------------------------------------------------------
/images/ui_screens/android/cwa_detail_android.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/android/cwa_detail_android.png
--------------------------------------------------------------------------------
/images/solution_architecture/dsos-date-unknown.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/dsos-date-unknown.png
--------------------------------------------------------------------------------
/images/solution_architecture/dsos-no-information.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/dsos-no-information.png
--------------------------------------------------------------------------------
/images/ui_screens/android/cwa_onboarding_android.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/android/cwa_onboarding_android.png
--------------------------------------------------------------------------------
/images/ui_screens/ios/cwa_risk_calculation_ios.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/ios/cwa_risk_calculation_ios.png
--------------------------------------------------------------------------------
/images/solution_architecture/EFGS_Autonomous_Backend.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/EFGS_Autonomous_Backend.jpg
--------------------------------------------------------------------------------
/images/solution_architecture/dsos-specific-date-known.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/solution_architecture/dsos-specific-date-known.png
--------------------------------------------------------------------------------
/images/ui_screens/android/cwa_risk_calculation_android.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/ui_screens/android/cwa_risk_calculation_android.png
--------------------------------------------------------------------------------
/images/risk_calculation/risk_calculation_enf_v2_overview.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/HEAD/images/risk_calculation/risk_calculation_enf_v2_overview.pdf
--------------------------------------------------------------------------------
/images/ui_screens/Outdated.md:
--------------------------------------------------------------------------------
1 | # Outdated screenshots
2 |
3 | Please note that the screenshots in this folder and its subfolders are outdated.
4 |
5 | Here you can find screenshots of some of the features that the Corona-Warn-App offers in the current release: [Take a Look](https://www.coronawarn.app/en/screenshots/). The corresponding German screenshots can be found here: [Machen Sie sich selbst ein Bild](https://www.coronawarn.app/de/screenshots/).
6 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/04_other.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: "\U0001F4AC Anything else?"
3 | about: For implementation specific issues (e.g., bug in the iOS app), please consider to open an issue in the respective repository.
4 |
5 | ---
6 |
11 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/03_questions.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: "\U00002753 Questions?"
3 | about: If you have *specific* questions about the documentation, please post them here.
4 | labels: question
5 |
6 | ---
7 |
12 |
13 | ## Your Question
14 |
15 | * Documentation File:
16 | * Line / Paragraph:
17 | * Question:
18 |
--------------------------------------------------------------------------------
/.markdownlint.json:
--------------------------------------------------------------------------------
1 | {
2 | "default": true,
3 | "MD013": false,
4 | "MD026": false,
5 | "MD024": {
6 | "allow_different_nesting": true
7 | },
8 | "MD033": {
9 | "allowed_elements": [
10 | "a",
11 | "blockquote",
12 | "br",
13 | "code",
14 | "details",
15 | "em",
16 | "hr",
17 | "img",
18 | "li",
19 | "ol",
20 | "p",
21 | "pre",
22 | "summary",
23 | "sup",
24 | "table",
25 | "tbody",
26 | "td",
27 | "th",
28 | "thead",
29 | "tr",
30 | "u",
31 | "ul"
32 | ]
33 | },
34 | "MD034": false,
35 | "MD036": false,
36 | "MD049": false
37 | }
38 |
--------------------------------------------------------------------------------
/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "docs",
3 | "version": "1.1.0",
4 | "description": "Corona-Warn-App: Documentation repository",
5 | "main": "README.md",
6 | "dependencies": {
7 | "markdown-link-check": "~3.8.7",
8 | "markdownlint": "^0.26.2",
9 | "markdownlint-cli": "^0.32.2",
10 | "npm-run-all": "^4.1.5"
11 | },
12 | "scripts": {
13 | "test": "run-s markdownlint checklinks",
14 | "markdownlint": "markdownlint '**/*.md' --ignore node_modules",
15 | "checklinks": "find . -not -path \"*node_modules*\" -not -path \"*.github*\" -name \"*.md\" | xargs -n 1 markdown-link-check"
16 | },
17 | "repository": {
18 | "type": "git",
19 | "url": "git@github.com:corona-warn-app/cwa-documentation.git"
20 | },
21 | "keywords": [
22 | "docs"
23 | ],
24 | "author": "Johannes Amorosa",
25 | "license": "Apache-2.0"
26 | }
27 |
--------------------------------------------------------------------------------
/.github/workflows/checks.yml:
--------------------------------------------------------------------------------
1 | name: Checks
2 |
3 | on: pull_request
4 |
5 | jobs:
6 | build:
7 | name: Build
8 | runs-on: ubuntu-latest
9 | steps:
10 | - name: Install requirements
11 | run: |
12 | sudo apt install -y automake npm nodejs
13 |
14 | - name: Checkout code
15 | uses: actions/checkout@v3
16 |
17 | - name: Setup Node.js 18 environment
18 | uses: actions/setup-node@v3
19 | with:
20 | node-version: 'lts/hydrogen'
21 |
22 | - name: Install npm dependencies
23 | if: always()
24 | run: |
25 | npm install
26 |
27 | - name: Linting markdown
28 | if: always()
29 | run: |
30 | npm run-script markdownlint
31 |
32 | - name: Checking for broken links
33 | if: always()
34 | run: |
35 | npm run-script checklinks
36 |
--------------------------------------------------------------------------------
/backend-infrastructure-architecture.md:
--------------------------------------------------------------------------------
1 | # German Corona-Warn-App (CWA)
2 |
3 | ## Backend Infrastructure Architecture Overview
4 |
5 | The file ``backend-infrastructure-architecture.pdf`` complements the "CWA Solution Architecture" document. It is intended as a technical overview document of Corona Warn App (CWA) and its underlying infrastructure and network.
6 |
7 | This description of the **CWA backend infrastructure architecture** is not published as MD file, because it is not intended to be developed together with the community. Whoever takes the sources and sets up their own "Corona-Warn-App" may use another backend structure. Nevertheless, it might be helpful to know how the current project is implemented in a data center. Therefore, we publish this document as a [PDF](backend-infrastructure-architecture.pdf) file.
8 |
9 | More CWA-Server Documentation can be found [here](https://github.com/corona-warn-app/cwa-server/tree/main/docs).
10 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/01_doc_issue.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: "\U0001F6A8 Documentation Issue"
3 | about: Did you come across parts of our documentation that should be fixed?
4 | labels: documentation, bug
5 |
6 | ---
7 |
12 |
13 | ## Where to find the issue
14 |
15 |
16 | ## Describe the issue
17 |
18 |
19 | ## Suggested change
20 |
21 |
--------------------------------------------------------------------------------
/CODEOWNERS:
--------------------------------------------------------------------------------
1 | # This file provides an overview of code owners in this repository.
2 |
3 | # Each line is a file pattern followed by one or more owners.
4 | # The last matching pattern has the most precedence.
5 | # For more details, read the following article on GitHub: https://help.github.com/articles/about-codeowners/.
6 |
7 | # These are the default owners for the whole content of this repository. The default owners are automatically added as reviewers when you open a pull request, unless different owners are specified in the file.
8 | * @corona-warn-app/cwa-moderators
9 |
10 | # Solution architecture document and its translations
11 | solution_architecture*.md @tklingbeil @mlenkeit @thomasaugsten @corona-warn-app/cwa-moderators
12 | /images/solution_architecture/ @tklingbeil @mlenkeit @thomasaugsten @corona-warn-app/cwa-moderators
13 |
14 | # Epidemiological Motivation of the Transmission Risk Level
15 | transmission_risk* @kirchnergo @hoehleatsu @weidemannf @dirkschumacher @benzlerj
16 |
17 | # How does the Corona-Warn-App identify an increased risk?
18 | cwa-risk* @benzlerj @hoehleatsu @kirchnergo @corona-warn-app/cwa-moderators
19 | translations/cwa-risk* @benzlerj @hoehleatsu @kirchnergo @corona-warn-app/cwa-moderators
20 |
--------------------------------------------------------------------------------
/cwa-versioning.md:
--------------------------------------------------------------------------------
1 | # Versioning
2 |
3 | All components of the Corona Warn App use [Semantic versioning](https://semver.org/).
4 |
5 | Given a version number MAJOR.MINOR.PATCH, increment the:
6 |
7 | - MAJOR version when you make incompatible API changes,
8 | - MINOR version when you add functionality in a backwards compatible manner, and
9 | - PATCH version when you make backwards compatible bug fixes.
10 |
11 | We plan to never deprecate outdated API versions. That means that even on MAJOR version changes our goal is to keep the old API functional.
12 |
13 | ## Maintaining compatible versions
14 |
15 | Backend components will always remain compatible due to ongoing the availability of old API versions.
16 |
17 | To ensure that all clients use the current "state of the art" information in order to apply the respective algorithms the cwa-server component can deprecate older Android and iOS app versions. The current minimum required app versions can be viewed in the [App Version Config](https://github.com/corona-warn-app/cwa-server/blob/main/services/distribution/src/main/resources/application.yaml#L118).
18 | The `app-version-config` is checked by the mobile clients on a regular basis. When the client detects that the required `min` version is higher than the current installed version, the user will be notified about the need to update the app. The app will not be useable until this update is performed.
19 |
20 | ## Changelogs
21 |
22 | Changelogs can be found the in release notes attached to git tags, e.g. [Android App, Version 1.0.3](https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.0.3).
23 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/02_bugs.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: "\U0001F6A8 Bug Report"
3 | about: Did you come across a bug or unexpected behaviour differing from the docs?
4 | labels: bug
5 |
6 | ---
7 |
14 |
15 | ## Avoid duplicates
16 | * [ ] Bug is not mentioned in the [FAQ](https://www.coronawarn.app/en/faq/)
17 | * [ ] Bug affects both Android **and** iOS, for specific issues / questions that apply only to one operating system, please raise them in the respective repositories:
18 | * [Android repository](https://github.com/corona-warn-app/cwa-app-android)
19 | * [iOS repository](https://github.com/corona-warn-app/cwa-app-ios)
20 | * [ ] Bug is not already reported in another issue
21 |
22 | ## Technical details
23 |
24 | - Device name:
25 | - iOS/Android version:
26 | - App version:
27 |
28 | ## Describe the bug
29 |
30 |
31 |
32 | ## Steps to reproduce the issue
33 |
34 |
35 |
36 |
42 |
43 | ## Expected behaviour
44 |
45 |
46 |
47 | ## Possible Fix
48 |
49 |
50 |
51 | ## Additional context
52 |
53 |
54 |
--------------------------------------------------------------------------------
/translations/LANGUAGE_STYLE.de.md:
--------------------------------------------------------------------------------
1 | # Sprachstil
2 |
3 | ## Vorurteilsfreie Sprache und Kommunikation
4 |
5 | Vorurteilsfreie Kommunikation bedeutet keine Stereotypisierung oder Diskriminierung von Menschen. Es geht darum, alle auf faire und respektvolle Weise zu behandeln. Dies bezieht sich auf verschiedene Dimensionen der Identität einer Person, wie Kultur, Geschlecht, Nationalität, ethnische Zugehörigkeit, Alter, wirtschaftlicher Hintergrund, Religion, sexuelle Orientierung oder besondere Bedürfnisse (Behinderungen). Diese Leitlinien berücksichtigen wir bei allen Veröffentlichungen in diesem Repository.
6 |
7 | ## Geschlecht und geschlechtsneutrale Sprache
8 |
9 | - Wir nutzen geschlechtsneutrale Terminologie, zum Beispiel "Abteilungsleitung" anstelle von "Abteilungsleiter".
10 | - Wir wenden diese Regel ausschließlich auf Begriffe an, die sich auf natürliche Personen beziehen. Begriffe, die ein maskulines oder feminines grammatikalisches Geschlecht haben, aber im Text keine natürliche Person beschreiben, können weiterhin uneingeschränkt benutzt werden. Beispiel: Die Verwendung von "Auftraggeber" für juristische Personen wie Firmen, Institutionen usw.
11 | - Wir vermeiden die maskulinen Singular-Pronomen "er", "ihn", "ihm" in generischen Aussagen wie zum Beispiel "Ein Nutzer kann seinen Bildschirm personalisieren". Besser: "Eine Person kann ihren Bildschirm personalisieren"
12 | - Wir achten dabei darauf, dass der Text natürlich klingt. Wir werden die deutsche Sprache dabei nicht bis an die Grenzen der Grammatik und Verständlichkeit ausdehnen. Bei der Suche nach Alternativen dürfen die Aussagen im Text nicht verfälscht werden. So ist etwa nicht immer die Nominalisierung des Partizips I (z.B. "Laufende") gleichbedeutend mit der geschlechtsspezifischen Formulierung (z.B. "Läufer" oder "Läuferin"), da das Partizip I in der Regel primär einen gerade aktiven Vorgang beschreibt. Im Beispiel sind alle "Laufenden" immer auch "Läuferinnen" und "Läufer", umgekehrt ist das jedoch nicht zu jedem Zeitpunkt der Fall.
13 | - Sofern eine neutrale Formulierung ohne eine Verfälschung des Textes bzw. seiner Aussage nicht möglich ist, verwenden wir den Doppelpunkt, gefolgt von der geschlechtsspezifischen Endung, um alle Geschlechter gleich anzusprechen. Beispiele für solche Endungen sind ":in", "innen" oder ":r". Beispiele: "Arbeiter:in", "Lehrer:innen" oder "Vorstandsvorsitzende:r". Diese Option sollte jedoch nur in Ausnahmefällen gewählt werden, da sie den Lesefluss stört. Zudem wird der Doppelpunkt von verschiedenen Screenreadern, die von Personen mit Einschränkung der Sehfähigkeit genutzt werden, explizit ausgesprochen. Beispiel: "Arbeiter Doppelpunkt innen". Dies beeinträchtigt Personen mit besonderen Bedürfnissen und sollte deswegen vermieden werden.
14 |
--------------------------------------------------------------------------------
/INSTALL.md:
--------------------------------------------------------------------------------
1 | # Development on documentation
2 |
3 | ## tl;dr
4 |
5 | **You will need to use following `npm scripts` before creating a pull request!**
6 |
7 | 1. `npm install`
8 | 2. `npm test`
9 |
10 | ## Features
11 |
12 | * Linting of markdown documents
13 | * Link checking
14 |
15 | ## Specifications
16 |
17 | This repository checks against following specification:
18 |
19 | * [Markdown Commonmark](https://spec.commonmark.org/)
20 |
21 | ## Prerequisites
22 |
23 | Install the Node.js 18 Active LTS version of [Node.js](https://nodejs.org/en/) (which includes npm).
24 |
25 | ## Installation
26 |
27 | For linting and all the checks you need several npm packages. The following command installs all necessary npm dependencies:
28 |
29 | ```shell
30 | npm install
31 | ```
32 |
33 | This installs all dependencies into a local `node_modules` folder.
34 |
35 | ## Checks
36 |
37 | To enforce specification conformity there are several checks defined as `npm run-script` targets. To run all checks please execute:
38 |
39 | ```shell
40 | npm test
41 | ```
42 |
43 | ### Individual checks
44 |
45 | If you want to run individual checks see the targets and the description below.
46 | Every individual check can be run like so:
47 |
48 | ```shell
49 | npm run-script my-individual-check
50 | ```
51 |
52 | See the [package.json](package.json) file for the currently available scripts.
53 |
54 | #### Markdown linter
55 |
56 | Markdown linting. See the rules [here](https://github.com/DavidAnson/markdownlint).
57 |
58 | ```shell
59 | npm run-script markdownlint
60 | ```
61 |
62 | ##### Markdown linter overrides
63 |
64 | Sometimes it is not possible to be commonmark conform. In these rare cases an inline tag to skip linting is possible.
65 |
66 | Candidates are tables.
67 |
68 | ```html
69 |
70 | | Column 1 | Column 2 | Column 3 |
71 | |----------|----------|----------|
72 |
73 | ```
74 |
75 | Additionally HTML image tags can be allowed globally. This is useful if you need
76 | to resize images, since commonmark has no annotation for this.
77 |
78 | This is done with a .markdownlint.json override file which would look something
79 | like this:
80 |
81 | ```json
82 | {
83 | "no-inline-html": {
84 | "allowed_elements": [
85 | "img",
86 | "table"
87 | ]
88 | }
89 | }
90 | ```
91 |
92 | For more information how to tweak overrides consult the markdown linter
93 | documentation mentioned above.
94 |
95 | #### Link resolver
96 |
97 | All cross references and external URLs are resolved.
98 |
99 | ```shell
100 | npm run-script checklinks
101 | ```
102 |
--------------------------------------------------------------------------------
/ui_screens.md:
--------------------------------------------------------------------------------
1 | # Corona-Warn-App User Interface Screens
2 |
3 | The design of the Corona-Warn-App combines the requirements of the German citizens, the German federal government, and the virologists with the latest technological capabilities. At the same time, it provides a user experience that is easy to understand and to follow. The design of the central overview, the usage of signal color to highlight the current risk level, as well as the explanatory illustrations ensure an intuitive consumption of the app.
4 |
5 | We highly appreciate your feedback on these screens! Though, please, bear in mind that major changes cannot be implemented without a decision by the Ministry of Health and the Robert Koch Institute. Further documentation, e.g. about questions of accessibility, will follow soon.
6 |
7 | ## User Validation
8 |
9 | We conducted usability tests with representative user groups and improved the design based on their feedback. Furthermore, Apple and Google were involved to optimize the design for iOS and Android usage.
10 |
11 | ## Accessibility
12 |
13 | Accessibility of the application was one of our top priorities when designing and implementing the app. Once available, it will support all accessibility features within the operating systems such as zooming to enlarge text, screen readers like VoiceOver for iOS and TalkBack for Android, or special color contrasts.
14 |
15 | ## Screens
16 |
17 | Here you can find screenshots of some of the features that the Corona-Warn-App offers in the current release: [Take a Look](https://www.coronawarn.app/en/screenshots/). The corresponding German screenshots can be found here: [Machen Sie sich selbst ein Bild](https://www.coronawarn.app/de/screenshots/).
18 |
19 | The screenshots shown in the following are outdated.
20 |
21 | 
22 | Figure 1: UI Screens for Google Android [(high-resolution images)](images/ui_screens/android/)
23 |
24 | 
25 | Figure 2: UI Screens for Apple iOS [(high-resolution images)](images/ui_screens/ios/)
26 |
27 | ## Screen Descriptions
28 |
29 | 1. This is the first screen ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/android/cwa_onboarding_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/ios/cwa_onboarding_ios.png)) that a user sees when launching the app for the first time. It describes the purpose of the app and is only displayed once after the very first app start.
30 | 2. The home screen ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/android/cwa_home_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/ios/cwa_home_ios.png)) is the entry point to the app for further starts. It provides the user with the current risk status. In case of a positive test, it offers the opportunity to submit the diagnosis keys to the server with a QR code or a TeleTAN. Further, it allows the sharing of the app with others, offers additional information, as well as the app setting button.
31 | 3. The detailed view ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/android/cwa_detail_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/ios/cwa_detail_ios.png)) of the risk level repeats the information displayed on the home screen. It provides the user with behavioral recommendations in line with his current infection risk. Moreover, it explains how the infection risk was determined.
32 | 4. The settings of the risk calculation screen ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/android/cwa_risk_calculation_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/main/images/ui_screens/ios/cwa_risk_calculation_ios.png)) can be accessed via the home screen as well as via the application settings. It explains the risk calculation and allows users to control it. In case of a significant malfunction of the risk calculation (e.g. the deactivation of Bluetooth) the user will be informed and provided with a solution.
33 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | # Contributing
2 |
3 | ## Build status
4 |
5 | 
6 |
7 | ## Code of Conduct
8 |
9 | All members of the project community must abide by the [Contributor Covenant, version 2.0](CODE_OF_CONDUCT.md).
10 | Only by respecting each other we can develop a productive, collaborative community.
11 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting [corona-warn-app.opensource@sap.com](mailto:corona-warn-app.opensource@sap.com) and/or a project maintainer.
12 |
13 | We appreciate your courtesy of avoiding political questions here. Issues which are not related to the project itself will be closed by our community managers.
14 |
15 | ## Engaging in Our Project
16 |
17 | We use GitHub to manage reviews of pull requests.
18 |
19 | * If you are a new contributor, see: [Steps to Contribute](#steps-to-contribute)
20 |
21 | * If you have a trivial fix or improvement, go ahead and create a pull request, addressing (with `@...`) a suitable maintainer of this repository (see [CODEOWNERS](CODEOWNERS) of the repository you want to contribute to) in the description of the pull request.
22 |
23 | * If you plan to do something more involved, please reach out to us and send an [email](mailto:corona-warn-app.opensource@sap.com). This will avoid unnecessary work and surely give you and us a good deal of inspiration.
24 |
25 | * Relevant coding style guidelines are available in the respective sub-repositories as they are programming language-dependent.
26 |
27 | ## Steps to Contribute
28 |
29 | Should you wish to work on an issue, please claim it first by commenting on the GitHub issue that you want to work on. This is to prevent duplicated efforts from other contributors on the same issue.
30 |
31 | If you have questions about one of the issues, please comment on them, and one of the maintainers will clarify.
32 |
33 | We kindly ask you to follow the [Pull Request Checklist](#pull-request-checklist) to ensure reviews can happen accordingly.
34 |
35 | ## Contributing Code
36 |
37 | You are welcome to contribute code in order to fix a bug or to implement a new feature.
38 |
39 | The following rule governs code contributions:
40 |
41 | * Contributions must be licensed under the [Apache 2.0 License](LICENSE)
42 |
43 | ## Contributing Documentation
44 |
45 | You are welcome to contribute documentation to the project. Please see the
46 | installation [document](INSTALL.md)
47 |
48 | The following rule governs documentation contributions:
49 |
50 | * Contributions must be licensed under the same license as code, the [Apache 2.0 License](LICENSE)
51 |
52 | ## Pull Request Checklist
53 |
54 | * Branch from the master branch and, if needed, rebase to the current master branch before submitting your pull request. If it doesn't merge cleanly with master, you may be asked to rebase your changes.
55 |
56 | * Commits should be as small as possible while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).
57 |
58 | * Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests. If tested manually, provide information about the test scope in the PR description (e.g. “Test passed: Upgrade version from 0.42 to 0.42.23.”).
59 |
60 | * Create _Work In Progress [WIP]_ pull requests only if you need clarification or an explicit review before you can continue your work item.
61 |
62 | * If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review by contacting us via [email](mailto:corona-warn-app.opensource@sap.com).
63 |
64 | * Post review:
65 | * If a review requires you to change your commit(s), please test the changes again.
66 | * Amend the affected commit(s) and force push onto your branch.
67 | * Set respective comments in your GitHub review to resolved.
68 | * Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.
69 |
70 | ## Issues and Planning
71 |
72 | * We use GitHub issues to track bugs and enhancement requests.
73 |
74 | * Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to reproduce that issue for the assignee. Therefore, contributors should use but aren't restricted to the issue template provided by the project maintainers.
75 |
76 | * When creating an issue, try using one of our issue templates which already contain some guidelines on which content is expected to process the issue most efficiently. If no template applies, you can of course also create an issue from scratch.
77 |
--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 |
2 | # Contributor Covenant Code of Conduct
3 |
4 | ## Our Pledge
5 |
6 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
7 |
8 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
9 |
10 | ## Our Standards
11 |
12 | Examples of behavior that contributes to a positive environment for our community include:
13 |
14 | * Demonstrating empathy and kindness toward other people
15 | * Being respectful of differing opinions, viewpoints, and experiences
16 | * Giving and gracefully accepting constructive feedback
17 | * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
18 | * Focusing on what is best not just for us as individuals, but for the overall community
19 |
20 | Examples of unacceptable behavior include:
21 |
22 | * The use of sexualized language or imagery, and sexual attention or advances of any kind
23 | * Trolling, insulting or derogatory comments, and personal or political attacks
24 | * Public or private harassment
25 | * Publishing others' private information, such as a physical or email address, without their explicit permission
26 | * Other conduct which could reasonably be considered inappropriate in a professional setting
27 |
28 | ## Enforcement Responsibilities
29 |
30 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
31 |
32 | Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
33 |
34 | ## Scope
35 |
36 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
37 |
38 | ## Enforcement
39 |
40 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [corona-warn-app.opensource@sap.com](mailto:corona-warn-app.opensource@sap.com). All complaints will be reviewed and investigated promptly and fairly.
41 |
42 | All community leaders are obligated to respect the privacy and security of the reporter of any incident.
43 |
44 | ## Enforcement Guidelines
45 |
46 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
47 |
48 | ### 1. Correction
49 |
50 | **Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
51 |
52 | **Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
53 |
54 | ### 2. Warning
55 |
56 | **Community Impact**: A violation through a single incident or series of actions.
57 |
58 | **Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
59 |
60 | ### 3. Temporary Ban
61 |
62 | **Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
63 |
64 | **Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
65 |
66 | ### 4. Permanent Ban
67 |
68 | **Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
69 |
70 | **Consequence**: A permanent ban from any sort of public interaction within the community.
71 |
72 | ## Attribution
73 |
74 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
75 |
76 | Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
77 |
78 | [homepage]: https://www.contributor-covenant.org
79 |
80 | For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
81 |
--------------------------------------------------------------------------------
/transmission_risk_references.bib:
--------------------------------------------------------------------------------
1 | @article{he_etal2020,
2 | Author = {He, Xi and Lau, Eric H. Y. and Wu, Peng and Deng, Xilong and Wang, Jian and Hao, Xinxin and Lau, Yiu Chung and Wong, Jessica Y. and Guan, Yujuan and Tan, Xinghua and Mo, Xiaoneng and Chen, Yanqing and Liao, Baolin and Chen, Weilie and Hu, Fengyu and Zhang, Qing and Zhong, Mingqiu and Wu, Yanrong and Zhao, Lingzhai and Zhang, Fuchun and Cowling, Benjamin J. and Li, Fang and Leung, Gabriel M.},
3 | Da = {2020/05/01},
4 | Date-Added = {2020-05-24 13:17:37 +0200},
5 | Date-Modified = {2020-05-24 13:17:37 +0200},
6 | Doi = {10.1038/s41591-020-0869-5},
7 | Id = {He2020},
8 | Isbn = {1546-170X},
9 | Journal = {Nature Medicine},
10 | Number = {5},
11 | Pages = {672--675},
12 | Title = {Temporal dynamics in viral shedding and transmissibility of COVID-19},
13 | Ty = {JOUR},
14 | Url = {https://doi.org/10.1038/s41591-020-0869-5},
15 | Volume = {26},
16 | Year = {2020},
17 | Bdsk-Url-1 = {https://doi.org/10.1038/s41591-020-0869-5}
18 | }
19 |
20 | @article{he_etal2020correction,
21 | title = {Author {Correction}: {Temporal} dynamics in viral shedding and transmissibility of {Covid}-19},
22 | volume = {26},
23 | copyright = {2020 The Author(s), under exclusive licence to Springer Nature America, Inc.},
24 | issn = {1546-170X},
25 | shorttitle = {Author {Correction}},
26 | url = {https://www.nature.com/articles/s41591-020-1016-z},
27 | doi = {10.1038/s41591-020-1016-z},
28 | abstract = {An amendment to this paper has been published and can be accessed via a link at the top of the paper.},
29 | language = {en},
30 | number = {9},
31 | urldate = {2020-10-06},
32 | journal = {Nature Medicine},
33 | author = {He, Xi and Lau, Eric H. Y. and Wu, Peng and Deng, Xilong and Wang, Jian and Hao, Xinxin and Lau, Yiu Chung and Wong, Jessica Y. and Guan, Yujuan and Tan, Xinghua and Mo, Xiaoneng and Chen, Yanqing and Liao, Baolin and Chen, Weilie and Hu, Fengyu and Zhang, Qing and Zhong, Mingqiu and Wu, Yanrong and Zhao, Lingzhai and Zhang, Fuchun and Cowling, Benjamin J. and Li, Fang and Leung, Gabriel M.},
34 | month = sep,
35 | year = {2020},
36 | pages = {1491--1493}
37 | }
38 |
39 | @online{AndroidExposureNotificationsApi,
40 | author = {Apple and Google},
41 | title = {{Exposure Notifications} Android API Documentation v1.3.2},
42 | year = 2020,
43 | url = {https://static.googleusercontent.com/media/www.google.com/en/covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.2.pdf},
44 | urldate = {2020-06-04}
45 | }
46 |
47 | @online{ExposureNotificationCrypto,
48 | author = {Apple and Google},
49 | title = {{Exposure Notifications} Cryptography Specification v1.2},
50 | year = 2020,
51 | url = {https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf},
52 | urldate = {2020-06-04}
53 | }
54 |
55 | % 17174352
56 | @Article{svensson2007,
57 | Author="Svensson, Å. ",
58 | Title="{{A} note on generation times in epidemic models}",
59 | Journal="Math Biosci",
60 | Year="2007",
61 | Volume="208",
62 | Number="1",
63 | Pages="300--311",
64 | Month="Jul",
65 | DOI="10.1016/j.mbs.2006.10.010"
66 | }
67 |
68 | @article{mizumoto_etal2020,
69 | author = "Mizumoto, Kenji and Kagaya, Katsushi and Zarebski, Alexander and Chowell, Gerardo",
70 | title = "Estimating the asymptomatic proportion of coronavirus disease 2019 (COVID-19) cases on board the Diamond Princess cruise ship, Yokohama, Japan, 2020",
71 | journal = "Eurosurveillance",
72 | year = "2020",
73 | volume = "25",
74 | number = "10",
75 | eid = 2000180,
76 | pages = "",
77 | url = "https://www.eurosurveillance.org/content/10.2807/1560-7917.ES.2020.25.10.2000180",
78 | doi = "https://doi.org/10.2807/1560-7917.ES.2020.25.10.2000180"
79 | }
80 |
81 | @Article{woelfel_etal2020,
82 | author={W{\"o}lfel, Roman
83 | and Corman, Victor M.
84 | and Guggemos, Wolfgang
85 | and Seilmaier, Michael
86 | and Zange, Sabine
87 | and M{\"u}ller, Marcel A.
88 | and Niemeyer, Daniela
89 | and Jones, Terry C.
90 | and Vollmar, Patrick
91 | and Rothe, Camilla
92 | and Hoelscher, Michael
93 | and Bleicker, Tobias
94 | and Br{\"u}nink, Sebastian
95 | and Schneider, Julia
96 | and Ehmann, Rosina
97 | and Zwirglmaier, Katrin
98 | and Drosten, Christian
99 | and Wendtner, Clemens},
100 | title={Virological assessment of hospitalized patients with COVID-2019},
101 | journal={Nature},
102 | year={2020},
103 | month={May},
104 | day={01},
105 | volume={581},
106 | number={7809},
107 | pages={465-469},
108 | issn={1476-4687},
109 | doi={10.1038/s41586-020-2196-x},
110 | url={https://doi.org/10.1038/s41586-020-2196-x}
111 | }
112 |
113 | @article{arons_etal2020,
114 | author = {Arons, Melissa M. and Hatfield, Kelly M. and Reddy, Sujan C. and Kimball, Anne and James, Allison and Jacobs, Jesica R. and Taylor, Joanne and Spicer, Kevin and Bardossy, Ana C. and Oakley, Lisa P. and Tanwar, Sukarma and Dyal, Jonathan W. and Harney, Josh and Chisty, Zeshan and Bell, Jeneita M. and Methner, Mark and Paul, Prabasaj and Carlson, Christina M. and McLaughlin, Heather P. and Thornburg, Natalie and Tong, Suxiang and Tamin, Azaibi and Tao, Ying and Uehara, Anna and Harcourt, Jennifer and Clark, Shauna and Brostrom-Smith, Claire and Page, Libby C. and Kay, Meagan and Lewis, James and Montgomery, Patty and Stone, Nimalie D. and Clark, Thomas A. and Honein, Margaret A. and Duchin, Jeffrey S. and Jernigan, John A.},
115 | title = {Presymptomatic SARS-CoV-2 Infections and Transmission in a Skilled Nursing Facility},
116 | journal = {New England Journal of Medicine},
117 | volume = {382},
118 | number = {22},
119 | pages = {2081-2090},
120 | year = {2020},
121 | doi = {10.1056/NEJMoa2008457},
122 | url = {https://doi.org/10.1056/NEJMoa2008457},
123 | eprint = {https://doi.org/10.1056/NEJMoa2008457}
124 | }
125 |
126 |
127 | @article {Lauer_etal2020,
128 | author = {Lauer, Stephen A and Grantz, Kyra H and Bi, Qifang and Jones, Forrest K and Zheng, Qulu and Meredith, Hannah and Azman, Andrew S and Reich, Nicholas G and Lessler, Justin},
129 | title = {The incubation period of 2019-nCoV from publicly reported confirmed cases: estimation and application},
130 | elocation-id = {2020.02.02.20020016},
131 | year = {2020},
132 | doi = {10.1101/2020.02.02.20020016},
133 | publisher = {Cold Spring Harbor Laboratory Press},
134 | URL = {https://www.medrxiv.org/content/early/2020/02/04/2020.02.02.20020016},
135 | eprint = {https://www.medrxiv.org/content/early/2020/02/04/2020.02.02.20020016.full.pdf},
136 | journal = {medRxiv}
137 | }
138 |
--------------------------------------------------------------------------------
/glossary.md:
--------------------------------------------------------------------------------
1 | # Glossary
2 |
3 | This overview provides a description for all acronyms and special terms which are used in the Corona-Warn-App repositories. If you encounter any missing terms, please [let us know](https://github.com/corona-warn-app/cwa-documentation/issues/new?labels=documentation%2C+bug&template=01_doc_issue.md) or [create a pull request](https://github.com/corona-warn-app/cwa-documentation/pulls).
4 |
5 | | Term, acronym... | Description |
6 | | --- | --- |
7 | | AEM | Acronym for "[Associated Encrypted Metadata](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A privacy preserving encrypted metadata that shall be used to carry protocol versioning and transmit (Tx) power for better distance approximation. The Associated Encrypted Metadata changes about every 15 minutes, at the same cadence as the Rolling Proximity Identifier, to prevent wireless tracking of the device. |
8 | | AES | Acronym for "[Advanced Encryption Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)", used in the [Exposure Notification Framework](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf) |
9 | | API | An [Application Programming Interface](https://en.wikipedia.org/wiki/Application_programming_interface) (API) is a computing interface which defines interactions between multiple software intermediaries. |
10 | | APNs | Acronym for "[Apple Push Notification service](https://en.wikipedia.org/wiki/Apple_Push_Notification_service)", a platform notification service created by Apple Inc. |
11 | | BGG | The [German Equality of Persons with Disabilities Act](https://www.gesetze-im-internet.de/bgg/), acronym for "Behindertengleichstellungsgesetz", long term: "Gesetz zur Gleichstellung von Menschen mit Behinderungen". |
12 | | BLE, BTLE | [Bluetooth Low Energy](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) is a wireless personal area network technology. It is used in the Corona-Warn-App. |
13 | | BMG | German [Federal Ministry of Health](https://www.bundesgesundheitsministerium.de/en/), acronym for "Bundesministerium für Gesundheit". |
14 | | CDN | Acronym for [Content Delivery Network](https://en.wikipedia.org/wiki/Content_delivery_network). |
15 | | COVID-19 | [Coronavirus disease 2019](https://en.wikipedia.org/wiki/Coronavirus_disease_2019) is an infectious disease caused by severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2). |
16 | | CTR | Acronym for "[Counter (Mode)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#CTR)", a mode of operation in cryptography, also used in the [Exposure Notification Framework](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf) |
17 | | CWA | The [Corona-Warn-App](https://github.com/corona-warn-app/cwa-documentation), the official COVID-19 exposure notification app for Germany. |
18 | | Diagnosis Key(s) | The subset of Temporary Exposure Keys uploaded when the device owner is diagnosed as positive for the coronavirus. See also the [Exposure Notification Bluetooth Specification](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) |
19 | | DP-3T | [Decentralized Privacy-Preserving Proximity Tracing](https://github.com/DP-3T/documents), another approach to an exposure notification app, mainly driven by institutions from Switzerland. |
20 | | ENA | Acronym for "Exposure Notification App", used as internal identifier for the Corona-Warn-App in certain locations. |
21 | | FAQ | Frequently Asked Questions |
22 | | FCM | Acronym for "[Firebase Cloud Messaging](https://en.wikipedia.org/wiki/Firebase_Cloud_Messaging)", a cross-platform cloud solution for messages and notifications. |
23 | | GUID | Acronym for "[Globally Unique Identifier](https://en.wikipedia.org/wiki/Universally_unique_identifier)". |
24 | | IfSG | The [German Prevention and Control Act of infectious diseases among humans](https://www.gesetze-im-internet.de/ifsg/index.html), acronym for "Infektionsschutzgesetz", long term: "Gesetz zur Verhütung und Bekämpfung von Infektionskrankheiten beim Menschen". |
25 | | OTC | Acronym for "[Open Telekom Cloud](https://open-telekom-cloud.com/)"
26 | | PEPP-PT | [Pan-European Privacy-Preserving Proximity Tracing](https://github.com/pepp-pt/pepp-pt-documentation), formerly endorsed approach to a COVID-19 exposure notification app for Germany. |
27 | | QR Code | Acronym for [Quick Response Code](https://en.wikipedia.org/wiki/QR_code), a two-dimensional/matrix barcode used in the Corona-Warn-App, handed out by the test center after a test was conducted. See our [solution architecture document](solution_architecture.md) for details. |
28 | | Registration Token | Used to a) link the mobile phone with the data from the QR Code and b) generate a TAN which is needed to finally perform the upload of the diagnosis keys to the Corona-Warn-App-Server. See our [solution architecture document](solution_architecture.md) for details. |
29 | | REST | Acronym for "[Representational State Transfer](https://en.wikipedia.org/wiki/Representational_state_transfer)". |
30 | | Risk score | Several parameters are used to calculate a risk score, i.e. the likelihood that a user has been exposed to the coronavirus. See our [solution architecture document](solution_architecture.md) for details. |
31 | | RKI | The [Robert Koch-Institut](https://www.rki.de/) is Germany’s public health institute. |
32 | | RPI | Acronym for "[Rolling Proximity Identifier](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A privacy preserving identifier derived from the Temporary Exposure Key and sent in the broadcast of the Bluetooth payload. The identifier changes about every 15 minutes to prevent wireless tracking of the device. |
33 | | SARS-CoV-2 | [Severe acute respiratory syndrome coronavirus 2](https://en.wikipedia.org/wiki/Severe_acute_respiratory_syndrome_coronavirus_2) (SARS-CoV-2) is the strain of coronavirus that causes coronavirus disease 2019 (COVID-19), a respiratory illness. It is colloquially known as coronavirus. |
34 | | TAN | Acronym for "[Transaction Authentication Number](https://en.wikipedia.org/wiki/Transaction_authentication_number)". Needed to ensure that a device is allowed to do the upload of the diagnosis keys. TANs are not visible to users. See our [solution architecture document](solution_architecture.md) for details. |
35 | | TAM | Acronym for "[Technical Architecture Modeling](http://www.fmc-modeling.org/fmc-and-tam)", a modeling language mainly used at SAP to describe software architectures.
36 | | TCN | The [TCN Coalition](https://github.com/TCNCoalition/TCN) is a global community of people to support exposure notification apps during the COVID-19 pandemic. |
37 | | TEK | Acronym for "[Temporary Exposure Key](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A key that’s generated every 24 hours for privacy consideration. |
38 | | teleTAN | Authorizes the upload of diagnosis keys from the app to the Corona-Warn-App Server if the test has returned a positive result and if the device wasn't linked using the QR Code. If the authorization is successful, the server will issue a registration token. See our [solution architecture document](solution_architecture.md) for details. |
39 |
40 | ## Other Glossaries
41 |
42 | ### Technical FAQ Site
43 |
44 | - [English Glossary](https://www.coronawarn.app/en/faq/#glossary)
45 | - [German Glossar](https://www.coronawarn.app/de/faq/#glossary)
46 |
47 | ### Federal Government (Bundesregierung) FAQ Site
48 |
49 | To access the glossaries, scroll down the page to the Glossary / Glossar section:
50 |
51 |
52 |
53 | - [English FAQs](https://www.bundesregierung.de/corona-warn-app-faq-englisch)
54 | - [German FAQs](https://www.bundesregierung.de/corona-warn-app-faq)
55 |
56 |
--------------------------------------------------------------------------------
/pruefsteine.md:
--------------------------------------------------------------------------------
1 | # Criteria for the Evaluation of Contact Tracing Apps
2 |
3 | The Chaos Computer Club (CCC) proposed minimum privacy [requirements](https://www.ccc.de/en/updates/2020/contact-tracing-requirements) that should be considered when designing and evaluating contact tracing apps.
4 |
5 | The CCC is a well-reputed European hacker collective dealing with ["technical and societal issues, such as surveillance, privacy, freedom of information, hacktivism, data security, and many other interesting things around technology and hacking issues."](https://www.ccc.de/en)
6 |
7 | This document describes the compliance of the [current architecture](solution_architecture.md) of the Corona-Warn-App with the *technical* criteria as outlined in the CCC's contact tracing requirements. For *political* and *epidemiological* criteria, we refer to the German Ministry of Health or the Robert-Koch-Institute, respectively.
8 |
9 | We are confident that the concept of the Corona-Warn-App is compliant with the CCC's technical requirements. We invite all members of the public to assess the ongoing implementation and discuss any issues or concerns [directly in the development repositories](https://github.com/corona-warn-app) in an open and transparent manner.
10 |
11 | ## No Central Entity to Trust
12 |
13 | The Corona-Warn-App server does not store or process any confidential information requiring trust or secrecy. Due to the decentralized approach, the server does not hold any secret information. All the information that is stored on the server is publicly available.
14 |
15 | Based on this publicly available data and the information that is securely stored on the end device, the app itself, and not a cloud service, decides whether to inform a user about a potential exposure event. This information never leaves the device.
16 |
17 | The information about individual potential exposure events is not stored in the app itself, but handled securely by the underlying exposure notification framework. This framework stores information about visible rolling proximity identifiers (RPI) that were in close proximity over a defined time interval. This information is stored directly on the device.
18 |
19 | Even if the central Corona-Warn-App server is compromised, this information cannot be linked back to devices without having access to the device in the first place. Even then, the app itself cannot access the RPIs. Access to the diagnosis keys is only possible with the user's consent and only for a short period of time. Information that links diagnosis keys and connection metadata is removed before processing this data. Furthermore, identifying metadata, such as the IP address, is removed before diagnosis keys are processed by the backend server to further reduce the risk of rogue individuals connecting this information.
20 |
21 | ## Data Economy/Minimization
22 |
23 | As mandated by the General Data Protection Regulation (GDPR), [data minimization](https://www.privacy-regulation.eu/en/article-5-principles-relating-to-processing-of-personal-data-GDPR.htm) is a paramount principle in the implementation of the Corona-Warn-App.
24 |
25 | Data collection is limited to the minimum data required for the app to function. Users only provide the following input:
26 |
27 | * Permission to use the Exposure Notification framework
28 | * QR Code scan during testing
29 | * TeleTAN in case of hotline-based result verification
30 | * Consent to upload daily diagnosis keys
31 |
32 | Location data is not and cannot be collected by apps using the Exposure Notification framework:
33 |
34 | * [Section 3.3 Exposure Notification APIs Addendum](https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf)
35 | * [Section 3.c Google COVID-19 Exposure Notifications Service Additional Terms](https://blog.google/documents/72/Exposure_Notifications_Service_Additional_Terms.pdf).
36 |
37 | The diagnosis keys are only stored centrally for the epidemiologically relevant period of 14 days and are removed automatically after that period.
38 |
39 | ## Anonymity
40 |
41 | Users remain anonymous within the Corona-Warn-App system as long as their temporary exposure keys (TEK) solely remain on their device.
42 |
43 | The rolling proximity identifiers (RPI) that are observed by other devices can only be verified via the uploaded TEKs. RPIs also change frequently, i.e. in 10-20 min intervals, based on the TEK and the TEK changes daily. This means that even if the list of RPIs for a given day is available, it would still not be possible to identify a person that is sitting next to you every day in public transport.
44 |
45 | Theoretically, it would be possible to follow a user, collect the user's RPIs, connect them with person-identifying data, and then check if the person is ever marked as infected. Yet, in practice, this attack vector to deanonymize a user requires a high amount of effort just to gain little additional information compared to the one already gathered while following the user.
46 |
47 | Once temporary exposure keys are uploaded to the server (in case of a positive test result), anonymity turns into pseudonymity. With the uploaded diagnosis keys available, it becomes possible to attribute all RPIs of a given day to a single diagnosis key. Attributing this diagnosis key to distinct users or their device's International Mobile Equipment Identity (IMEI) is, however, still not possible without having direct access to the secret storage of the device.
48 |
49 | Users only have to identify themselves when they obtain the permission to upload diagnosis keys via teleTAN. But this happens just for verification reasons and should not provide identifying information beyond the one already known to health authorities. To further increase anonymity, users can make the call using a different device than the device they use for exposure detection.
50 |
51 | ## No Creation of Central Movement or Contact Profiles
52 |
53 | Movement or contact data is not collected centrally.
54 |
55 | Neither location data, nor the rolling proximity identifiers that are part of potential exposure events are ever stored centrally. At any given point in time, the system is only aware that diagnosis keys belong to individuals that have tested positive, not whom they met, where they met, or when they met.
56 |
57 | To use the app for exposure detection, no identification is required. An identification is only necessary for the results retrieval and diagnosis key transmission functions. Linking the app to social media profiles is not and will not be implemented in this project.
58 |
59 | ## Unlinkability
60 |
61 | The Corona-Warn-App and the underlying Exposure Notification framework take necessary cryptographic and technical means to prevent linking of user identity and the keys and identifiers visible in the system.
62 |
63 | Temporary Exposure Keys (TEK) are newly generated every day only on the user's device. From these TEKs, rolling proximity identifiers (RPI) are generated in 10 to 20 minute intervals. Without TEKs being uploaded and, thus, becoming diagnosis keys, RPIs cannot be linked to a certain user. If diagnosis keys have been uploaded, linking becomes only possible between diagnosis key and RPI and not directly to a user.
64 |
65 | As a rare edge case, diagnosis keys could be attributed to a single person in case this person is the only one reporting positive for a prolonged period of time. By only publishing diagnosis keys once a certain threshold of submissions is reached over a period of time, this risk is mitigated. Also, diagnosis key upload is limited for the last 14 days prior to the positive test results and no linking of exposure events beyond the epidemiological relevant timeframe is possible.
66 |
67 | ## Unobservability of Communication
68 |
69 | The Corona-Warn-App takes state of the art measures to make individual messages and communication patterns unobservable to malicious entities.
70 |
71 | Well-established encryption mechanisms such as HTTP over TLS (HTTPS) ensure that messages are not readable for outside viewers. Metadata is removed before processing payload in diagnosis key submissions and can therefore not be linked to them on a database level. To further reduce the possibility of man-in-the-middle attacks, static public key pinning shall ensure that trusted communication only happens between the Corona-Warn-App and the server.
72 |
73 | Besides shielding individual messages that are transmitted by the system, also communication patterns need to be disguised. Consider, for example, that polling for test results and submitting diagnosis keys would only happen in case of a real infection. In this case, observing network traffic would be sufficient to know that users took a SARS-CoV-2 test and had a positive result. This attack surface is mitigated by random fake messages that are indistinguishable from valid ones. This way, key submission and the retrieval of test results are indistinguishable from the system's background noise, creating plausible deniability for users even if network traffic is observed.
74 |
--------------------------------------------------------------------------------
/translations/pruefsteine.de.md:
--------------------------------------------------------------------------------
1 | # Prüfsteine für die Beurteilung von „Contact Tracing“-Apps
2 |
3 | Der Chaos Computer Club (CCC) hat einige [Minimalanforderungen](https://www.ccc.de/updates/2020/contact-tracing-requirements) zur Wahrung der Privatsphäre bei der Konzeption und Bewertung von „Contact Tracing“-Apps vorgeschlagen.
4 |
5 | Der CCC ist eine renommierte europäische Hackervereinigung, die sich mit dem [Spannungsfeld technischer und sozialer Entwicklungen](https://www.ccc.de) befasst: „Die Aktivitäten des Clubs reichen von technischer Forschung und Erkundung am Rande des Technologieuniversums über Kampagnen, Veranstaltungen, Politikberatung, Pressemitteilungen und Publikationen bis zum Betrieb von Anonymisierungsdiensten und Kommunikationsmitteln.“
6 |
7 | Dieses Dokument beschreibt, inwieweit die [aktuelle Architektur](../solution_architecture.md) die *technischen* Anforderungen erfüllt. In Bezug auf die *politischen* und *epidemiologischen* Anforderungen verweisen wir an das deutsche Bundesministerium für Gesundheit bzw. das Robert Koch-Institut.
8 |
9 | Wir sind davon überzeugt, dass das Konzept der Corona-Warn-App die technischen Anforderungen des CCC erfüllt. Es sind alle dazu eingeladen, die laufende Implementierung der App zu prüfen und jegliche Probleme, Bedenken oder sonstige Themen offen und transparent [direkt in den Entwicklungs-Repositories](https://github.com/corona-warn-app) zu diskutieren.
10 |
11 | ## Keine zentrale Entität, der vertraut werden muss
12 |
13 | Der Server der Corona-Warn-App speichert und verarbeitet keinerlei vertrauliche Informationen, für die Vertrauenswürdigkeit oder Geheimhaltung erforderlich sind. Aufgrund des dezentralen Ansatzes liegen auf dem Server keine geheimen Informationen – alle gespeicherten Informationen sind öffentlich zugänglich.
14 |
15 | Auf Basis dieser öffentlich zugänglichen Daten und den sicher auf dem Endgerät gespeicherten Informationen entscheidet die App – und kein Cloud-Service –, ob eine nutzende Person über ein potenzielles Kontaktereignis informiert wird. Diese Information verlässt das Gerät zu keinem Zeitpunkt.
16 |
17 | Die App selbst speichert keine Informationen über einzelne potenzielle Kontaktereignisse. Diese Informationen werden über das zugrunde liegende Exposure Notification Framework sicher verarbeitet. Das Framework speichert lediglich sichtbare Rolling Proximity Identifiers (RPI), die sich über einen bestimmten Zeitraum in nächster Nähe befanden. Auch dies wird direkt auf dem Smartphone gespeichert.
18 |
19 | Selbst wenn der zentrale Corona-Warn-App-Server kompromittiert sein sollte, können diese Informationen nicht zu Smartphones zurückverfolgt werden, wenn nicht ohnehin schon Zugriff auf das Smartphone besteht. Auch dann kann die App selbst nicht auf die RPIs zugreifen. Der Zugriff auf die Diagnoseschlüssel ist nur mit Zustimmung der nutzenden Person und nur für einen kurzen Zeitraum möglich. Vor der Verarbeitung der Daten werden die Informationen entfernt, die die Diagnoseschlüssel und die Verbindungsmetadaten miteinander verknüpfen. Metadaten, die eine Identifizierung ermöglichen (z.B. die IP-Adresse), werden entfernt, bevor der Backend-Server Diagnoseschlüssel verarbeitet. Dadurch wird das Risiko weiter verringert, dass ein Angreifer diese Informationen miteinander verknüpfen kann.
20 |
21 | ## Datensparsamkeit
22 |
23 | Wie in der Datenschutz-Grundverordnung (DSGVO) vorgeschrieben, ist die [Datenminimierung](https://www.privacy-regulation.eu/de/5.htm) einer der wichtigsten Grundsätze für die Umsetzung der Corona-Warn-App.
24 |
25 | Es werden nur die Daten gesammelt, die für ein Funktionieren der App nötig sind. Die nutzenden Personen können und müssen in Verbindung mit der App ausschließlich die folgenden Angaben machen:
26 |
27 | * Zustimmung zur Nutzung des Exposure Notification Frameworks
28 | * Scannen eines QR-Codes mit dem Testergebnis
29 | * Eingabe einer TeleTAN bei der Verifizierung eines Testergebnisses per Hotline
30 | * Zustimmung zum Upload der täglichen Diagnoseschlüssel
31 |
32 | Apps können über das Exposure Notification Framework keine Daten zum Standort sammeln:
33 |
34 | * [Section 3.3 Exposure Notification APIs Addendum](https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf)
35 | * [Section 3.c Google COVID-19 Exposure Notifications Service Additional Terms](https://blog.google/documents/72/Exposure_Notifications_Service_Additional_Terms.pdf).
36 |
37 | Die Diagnoseschlüssel werden nur für den epidemiologisch relevanten Zeitraum von 14 Tagen zentral gespeichert und nach den 14 Tagen automatisch entfernt.
38 |
39 | ## Anonymität
40 |
41 | Nutzende Personen bleiben innerhalb des Corona-Warn-App-Systems anonym, solange ihre Temporary Exposure Keys (TEK) auf ihrem Smartphone verbleiben.
42 |
43 | Die Rolling Proximity Identifiers (RPI), die von anderen Smartphones beobachtet werden, können nur mit diesen hochgeladenen TEKs verifiziert werden. Die RPIs werden häufig (alle 10 bis 20 Minuten) auf Basis des Temporary Exposure Keys geändert, der sich wiederum selbst täglich erneuert. Man könnte also z.B. selbst dann nicht feststellen, dass eine nutzende Person jeden Tag im Bus neben derselben Person gesessen hat, wenn die Liste der RPIs für bestimmte Tage einsehbar wäre.
44 |
45 | Theoretisch könnte man einer nutzenden Person folgen, die RPIs der Person sammeln, diese mit bestimmten Informationen verknüpfen, die die Person identifizieren, und dann prüfen, ob die Person jemals als infiziert gemeldet wurde. In der Praxis wäre dieser Angriffsvektor zur Deanonymisierung einer nutzenden Person sehr aufwendig, da der Informationsgewinn verglichen mit dem, was man beim Verfolgen der nutzenden Person ohnehin bereits erfahren hat, sehr gering wäre.
46 |
47 | Sobald TEKs (im Falle eines positive Testergebnisses) auf den Server hochgeladen werden, wird aus Anonymität Pseudonymität. Wenn der hochgeladene Diagnoseschlüssel verfügbar ist, können alle RPIs eines bestimmten Tages einem einzelnen Diagnoseschlüssel zugeordnet werden. Es ist jedoch nicht möglich, diesen Diagnoseschlüssel konkreten nutzenden Personen oder der International Mobile Equipment Identity (IMEI) von deren Smartphone zuzuordnen, ohne Zugang zum geheimen Speicher des Geräts zu haben.
48 |
49 | Nutzende Personen müssen sich nur identifizieren, wenn sie die Erlaubnis erteilen, dass Diagnoseschlüssel per TeleTAN hochgeladen werden dürfen. Diese Identifizierung dient aber nur der Verifizierung und legt außer den Informationen zur Identifizierung, über die die Gesundheitsbehörden ohnehin schon verfügen, keine weiteren Angaben offen. Um noch mehr Anonymität zu erreichen, könnte eine nutzende Person die Hotline mit einem anderen Telefon anrufen als mit dem, das zur Kontakterkennung verwendet wird.
50 |
51 | ## Kein Aufbau von zentralen Bewegungs- und Kontaktprofilen
52 |
53 | Bewegungs- und Kontaktdaten werden nicht zentral gesammelt.
54 |
55 | Weder Standortdaten noch die Rolling Proximity Identifiers, die Bestandteil potenzieller Kontaktereignisse sind, werden jemals zentral gespeichert. Das System weiß zu jedem Zeitpunkt nur, dass ein Diagnoseschlüssel zu einer positiv getesteten Person gehört. Das System weiß weder, wen diese Person getroffen hat, noch wo oder wann es zu dem Kontakt kam.
56 |
57 | Damit die App erkennen kann, dass ein Kontakt stattgefunden hat, ist keine Identifizierung notwendig. Eine Identifizierung ist nur erforderlich, um die Ergebnisse abzurufen und den Diagnoseschlüssel zu übermitteln. Die App verbindet sich im Rahmen dieses Projekts nicht mit irgendwelchen Profilen in sozialen Medien und wird dies auch in Zukunft nicht tun.
58 |
59 | ## Unverkettbarkeit
60 |
61 | Die Corona-Warn-App und das zugrunde liegende Exposure Notification Framework sehen die erforderlichen kryptografischen und technischen Mittel vor, um zu verhindern, dass die Identität der nutzenden Person und die im System sichtbaren Schlüssel und IDs miteinander verkettet werden können.
62 |
63 | Temporary Exposure Keys (TEK) werden täglich neu und ausschließlich auf dem Gerät der nutzenden Person generiert. Über diese TEKs werden alle 10 bis 20 Minuten Rolling Proximity Identifiers (RPI) erzeugt. Solange die TEKs nicht hochgeladen (und damit zu Diagnoseschlüsseln) werden, können RPIs nicht mit einer bestimmten nutzenden Person verknüpft werden. Wenn die Diagnoseschlüssel hochgeladen wurden, können die Diagnoseschlüssel nur mit RPIs verkettet werden, aber nicht direkt mit einer nutzenden Person.
64 |
65 | In einem seltenen Grenzfall könnten Diagnoseschlüssel auf eine Einzelperson zurückführbar sein, und zwar wenn sich diese Person über einen längeren Zeitraum als einzige als positiv getestete Person meldet. Indem Diagnoseschlüssel nur veröffentlicht werden, sobald über eine gewisse Zeit ein bestimmter Schwellenwert erreicht ist, wird dieses Risiko gemindert. Darüber hinaus werden Diagnoseschlüssel nur für die letzten 14 Tage vor dem positiven Testergebnis hochgeladen, sodass eine Verkettung von Kontaktereignissen über den epidemiologisch relevanten Zeitraum hinaus nicht möglich ist.
66 |
67 | ## Unbeobachtbarkeit der Kommunikation
68 |
69 | Die Maßnahmen der Corona-Warn-App, mit denen gewährleistet wird, dass einzelne Nachrichten und Kommunikationsmuster nicht von Angreifern beobachtet werden können, entsprechen dem aktuellen Stand der Technik.
70 |
71 | Etablierte Verschlüsselungsmechanismen wie HTTP over TLS (HTTPS) stellen sicher, dass Nachrichten von außen nicht lesbar sind. Die Metadaten werden entfernt, bevor die Nutzdaten bei der Übermittlung von Diagnoseschlüsseln verarbeitet werden. Somit können diese nicht auf Datenbankebene verkettet werden. Um das Risiko von Man-in-the-Middle-Angriffen weiter zu reduzieren, wird durch statisches Public Key Pinning sichergestellt, dass vertrauliche Kommunikation nur zwischen der Corona-Warn-App und dem Server stattfindet.
72 |
73 | Neben einzelnen Nachrichten, die vom System übertragen werden, müssen auch Kommunikationsmuster abgeschirmt werden. Beispiel: Der Sendeaufruf von Testergebnissen und die Übermittlung von Diagnoseschlüsseln würde normalerweise nur im Fall einer tatsächlichen Infektion stattfinden. In diesem Fall könnte man durch die Beobachtung des Netzwerkverkehrs erkennen, dass eine nutzende Person einen SARS-CoV-2-Test gemacht hat und positiv getestet wurde. Um dies zu verhindern, werden zufällig generierte unechte Meldungen versendet, die von gültigen Meldungen nicht unterschieden werden können. Dadurch sind die Übermittlung von Schlüsseln und der Abruf von Testergebnissen nicht vom Hintergrundrauschen der Systeme unterscheidbar. Dies führt selbst bei beobachtbarem Netzwerkverkehr zu einer plausiblen Abstreitbarkeit.
74 |
--------------------------------------------------------------------------------
/translations/README.de.md:
--------------------------------------------------------------------------------
1 |
2 |
19 |
20 |
21 | # Corona-Warn-App: Dokumentation
22 |
23 | HINWEIS: Die [englische Version](../README.md) der README-Datei ist die maßgebliche Fassung. Bitte haben Sie dafür Verständnis, dass die deutsche Version möglicherweise nicht durchgängig auf dem neuesten Stand ist.
24 |
25 | ## Über dieses Projekt
26 |
27 | Wir entwickeln die offizielle COVID-19-App zur Kontaktfallbenachrichtigung für Deutschland, die sogenannte "Corona-Warn-App". Dieses Projekt hat zum Ziel, eine Anwendung auf der Grundlage einer Technologie mit einem dezentralisierten Ansatz zu entwickeln. Als Grundlage dienen die Protokolle [DP-3T](https://github.com/DP-3T/documents) (Decentralized Privacy-Preserving Proximity Tracing, [Erklär-Comic des Konzeptes](https://github.com/DP-3T/documents/tree/master/public_engagement/cartoon)) und [TCN](https://github.com/TCNCoalition/TCN) sowie die Spezifikationen für [Privacy-Preserving Contact Tracing](https://www.apple.com/covid19/contacttracing/) von Apple und Google. Wie DP-3T und TCN folgen auch die Apps und die Backend-Infrastruktur dem Open-Source-Prinzip - lizenziert unter [Apache 2.0](../LICENSE). Die Apps (für iOS und Android) werden pseudonymisierte Daten von Mobiltelefonen in der Umgebung mit Hilfe von Bluetooth-Technologie sammeln. Die Daten werden lokal auf den einzelnen Geräten gespeichert, um so den Zugriff auf die Daten und die Kontrolle über die Daten durch Behörden oder andere Instanzen zu verhindern. Wir erfüllen die geltenden Datenschutzvorgaben und garantieren höchste IT-Sicherheitsstandards. Auf diese Weise stellen wir uns den Datenschutzbedenken der Bevölkerung und hoffen dadurch, die Nutzung der Anwendung zu steigern.
28 |
29 | ## Wer wir sind
30 |
31 | Die deutsche Regierung hat SAP und die Deutsche Telekom beauftragt, die Corona-Warn-App für Deutschland als Open-Source-Software zu entwickeln. Die Deutsche Telekom stellt das Netzwerk und die Mobiltechnologie zur Verfügung und wird für den sicheren, skalierbaren und stabilen Betrieb des Backends der App sorgen. SAP entwickelt die App, das zugehörige Framework und die zugrundeliegende Plattform. Das bedeutet also, dass Entwicklungsteams sowohl von SAP als auch der Deutschen Telekom zu diesem Projekt beitragen. Open Source bedeutet in diesem Fall, dass wir es allen Interessierten ermöglichen und sie sogar dazu ermutigen, an dem Projekt teilzunehmen und Teil der Entwicklungscommunity zu werden.
32 |
33 | ## Danksagungen
34 |
35 | Wir möchten allen danken, die an diesem wichtigen Projekt gleich von Beginn an beteiligt waren. Wir wären nicht da, wo wir heute sind, wenn wir durch viele Beiträge auf europäischer und nationaler Ebene nicht bereits so große Fortschritte mit [PEPP-PT](https://github.com/pepp-pt/pepp-pt-documentation) erzielt hätten. Wir setzen auf einigen dieser Komponenten auf und sind sehr dankbar dafür, mit wie viel Einsatz sich alle Beteiligten für den Erfolg dieses neuen Ansatzes einsetzen. Darüber hinaus bedanken wir uns bei GitHub für die großartige Unterstützung.
36 |
37 | ## Datenschutz
38 |
39 | In diesem Projekt berücksichtigen wir die Prinzipien der Datenschutzgrundverordnung (DSGVO), um die Privatsphäre aller zu schützen. Wir verarbeiten ausschließlich notwendige Daten und ausschließlich zu dem Zweck, alle wissen zu lassen, ob sie in engem Kontakt mit anderen, bereits infizierten Personen standen, ohne die jeweilige Identität zu offenbaren. Die Einhaltung dieser Grundsätze wird durch verschiedene Schritte sichergestellt, zum Beispiel durch die Implementierung technischer und organisatorischer Maßnahmen, die sich sorgfältig an die hohen Standards der DSGVO halten. Selbstverständlich wird die Anwendung eine verständliche Datenschutzerklärung vorhalten, um so transparent und klar wie möglich zu sein. Da wir die Anwendung als Open-Source-Projekt entwickeln, kann die Community dies überprüfen. Wir begrüßen Ihre Rückmeldungen!
40 |
41 | ## Code of Conduct
42 |
43 | Dieses Projekt hat den [Contributor Covenant](https://www.contributor-covenant.org/) in Version 2.0 als unseren Code of Conduct übernommen. Bitte beachten Sie die Einzelheiten in unserem [CODE_OF_CONDUCT.md](../CODE_OF_CONDUCT.md). Alle Mitwirkenden müssen sich an den Code of Conduct halten.
44 |
45 | ## Arbeitssprache
46 |
47 | Wir entwickeln diese Anwendung für Deutschland. Wir möchten so offen und transparent wie möglich sein, auch für Interessierte in der globalen Entwicklungscommunity, die nicht Deutsch sprechen. Daher wird sämtlicher Inhalt vor allem auf _Englisch_ zur Verfügung gestellt. Wir bitten auch alle Interessierten, Englisch als Arbeitssprache zu verwenden, etwa für Kommentare im Code, für die Dokumentation oder wenn Sie uns Anfragen senden. Die Anwendung selbst, die zugehörige Dokumentation und sämtlicher Inhalt für diejenigen, welche die Anwendungen nutzen, werden selbstverständlich auf Deutsch (und möglicherweise auch andere Sprachen) zur Verfügung gestellt. Wir werden auch versuchen, Entwicklungsdokumentation auf Deutsch zur Verfügung zu stellen, aber wir bitten um Verständnis dafür, dass es nur mit Englisch als der _Lingua Franca_ der globalen Entwicklungscommunity möglich sein wird, bei der Entwicklung dieser Anwendung mit höchstmöglicher Effizienz zu arbeiten.
48 |
49 | ## Unsere Dokumentation
50 |
51 | Dieses Repository enthält die Entwicklungsdokumentation und zugehörige Inhalte.
52 |
53 | ### Projektumfang (Scoping-Dokument)
54 |
55 | Der Projektumfang wurde gemeinsam von der Deutschen Telekom AG sowie der SAP SE als Auftragnehmer und der deutschen Bundesregierung sowie dem Robert Koch-Institut als Auftraggeber festgelegt. Der Projektumfang kann sich im Laufe der Zeit ändern, wenn neue Anforderungen einbezogen werden müssen oder wenn sich bestehende Anforderungen ändern. Wir begrüßen Rückmeldungen zu allen Bestandteilen dieses Dokuments zum Projektumfang. Allerdings müssen zusätzliche Funktionen oder andere inhaltliche Änderungen, die über das Beheben von Grammatik- oder Schreibfehlern hinausgehen, zwischen den Verantwortlichen abgestimmt werden, bevor sie in das Dokument aufgenommen werden können. Vielen Dank für Ihr Verständnis.
56 |
57 | - [Corona-Warn-App - Scoping-Dokument](scoping_document.de.md)
58 |
59 | ### Technische Dokumentation
60 |
61 | Die technischen Dokumente sind für ein technisches Publikum bestimmt und repräsentieren den neuesten Stand der Architektur. Die Lösungsarchitektur und die Konzepte können sich im Laufe der Zeit ändern, da sich externe Abhängigkeiten (z. B. das von Apple/Google bereitgestellte Framework) noch immer ändern und neue Anforderungen aufgenommen werden müssen oder sich bestehende ändern. Wir freuen uns über Rückmeldungen zu allen Elementen dieser technischen Dokumente.
62 |
63 | - [Prüfsteine für die Beurteilung von "Contact Tracing"-Apps](pruefsteine.de.md)
64 | - [Wie ermittelt die Corona-Warn-App ein erhöhtes Risiko?](cwa-risk-assessment.de.md) (nicht mehr aktuell). Der englischsprachige Dokumentenabschnitt [Solution Architecture > Mobile Application](../solution_architecture.md#mobile-applications) enthält eine aktuelle Beschreibung.
65 | - [Corona-Warn-App Datenschutz-Folgeabschätzung/DSFA (PDF)](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung.pdf), [DSFA Anlage 1a](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1a.pdf), [DSFA Anlage 1b](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1b.pdf), [DSFA Anlage 1c](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1c.pdf), [DSFA Anlage 2](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage2.pdf), [DSFA Anlage 3](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage3.pdf), [DSFA Anlage 4](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage4.pdf), [DSFA Anlage 5](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage5.pdf), [DSFA Anlage 6](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage6.pdf), [DSFA Anlage 7](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage7.pdf) und [DSFA Anlage 8](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage8.pdf)
66 |
67 | ## Lizenzierung
68 |
69 | Copyright (c) 2020-2023 Deutsche Telekom AG und SAP SE oder ein SAP-Konzernunternehmen.
70 |
71 | Lizenziert unter **Apache-Lizenz, Version 2.0** (die "Lizenz"). Sie dürfen diese Datei ausschließlich im Einklang mit der Lizenz verwenden.
72 |
73 | Eine Kopie der Lizenz erhalten Sie unter https://www.apache.org/licenses/LICENSE-2.0.
74 |
75 | Sofern nicht durch anwendbares Recht gefordert oder schriftlich vereinbart, wird jede unter der Lizenz bereitgestellte Software „OHNE MÄNGELGEWÄHR“ UND OHNE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GARANTIE JEGLICHER ART bereitgestellt. Die genauen Angaben zu Genehmigungen und Einschränkungen unter der Lizenz finden Sie in der [LIZENZ](../LICENSE).
76 |
77 |
78 |
79 | Das "Corona-Warn-App"-Logo ist eine registrierte Wort-/Bildmarke des Presse- und Informationsamts der Bundesregierung. Weitere Informationen finden Sie unter [bundesregierung.de](https://www.bundesregierung.de/breg-de/bundesregierung/bundespresseamt).
80 |
81 |
82 | ## Informationen zur Teilnahme
83 |
84 | Weitere Informationen z.B. darüber, wie Sie das Projekt unterstützen können, unser Team aufgebaut ist oder unsere Projektstruktur aussieht, finden Sie hier: [CONTRIBUTING.md](../CONTRIBUTING.md).
85 |
--------------------------------------------------------------------------------
/event_registration.md:
--------------------------------------------------------------------------------
1 | # Event Registration - Summary
2 |
3 | Presence Tracing - in the Corona-Warn-App (CWA) also referred to as _Event Registration_ - aims at notifying people of a potential SARS-CoV-2 exposure if they have been to the same venue at a similar time as a positively tested individual. It addresses the potential of airborne transmission in spaces with poor ventilation despite maintaining physical distance. As such, it complements BLE-based proximity tracing with the Exposure Notification Framework.
4 |
5 | CWA proposes a fully-automated decentral solution for Presence Tracing which can work independent of local health authorities and the collaboration of the host of a venue. It integrates into the existing verification processes of CWA to issue warnings. The solution prioritizes the speed of issuing warnings over their accuracy. A higher degree of accuracy would require manual assessment by local health authorities and the respective resources to do so and is currently not in scope. The solution also protects the privacy of both venues and users, as details about a venue such as description or address are not shared with the CWA infrastructure.
6 |
7 | In summary, the proposed solution allows a _host_ to create a venue through CWA. All necessary data about the venue is encoded in a QR code which can be presented on a mobile device or printed out, for example to be posted at the entrance of the venue. An _attendee_ can check in to the venue by scanning the QR code. Check-ins are stored locally on the mobile device and deleted automatically after two weeks.
8 |
9 | When an attendee tests positive for SARS-CoV-2, they can upload their check-ins along with their Diagnosis Keys to the CWA Server. The CWA Server publishes the relevant check-ins on CDN as _warnings_. Clients regularly download these warnings and match them against the local check-ins on the mobile device. If there is a match and the time an attendee spent at a venue overlaps with a warning for a sufficiently long time, the attendee receives a warning in CWA similar to how warnings are issued for BLE-based exposures.
10 |
11 | 
12 |
13 | ## Threats
14 |
15 | Several security and privacy threats have been identified for the proposed solution. This includes common security threats such as distributed denial of service attacks or code injection, which also exist for other CWA components and are mitigated accordingly. It also includes threats specific to Presence Tracing, such as profiling venues and users or issuing false warnings for specific venues. These threats are described below along with the corresponding mitigation.
16 |
17 | ### Profiling of Venues
18 |
19 | The proposed solution publishes warnings on CDN. A warning consists of the hashed ID of a venue and a time interval. An adversary can collect these warnings and aggregate them to compile a list of venues with the most warnings (colloquially referred to as _most infectious venues_) or a list of venues with their most recent warning.
20 |
21 | This information is easy to collect, as warnings are publicly accessible and do not even require to make modifications to the CWA client.
22 |
23 | The value of this information increases significantly once an adversary can link the ID of a venue with the data included in the QR code such as the name or the address of the venue, or with metadata from other services, such as coordinates of the venue.
24 |
25 | An adversary can collect this information for a single venue by scanning the QR code and extracting and storing the data outside of CWA. Collecting this information at scale requires coordinated effort by many individuals.
26 |
27 | Note that CWA itself does not store this data on the server or anywhere else and cannot do profiling of venues.
28 |
29 | To mitigate the risk, CWA encourages owners to regularly generate new QR codes for their venues. The more frequent QR codes are updated, the more difficult it is to keep a central database with venue data up-to-date. A new QR code should only be generated when no visitor is at the event or location, because visitors can only warn each other with the same QR code.
30 |
31 | However, we acknowledge that the proposed solution does not prevent this attack with technical means.
32 |
33 | ### Profiling of Users
34 |
35 | The proposed solution publishes warnings on CDN in packages on an hourly basis. A package includes multiple warnings. A warning consists of the hashed ID of a venue and a time interval. All warnings that were created from the check-ins of a single user are included in one package. A package can include warnings of multiple users.
36 |
37 | An adversary can analyze the check-ins of a single package and try to build a profile of the users whose check-ins are included. This reveals limited information if the IDs of the venues cannot be linked to an actual venue (cf. [Profiling of Venues](#profiling-of-venues)), but can reveal significant information about the user the more venue IDs can be identified.
38 |
39 | To mitigate the risk, CWA generates fake check-ins for each submission. These fake check-ins are generated upon submission of genuine check-ins so that even CWA cannot distinguish them.
40 |
41 | However, we acknowledge that this does not prevent the attack if there is a central database of all venue IDs and venue metadata.
42 |
43 | ### Targeting Specific Venues
44 |
45 | The proposed solution turns check-ins of the user into warnings and cannot verify if the user has actually visited the respective venue of a check-in.
46 |
47 | An adversary can target specific venues by obtaining the respective QR code and pretending a check-in. If the adversary also obtains the authorization to submit the check-ins to the CWA Server, false warnings would be issued for these venues.
48 |
49 | The difficulty of this attack is dominated by the difficulty of obtaining authorization to submit check-ins. This is currently only possible with a confirmed positive test for SARS-CoV-2 or by obtaining a TeleTAN from the hotline. While a confirmed positive test is difficult obtain without putting oneself at risk, a valid TeleTAN can be obtained for example by Social Engineering.
50 |
51 | To mitigate the risk, CWA only allows a certain number of check-ins per day. This prevents to scale such an attack by a single adversary across a multitude of venues.
52 |
53 | However, we acknowledge that this does not prevent to execute this attack for a small number of venues.
54 |
55 | ## QR Code Structure
56 |
57 | The QR code of a venue contains all required attributes for Presence Tracing, so that no server communication is necessary when an attendee checks in to a venue.
58 |
59 | The data structure is described by the Protocol Buffer message `QRCodePayload`:
60 |
61 | ```protobuf
62 | message QRCodePayload {
63 | uint32 version = 1;
64 | TraceLocation locationData = 2;
65 | CrowdNotifierData crowdNotifierData = 3;
66 | // byte sequence of CWALocationData
67 | bytes vendorData = 4;
68 | }
69 |
70 | message TraceLocation {
71 | uint32 version = 1;
72 | // max. 100 characters
73 | string description = 2;
74 | // max. 100 characters
75 | string address = 3;
76 |
77 | // UNIX timestamp (in seconds)
78 | uint64 startTimestamp = 5;
79 | // UNIX timestamp (in seconds)
80 | uint64 endTimestamp = 6;
81 | }
82 |
83 | message CrowdNotifierData {
84 | uint32 version = 1;
85 | bytes publicKey = 2;
86 | bytes cryptographicSeed = 3;
87 | uint32 type = 4; // exact semantic tbd
88 | }
89 |
90 | enum TraceLocationType {
91 | LOCATION_TYPE_UNSPECIFIED = 0;
92 | LOCATION_TYPE_PERMANENT_OTHER = 1;
93 | LOCATION_TYPE_TEMPORARY_OTHER = 2;
94 |
95 | LOCATION_TYPE_PERMANENT_RETAIL = 3;
96 | LOCATION_TYPE_PERMANENT_FOOD_SERVICE = 4;
97 | LOCATION_TYPE_PERMANENT_CRAFT = 5;
98 | LOCATION_TYPE_PERMANENT_WORKPLACE = 6;
99 | LOCATION_TYPE_PERMANENT_EDUCATIONAL_INSTITUTION = 7;
100 | LOCATION_TYPE_PERMANENT_PUBLIC_BUILDING = 8;
101 |
102 | LOCATION_TYPE_TEMPORARY_CULTURAL_EVENT = 9;
103 | LOCATION_TYPE_TEMPORARY_CLUB_ACTIVITY = 10;
104 | LOCATION_TYPE_TEMPORARY_PRIVATE_EVENT = 11;
105 | LOCATION_TYPE_TEMPORARY_WORSHIP_SERVICE = 12;
106 |
107 | }
108 |
109 | message CWALocationData {
110 | uint32 version = 1;
111 | TraceLocationType type = 2;
112 | uint32 defaultCheckInLengthInMinutes = 3;
113 | }
114 | ```
115 |
116 | The ID of a venue is derived as the SHA-256 hash of the concatenated byte representation of the string `CWA-GUID` and the byte representation of the Protocol Buffer message `QRCodePayload`. The `cryptographicSeed` adds sufficient entropy so that any modifications to the QR code result in a unique ID.
117 |
118 | A `QRCodePayload` is base64url-encoded and included in a URL. The URL is the content of the QR code and has the following structure:
119 |
120 | ```text
121 | https://e.coronawarn.app?v=1#
122 |
123 | # example:
124 | CWA Germany:
125 | https://e.coronawarn.app?v=1#Y3dh...
126 | NotifyMe CH:
127 | https://qr.notify-me.ch?v=2#bm90aWZ5bWU
128 | CLEA FR:
129 | https://tac.gouv.fr?v=1#Y2xlYQ
130 |
131 | ```
132 |
133 | ```text
134 |
135 | #Example:
136 | https://e.coronawarn.app?v=1#CAESEwgBEgdGcmlzZXVyGgZCZXJsaW4adggBEmCDAszMTXne1DAA5_YxmhRdd_NZN2VKl9L32Jl9-ZybE4b2eNIrhFOKYU4XAOHq3RPLDxdHTW6ANiO24rCOO4rj06HzcVZy3pel58-L1KSPG-_PneL2BoyZQRz3qlu2hoAaEATXwzyyIshzBHREtsdmc6kiBggBEAUYeA
137 |
138 | version: 1
139 | locationData:
140 | version: 1
141 | description: Friseur
142 | address: Berlin
143 | crowdNotifierData:
144 | version: 1
145 | publicKey: gwLMzE153tQwAOf2MZoUXXfzWTdlSpfS99iZffmcmxOG9njSK4RTimFOFwDh6t0Tyw8XR01ugDYjtuKwjjuK49Oh83FWct6XpefPi9Skjxvvz53i9gaMmUEc96pbtoaA
146 | cryptographicSeed: RANDOM16Byte as base64
147 | vendorData: CAEQBRh4
148 |
149 |
150 | Vendor Data Example:
151 | version: 1
152 | type: 5
153 | defaultCheckInLengthInMinutes: 120
154 |
155 | ```
156 |
157 | ### QR Code Compatibility with Other Contract Tracing Apps in Germany
158 |
159 | Other contact tracing apps in Germany that leverage QR codes for Presence Tracing can integrate with CWA by creating QR codes according to the following pattern:
160 |
161 | ```text
162 | /#[VENDOR_ADDITIONAL_DATA]/CWA1/
163 | ```
164 |
165 | | Parameter | Description |
166 | |---|---|
167 | | `` | The URL associated with the respective contact tracing apps, with or without a partial path. |
168 | | `` | Any vendor-specific data such as the venue id in the vendor's system. This data may be passed to the vendor-specific app upon interaction by the user if a deeper integration is required. |
169 | | `[VENDOR_ADDITIONAL_DATA]` | Additional vendor-specific data (optional). |
170 | | `` | A representation of the Protocol Buffer message `QRCodePayload` encoded in base64url. |
171 |
172 | **Note:** QR codes that are generated by other contact tracing apps must be allowlisted individually per app (based on the hostname in the QR code) before they can be scanned and are accepted by CWA. Such contact tracing apps must ensure that they do not process or store any information from the CWA part of the QR code.
173 |
174 | Representatives of other contact tracing apps may request allowlisting from the Robert Koch Institute through e-mail CoronaWarnApp@rki.de.
175 |
176 | Examples:
177 |
178 | ```text
179 | # without optional data
180 | https://presence-tracing.app/386d0384-8aaa-41b6-93c2-d3399894d0ee#/CWA1/CiRmY2E...
181 | URL: https://presence-tracing.app
182 | VENDOR_DATA: 386d0384-8aaa-41b6-93c2-d3399894d0ee
183 | VENDOR_ADDITIONAL_DATA: ∅
184 | ENCODED_PAYLOAD: CiRmY2E...
185 |
186 | # with optional data
187 | https://check-in.pt.app/386d0384-8aaa-41b6-93c2-d3399894d0ee#42/CWA1/CiRmY2E...
188 | URL: https://check-in.pt.app
189 | VENDOR_DATA: 386d0384-8aaa-41b6-93c2-d3399894d0ee
190 | VENDOR_ADDITIONAL_DATA: 42
191 | ENCODED_PAYLOAD: CiRmY2E...
192 | ```
193 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 |
2 | Apache License
3 | Version 2.0, January 2004
4 | http://www.apache.org/licenses/
5 |
6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
7 |
8 | 1. Definitions.
9 |
10 | "License" shall mean the terms and conditions for use, reproduction,
11 | and distribution as defined by Sections 1 through 9 of this document.
12 |
13 | "Licensor" shall mean the copyright owner or entity authorized by
14 | the copyright owner that is granting the License.
15 |
16 | "Legal Entity" shall mean the union of the acting entity and all
17 | other entities that control, are controlled by, or are under common
18 | control with that entity. For the purposes of this definition,
19 | "control" means (i) the power, direct or indirect, to cause the
20 | direction or management of such entity, whether by contract or
21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the
22 | outstanding shares, or (iii) beneficial ownership of such entity.
23 |
24 | "You" (or "Your") shall mean an individual or Legal Entity
25 | exercising permissions granted by this License.
26 |
27 | "Source" form shall mean the preferred form for making modifications,
28 | including but not limited to software source code, documentation
29 | source, and configuration files.
30 |
31 | "Object" form shall mean any form resulting from mechanical
32 | transformation or translation of a Source form, including but
33 | not limited to compiled object code, generated documentation,
34 | and conversions to other media types.
35 |
36 | "Work" shall mean the work of authorship, whether in Source or
37 | Object form, made available under the License, as indicated by a
38 | copyright notice that is included in or attached to the work
39 | (an example is provided in the Appendix below).
40 |
41 | "Derivative Works" shall mean any work, whether in Source or Object
42 | form, that is based on (or derived from) the Work and for which the
43 | editorial revisions, annotations, elaborations, or other modifications
44 | represent, as a whole, an original work of authorship. For the purposes
45 | of this License, Derivative Works shall not include works that remain
46 | separable from, or merely link (or bind by name) to the interfaces of,
47 | the Work and Derivative Works thereof.
48 |
49 | "Contribution" shall mean any work of authorship, including
50 | the original version of the Work and any modifications or additions
51 | to that Work or Derivative Works thereof, that is intentionally
52 | submitted to Licensor for inclusion in the Work by the copyright owner
53 | or by an individual or Legal Entity authorized to submit on behalf of
54 | the copyright owner. For the purposes of this definition, "submitted"
55 | means any form of electronic, verbal, or written communication sent
56 | to the Licensor or its representatives, including but not limited to
57 | communication on electronic mailing lists, source code control systems,
58 | and issue tracking systems that are managed by, or on behalf of, the
59 | Licensor for the purpose of discussing and improving the Work, but
60 | excluding communication that is conspicuously marked or otherwise
61 | designated in writing by the copyright owner as "Not a Contribution."
62 |
63 | "Contributor" shall mean Licensor and any individual or Legal Entity
64 | on behalf of whom a Contribution has been received by Licensor and
65 | subsequently incorporated within the Work.
66 |
67 | 2. Grant of Copyright License. Subject to the terms and conditions of
68 | this License, each Contributor hereby grants to You a perpetual,
69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
70 | copyright license to reproduce, prepare Derivative Works of,
71 | publicly display, publicly perform, sublicense, and distribute the
72 | Work and such Derivative Works in Source or Object form.
73 |
74 | 3. Grant of Patent License. Subject to the terms and conditions of
75 | this License, each Contributor hereby grants to You a perpetual,
76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
77 | (except as stated in this section) patent license to make, have made,
78 | use, offer to sell, sell, import, and otherwise transfer the Work,
79 | where such license applies only to those patent claims licensable
80 | by such Contributor that are necessarily infringed by their
81 | Contribution(s) alone or by combination of their Contribution(s)
82 | with the Work to which such Contribution(s) was submitted. If You
83 | institute patent litigation against any entity (including a
84 | cross-claim or counterclaim in a lawsuit) alleging that the Work
85 | or a Contribution incorporated within the Work constitutes direct
86 | or contributory patent infringement, then any patent licenses
87 | granted to You under this License for that Work shall terminate
88 | as of the date such litigation is filed.
89 |
90 | 4. Redistribution. You may reproduce and distribute copies of the
91 | Work or Derivative Works thereof in any medium, with or without
92 | modifications, and in Source or Object form, provided that You
93 | meet the following conditions:
94 |
95 | (a) You must give any other recipients of the Work or
96 | Derivative Works a copy of this License; and
97 |
98 | (b) You must cause any modified files to carry prominent notices
99 | stating that You changed the files; and
100 |
101 | (c) You must retain, in the Source form of any Derivative Works
102 | that You distribute, all copyright, patent, trademark, and
103 | attribution notices from the Source form of the Work,
104 | excluding those notices that do not pertain to any part of
105 | the Derivative Works; and
106 |
107 | (d) If the Work includes a "NOTICE" text file as part of its
108 | distribution, then any Derivative Works that You distribute must
109 | include a readable copy of the attribution notices contained
110 | within such NOTICE file, excluding those notices that do not
111 | pertain to any part of the Derivative Works, in at least one
112 | of the following places: within a NOTICE text file distributed
113 | as part of the Derivative Works; within the Source form or
114 | documentation, if provided along with the Derivative Works; or,
115 | within a display generated by the Derivative Works, if and
116 | wherever such third-party notices normally appear. The contents
117 | of the NOTICE file are for informational purposes only and
118 | do not modify the License. You may add Your own attribution
119 | notices within Derivative Works that You distribute, alongside
120 | or as an addendum to the NOTICE text from the Work, provided
121 | that such additional attribution notices cannot be construed
122 | as modifying the License.
123 |
124 | You may add Your own copyright statement to Your modifications and
125 | may provide additional or different license terms and conditions
126 | for use, reproduction, or distribution of Your modifications, or
127 | for any such Derivative Works as a whole, provided Your use,
128 | reproduction, and distribution of the Work otherwise complies with
129 | the conditions stated in this License.
130 |
131 | 5. Submission of Contributions. Unless You explicitly state otherwise,
132 | any Contribution intentionally submitted for inclusion in the Work
133 | by You to the Licensor shall be under the terms and conditions of
134 | this License, without any additional terms or conditions.
135 | Notwithstanding the above, nothing herein shall supersede or modify
136 | the terms of any separate license agreement you may have executed
137 | with Licensor regarding such Contributions.
138 |
139 | 6. Trademarks. This License does not grant permission to use the trade
140 | names, trademarks, service marks, or product names of the Licensor,
141 | except as required for reasonable and customary use in describing the
142 | origin of the Work and reproducing the content of the NOTICE file.
143 |
144 | 7. Disclaimer of Warranty. Unless required by applicable law or
145 | agreed to in writing, Licensor provides the Work (and each
146 | Contributor provides its Contributions) on an "AS IS" BASIS,
147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
148 | implied, including, without limitation, any warranties or conditions
149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
150 | PARTICULAR PURPOSE. You are solely responsible for determining the
151 | appropriateness of using or redistributing the Work and assume any
152 | risks associated with Your exercise of permissions under this License.
153 |
154 | 8. Limitation of Liability. In no event and under no legal theory,
155 | whether in tort (including negligence), contract, or otherwise,
156 | unless required by applicable law (such as deliberate and grossly
157 | negligent acts) or agreed to in writing, shall any Contributor be
158 | liable to You for damages, including any direct, indirect, special,
159 | incidental, or consequential damages of any character arising as a
160 | result of this License or out of the use or inability to use the
161 | Work (including but not limited to damages for loss of goodwill,
162 | work stoppage, computer failure or malfunction, or any and all
163 | other commercial damages or losses), even if such Contributor
164 | has been advised of the possibility of such damages.
165 |
166 | 9. Accepting Warranty or Additional Liability. While redistributing
167 | the Work or Derivative Works thereof, You may choose to offer,
168 | and charge a fee for, acceptance of support, warranty, indemnity,
169 | or other liability obligations and/or rights consistent with this
170 | License. However, in accepting such obligations, You may act only
171 | on Your own behalf and on Your sole responsibility, not on behalf
172 | of any other Contributor, and only if You agree to indemnify,
173 | defend, and hold each Contributor harmless for any liability
174 | incurred by, or claims asserted against, such Contributor by reason
175 | of your accepting any such warranty or additional liability.
176 |
177 | END OF TERMS AND CONDITIONS
178 |
179 | APPENDIX: How to apply the Apache License to your work.
180 |
181 | To apply the Apache License to your work, attach the following
182 | boilerplate notice, with the fields enclosed by brackets "[]"
183 | replaced with your own identifying information. (Don't include
184 | the brackets!) The text should be enclosed in the appropriate
185 | comment syntax for the file format. We also recommend that a
186 | file or class name and description of purpose be included on the
187 | same "printed page" as the copyright notice for easier
188 | identification within third-party archives.
189 |
190 | Copyright [yyyy] [name of copyright owner]
191 |
192 | Licensed under the Apache License, Version 2.0 (the "License");
193 | you may not use this file except in compliance with the License.
194 | You may obtain a copy of the License at
195 |
196 | http://www.apache.org/licenses/LICENSE-2.0
197 |
198 | Unless required by applicable law or agreed to in writing, software
199 | distributed under the License is distributed on an "AS IS" BASIS,
200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
201 | See the License for the specific language governing permissions and
202 | limitations under the License.
203 |
--------------------------------------------------------------------------------
/images/solution_architecture/exposure_windows.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
--------------------------------------------------------------------------------
/images/solution_architecture/upload_schedule.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
--------------------------------------------------------------------------------
/cwa-risk-assessment.md:
--------------------------------------------------------------------------------
1 | # How does the Corona-Warn-App identify an increased risk?
2 |
3 | Please note that this document is _not_ up-to-date anymore. It reflects the original risk assessment for the Corona-Warn-App before version 1.5 (released in October 2020) and is kept here for historical reference only. An up-to-date description of risk assessment and risk calculation in the Corona-Warn-App is available in the [Solution Architecture > Mobile Application](./solution_architecture.md#mobile-applications) document section.
4 |
5 |
6 |
7 | ## IMPORTANT! - DEPRECATION NOTICE
8 |
9 | **The content of this document is not up-to-date and is no longer maintained.**
10 |
11 |
12 |
13 | ---
14 |
15 | ## Prerequisites
16 |
17 | People who use the Corona-Warn-App (CWA) and are tested positive for the SARS-CoV-2 coronavirus can allow their CWA to upload the random device keys (*temporary exposure keys*) that have been generated by their smartphone's operating system in recent days to the Corona-Warn-App server as *diagnosis keys* and release them there.
18 | These diagnosis keys are the basis for risk identification for all other CWA users.
19 |
20 | A user who has tested positive for coronavirus uploads up to 15 diagnosis keys: one for each of the up to 14 days before the upload, as well as (still to be implemented) one for the current day, which is uploaded the next day.
21 | The latter is necessary because diagnosis keys can only be uploaded for past days in order to prevent abuse of diagnosis keys that are still active.
22 |
23 | Diagnosis keys do not give any indication as to the identity of a person who has tested positive, but a diagnosis key from a certain day can be matched with the *rolling proximity identifiers* that a user's smartphone has transmitted via Bluetooth throughout a given day and were received and recorded by other smartphones nearby.
24 | Each diagnosis key is appended with a value that indicates the *transmission risk level* that likely existed for the person who has tested positive on the day that the diagnosis key belongs to.
25 | This transmission risk is [estimated in a mathematical procedure](transmission_risk.pdf), which is based on empirical evidence and takes the latest scientific findings into account.
26 | Every diagnosis key expires after 14 days. Therefore, only the diagnosis keys from the last 14 days are available.
27 |
28 | ## Procedure
29 |
30 | Daily, all active Corona-Warn-Apps download the diagnosis keys released on the Corona-Warn-App server and pass them on to the smartphone's operating system in batches through an interface.
31 | The operating system checks whether any of the rolling proximity identifiers that it has received and recorded over the past 14 days match any of the diagnosis keys.
32 | If there is a match, this indicates that the user's smartphone encountered the smartphone of a person who has uploaded the diagnosis key, on the day to which the diagnosis key belongs.
33 |
34 | > Note: Days in the context of the Corona-Warn-App and thus in this document are calendar days according to UTC (Coordinated Universal Time). They change at 1 am Central European Time and 2 am Central European Summer Time, respectively.
35 |
36 | In the next step, the operating system analyzes all the matching rolling proximity identifiers for each diagnosis key, to estimate how long the encounter lasted in total on the day in question and how close both smartphones were to each other on average during the encounter.
37 | The distance is calculated from the measured reduction in strength of the Bluetooth signal, which is specified in dB (decibel).
38 | Under perfect circumstances, i.e. without any obstacle in the signal pathway (see also section "Consequences and Constraints"), each dB value is associated with a particular distance.
39 | All encounters for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (>73 dB attenuation) apart on average (regardless of how long the encounter lasted) are discarded as negligible risk.
40 |
41 | > Note: In the following, the total of all encounters that belong to a particular diagnosis key, that is, all encounters over a given day between the same two smartphones, is referred to as the "encounter set".
42 |
43 | For the remaining encounters that have not been discarded, a *total risk score* is calculated for each encounter set, by multiplying the transmission risk score described above by the *days since last exposure* value, which is derived from the day count since the most recent encounter to the current day.
44 |
45 | All encounter sets whose total risk score exceeds a certain threshold (the *minimum risk score*) are considered to be risk exposures.
46 | The other encounter sets are discarded as negligible risk, like the sets that were previously discarded for being too short and/or too distant.
47 |
48 | At the same time, all remaining risk exposures are summarised to determine the total time of exposure that took place within a very close range below 1.5 meters (<55 dB attenuation) and the total time of exposure that took place in a close range between 1.5 and 3 meters (55 to 63 dB attenuation).
49 | Time spent in a distance greater than 3 meters apart will not be considered.
50 |
51 | The above calculated total time of all exposures of the latest 14 days is then adjusted using the *maximum risk score* of the exposure with the highest risk as follows: the time remains unchanged if this risk is estimated as being "average" (for risk exposures), it is extended to up to one and a half times if the risk is estimated as being "above average", and it is reduced accordingly if the risk is estimated to be "below average".
52 | As a result, an exposure time of 10 minutes can be extended to more than 15 minutes and an exposure time of 25 minutes can be reduced to 15 minutes.
53 |
54 | ## Consequences and Constraints
55 |
56 | In the end, a CWA user is notified of an increased risk whenever the risk exposure time calculated as described above amounts to 15 minutes or longer.
57 | This notification takes place in the CWA and, at the same time, provides recommendations as to how the user should proceed.
58 |
59 | When assessing the times and distances calculated by the CWA, it is important to consider that it is not possible to measure these two parameters precisely.
60 | The individually measured times can deviate from the actual encounter time by 5 minutes plus or minus and the calculated distances are approximate values under ideal conditions, that is, without any impediments between the two smartphones.
61 | Even minor impediments, such as a person between the two smartphones or a signal-impeding smartphone case, can cause the distance to appear to be twice as large as it actually is.
62 |
63 | Due to privacy considerations, the properties described above can currently only be queried for the total set of all risk exposures at the interface to the operating system, but not for individual risk exposures or exposure by day.
64 | As long as the number of new infections remains relatively low, this should not make much of a difference, because it is likely that only very few CWA users will have been exposed to multiple persons who have tested positive within the time frame until they are notified.
65 |
66 | ## An Example
67 |
68 | Anton and Aisha are each notified on the 20th of the month that according to their test results, they have contracted COVID-19.
69 | That same day, Anton allows his CWA to notify other CWA users with whom he has had risk exposures.
70 | The CWA has been running on his smartphone continuously for the past week.
71 | The CWA now uploads his temporary exposure keys from the latest 7 days to the CWA server as diagnosis keys (no further keys are available, because Anton has only been using the CWA for 8 days and the current exposure keys cannot be uploaded yet).
72 | They are assigned the transmission risk levels VI (for the previous day), three times VIII (for the 16th to the 18th), V, III, and I (in descending order for the other past days, the 13th to the 15th).
73 |
74 | |||||||||
75 | |-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
76 | |Transmission risk level|VI|VIII|VIII|VIII|V|III|I|
77 | |Days until upload consent granted|1|2|3|4|5|6|7|
78 | |Generation date of the key|19th|18th|17th|16th|15th|14th|13th|
79 |
80 | Table 1: Transmission risk level for Anton's 7 shared diagnosis keys, based on the interval from the day upload consent is granted (20th)
81 |
82 | Aisha hesitates for a day and does not grant consent until the 21st of the month.
83 | Since she activated her CWA several weeks ago and has been running it in the background ever since, her temporary exposure keys from the latest 14 days are available to upload.
84 | Her diagnosis keys are also assigned the transmission risk level VI, three times VIII, V, III, and I in descending order for the previous seven days, but starting with the 20th, and thus offset one day compared to Anton.
85 | (The CWA does not know that both people were informed of their test results on the same day. In the current version, only the date on which consent to upload is granted is available to determine the day-specific transmission risk levels.)
86 | The 7 older days, the period from the 7th to the 13th of the month, are each assigned the transmission risk level I.
87 |
88 | ||||||||||||||||
89 | |-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
90 | |Transmission risk level|VI|VIII|VIII|VIII|V|III|I|I|I|I|I|I|I|I|
91 | |Days until upload consent granted|1|2|3|4|5|6|7|8|9|10|11|12|13|14|
92 | |Generation date of the key|20th|19th|18th|17th|16th|15th|14th|13th|12th|11th|10th|9th|8th|7th|
93 |
94 | Table 2: Transmission risk level for Aisha's 14 shared diagnosis keys, based on the interval from the day upload consent is granted (21st)
95 |
96 | Anton and Aisha regularly travel to work together by bus.
97 | Betty takes the same route and occasionally rides the same bus.
98 | All three of them use their smartphones during the journey, which means there are no impediments to the Bluetooth signals.
99 | Betty met Anton and Aisha on the 9th and the 16th, for 10 minutes each in the morning and in the evening.
100 | Anton sat one meter away from Betty, while Aisha sat two meters away.
101 |
102 | When Betty’s CWA retrieves Anton’s diagnosis keys on the 21st and passes them on to her smartphone's operating system's interface, an encounter set is recognized for the 16th.
103 | (Anton's CWA did not upload a diagnosis key for the 9th.)
104 | This encounter set lasted a total of 20 minutes and the smartphones were an average of one meter apart.
105 | This results in values of 1 for both duration and attenuation (also see "Exposure Configuration" in the section "Current Configuration").
106 |
107 | This ensures that this encounter set is not discarded.
108 | The value of the parameter for the delay risk (21 - 16 = 5 days) is configured to be 5 throughout and the value for the transmission risk is taken directly from the transmission risk level, which means it is 8.
109 | The total risk level is therefore calculated as 1 x 1 x 5 x 8 = 40, which incidentally is the highest value that can be reached with the current configuration.
110 | The threshold of 11 is exceeded, which means the encounter set counts as a risk exposure.
111 |
112 | | | | | | | | | | |
113 | |-|-|-|-|-|-|-|-|-|
114 | |Days since last exposure| ≥14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | 6-7d (5) | **4-5d (5)** | 2-3d (5) | 0-1d (5) |
115 | |Attenuation| >73dB (0) | >63-≤73dB (1) | >51-≤63dB (1) | **>33-≤51dB (1)** | >27-≤33dB (1) | >15-≤27dB (1) | >10-≤15dB (1) | ≤10dB (1) |
116 | |Duration| 0min (0) | >0-≤5min (0) | >5-≤10min (0) | >10-≤15min (1) | **>15-≤20min (1)** | >20-≤25min (1) | >25-≤30min (1) | >30min (1) |
117 | |Transmission risk| I (1) | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | **VIII (8)** |
118 |
119 | Table 3: Parameter values for Betty's encounter set with Anton on the 16th (relevant values in bold)
120 |
121 | Since this risk exposure is the only risk exposure known to Betty’s CWA, it is the only one taken into account in the summary evaluation of her times spent in the distance ranges up to 1.5 meters and up to 3 meters.
122 | Betty spent 20 minutes in the distance range below 1.5 meters, which are counted fully.
123 |
124 | Even if these 20 minutes are adjusted by the risk exposure with the highest risk, only this one risk exposure is taken into account, with its exposure risk of 40.
125 | The multiplication of these 20 minutes by 40/25 (25 is the currently configured value for "average risk" exposures; also see the risk score normalization divisor in "Configuration of Attenuation and Duration" in the section "Current Configuration") equals 32 minutes.
126 | Since the CWA sends notifications of increased risk starting with 15 minutes, Betty's app sends her a notification.
127 | She is notified that she had a risk exposure 5 days ago.
128 |
129 | The next day, the 22nd, Betty's CWA also retrieves Aisha's diagnosis keys.
130 | It identifies additional encounters on the 16th and the 9th of the month.
131 | Both encounter sets lasted a total of 20 minutes each and the smartphones were an average of two meters apart.
132 | This also results in values of 1 for duration and attenuation.
133 | The delay risk values (22 - 16 = 6 days; 22 - 9 = 13 days) are a constant 5 and the transmission risk values are 5 for the 16th and 1 for the 9th of the month.
134 |
135 | As a result, the exposure risks for the 16th are calculated as 1 x 1 x 5 x 5 = 25 and for the 9th as 1 x 1 x 5 x 1 = 5.
136 | The encounter set from the 9th does not reach the threshold and is therefore not counted as a risk exposure.
137 |
138 | | | | | | | | | | |
139 | |-|-|-|-|-|-|-|-|-|
140 | |Days since last exposure| ≥14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | **6-7d (5)** | 4-5d (5) | 2-3d (5) | 0-1d (5) |
141 | |Attenuation| >73dB (0) | >63-≤73dB (1) | **>51-≤63dB (1)** | >33-≤51dB (1) | >27-≤33dB (1) | >15-≤27dB (1) | >10-≤15dB (1) | ≤10dB (1) |
142 | |Duration| 0min (0) | >0-≤5min (0) | >5-≤10min (0) | >10-≤15min (1) | **>15-≤20min (1)** | >20-≤25min (1) | >25-≤30min (1) | >30min (1) |
143 | |Transmission risk| I (1) | II (2) | III (3) | IV (4) | **V (5)** | VI (6) | VII (7) | VIII (8) |
144 |
145 | Table 4: Parameter values for Betty's encounter set with Aisha on the 16th (relevant values in bold)
146 |
147 | | | | | | | | | | |
148 | |-|-|-|-|-|-|-|-|-|
149 | |Days since last exposure| ≥14d (5) | **12-13d (5)** | 10-11d (5) | 8-9d (5) | 6-7d (5) | 4-5d (5) | 2-3d (5) | 0-1d (5) |
150 | |Attenuation| >73dB (0) | >63-≤73dB (1) | **>51-≤63dB (1)** | >33-≤51dB (1) | >27-≤33dB (1) | >15-≤27dB (1) | >10-≤15dB (1) | ≤10dB (1) |
151 | |Duration| 0min (0) | >0-≤5min (0) | >5-≤10min (0) | >10-≤15min (1) | **>15-≤20min (1)** | >20-≤25min (1) | >25-≤30min (1) | >30min (1) |
152 | |Transmission risk| **I (1)** | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | VIII (8) |
153 |
154 | Table 5: Parameter values for Betty's encounter set with Aisha on the 9th (relevant values in bold)
155 |
156 | In contrast, the risk exposure on the 16th is taken into account in the summary evaluation, which means Betty's CWA now counts 20 minutes (with Anton) in the distance range up to 1.5 meters fully and an additional 20 minutes (with Aisha) in the distance range up to 3 meters half (that is, 10 minutes).
157 | The calculated 30 minutes are once again adjusted by Betty’s risk exposure with Anton, which at 40 is still the highest exposure risk from all risk encounters identified in the recorded 14-day period, resulting in 30 x 40/25 = 48 minutes.
158 |
159 | Betty's updated risk notification now shows 2 risk encounters, the most recent of which took place 6 days ago.
160 |
161 | ## Current Configuration
162 |
163 | As documented in the [Risk Calculation](solution_architecture.md#risk-calculation) section of the solution architecture document, the actual parameters for the calculation are provided by a set of parameters which are hosted on cwa-server.
164 | This configuration might change over time according to the new research results and insights. The respective current set of configuration values can be looked up in the [cwa-server repository](https://github.com/corona-warn-app/cwa-server):
165 |
166 | - [Exposure Configuration](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/exposure-config.yaml)
167 | - [Attenuation & Duration Configuration](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/attenuation-duration.yaml)
168 | - [App Configuration, including minimum risk score](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/app-config.yaml)
169 | - [Risk Score Classification](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/risk-score-classification.yaml)
170 |
--------------------------------------------------------------------------------
/images/solution_architecture/ios_releases.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 |
19 |
20 |
21 | # Corona-Warn-App: Documentation
22 |
23 | NOTE: This README is also available [in German](translations/README.de.md). Thank you for understanding that the German version might not always be up-to-date with the English one.
24 |
25 | HINWEIS: Diese README ist ebenfalls [auf Deutsch](translations/README.de.md) verfügbar. Bitte haben Sie Verständnis, dass die deutsche Version nicht immer auf dem gleichen Stand wie die englische Version ist.
26 |
27 | ## About this Project
28 |
29 | 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](https://github.com/DP-3T/documents) (Decentralized Privacy-Preserving Proximity Tracing, see [this comic](https://github.com/DP-3T/documents/tree/master/public_engagement/cartoon) for concept explanation) and [TCN](https://github.com/TCNCoalition/TCN) protocols and based on the [Privacy-Preserving Contact Tracing specifications](https://www.apple.com/covid19/contacttracing/) 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](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.
30 |
31 | ## Who We Are
32 |
33 | 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.
34 |
35 | ## Credits
36 |
37 | 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](https://github.com/pepp-pt/pepp-pt-documentation) 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.
38 |
39 | ## Data Privacy
40 |
41 | 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!
42 |
43 | ## Code of Conduct
44 |
45 | This project has adopted the [Contributor Covenant](https://www.contributor-covenant.org/) in version 2.0 as our code of conduct. Please see the details in our [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md). All contributors must abide by the code of conduct.
46 |
47 | ## Working Language
48 |
49 | 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](https://www.coronawarn.app/en/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.
50 |
51 | ## Our Documentation
52 |
53 | This repository contains the developer documentation and related content.
54 |
55 | ### Project Scope
56 |
57 | 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!
58 |
59 | - [Corona-Warn-App - Scoping Document](scoping_document.md)
60 | - [Corona-Warn-App - User Interface Screens](ui_screens.md)
61 |
62 | ### Technical Documentation
63 |
64 | 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.
65 |
66 | - [Corona-Warn-App - Solution Architecture](solution_architecture.md)
67 | - [Corona-Warn-App Server Architecture](https://github.com/corona-warn-app/cwa-server/blob/main/docs/ARCHITECTURE.md)
68 | - [Corona-Warn-App Verification Server Software Design](https://github.com/corona-warn-app/cwa-verification-server/blob/master/docs/architecture-overview.md)
69 | - [Corona-Warn-App Verification Portal Server Software Design](https://github.com/corona-warn-app/cwa-verification-portal/blob/master/docs/architecture-overview.md)
70 | - [Corona-Warn-App Test Result Server Software Design](https://github.com/corona-warn-app/cwa-testresult-server/blob/master/docs/architecture-overview.md)
71 | - [Corona-Warn-App Mobile Client (Android) Architecture](https://github.com/corona-warn-app/cwa-app-android/blob/main/docs/architecture-overview.md)
72 | - [Corona-Warn-App Mobile Client (iOS) Architecture](https://github.com/corona-warn-app/cwa-app-ios/blob/main/docs/architecture-overview.md)
73 | - [Criteria for the Evaluation of Contact Tracing Apps](pruefsteine.md)
74 | - [Corona-Warn-App Security Overview](overview-security.md)
75 | - [Corona-Warn-App Backend Infrastructure Architecture Overview](backend-infrastructure-architecture.pdf)
76 | - [How does the Corona-Warn-App identify an increased risk?](solution_architecture.md#mobile-applications)
77 | - [Epidemiological Motivation of the Transmission Risk Level (PDF)](transmission_risk.pdf), [(Rmd file)](transmission_risk.Rmd), [(bib references)](transmission_risk_references.bib)
78 | - [Corona-Warn-App Data Privacy Impact Assessment/DPIA (PDF, German)](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung.pdf), [DPIA Annex 1a](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1a.pdf), [DPIA Annex 1b](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1b.pdf), [DPIA Annex 1c](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1c.pdf), [DPIA Annex 2](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage2.pdf), [DPIA Annex 3](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage3.pdf), [DPIA Annex 4](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage4.pdf), [DPIA Annex 5](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage5.pdf), [DPIA Annex 6](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage6.pdf), [DPIA Annex 7](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage7.pdf) and [DPIA Annex 8](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage8.pdf)
79 | - [Exposure Notification API Testing](2020_06_24_Corona_API_measurements.pdf)
80 | - [Event Registration](event_registration.md)
81 |
82 | To be published:
83 |
84 | - System Operation
85 |
86 | ### Glossary
87 |
88 | For an easier understanding of the used acronyms and special terms in our documents please see our [glossary](glossary.md).
89 |
90 | ## Repositories
91 |
92 | | Repository | Description |
93 | | ---------------------------- | ------------------------------------------------------------------------------------------- |
94 | | [cwa-app-android] | Native Android app using the Apple/Google exposure notification API. |
95 | | [cwa-app-ccl] | Common Covid Logic (CCL) for Android and iOS. |
96 | | [cwa-app-ios] | Native iOS app using the Apple/Google exposure notification API. |
97 | | [cwa-dcc-server] | Backend implementation of the process to issue EU Digital Covid Certificate. |
98 | | [cwa-documentation] | Project overview, general documentation and white papers. |
99 | | [cwa-event-landingpage] | Landing page for CWA which opens if the user does not have the app installed. |
100 | | [cwa-event-qr-code] | Utility to generate QR codes for Event Registration. |
101 | | [cwa-hotline] | Contains all issues reg. the hotlines of the CWA. |
102 | | [cwa-icao-transliteration] | A simple transliteration of non-latin letters into latin for the CWA. |
103 | | [cwa-kotlin-jfn] | JsonFunctions Engine - DCC Logic. |
104 | | [cwa-log-upload] | Counterpart of the log upload in the app. |
105 | | [cwa-parent] | Repository containing Maven files for parent project and dependency building blocks. |
106 | | [cwa-map-backend] | Backend of map.schnelltestportal.de. |
107 | | [cwa-map-operators-frontend] | Frontend for test center operators to manage their test centers in a simple way. |
108 | | [cwa-map-public-frontend] | Public frontend of map.schnelltestportal.de. |
109 | | [cwa-ppa-server] | Backend implementation for the privacy-preserving analytics server. |
110 | | [cwa-quick-test-backend] | Backend implementation of the rapid antigen test portal and API for participating partners. |
111 | | [cwa-quick-test-frontend] | Frontend implementation of the rapid antigen test portal for participating partners. |
112 | | [cwa-quicktest-onboarding] | Documentation about onboarding procedure for rapid antigen test partners. |
113 | | [cwa-registrierung] | Registration portal for the rapid antigen test portal |
114 | | [cwa-server] | Backend implementation for the Apple/Google exposure notification API. |
115 | | [cwa-testresult-server] | Receives PCR test results from connected laboratories. |
116 | | [cwa-verification-iam] | The identity and access management to interact with the verification server. |
117 | | [cwa-verification-portal] | The portal to interact with the verification server. |
118 | | [cwa-verification-server] | Backend implementation of the verification process. |
119 | | [cwa-website] | The official website for the Corona-Warn-App. |
120 | | [cwa-wishlist] | Community feature requests. |
121 | | [dcc-rule-translation] | Translations of Booster Notification Rules. |
122 |
123 | [cwa-app-android]: https://github.com/corona-warn-app/cwa-app-android
124 | [cwa-app-ccl]: https://github.com/corona-warn-app/cwa-app-ccl
125 | [cwa-app-ios]: https://github.com/corona-warn-app/cwa-app-ios
126 | [cwa-dcc-server]: https://github.com/corona-warn-app/cwa-dcc-server
127 | [cwa-documentation]: https://github.com/corona-warn-app/cwa-documentation
128 | [cwa-event-landingpage]: https://github.com/corona-warn-app/cwa-event-landingpage
129 | [cwa-event-qr-code]: https://github.com/corona-warn-app/cwa-event-qr-code
130 | [cwa-hotline]: https://github.com/corona-warn-app/cwa-hotline
131 | [cwa-icao-transliteration]: https://github.com/corona-warn-app/cwa-icao-transliteration
132 | [cwa-kotlin-jfn]: https://github.com/corona-warn-app/cwa-kotlin-jfn
133 | [cwa-log-upload]: https://github.com/corona-warn-app/cwa-log-upload
134 | [cwa-parent]: https://github.com/corona-warn-app/cwa-parent
135 | [cwa-map-backend]: https://github.com/corona-warn-app/cwa-map-backend
136 | [cwa-map-operators-frontend]: https://github.com/corona-warn-app/cwa-map-operators-frontend
137 | [cwa-map-public-frontend]: https://github.com/corona-warn-app/cwa-map-public-frontend
138 | [cwa-ppa-server]: https://github.com/corona-warn-app/cwa-ppa-server
139 | [cwa-quick-test-backend]: https://github.com/corona-warn-app/cwa-quick-test-backend
140 | [cwa-quick-test-frontend]: https://github.com/corona-warn-app/cwa-quick-test-frontend
141 | [cwa-quicktest-onboarding]: https://github.com/corona-warn-app/cwa-quicktest-onboarding
142 | [cwa-registrierung]: https://github.com/corona-warn-app/cwa-registrierung
143 | [cwa-server]: https://github.com/corona-warn-app/cwa-server
144 | [cwa-testresult-server]: https://github.com/corona-warn-app/cwa-testresult-server
145 | [cwa-verification-iam]: https://github.com/corona-warn-app/cwa-verification-iam
146 | [cwa-verification-portal]: https://github.com/corona-warn-app/cwa-verification-portal
147 | [cwa-verification-server]: https://github.com/corona-warn-app/cwa-verification-server
148 | [cwa-website]: https://github.com/corona-warn-app/cwa-website
149 | [cwa-wishlist]: https://github.com/corona-warn-app/cwa-wishlist
150 | [dcc-rule-translation]: https://github.com/corona-warn-app/dcc-rule-translation
151 |
152 | ## Licensing
153 |
154 | Copyright (c) 2020-2023 Deutsche Telekom AG and SAP SE or an SAP affiliate company.
155 |
156 | Licensed under the **Apache License, Version 2.0** (the "License"); you may not use this file except in compliance with the License.
157 |
158 | You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.
159 |
160 | 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](./LICENSE) for the specific language governing permissions and limitations under the License.
161 |
162 |
163 |
164 | 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](https://www.bundesregierung.de/breg-en/federal-government/federal-press-office).
165 |
166 |
167 | ## How to Contribute
168 |
169 | Please see our [CONTRIBUTING.md](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.
170 |
--------------------------------------------------------------------------------
/translations/cwa-risk-assessment.de.md:
--------------------------------------------------------------------------------
1 | # Wie ermittelt die Corona-Warn-App ein erhöhtes Risiko?
2 |
3 | Dieses Dokument ist **nicht mehr aktuell**. Es beschreibt die ursprüngliche Risikoberechnung in der Corona-Warn-App vor Version 1.5 (im Oktober 2020 veröffentlicht) und wird hier aus Dokumentationsgründen noch beibehalten. Eine aktuelle Beschreibung der Risikoanalyse und Risikoberechnung in der Corona-Warn-App befindet sich im Dokumentenabschnitt [Solution Architecture > Mobile Application](../solution_architecture.md#mobile-applications) (auf Englisch).
4 |
5 |
6 |
7 | ## WICHTIG! - DOKUMENT ZURÜCKGEZOGEN
8 |
9 | **Der Inhalt dieses Dokuments entspricht nicht mehr dem aktuellen Stand und wird nicht weiter gepflegt.**
10 |
11 |
12 |
13 | ---
14 |
15 | ## Voraussetzungen
16 |
17 | Personen, die die Corona-Warn-App (CWA) nutzen und positiv auf das Coronavirus SARS-CoV-2 getestet wurden, können ihrer CWA erlauben, die vom Betriebssystem ihres Smartphones erzeugten zufälligen Geräteschlüssel (*Temporary Exposure Keys*) der vergangenen Tage als sogenannte Positivkennungen (*Diagnosis Keys*) auf den Corona-Warn-App-Server hochzuladen und dort zu veröffentlichen.
18 | Diese Positivkennungen sind die Grundlage der Risikoermittlung für alle anderen die CWA nutzenden Personen.
19 |
20 | Eine Corona-positiv getestete Person lädt bis zu 15 Positivkennungen hoch, nämlich je eine für jeden der bis zu 14 letzten Tage vor dem Hochladen sowie (derzeit noch nicht umgesetzt) am folgenden Tag die für den aktuellen Tag.
21 | Letzteres ist nötig, da Positivkennungen nur für bereits vergangene Tage hochgeladen werden können, um Missbrauch noch aktiver Positivkennungen zu verhindern.
22 |
23 | Positivkennungen lassen keine Rückschlüsse auf die Identität der positiv getesteten Person zu, aber die Positivkennung eines bestimmten Tages passt zu den ständig wechselnden Zufallscodes (*Rolling Proximity Identifiers*), die das Smartphone der Person den ganzen Tag über mittels Bluetooth versendet hat und die von anderen Smartphones in der Nähe empfangen und aufgezeichnet wurden.
24 | An jede Positivkennung ist noch ein Wert angehängt, der angibt, wie groß das Übertragungsrisiko (*Transmission Risk Level*) der positiv getesteten Person an dem Tag, zu dem die Positivkennung gehört, vermutlich gewesen ist. Dieses Übertragungsrisiko wird anhand von Erfahrungswerten unter Berücksichtigung der aktuell vorliegenden wissenschaftlichen Erkenntnisse [in einem mathematischen Verfahren geschätzt](../transmission_risk.pdf).
25 | Jede Positivkennung verfällt, wenn sie älter als 14 Tage ist. Deshalb sind stets nur die Positivkennungen der letzten 14 Tage verfügbar.
26 |
27 | ## Verfahren
28 |
29 | Alle aktiven Corona-Warn-Apps laden täglich vom Corona-Warn-App-Server die dort veröffentlichten Positivkennungen herunter und übergeben sie gesammelt über eine Schnittstelle an das Betriebssystem des Smartphones.
30 | Dort wird geprüft, ob empfangene und aufgezeichnete Zufallscodes der letzten 14 Tage vorliegen, die zu einer der Positivkennungen passen.
31 | Ein solches Zusammenpassen zeigt an, dass sich das Smartphone, das die Zufallscodes aufgezeichnet hat, und das Smartphone der Corona-positiv getesteten Person, die die Positivkennung hochgeladen hat, an dem Tag, zu dem die Positivkennung gehört, begegnet sind.
32 |
33 | > NB: Tage im Kontext der Corona-Warn-App und damit auch dieses Dokuments sind Kalendertage nach UTC (Coordinated Universal Time). Der Tageswechsel erfolgt demnach um 1 Uhr Mitteleuropäischer Zeit bzw. 2 Uhr Mitteleuropäischer Sommerzeit.
34 |
35 | Als nächstes wird im Betriebssystem des Smartphones für jede Positivkennung anhand aller dazu passenden Zufallscodes geschätzt, wie lange die Begegnungen jenes Tags insgesamt gedauert haben und wie nahe die beiden Smartphones sich dabei im Durchschnitt waren.
36 | Die Entfernung wird aus der gemessenen Abschwächung des Bluetooth-Signals errechnet, die in dB (Dezibel) angegeben wird.
37 | Jedem dB-Wert lässt sich eine Entfernung im Freiraum (d.h., ohne Hindernisse im Signalweg; s.a. Erläuterungen im Abschnitt "Folgen und Einschränkungen") zuordnen.
38 | Alle Begegnungen zu einer Positivkennung, die insgesamt weniger als 10 Minuten gedauert haben (egal, wie nahe sich die Smartphones dabei gekommen sind) oder bei denen die Smartphones im Durchschnitt mehr als ca. 8 Meter Freiraum (>73 dB Dämpfung) voneinander entfernt waren (egal, wie lange sie insgesamt gedauert haben), werden als unbedenklich verworfen.
39 |
40 | > NB: Wir bezeichnen die Gesamtheit aller Begegnungen, die jeweils zu einer bestimmten Positivkennung gehören, also alle Begegnungen eines Tages zwischen denselben zwei Smartphones, im Weiteren als Begegnungsmenge.
41 |
42 | Bei den restlichen, nicht als unbedenklich verworfen Begegnungen wird für jede Begegnungsmenge ein Begegnungsrisiko (*Total Risk Score*) errechnet, indem der oben erläuterte Übertragungsrisikowert mit einem Verzugsrisikowert (*Days Since Last Exposure Value*) multipliziert wird, der sich aus der Anzahl der seit der Begegnung vergangenen Tage ableitet.
43 |
44 | Alle Begegnungsmengen, deren Begegnungsrisiko dabei einen bestimmten Grenzwert (*Minimum Risk Score*) überschreitet, werden als Risikobegegnungen angesehen.
45 | Die anderen Begegnungsmengen werden ebenso wie zuvor schon die zu kurzen oder zu entfernten Begegnungsmengen als unbedenklich verworfen.
46 |
47 | Zugleich wird für alle verbleibenden Begegnungsmengen, die Risikobegegnungen, zusammengezählt, wieviel Zeit in einem sehr nahen Entfernungsbereich unter ca. 1,5 Metern (<55 dB Dämpfung) verbracht wurde und wieviel Zeit in einem nahen Entfernungsbereich zwischen ca. 1,5 und 3 Metern (55 bis 63 dB Dämpfung) verbracht wurde.
48 | Dabei wird die Zeit im sehr nahen Bereich ganz und die Zeit im nahen Bereich zur Hälfte gezählt.
49 | Die in einer Entfernung von mehr als ca. 3 Metern verbrachte Zeit wird nicht gezählt.
50 |
51 | Die so errechnete Gesamtzeit aller Risikobegegnungen der letzten 14 Tage wird dann noch mit dem Begegnungsrisiko der Risikobegegnung mit dem höchsten Risiko (*Maximum Risk Score*) verrechnet.
52 | Und zwar so, dass sie unverändert bleibt, wenn dieses Risiko als "durchschnittlich" (für Risikobegegnungen) eingeschätzt wird, dass sie sich bis auf das ungefähr anderthalbfache verlängert, wenn dieses Risiko überdurchschnittlich ist, und entsprechend verkürzt, wenn dieses Risiko unterdurchschnittlich ist.
53 | Dadurch kann eine Zeit, die zuvor 10 Minuten betrug, auf über 15 Minuten verlängert werden und eine Zeit, die zuvor 25 Minuten betrug, auf 15 Minuten verkürzt werden.
54 |
55 | ## Folgen und Einschränkungen
56 |
57 | Am Ende wird die die CWA nutzende Person immer dann über ein erhöhtes Risiko benachrichtigt, wenn die so ermittelte gesamte Risikobegegnungszeit 15 Minuten oder länger ist.
58 | Diese Benachrichtigung erfolgt in der CWA und gibt der Person zugleich Handlungsempfehlungen für das weitere Vorgehen.
59 |
60 | Bei der Bewertung der von der CWA ermittelten Zeiten und Entfernungen muss berücksichtigt werden, dass beide Parameter nicht exakt gemessen werden können.
61 | Die einzelnen gemessenen Zeiten können bis zu 5 Minuten in beide Richtungen abweichen und die ermittelten Entfernungen sind Näherungswerte unter Idealbedingungen, d.h., wenn z.B. keine Hindernisse zwischen den beiden Smartphones sind.
62 | Schon bei kleineren Hindernissen, z.B. einer Person zwischen den beiden Smartphones oder wenn das Smartphone abgeschirmt verstaut ist, kann die Entfernung doppelt so groß erscheinen wie sie wirklich ist.
63 |
64 | Aufgrund von Datenschutzerwägungen können die oben beschriebenen Eigenschaften an der Schnittstelle zum Betriebssystem vorerst nur für die Gesamtheit aller Risikobegegnungen abgefragt werden, nicht aber für einzelne Risikobegegnungen oder tageweise.
65 | Solange die Anzahl neuer Fälle vergleichsweise gering bleibt, dürfte das keinen großen Unterschied machen, da vermutlich nur wenige die CWA nutzende Personen im Zeitraum vor ihrer Benachrichtigung Risikobegegnungen mit mehreren positiv getesteten Personen haben, die die CWA nutzen.
66 |
67 | ## Ein Beispiel
68 |
69 | Anton und Aisha werden am 20. eines Monats über ihr jeweils Corona-positives Testergebnis informiert.
70 | Anton erlaubt noch am selben Tag seiner CWA, andere die CWA nutzende Personen, mit denen er Risikobegegnungen hatte, darüber zu informieren.
71 | Er hat die CWA auf seinem Smartphone seit einer Woche durchgehend aktiviert.
72 | Die CWA lädt nun seine zufälligen Geräteschlüssel der letzten 7 Tage (mehr sind nicht verfügbar, da Anton die CWA erst 8 Tage im Einsatz hat und der aktuelle Geräteschlüssel noch nicht hochgeladen werden kann) als Positivkennungen auf den CWA-Server hoch.
73 | Sie werden mit den Übertragungsrisikograden VI (für den Vortag), dreimal VIII (für den 16. bis 18.), V, III und I (rückwärts für die anderen vorausgegangenen Tage, 13. bis 15.) versehen.
74 |
75 | |||||||||
76 | |-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
77 | |Übertragungsrisikograd|VI|VIII|VIII|VIII|V|III|I|
78 | |Abstand zum Tag der Upload-Zustimmung|1|2|3|4|5|6|7|
79 | |Erzeugungsdatum des Schlüssels|19.|18.|17.|16.|15.|14.|13.|
80 |
81 | Tabelle 1: Übertragungsrisikograd für Antons 7 geteilte Positivkennungen, basierend auf dem Abstand zum Tag der Upload-Zustimmung (20.)
82 |
83 | Aisha zögert noch einen Tag und gibt ihre Zustimmung erst am 21. des Monats.
84 | Da sie ihre CWA schon vor mehreren Wochen aktiviert hatte und seitdem durchgehend im Hintergrund laufen hatte, stehen ihre zufälligen Geräteschlüssel der letzten 14 Tage zum Hochladen zur Verfügung.
85 | Auch ihren Positivkennungen werden die Übertragungsrisikograde VI, dreimal VIII, V, III und I rückwärts für die 7 vorausgegangenen Tage vergeben, allerdings beginnend mit dem 20. und damit einen Tag gegenüber Anton versetzt.
86 | (Dass beide am selben Tag über ihr Testergebnis informiert wurden, weiß die CWA nicht. In der aktuellen Version steht ihr nur das Datum der Zustimmung zum Hochladen für die Ermittlung des tagesspezifischen Übertragungsrisikograds zur Verfügung.)
87 | Für die 7 noch weiter zurückliegenden Tage, den Zeitraum vom 7. bis zum 13. des Monats, wird jeweils der Übertragungsrisikograd I vergeben.
88 |
89 | ||||||||||||||||
90 | |-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
91 | |Übertragungsrisikograd|VI|VIII|VIII|VIII|V|III|I|I|I|I|I|I|I|I|
92 | |Abstand zum Tag der Upload-Zustimmung|1|2|3|4|5|6|7|8|9|10|11|12|13|14|
93 | |Erzeugungsdatum des Schlüssels|20.|19.|18.|17.|16.|15.|14.|13.|12.|11.|10.|9.|8.|7.|
94 |
95 | Tabelle 2: Übertragungsrisikograd für Aishas 14 geteilte Positivkennungen, basierend auf dem Abstand zum Tag der Upload-Zustimmung (21.)
96 |
97 | Anton und Aisha fahren regelmäßig zusammen mit dem Bus zur Arbeit.
98 | Betty hat denselben Arbeitsweg und sitzt gelegentlich im selben Bus.
99 | Alle drei beschäftigen sich während der Fahrt mit ihren Smartphones, so dass den Bluetooth-Signalen keine Hindernisse im Weg sind.
100 | Betty hat Anton und Aisha am 9. und am 16. morgens und abends für jeweils 10 Minuten getroffen.
101 | Anton saß dabei einen Meter von ihr entfernt und Aisha zwei.
102 |
103 | Als Bettys CWA am 21. Antons Positivkennungen abruft und an die Schnittstelle des Betriebssystems ihres Smartphones übergibt, wird eine Begegnungsmenge für den 16. erkannt.
104 | (Für den 9. hat Antons CWA keine Positivkennung hochgeladen.)
105 | Diese Begegnungsmenge hat insgesamt 20 Minuten gedauert und die Smartphones waren im Durchschnitt einen Meter voneinander entfernt.
106 | Daraus ergeben sich Werte von jeweils 1 für die Dauer und die Dämpfung (s.a. "Konfiguration von Begegnungen" im Abschnitt "Aktuelle Konfiguration").
107 |
108 | Damit ist sichergestellt, dass diese Begegnungsmenge nicht verworfen wird.
109 | Der Wert des Parameters für das Verzugsrisiko (21 - 16 = 5 Tage) ist durchgehend mit 5 konfiguriert und der Wert des Parameters für das Übertragungsrisiko wird eins-zu-eins vom Übertragungsrisikograd übernommen, beträgt also 8.
110 | Das Begegnungsrisiko errechnet sich damit als 1 x 1 x 5 x 8 = 40, was übrigens der höchste mit der aktuellen Konfiguration erreichbare Wert ist.
111 | Der Grenzwert von 11 wird überschritten, womit die Begegnungsmenge als Risikobegegnung zählt.
112 |
113 | | | | | | | | | | |
114 | |-|-|-|-|-|-|-|-|-|
115 | |Verzugsrisiko| ≥14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | 6-7d (5) | **4-5d (5)** | 2-3d (5) | 0-1d (5) |
116 | |Dämpfung| >73dB (0) | >63-≤73dB (1) | >51-≤63dB (1) | **>33-≤51dB (1)** | >27-≤33dB (1) | >15-≤27dB (1) | >10-≤15dB (1) | ≤10dB (1) |
117 | |Dauer| 0min (0) | >0-≤5min (0) | >5-≤10min (0) | >10-≤15min (1) | **>15-≤20min (1)** | >20-≤25min (1) | >25-≤30min (1) | >30min (1) |
118 | |Übertragungsrisiko| I (1) | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | **VIII (8)** |
119 |
120 | Tabelle 3: Parameterwerte für Bettys Begegnungsmenge mit Anton am 16. (zutreffende Werte fett)
121 |
122 | Da diese Risikobegegnung zugleich die einzige Risikobegegnung ist, die Bettys CWA bekannt ist, wird auch nur sie bei der summarischen Auswertung ihrer Aufenthaltszeiten in den Entfernungsräumen bis 1,5 Meter und bis 3 Meter berücksichtigt.
123 | Betty hielt sich 20 Minuten im Entfernungsraum unter 1,5 Meter auf, die zur Gänze gezählt werden.
124 |
125 | Auch bei der Verrechnung dieser 20 Minuten mit dem Begegnungsrisiko der Risikobegegnung mit dem höchsten Risiko kann wieder nur diese eine Risikobegegnung mit ihrem Begegnungsrisiko von 40 berücksichtigt werden.
126 | Die Multiplikation der 20 Minuten mit 40/25 (25 ist der aktuell konfigurierte Wert für "durchschnittlich riskante" Risikobegegnungen; s.a. *risk-score-normalization-divisor* in "Konfiguration von Dämpfung & Dauer" im Abschnitt "Aktuelle Konfiguration") ergibt 32 Minuten.
127 | Da die CWA ab 15 Minuten über ein erhöhtes Risiko benachrichtigt, erhält Betty nun eine solche Benachrichtigung.
128 | Zugleich wird ihr mitgeteilt, dass sie eine Risikobegegnung hatte und diese 5 Tage zurückliegt.
129 |
130 | Am folgenden Tag, dem 22., ruft Bettys CWA auch Aishas Positivkennungen ab.
131 | Sie erkennt zusätzliche Begegnungen am 16. und am 9. des Monats.
132 | Beide Begegnungsmengen haben insgesamt jeweils 20 Minuten gedauert und die Smartphones waren im Durchschnitt zwei Meter voneinander entfernt.
133 | Auch hieraus ergeben sich Werte von jeweils 1 für die Dauer und die Dämpfung.
134 | Die Verzugsrisikowerte (22 - 16 = 6 Tage; 22 - 9 = 13 Tage) sind konstant 5 und die Übertragungsrisikowerte 5 für den 16. und 1 für den 9. des Monats.
135 |
136 | Die Begegnungsrisiken berechnen sich für den 16. also als 1 x 1 x 5 x 5 = 25 und für den 9. als 1 x 1 x 5 x 1 = 5.
137 | Die Begegnungsmenge des 9. erreicht den Grenzwert nicht und zählt damit nicht als Risikobegegnung.
138 |
139 | || | | | | | | | |
140 | |-|-|-|-|-|-|-|-|-|
141 | |Verzugsrisiko| ≥14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | **6-7d (5)** | 4-5d (5) | 2-3d (5) | 0-1d (5) |
142 | |Dämpfung| >73dB (0) | >63-≤73dB (1) | **>51-≤63dB (1)** | >33-≤51dB (1) | >27-≤33dB (1) | >15-≤27dB (1) | >10-≤15dB (1) | ≤10dB (1) |
143 | |Dauer| 0min (0) | >0-≤5min (0) | >5-≤10min (0) | >10-≤15min (1) | **>15-≤20min (1)** | >20-≤25min (1) | >25-≤30min (1) | >30min (1) |
144 | |Übertragungsrisiko| I (1) | II (2) | III (3) | IV (4) | **V (5)** | VI (6) | VII (7) | VIII (8) |
145 |
146 | Tabelle 4: Parameterwerte für Bettys Begegnungsmenge mit Aisha am 16. (zutreffende Werte fett)
147 |
148 | || | | | | | | | |
149 | |-|-|-|-|-|-|-|-|-|
150 | |Verzugsrisiko| ≥14d (5) | **12-13d (5)** | 10-11d (5) | 8-9d (5) | 6-7d (5) | 4-5d (5) | 2-3d (5) | 0-1d (5) |
151 | |Dämpfung| >73dB (0) | >63-≤73dB (1) | **>51-≤63dB (1)** | >33-≤51dB (1) | >27-≤33dB (1) | >15-≤27dB (1) | >10-≤15dB (1) | ≤10dB (1) |
152 | |Dauer| 0min (0) | >0-≤5min (0) | >5-≤10min (0) | >10-≤15min (1) | **>15-≤20min (1)** | >20-≤25min (1) | >25-≤30min (1) | >30min (1) |
153 | |Übertragungsrisiko| **I (1)** | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | VIII (8) |
154 |
155 | Tabelle 5: Parameterwerte für Bettys Begegnungsmenge mit Aisha am 9. (zutreffende Werte fett)
156 |
157 | Die Risikobegegnung des 16. wird hingegen bei der aktualisierten summarischen Auswertung mit berücksichtigt, so dass Bettys CWA nun 20 Minuten (mit Anton) im Entfernungsraum bis 1,5 Metern ganz und weitere 20 Minuten (mit Aisha) im Entfernungsraum bis 3 Meter zur Hälfte (also als 10 Minuten) zählt.
158 | Die so ermittelten 30 Minuten werden wieder mit Bettys Risikobegegnung mit Anton verrechnet, die mit 40 nach wie vor das höchste Begegnungsrisiko aller erkannten Risikobegegnungen des aufgezeichneten 14-Tage-Zeitraums hat, so dass sich 30 x 40/25 = 48 Minuten ergeben.
159 |
160 | Bettys aktualisierte Risikobenachrichtigung zeigt jetzt 2 Risikobegegnungen an, von denen die letzte 6 Tage zurückliegt.
161 |
162 | ## Aktuelle Konfiguration
163 |
164 | Wie im [Abschnitt "*Risk Calculation*"](../solution_architecture.md#risk-calculation) des *Solution-Architecture*-Dokuments beschrieben, werden die jeweiligen Parameter für die Berechnung aus von einer Menge an Parametern bestimmt, die vom CWA-Server zur Verfügung gestellt werden.
165 | Diese Konfiguration kann sich über die Zeit auf Basis neuer Forschungsergebnisse und Erkenntnisse ändern.
166 | Die jeweils aktuell gültigen Parameterwerte können im [*CWA-Server-Repository*](https://github.com/corona-warn-app/cwa-server) eingesehen werden:
167 |
168 | - [Konfiguration von Begegnungen](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/exposure-config.yaml)
169 | - [Konfiguration von Dämpfung & Dauer](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/attenuation-duration.yaml)
170 | - [App-Konfiguration, inkl. des minimalen Risikowerts](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/app-config.yaml)
171 | - [Risikowertklassifizierung](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/risk-score-classification.yaml)
172 |
--------------------------------------------------------------------------------
/images/solution_architecture/key_flow_receiving.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
--------------------------------------------------------------------------------
4 |