Merge pull request #840 from MikeMcC399/migrate-to-relative-links

Migrate repository to use relative links (resolves #839)

INSTALL.md

@@ -56,7 +56,7 @@ Every individual check can be run like so:
 npm runscript my-individual-check
 ```
 
-See the [package.json](https://github.com/corona-warn-app/cwa-documentation/blob/master/package.json) file for the currently available scripts.
+See the [package.json](package.json) file for the currently available scripts.
 
 #### Markdown linter
 

README.md

@@ -1,5 +1,5 @@
 <p align="center">
- <a href="https://www.coronawarn.app/en/"><img src="https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/master/images/CWA_title.png" width="400"></a>
+ <a href="https://www.coronawarn.app/en/"><img src="https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/main/images/CWA_title.png" width="400"></a>
 </p>
 
 <hr />
@@ -71,11 +71,11 @@ The technical documents are intended for a technical audience and represent the
 - [Corona-Warn-App Mobile Client (iOS) Architecture](https://github.com/corona-warn-app/cwa-app-ios/blob/main/docs/architecture-overview.md)
 - [Criteria for the Evaluation of Contact Tracing Apps](pruefsteine.md)
 - [Corona-Warn-App Security Overview](overview-security.md)
-- [Corona-Warn-App Backend Infrastructure Architecture Overview](https://github.com/corona-warn-app/cwa-documentation/blob/master/backend-infrastructure-architecture.pdf)
+- [Corona-Warn-App Backend Infrastructure Architecture Overview](backend-infrastructure-architecture.pdf)
 - [How does the Corona-Warn-App identify an increased risk?](solution_architecture.md#mobile-applications)
-- [Epidemiological Motivation of the Transmission Risk Level (PDF)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.pdf), [(Rmd file)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.Rmd), [(bib references)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk_references.bib)
+- [Epidemiological Motivation of the Transmission Risk Level (PDF)](transmission_risk.pdf), [(Rmd file)](transmission_risk.Rmd), [(bib references)](transmission_risk_references.bib)
 - [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)
-- [Exposure Notification API Testing](https://github.com/corona-warn-app/cwa-documentation/blob/master/2020_06_24_Corona_API_measurements.pdf)
+- [Exposure Notification API Testing](2020_06_24_Corona_API_measurements.pdf)
 - [Event Registration](event_registration.md)
 
 To be published:

backend-infrastructure-architecture.md

@@ -4,6 +4,6 @@
 
 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.
 
-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](https://github.com/corona-warn-app/cwa-documentation/blob/master/backend-infrastructure-architecture.pdf) file.
+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.
 
 More CWA-Server Documentation can be found [here](https://github.com/corona-warn-app/cwa-server/tree/main/docs).

pruefsteine.md

@@ -4,7 +4,7 @@ The Chaos Computer Club (CCC) proposed minimum privacy [requirements](https://ww
 
 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)
 
-This document describes the compliance of the [current architecture](https://github.com/corona-warn-app/cwa-documentation/blob/master/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.
+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.
 
 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.
 

solution_architecture.md

@@ -38,7 +38,7 @@ To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandem
 |:--:|
 | **Figure 1: High-level architecture overview**|
 
-The Corona-Warn-App (see [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md )), shown centrally in *Figure 1*, enables individuals to trace their personal exposure risk via their mobile phones. The Corona-Warn-App uses a new framework provided by Apple and Google called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). The framework employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics. BLE lets the individual mobile phones act as beacons meaning that they constantly broadcast a temporary identifier called Rolling Proximity Identifier (RPI) that is remembered and, at the same time, lets the mobile phone scan for identifiers of other mobile phones. This is shown on the right side of *Figure 1*.
+The Corona-Warn-App (see [scoping document](scoping_document.md)), shown centrally in *Figure 1*, enables individuals to trace their personal exposure risk via their mobile phones. The Corona-Warn-App uses a new framework provided by Apple and Google called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). The framework employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics. BLE lets the individual mobile phones act as beacons meaning that they constantly broadcast a temporary identifier called Rolling Proximity Identifier (RPI) that is remembered and, at the same time, lets the mobile phone scan for identifiers of other mobile phones. This is shown on the right side of *Figure 1*.
 Identifiers are ID numbers sent out by the mobile phones. To ensure privacy and to prevent the tracking of movement patterns of the app user, those broadcasted identifiers are only temporary and change constantly. New identifiers are derived from a Temporary Exposure Key (TEK) that is substituted at midnight (UTC) every day through means of cryptography. For a more detailed explanation, see *Figure 10*. Once a TEK is linked to a positive test result, it remains technically the same, but is then called a Diagnosis Key.
 
 The collected identifiers from other users as well as the device's own keys, which can later be used to derive the identifiers, are stored locally on the phone in the secure storage of the framework provided by Apple and Google. The application cannot access this secure storage directly, but only through the interfaces the Exposure Notification Framework provides. To prevent misuse, some of these interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures). If app users are tested positive for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys from up to 14 days back. On the Corona-Warn-App back-end server, all keys of individuals that have tested positive are aggregated and are then made available to all mobile phones that have the app installed. Additionally, the configuration parameters for the framework are available for download, so that adjustments to the risk score calculation can be made, see the *Risk Scores* section.
@@ -145,7 +145,7 @@ The Corona-Warn-App Server needs to fulfill the following tasks:
 
 - Accept upload requests from clients
   - Verify association with a positive test through the Verification Server and the associated workflow as explained in the “Retrieval of Lab Results and Verification Process” section and shown in the center of the left side of *Figure 7*.
-  - Accept uploaded diagnosis keys and store them (optional) together with the corresponding information (days since onset of symptoms/transmission risk level ) into the database. Note that the transport of connection metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labeled “Transport Metadata Removal” in *Figure 7*.
+  - Accept uploaded diagnosis keys and store them (optional) together with the corresponding information (days since onset of symptoms/transmission risk level) into the database. Note that the transport of connection metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labeled “Transport Metadata Removal” in *Figure 7*.
 - Provide [configuration parameters](#data-format) to the mobile applications
   - Threshold values for [attenuation buckets](#attenuation-buckets)
   - Encoding and mapping of the Transmission Risk Level
@@ -215,7 +215,7 @@ The data on all involved servers is only retained as long as required. Diagnosis
 
 ## MOBILE APPLICATIONS
 
-The functional scope of the mobile applications (apps) is defined in the corresponding [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md). The apps are developed natively for Apple’s iOS and Google’s Android operating systems. They make use of the respective interfaces for the exposure notification, i.e. broadcasting and scanning for Bluetooth advertisement packages, see *Figure 8*.
+The functional scope of the mobile applications (apps) is defined in the corresponding [scoping document](scoping_document.md). The apps are developed natively for Apple’s iOS and Google’s Android operating systems. They make use of the respective interfaces for the exposure notification, i.e. broadcasting and scanning for Bluetooth advertisement packages, see *Figure 8*.
 
 For Apple devices an OS version of at least 12.5 (for older devices) or 13.7 is required for the system to work, as the framework is integrated into the operating system (see Figure 10).
 
@@ -285,7 +285,7 @@ Those parameters are regularly downloaded from the CWA Server, which means they
 
 As mentioned before, the individual scan instances from the exposure windows are weighted according to the weight attached to the individual bucket. When those individual instances are summed up, they can be multiplied with a transmission risk value (which in turn is derived from the TRL described before). The result is one normalized exposure time per day. If those times are summed up, the overall risk can be determined, as shown in *Figure 16*.
 
-Note that the transmission risk level plays a special role in the above calculations: It can be defined by the app and be associated with each individual diagnosis key (i.e. specific for each day of an infected person) that is being sent to the server. It contains a value from 1 to 8, which can be used to represent a calculated risk defined by the health authority. As an example it could contain an estimate of the infectiousness of the potential infector at the time of contact and, hence, the likelihood of transmitting the disease. The specific values are defined as part of the [app](https://github.com/corona-warn-app/cwa-app-android/blob/master/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/ProtoFormatConverterExtensions.kt) - a motivation of the parameter choices is found in the document [Epidemiological Motivation of the Transmission Risk Level](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.pdf).
+Note that the transmission risk level plays a special role in the above calculations: It can be defined by the app and be associated with each individual diagnosis key (i.e. specific for each day of an infected person) that is being sent to the server. It contains a value from 1 to 8, which can be used to represent a calculated risk defined by the health authority. As an example it could contain an estimate of the infectiousness of the potential infector at the time of contact and, hence, the likelihood of transmitting the disease. The specific values are defined as part of the [app](https://github.com/corona-warn-app/cwa-app-android/blob/master/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/ProtoFormatConverterExtensions.kt) - a motivation of the parameter choices is found in the document [Epidemiological Motivation of the Transmission Risk Level](transmission_risk.pdf).
 
 ### Data Transfer and Data Processing
 

translations/README.de.md

@@ -1,5 +1,5 @@
 <p align="center">
-    <a href="https://www.coronawarn.app/de/"><img src="https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/master/images/CWA_title.png" width="400"></a>
+    <a href="https://www.coronawarn.app/de/"><img src="https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/main/images/CWA_title.png" width="400"></a>
 </p>
 
 <hr />

translations/pruefsteine.de.md

@@ -4,7 +4,7 @@ Der Chaos Computer Club (CCC) hat einige [Minimalanforderungen](https://www.ccc.
 
 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.“
 
-Dieses Dokument beschreibt, inwieweit die [aktuelle Architektur](https://github.com/corona-warn-app/cwa-documentation/blob/master/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.
+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.
 
 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.