generaliinformatik / mycoradar Goto Github PK

The READMEs in directories

/app
/baking
/docs

should be present and filled with helpful information. The information supplements the general information with technical information relevant to the component in the respective subdirectory. The format is still to be agreed, but should be based on standard boilerplates and recommendations.

The STORY.md must be written to or deleted. Content of the file is the story of our team and the hackathon.

Add license header to all readable (non-binary) files (wherever possible)

Fix the README.md (and all language specific READMEs) to filter feature requests (closed and open). The working filter statement looks like:

is:issue -label:bug -label:duplicate -label:"good first issue" -label:"help wanted" -label:invalid -label:question -label:wontfix -label:generali -label:documentation -label:website

This is a workaround for the missing function of the logical operators at github queries (missing OR query)

(assuming that the current labels remain as they are)

The necessary configuration files for the frontend and backend (where required) must be described in the README in the corresponding subdirectory.

Folgende Erweiterung des aktuellen Zustandes soll erreicht werden (aktueller Stand aus unserer gestrigen Diskussion). Bitte Erweiterungen, Korrekturen etc. als Antwort melden.

Funktionsweise

My co:radar ("die App") arbeitet als lokaler Service auf dem Mobiltelefon des Anwenders. Die App generiert beim ersten Aufruf eine eigene zufällige Kennung ("UUID"), die zudem mit einem gerätespezifisch generierten Code ("Code") gesichert wird. Dieser Code wird in der App als Klartext-Information für den Anwender angezeigt und ist später auch als QR-Code abrufbar.

Die App scannt alle 2:30 Minuten (konfigurierbar) per Bluetooth nach weiteren Geräten mit der App ("Ping"). Andere Geräte mit der App senden eine Bestätigung ("Pong") mit der eigenen UUID, die in der suchenden App lokal auf dem Gerät gespeichert wird ("Kontakt"). Gespeichert werden UUIDs des Kontakts und Zeitstempel des Kontakts.

Dabei ist für die abfragende App relevant, wie dicht man sich an anderen Geräten befindet (Signalstärke Bluetooth) und wie lange man sich in der Nähe des anderen Geräts aufhält (Anzahl der Pings). Diese Werte richten sich nach den Empfehlungen des Robert-Koch-Instituts ("RKI"): weniger als 2 Meter Abstand und länger als 15 Minuten. Diese Angaben lassen sich bei Bedarf anpassen.

Wird ein Anwender eines Gerätes nun als positiv COVID-19 getestete, meldet die App darauf hin alle in Kontakt gestandenen UUIDs der vergangenen 14 Tage (anpassbar; gemäß Empfehlung des RKI) an einen zentralen Service ("Backend").

Andere Geräte fragen über das Backend nun regelmäßig die EIGENE UUID gegen diesen Service ab und erhalten eine Rückmeldung. Diese kann entweder Wahr/Falsch oder eine konkrete Handlungsempfehlung beinhalten. Die Ausgabe erfolgt nur nach erfolgreicher AuthZ durch die App und betrachtet zudem nur die Daten, die gemäß RKI-Empfehlung relevant sind (z.B. 14 Tage). Das Backend löscht regelmäßig nicht mehr relevante UUIDs aus dem eigenen Bestand.

Die Nutzung der App als Service hat dabei den Vorteil dass die UUID nur an die App und nicht an das Gerät gebunden ist und bei einer Löschung der App die lokalen und auf dem zentralen Service gespeicherten UUIDs nicht mehr nutzbar sind (Exit-Strategie). Durch das Neugenerieren der UIUID bei erneuter Installation der App wird zudem sichergestellt, dass der Anwender selbstbestimmt an dem Datenaustausch teilnimmt.

Geplanter Informationsaustausch bei Abfragen:

1. UUID lokal generieren
2. Code lokal generieren (oder durch Anwender definieren)
3. UUID und Code an Server melden
4. Server hasht Code ("Hash")
5. Server speichert UUID und Hash
6. weitere Abfragen dann per UUID und Code
7. Server hasht wieder den Code
8. Server vergleicht Hashes und antwortet erst bei übereinstimmung

Ausblick:

• Abfrage von befreundeten/familären UUIDs, wenn die gerätespezifischen Kennwörter bekannt sind
• 2FA zur Meldung einer Infektion

Hi there,

we're another project from the WirVsVirus hackathon and are trying to tie together all the international efforts that try to work on this problem.

Which leaves the question: How can we best work together? :-)

We coordinate here right now, I would very much like to invite (some?/all?) of you to join our discord or use any other means necessary so we can get into contact.

https://start.ito-app.org

The international website for my co:radar is to be built for the domain mycoradar.eu. The contents are to be described according to the German website. At a later point in time, consideration should be given to how the contents are to be synced between the mycoradar.de and mycoradar.eu sites. Ideally, the website should only represent a static framework in which further content is dynamically integrated.

Im not sure why you would need BlueTooth?
I wanted to run a Test in Bluestacks Android Emulator which doesnt Support BlueTooth anyway so i always gets stuck at "turn BlueTooth on"

Apps should not request permissions to things they don't need in my opinion, or do you need use it for tracking proximity? Can't see that from the chart?

the internal profile for the repository must be created and filed in the designated place.

Responsible:
@rfuehrer @dehesselle

Translate the README to english to address english speaking contributors.

This is one of the tasks from the team vote of 25th March 2020. With the development of the website mycoradar.eu, which is also to be written in English, English-speaking interested parties may be increasingly addressed

Fix the additional asterisk in "Desiree - *Frontend"

Add the attached favicon.ico to the root of our websites to be shown in browsers as website icon.

mycoradar.de
mycoradar.eu

favicon.ico.zip

Sample (from Github):

The words in logo picture should be english in englisch README. The picture has to added and linked.