From 6ef01d9ee4951b4215b14b75fb2992b729ef5c5f Mon Sep 17 00:00:00 2001 From: Sebastian Wolf Date: Tue, 14 Jul 2020 11:33:51 +0200 Subject: [PATCH] Some spellchecking updates... --- .spelling | 95 ++++++++++++++++++++++++++ INSTALL.md | 31 +++------ backend-infrastructure-architecture.md | 2 +- scoping_document.md | 2 +- solution_architecture.md | 4 +- 5 files changed, 109 insertions(+), 25 deletions(-) diff --git a/.spelling b/.spelling index 8c2151f..f5e8fe6 100644 --- a/.spelling +++ b/.spelling @@ -1,28 +1,123 @@ +14-day +24-hour +alex +amongst +analytics +APIs +APNs backend Backend +barcode +barcodes +BlackDuck +blacklist +broadcasted Bundesbeauftragter Bundesnetzagentur +Changelog +Changelogs +changelog +changelogs +Checkmarx Commonmark +commonmark +config +Config coronavirus Covid-19 +cwa-app-android +cwa-app-ios +cwa-server +cwa-testresult-server +cwa-verification-iam +cwa-verification-portal +cwa-verification-server +CxSAST +Cyber +cyber +DDoS +deanonymize Deutsche +DP-3T e.g. en_US +epidemiologically +flyer +focussing Gesundheitsamt +hacktivism +hardcoded +Hardcoded +how-tos +i.e. +IfSG Informationsfreiheit Infrastrukturen iOS Kritische linter +linters +Lifecycle +lifecycle +logfile +logfiles macOS +markdownlint.json Metadata +metadata +misconfiguration +natively npm +Onboarding +onboarding +package.json +PEPP-PT +PostgreSQL +pre-printed Probenbegleitschein +Protecode pseudonymized +rebase +reinstall +reinstalls +remediate +Remediate +resize RPIs +SafetyNet +sap.com +Sarbanes-Oxley SARS-CoV-2 +sexualized +socio-economic +SonarQube +Synopsys TalkBack +TEK +TEKs Telekom TeleTAN +TeleTANs +teleTAN +teleTANs +timeframe +timestamp +timestamping +Timestamping tl;dr +tl +Tx UI +uninstallation +Uninstallation +unlinkability +Unlinkability +Unobservability +unobservability +unsecure +up-to-dateness +useable +versioning +Vulas +whitelist +WhiteSource \ No newline at end of file diff --git a/INSTALL.md b/INSTALL.md index 92dc7b1..1b17bc0 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -33,8 +33,7 @@ To run all the linters please install for your OS: ## Installation -For linting and all the checks you need several npm packages. The following -command installs all necessary npm dependencies: +For linting and all the checks you need several npm packages. The following command installs all necessary npm dependencies: ```shell npm install @@ -44,8 +43,7 @@ This installs all dependencies into a local `node_modules` folder. ## Checks -To enforce good spelling and specification conformity there are several checks -defined as `npm run-script` targets. To run all checks please execute: +To enforce good spelling and specification conformity there are several checks defined as `npm run-script` targets. To run all checks please execute: ```shell npm test @@ -59,7 +57,7 @@ Every individual check can be run like so: ```shell npm runscript my-individual-check ``` -See the package-json file for help. +See the package.json file for help. #### Markdown linter @@ -71,8 +69,7 @@ npm run-script markdownlint ##### Overrides -Sometimes it is not possible to be commonmark conform. In this -rare cases an inline tag to skip linting is possible. +Sometimes it is not possible to be commonmark conform. In this rare cases an inline tag to skip linting is possible. Candidates are tables. @@ -83,11 +80,9 @@ Candidates are tables. ``` -Additionally html image tags can be allowed globally. This is useful if you need -to resize images, since commonmark has no annotation for this. +Additionally HTML image tags can be allowed globally. This is useful if you need to resize images, since commonmark has no annotation for this. -This is done with a .markdownlint.json override file which would look something -like this: +This is done with a .markdownlint.json override file which would look something like this: ```json { @@ -100,8 +95,7 @@ like this: } ``` -For more information how to tweak overrides consult the markdown linter -documentation mentioned above. +For more information how to tweak overrides consult the markdown linter documentation mentioned above. #### Spell checker @@ -119,16 +113,13 @@ Not implemented yet. ##### Overrides -Add any additional words to the .spelling file and use the target to sort -and clean them before adding these to master. +Add any additional words to the .spelling file and use the target to sort and clean them before adding these to master. ```shell npm run-script format-spelling ``` -Please note sometimes overriding is not the way to go. For example there may be -three ways for the word TeleTan (TeleTAN, teleTAN) in this repository. The -documents should stick to one variation. +Please note sometimes overriding is not the way to go. Our terminology should be applied consistently. #### Link resolver @@ -140,9 +131,7 @@ npm run-script checklinks #### Inconsiderate language scanner -This checks against profanity and inconsiderate language. This is help full for -non-natives to detect words that could be inconsiderate. This utilizes -[alex](https://github.com/get-alex/alex) +This checks against profanity and inconsiderate language. This is help full for non-natives to detect words that could be inconsiderate. This utilizes [alex](https://github.com/get-alex/alex) ```shell npm run-script detect-inconsiderate-language diff --git a/backend-infrastructure-architecture.md b/backend-infrastructure-architecture.md index b2de9da..d2b7e1b 100644 --- a/backend-infrastructure-architecture.md +++ b/backend-infrastructure-architecture.md @@ -3,4 +3,4 @@ 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 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 file. diff --git a/scoping_document.md b/scoping_document.md index 5fa65ef..a18c9fc 100644 --- a/scoping_document.md +++ b/scoping_document.md @@ -141,7 +141,7 @@ the app have different needs. 4. **Infection case** - If an app user tests positive for SARS-COV-2 infection, they can voluntarily + If an app user tests positive for SARS-CoV-2 infection, they can voluntarily publish the pseudonymized warn IDs saved in their app. That way, other app users can use their smartphones to find out whether they have been exposed to the infected user. diff --git a/solution_architecture.md b/solution_architecture.md index d7dcded..e5da7c9 100644 --- a/solution_architecture.md +++ b/solution_architecture.md @@ -82,7 +82,7 @@ The TAN is used as authorization in the HTTP header of the POST request for uplo Note regarding *Figure 3* and *Figure 4*: The white boxes with rounded corners represent data storage. The HTTP method POST is used instead of GET for added security, so data (e.g. the registration token) can be transferred in the body. -As mentioned before, users might have decided against retrieving test results electronically, or the lab may not support the electronic process. Step 3 of *Figure 2* shows that in these cases the health authority (“Gesundheitsamt”) reaches out to the patient directly. Also during this conversation, the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding a positive test result, they can choose to receive a teleTAN. The teleTan is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5) who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17). +As mentioned before, users might have decided against retrieving test results electronically, or the lab may not support the electronic process. Step 3 of *Figure 2* shows that in these cases the health authority (“Gesundheitsamt”) reaches out to the patient directly. Also during this conversation, the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding a positive test result, they can choose to receive a teleTAN. The teleTAN is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5) who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17). ![Figure 4: Verification process for teleTAN received via phone](images/solution_architecture/figure_4.svg "Figure 4: Verification process for teleTAN received via phone") @@ -226,7 +226,7 @@ Additionally, a central threshold for the combined risk score specifies whether Furthermore the Google/Apple framework allows to set a [```minimalRiskScore```](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration/3583692-minimumriskscore) to exclude exposure incidents with scores lower than the value of this property. In the current version of the API the time spent within the ranges of attenuation buckets are accumulated over all exposure incidents during one matching session. Since the number of requests is currently limited, it is not possible to get these values for each day and each exposure incident separately. -While by default there is no minimum value set, this value is being configured accordingly, so that resumably irrelevant exposure incidents are excluded. +While by default there is no minimum value set, this value is being configured accordingly, so that presumably irrelevant exposure incidents are excluded. ![Figure 13: Calculation of the combined risk score](images/solution_architecture/figure_13.svg "Figure 13: Calculation of the combined risk score")