 C, W, A. Drei einfache Buchstaben. Aber was dahinter steht, ist nicht sonderlich einfach. Aus unterschiedlichen Gründen ist die Corona-Warn-App eins der am neuesten gesprochenen digitalen Projekten des Jahres. Es gibt viele Entscheidungen, die da reingeflossen sind, wie sie designt wird, um die Benutzer und die Daten zu schützen. Aber was viele Leute nicht sehen, ist, dass diese Anforderung eine direkte Anfrage direkt daran gearbeitet hat, wie die aufgebaut ist. Und wir haben hier einen der Architekten der Corona-Warn-App. Ich bin wahrscheinlich nicht der einzige hier auf dem RC3, der ein aktiver Benutzer ist. Und ich hoffe, mehr darüber zu erfahren, was hinter den Zähnen der App passiert. Also ohne weiteres Warten, einen großen Applaus für Thomas Klingbeil. Thomas, das ist dein Stream. Hallo, alle zusammen. Ich bin Thomas Klingbeil und ich werde heute über die deutsche Corona-Warn-App reden. Ich zeige euch, was hinter der App-Entwicklung passiert. Die Technologien, die dabei sind, sind Sachen, die vom Affinit-Benutzer unsichtbar sind, aber sehr wichtig für die Anwendung selber. Zuerst eine kleine Einleitung darüber, wie die App aufgebaut ist und die Technologien, die im Hintergrund benutzt werden. Dann werde ich ein bisschen darüber reden, wie die App mit dem Backend kommuniziert und schauen, welche möglichen Privatsphären Probleme dabei existieren, wie man sie umgehen kann. Und dann werden wir ein bisschen über die Risikoberechnungen gehen und euch zeigen, was es bedeutet, wenn ein roter oder grüner Bildschirm sichtbar ist. Die erste Frage, was ist diese Corona-Warn-App eigentlich? Das ist die Corona-Warn-App. Ihr könnt sie vom Appstore herunterladen. Und wenn ihr die App gestartet habt, dann seht ihr, dass das Login aktiv ist. Das heißt, es ist eine aktive App. Und dann diese grüne Karte, das bedeutet, es gibt keine Exposures. Es ist aktiv und es hat gerade diesen Nachmittag geupdatet. Das heißt, alles ist in Ordnung. Und wenn ihr jetzt gerade getestet wurdet von einem Doktor, dann könnt ihr hier drauf drücken und die Seite zu bekommen, wo ihr einen Testergebnis digital bekommen könnt. Dazu müsst ihr einen QR-Code scanen, den ihr von eurem Doktor bekommt. Und dann bekommt ihr ein Update, sobald ein Testergebnis verfügbar ist. Ihr könnt auch weitere Informationen über die App bekommen. Wenn ihr den Knopf hier oben drückt, dann kriegt ihr diesen Bildschirm, auf dem ihr mehr darüber lernen könnt, wie das Logging funktioniert. Weil die deutsche Corona-Warn-App nicht alleine ist. Sie ist verbunden mit anderen Corona-Apps. In anderen Ländern innerhalb von Europas. Und Benutzer von anderen können einander treffen und über gefährliche Treffen informiert werden. Nur, um ein bisschen mehr über die Technologie zu reden über das Framework. Und dann seht ihr auch, was wir während des Sessions reden werden. Es beginnt alles mit einem temporären Exposure-Key, der auf dem Telefon erstellt wird und für 24 Stunden gültig ist. Von diesem Schlüssel werden unterschiedliche Sachen abgeleitet. Das eine ist der rollende Proximität-Key und den reichenden, verstößtete Metadatenschlüssel. Der untere Teil können wir jetzt erstmal ignorieren und reden darüber, wie dieser rollende Nachbarschafts-Identifizierer funktioniert. Die werden alle 10 Minuten ausgeteilt und sind auch nur für 10 Minuten gültig. Und der rollende Nachbarschafts-Notifizierer ist das, was von über Bluetooth gesendet wird. Alle 250 Minisekunden sendet das Telefon seinen eigenen Identifizierer aus und andere Telefone in der Nachbarschaft, die für diese Signale suchen, die empfangen können und die lokal speichern können. Also lasst uns mal die Empfangs-Seite anschauen. Hier sehen wir das und wir bekommen diese Bluetooth Low Energy Beacons, die hier ankommen. Und das ist auch eine sehr vereinfachte Darstellung, nur um euch ein kleines Gefühl davon zu geben, was hier alles passiert. Jetzt haben wir diese Rollen dann nahe und jetzt muss das andere Telefon herausfinden, ob es ein Match gibt. Das funktioniert dadurch, dass diese temporären E-Clies in Diagnosischlüssel weit umgeleitet werden können. Das ist einfach nur eine Umbenennung. Aber sobald jemand positiv getestet würde und eine positive Diagnose gibt, dann nennt sich das ein Diagnosischlüssel. Die werden zum Server hochgeladen und dann, sehr viel vereinfacht, werden sie vom anderen Telefon empfangen. Hier werden sie heruntergeladen und die ganzen Diagnosischlüssel werden extrahiert. Und dieselbe Funktion wird angewendet, eine Keyderivation Funktion, dann AES, und dann haben wir hier ganz viele Identifizierer, die wir hier überprüfen können. Und hier oben sind die Gespeicherten und jetzt können wir die vergleichen und schauen, ob es einer dieser schon bekannt ist. Und das empfangende Telefon kann auch überprüfen, dass die rollenden Schlüssel zu einem einzelnen Diagnosischlüssel gehören. Das heißt, sie gehören zu einem anderen Telefon, die miteinander verbunden war. Das heißt, wir können auch herausfinden, welche Dänger als 10 Minuten dauern. Das heißt, wenn man sich 90 Minuten lang trifft, dann würden wir hier die neuen Keys finden und eine einzige Verbindung daraus machen. Und die wird auch mit diesen zusätzlichen verstöckelten Daten erweitert. Das ist einfach die Sendestärke und als Übersicht hier unten anzeigen. Jetzt, weil wir wissen, welche Informationen von einem Telefon zu einem anderen Telefon übertragen werden, können wir die Architektur uns anschauen. Diese graue Kiste ist ein Mobiltelefon und hier unten ist die deutsche Corona-Wahlen-App, die gestrichelte Linie. Das bedeutet, hier ist weitere Informationen online verfügbar. Das heißt, ihr könnt auf das GitHub-Repository gehen und unseren Code anschauen und die ganze Dokumentation natürlich auch. Und wir haben da noch weitere Diagramme. Und wie ihr hier sehen könnt, die App selber speichert nicht viele Daten. Hier wird gespeichert, also es speichert nur etwas in Registrierungstoken und die Kontaktjournaleinträge. Das ist alles, was die App selber speichert. Was ihr hier sehen könnt, ist, dass es mit dem Betriebssystem verbunden ist, mit dem SDK, das Exposure-Notifikations-Framework, dass die ganzen Schlüssel sammelt und weiter sendet und überprüft. Und dann gibt es einen Protokoll-Buffer, den wir benutzen für den Datentransfer und wir benutzen das Betriebssystem, die Kryptografie-Bibliothek des Betriebssystems oder deren Bibliotheken, das wir da keine externen Bibliotheken benutzen müssen. Was ihr hier sehen könnt, ist, dass das Betriebssystem SDK für Push-Nachrichten, das sind nicht remote Push-Notifikationen, sondern lokale. Hier werden Lokale und die Notifikationen sendet werden, die dann so erscheinen, als ob die Push-Nachrichten von einem externen Server kommen. Aber es sind nur lokale Nachrichten. Aber was wäre die App ohne die Big-End-Infrastruktur? Hier könnt ihr sehen, das ist die Server-der-Corona-Warn-App. Das ist die, die die ganzen Daten sammelt und den Upload-Fahrt wird hier hochladen und wird an einen Inhalts- und Auslieferungs-Netzwerk verbunden. Aber wir haben noch mehr. Wir haben die Verifikations-Servat, die den Job haben, die positive Testergebnisse zu überprüfen. Und wie machen sie das? Es gibt zwei Arten und Weisen. Die Information, dass ein Test positiv war, durch ein Teletan bekommen. Sie rufen an die Hotline an, kriegen einen Teletan, geben sie in ihre Anwendung ein und dann könnte die Diagnose ein Schlüssel hochladen. Oder wenn Leute, die vollen digitalen Weg gehen, dann kriegen sie ein Testergebnis durch die App und darum haben wir hier auch ein Testergebnis-Servat, der von dem Verifikations-Servat angefragt werden kann, sodass Benutzer ihre Testergebnisse durch unsere Infrastruktur bekommen können. Aber das ist auch noch nicht alles, weil, wie ich hier versprochen habe, wir haben die Verbindungen zu anderen europäischen Ländern. Das ist hier unten, ist das Gateways-Service der Europäischen Union und da können wir ein und unsere eigenen Schlüssel hochladen. Das heißt, andere Laden können auch unsere Schlüssel bekommen, sie ihren Benutzern weiterleiten. Aber wir können auch fremde Schlüssel weiterleiten und wir können auch Informationen darüber bekommen, wenn neue fremde Schlüssel verfügbar sind. Und das ist hier auf der rechten Seite. So, wenn die App mit dem Backend kommuniziert, was würde wirklich passieren, wenn jemand zuhört? Wir haben hier unsere Datenflüsse. Lass die uns mal anschauen. Im ersten Schritt kennen wir den QR-Code mit einer Kamera des Telefons und holen uns daraus eine GUID, die die Corona One App bekommt. Und wir können hier sehen, es wird nie in der App gespeichert. Das ist sehr wichtig, weil wir sicherstellen wollen, dass so wenig Informationen wie möglich auf der App gespeichert werden müssen, in der App gespeichert werden müssen. Und es ist unmöglich, unterschiedliche Sources zu benutzen, um Diagnose-Schlüssel zum Beispiel auf eine GUID zurückzuführen zu können, um eine Person zu identifizieren. Das darf nicht möglich sein. Also haben wir hier sicherstellen müssen, dass keine Daten zusammengespeichert werden müssen und die Daten einfach nicht wieder verbunden werden können. Das heißt, im ersten Schritt haben wir die GUID und die wird auf dem Telefon gehashed, auf den Verifikationshauber gesendet und der erstellt ein Registrationstoken und speichert es zusammen und speichert den hashed GUID und den Registrierungstoken. Das heißt, die GUID kann nur einmal benutzt werden den Registrierungstoken zurück zur App. Jetzt kann die App den Registrierungstoken speichern und ihn benutzen, im Schritt 5, um nachzufragen, ob es Testergebnisse gibt. Aber die Testergebnisse sind nicht auf dem Verifikationsserver verfügbar, aber die Verifikationsserver verbindet sich mit dem Testergebnisserver mit der hashed GUID, die sie aus dem Registrierungstoken erfahren können und dann kann den Testergebnisserver schauen, wo da vielleicht ein Testergebniss hinterlegt ist. Und diese Überprüfung wird gemacht, weil das Testergebnisserver vielleicht auch keine Informationen zu einer hashed GUID hat. Das bedeutet einfach nur, dass kein Testergebniss bis jetzt gefunden wurde. Das ist was hier im Schritt A passiert. Das Laborinformationssystem kann ein hashed GUID und das Testergebnis zum Testergebnisserver weiterleiten. Und wenn es schon verfügbar ist, dann wird es zum Verifikationsserver weitergeleitet im Schritt 7 und wo relevant an die App weitergeleitet. Ihr könnt vielleicht sehen, das Testergebnis ist nie gecached oder auch nie gespeichert auf dem Verifikationsserver. Das heißt, wenn der Testergebnisserver dann wieder eine TAN notwendig ist, wenn er den Schluss seiner eigenen Schlüssel hochladen möchte, der Benutzer, dann muss hier in Schritt 9 wieder ein Registrierungstoken zum TAN Endpunkt weitergegeben werden kann. Wieder auf den Verifikationsserver. Es muss wieder geschaut werden, ob es ein positives Testergebnis ist. Und dann wieder Schritt 11, dann wird eine TAN gereneriert. Beim Schritt 12, die TAN wird wieder hier nicht gespeichert, sondern es wird ein hash gespeichert. Und der Pentax-Wert ist wieder in die App weitergeleitet, die dann wieder ein Diagnose-Schlüssel erstellen kann aus dem Diagnose-Framework und das auf die Corona-Warn-App-Server hochladen oder den Eingabeserver. Aber der muss auch verifizieren, dass es stimmt. Das heißt, die nehmen die TAN, im Schritt 15 zum Verifikationsserver, wo die TAN validiert wird und die Validierung bedeutet, es wird als gebraucht benutzt. Das heißt, diese TAN kann nur einmal benutzt werden, dann wird das Ergebnis zum Becken zurückgegeben, die, wenn es positiv ist, das heißt, wenn es eine gültige TAN ist, den Diagnose-Schlüssel an seinen eigenen Speichern legen. Und nur die Diagnose-Schlüssel werden hier gespeichert und nichts weiter. Das heißt, es gibt keine Koalition, die möglich ist zwischen den Diagnose-Schlüsseln, den Registrierungstokens, in dem Gültzweitessen komplett unterschiedliche Systeme sind. Aber trotzdem, was könnte man herausfinden über die Nutzer, wenn jemand sich den Netzwerk-Traffic angucken würde. Und eins als Anfang war ja, dass der Inhalt aller Nachrichten sicher ist, denn da nur gesicherte Verbindung verwendet werden. Und nur die Größe der Transfers kann man sich vom Netzwerk aus anschauen. Das heißt, wenn wir uns das vom Netzwerk Sniffing angucken, können wir uns sehen, dass eine Verbindung stattfindet. Wir können sehen, wie viele Bytes transferiert werden. Aber wir können nicht verstehen, was der Inhalt der Nachrichten ist. Also wir können uns als Erstes bei der Koalition angucken, ah, die Person ist getestet worden. Wir können sehen, dass jemand etwas vom Registrierungstokentpunkt anguckt. Dann hat diese Person mal einen Test bekommen. Und vielleicht an diesem spezifischen Tag. Dann die nächste Kommunikation, die stattfindet, ist der Schritt 5. Das heißt, die Person ist getestet worden. Und das wissen wir vielleicht schon vom Schritt 2. Aber die Person hat ihr Testergebnis und nicht bekommen. Es könnte immer noch positiv oder negativ sein. Und wenn wir uns jetzt beobachten können, dass der Registrierungstokentpunkt stattgefunden hat, dann wissen wir, dass die Person positiv getestet worden ist. Okay. Das ist der Art of WS. Aber wir können ja gar nicht wissen, welcher Endpunkt angefragt wurde. Aber es gibt vielleicht bestimmte Requestgrößen, an denen wir sehen können, ob die Richtung in der Request geht. Das ist vielleicht ein Gedanke. Okay. Und dann, of course, wir haben den Übermittlungsservice an Schritt 14, wo der TAN übertragen wird. Und das ist wirklich ohne jegliche Möglichkeiten zur Diskussion. Denn wenn eine App den Corona One App Server kontaktiert, dort eine Verbindung herstellt, das muss sein, wenn der User positiv business und Diagnosischlüssel übermittelt. Aber darüber hinaus, sobald der Nutzer das getan hat und sobald die Diagnosischlüssel übertragen hat und die Apps mit dem Corona-Backend redet, das kann natürlich sein, um diese Schlüssel zu einer IP-Adress verbinden. Und könnte man da vielleicht drüber umgehen? Was wir hier also brauchen, ist lausible Denialability. Das heißt, Verneinbarkeit herstellen. Und wir müssen so mit so viel Krach quasi bei den Verbindungen erzeugen, dass es nicht möglich ist, zu definieren, welche Individuen diese Verbindung benutzt haben, um Corona-Test-Ergebnisse zu übermitteln, Test-Ergebnisse zu erhalten, positive Ergebnisse zu bekommen und TAN- oder Schlüssel zu übertragen. Also ist das Schlüssel hier tatsächlich diesen Lärm zu erzeugen. Und wie die App das tut, ist das simulierte, den Backend-Traffic oben quasi gefälschte Anforderungen zu verwenden. Das heißt, wir nennen dieses, das ist ein Playbook, was die App tun soll, wie sie warten oft warten soll, was die große Bemittlungen machen soll. Und es ist interessant, die können vielleicht sogar von einem real Event, vom echten Event, aber vielleicht auch von einem zu verliegenden Tracker gemacht werden. Das heißt, das können einen QR-Code oder einen TAN machen, bestellt auch diesen Vorgang. Und man dann diese Token bekommt und dann die Testergebnisse bekommt, was normalerweise für jetzt ein Tag gedauert. Das hört irgendwann auf. Aha, das heißt, passiert, da ist irgendein Ergebnis gewesen, also positiv oder negativ. Wenn es dann bedeutet, dass danach der Übermittlungs-Service kommt, das würde heißen, dass es positiv gewesen ist. Das heißt, was die App tut ist, sogar wenn es negativ ist, sind es weite, da mehr Request an den Variation-Surfer. Das heißt, es kann manchmal, das ist rein zufällig, es kann dann sogar sich eine gefakete TAN holen. Und es mag sogar Fake-Uploads von Diagnose-Kies. Das heißt, die App weiß nicht, ob das tatsächlich echte Daten sind oder ob das die App irgendwelchen Playbook Unsinn macht. Also, um hier quasi einfach diesen Kraftzeugen ob es wirklich Diagnose-Kies sind. Das heißt, man kann es nicht unterscheiden, wo es herkommt. Und um sicherzustellen, dass unser Backend nicht mit Fake-Requestes umbestimmt wird, gibt es einen speziellen Hader, dass der Backend diese Request zu ignorieren soll. Wenn sie einfach ignorieren würde und dann keine Antwort sehen würde, könnte man beim Kleinen zwar so einrichten, aber dann könnte der Netzwerksniffer identifizieren, dass das einfach gefakete Request sind. Das ist Backend, das mit den Datenbank-Request darunter ignoriert. Aber es ist nach einer Verzögerung zur Response dann tatsächlich, die Inter-Response-Zeit ist genau so groß, wie als wenn es ein echter Request wäre. Und was wir dann auch machen, das sind beide Richtungen zwischen dem Kleid im Server, wird ein bisschen Padding erstellt. Das heißt, es ist immer die gleiche Größe. Das heißt, egal was dann eigentlich darin passiert und was in der Datenpaketin darin steht. Das heißt, das Reihen beobachten der Datenpakete und der Größe würde nicht helfen, wirklich zu gucken, was eigentlich passiert. Nein, das kann man sagen. Also wenn jetzt so viel zusätzlicher Traffic passiert wegen den Fake-Request wegen den Fake-Uploads und so weiter, das muss doch eine Menge kosten für die Nutzer. Und das ist stimmt zwar, das ist alles zero rated mit den deutschen Befunkanbietern, das heißt, das wird nicht für die Endrunden kostenpflichtig. Jetzt ist dann immer noch ein Thema zum Extrahirn von Metadaten, wenn man die Diagnose Schlüssel hoch lädt. Und diese Metadaten sind zum Beispiel die Queller-Gene oder der User-Agent, also dass man Android und iOS unterscheiden könnte und vielleicht könnte man auch was herausfinden über die Trips Team-Vision. Und damit man das nicht machen kann, haben wir einen Zwischenserver, der die Metadaten abschneidet und nur den Inhalt der eigentlichen Pakete zum Backend transportiert. Der Backend-Service nicht weiß, wo das Paket eigentlich herkommt. Das kommen wir zur Risikoberechnung. Also da können wir uns mal genau angucken, welche Informationen verfügbar sind. Also, hier gibt es eine Information über die Treff-Events, also über die Näherberechnungen. Und diese Informationen kommen in 30 Minuten um Aussetzungsfenster. Das heißt also, alle Events gehen an die gleichen Diagnose-Key. Und was die macht, ist, dass die einzelnen Verbindungen in 30 Minuten-Fenster aufteilt und die ersten Skennet- Entfernung, wo ein anderes Gerät identifiziert wird, ist die Kindesfenster und dann dauert es bis 30 Minuten voll sind. Und wenn wir weitere Verbindungen mit dem selben Schlüssel haben, dann wird das Fenster neu geöffnet. Ein einziges Fenster hat nur ein einziges Gerät. Das heißt, es ist ein Mapping von 1 zu 1 Mapping. Und innerhalb des Fensters können wir die Einzahl der Scanneninsanzen haben. Das findet alle 3-5 Minuten statt. Und in diesen Scannen-Entfernung gibt es auch unterschiedliche Scans. Und wir nehmen die minimalen und durchschnittlichen Reduktion. Und das ist die angegebene Sende-Power mit nur die Empfangsstärke. Und das zeigt einfach wie viel Signalstärke verloren ging. Wenn sie sehr klein ist, dann war das Gerät sehr nah. Wenn sie höher ist, dann bedeutet es, dass das Gerät weiter weg ist. Und die andere Richtung, durch den Diagnose-Schlüssel, die wir auf den Zerber hochgeladen hatten und durchgeschaut und über das CDN verteilt wurde, können wir auch sehen, die Infektion über die Infektion nicht bekommt. Das ist ein Transmissions-Risiko-Level. Wie infektionär die Person ist. Und das gibt uns wie groß die Infektionsrisiko an diesem Person an diesem Tag war. Also die Übertragungsrisiko-Levels erhängt vom Symptomstatus an. Und das Symptomstatus ist der Person Symptome, möchte sie über ihre Symptome reden oder vielleicht wenn sie nicht über ihre Symptome reden. Und zusätzlich wenn sie Symptome gibt, sehen wir, ob wann die Symptome begonnen haben. Das mehrere Tage waren, in denen sie Symptome gestartet haben. Oder Leute können auch sagen, ich weiß es nicht, aber mit Sicherheit. Also das ist der erste Fall. Leute können sagen, wenn ihre Symptome gestartet begannen haben, dass der Symptom-Statttag hier unten und um den Tag herum gab es relativ gleich, also das Infektions-Risiko relativ gleich. Das bedeutet, gut bedeutet hohes Risiko, blau bedeutet kringes Risiko. Wenn man der Symptom-Statttag weit verschiebt, dann fehlt sich auch die Infektionsrate und die Infektion sie haben einen Matrix wo die Information herkommt und das Ganze ist im Kölkurt verfügbar. Und es gibt auch die Möglichkeit, dass man sagt, hey, die Symptome beginnen in den letzten sieben Tagen. Das ist hier oben der Fall. Es ist ein bisschen anders verschoben. Leute können auch sagen, ich bin vor eins oder zwei Wochen und sieht mir das hier und die dritte Karte ist der Fall, wenn die Symptome vor mehr als zwei Wochen begannen. Jetzt ist hier der Fall, wo der Benutzer spezifiziert, dass sie gerade ein positives Testergebnis bekommen haben. Das heißt, sie haben Sicherheit Corona, aber sie nie Symptome hatten. Das heißt, es konnte sein, aber hier sehen wir, dass ungefähr um den Bereich das hier eine erhöhte Risiko ist, aber die ganze Zeit davor nur eine geringe Infektionsrisiko hat. Wenn ein Benutzer spezifiziert, dass sie Symptome hatten, aber nicht wussten, wann sie begannen, dann ist es ein bisschen anders verteilt und genauso wenn die Benutzer ihre Information stellen wollen, ob sie Symptome haben oder nicht. Also, sie haben dieses Risiko- Berechnungsformular Links haben wir die Konfigurationen, die in die Notifikations- Framework eingeschrieben werden. Es gibt ein paar Mappings, die wir brauchen und diesen Framework von uns braucht. Es gibt ein paar interne Konfigurationen, weil wir beschlossen haben, dass wir das Risiko- Berechnung in der App machen, weil wir 8 Level haben wollen anstelle der 3 Level, die Niedrigstandard und hoch die Apple und zur Verfügung stellt. Um diese 8 Level zu haben, haben wir die Infektionsparameter, die aus den besprochenen und das Ergebnis. Und wir haben hier immer in Europa einen konfirmierten Test oder einen bestätigten Test. Das heißt, wir haben diese 3 Dinge, die wir jetzt benutzen können, um einen Infektionsrisiko zu errechnen. Das wird auf dem Server berechnet, wird den Schüssel angehängt und wird von den Apps darunter geladen. Und dann wird sie durch die Berechnung gepasst, hier rein und wird aus diesen 2 Parametern berechnet und wird jetzt weitergeleitet. Zuerst die Frage ist die Summe der unter 32 Dezibel, dass es das erste Anforderung weniger als 10 Minuten ist. Wenn es weniger als 10 Minuten war, dann wird es einfach ignoriert. Wenn es mehr oder gleich oder mehr als 10 Minuten war, dann könnten wir es benutzen, abhängig davon, ob das größer oder kleiner 3 ist. Und wenn es größer oder gleich 3 ist, dann berechnen wir die relevanten Zeit und die Zeit zwischen 45 und 63 Dezibel werden nur halb gezählt, weil das ist eine mittelere Entfernung und unter 55 Dezibel hier oben werden voll gezählt, die werden addiert und dann gibt es die normalisierte Exposure Times und mit dem Risikolevel normalisieren wir das Ganze und das wird damit auch multipliziert und wir bekommen hier unten einen normalisierte Exposure Time für jedes Fenster und jedes wird auch wieder aufaddiert für den ganzen Tag und dann gibt es einen 50 Minuten Threshold ob man eine hohe Risiko hat oder einen niedrigen Risik wie man das Infektionsrisiko hat also jetzt wo ihr diese ganzen Berechnungen machen könnt können wir sie nochmal durchgehen durch 3 Beispiele das erste Beispiel ist hier ein Risikolevel 7 hier sind alle relativ nah die Thresholds sind hier oben 35 ob es überhaupt gezählt wird 63 und bei 55 nahe Kontakt und ein bisschen mittlerer im mittleren Bereich also lasst uns vorfiltern es waren mindestens 10 Minuten unter 37 Dezibel ja klar jeder dieser einzelnen Punkte ist in 3 Minuten und für so ein paar Spiele Berechnungen vermutigen wir einfach dass der Scanwindfenster 3 Minuten auseinander ist das mindestens 3 Ja, es ist 7 es gab 18 Minuten mit einer geringen Abstand da dran 18 Minuten und 9 Minuten mit einer mittleren Entfernung ein bisschen weiter und das sind 4,5 Minuten wir haben hier unseren Faktor und insbesondere kriegen wir das bei 35 31,5 Minuten und das bedeutet dass wir einen roten Status bekommen schon mit einem einzigen Fenster jetzt im zweiten Beispiel sehen wir dass wir ziemlich weit weg sind und es gibt eine nahe Verbindung Transmission Level 8 Prefiltering sind 10 Minuten unter 7,3 Dezibel nein also ignorieren wir es und dann das dritte wieder Transmission Level 8 Transfektions Level 8 es hat da ein bisschen weiter weg aber es gab auch ein paar nahe Kontakte das heißt wir schauen das Vorfiltern waren es mindestens 10 Minuten unter 7,30 Dezibel jetzt müssen wir wieder genauer hinschauen ja, wir haben 1 und diese auch wir haben 4 Punkte unter 7,30 Dezibel das Mission Level 3 ja und jetzt können wir das berechnen es waren 6 Minuten mit der niedrigen 5 die sind voll 0 im mittleren Bereich und der Transmission Level ist ein Faktor 1,6 und das multiplizieren wir und bekommen jetzt 9,6 Minuten wenn das der einzige Verbindung an dem Tag ist ist es immer noch grün aber wenn wir 2 ähnliche Verbindungen hatten mit derselben Person oder mit unterschiedlichen Personen dann würde es schon rot werden weil dann sind das nahe an 20 Minuten und das wäre über der 15 Minuten Marke vielen Dank für den Vortrag und für die du zugehört habt und ich werde jetzt nochmal für Fragen und Antworten zur Verfügung stehen vielen Dank Thomas das war ein voraus bezeichneter Tag und die Diskussion war sehr sehr belebt during während der Diskussion und Thomas wird hier für das Q&A sein vielleicht um zu beginnen mit der ersten Frage von Amber von ASC und über Sicherheit und Playback Artikel und Holland haben ASC so zu früh publisiert haben dass es noch verfunden war wie ist das in der europäischen Zusammenarbeit und kann man sie dazu bringen an die Sicherheitsregeln um zu achten das ist eine Frage für dich Thomas alles klar also danke für die Frage ob wir das mit Schlüssel aus anderen europäischen Ländern das machen da gibt es einen europäischen Gateway-Dienst es wird gemacht wie heißt das europäische Quiz-Fan das heißt wir machen eine Art Embargo für zwei Stunden nach dem der Gültigkeit sorgen wether für das Replay-Attacken nicht wirklich sind alles klar ich hoffe das antwortet die Frage es ist eine weitere internationale Interoperabilität ist es nur in der EU oder gibt es auch eine Zusammenarbeit mit der EU und zum Beispiel der Schweiz also so weit haben wir Zusammenarbeit mit den EU-Ländern das heißt für die EU haben wir eine Übersicht welche Apps schon miteinander integrieren und über die Integration von nicht EU-Ländern das ist eine politische Entscheidung die in diesen Orten gemacht werden muss das ist nichts weiß ich als Architekt oder kontrollieren kann aber zur Phase also weit ist das nur die EU-Länder haben wir ein paar Fragen von neuen Features und international Community die manchmal ein bisschen langsam ist dass der Sicht einige Leute zum Beispiel haben das ist ein Vorschlag also ein Crowd-Notifier das heißt dass man Restaurants oder andere Orte quasi über das Kennen in Skrag als informiert, habt ihr davon schon mal gehört könnt ihr mehr zu sagen also ich habe persönlich schon mal gesehen das ist ein Proposal es gibt online dass es da auch Diskussionen gibt was man im Kopf behalten muss ist das die Aufgabe haben das zu entwickeln für das Gesundheitsministerium und die sind diejenigen die Features verlangen können und da gibt es natürlich eine gewisse Entscheidung was im Fokus liegt und nicht aber tut mir leid das zu sagen aber ich als Architekt kann nicht entscheiden welche Regionen welche Funktionen integriert werden und sobald die Entscheidung gemacht werden dass eine neue Funktion ermötigt wird dann kann ich rein und mich um die Architektur dafür kümmern also ich bin nicht mir ist nicht klar wie weit diese Entwicklung gerade sind außerhalb meines eigenen Scopes das ist sicherlich oft bei großen Projekten so der Fall aber grundsätzlich finden Leute das gut dass alles auf GitHub verfügbar ist aber einige Leute sind sehr stark fokussiert und sind ein bisschen enttäuscht davon dass die Interaktion mit der Community auf GitHub ein bisschen langsam ist und es gibt manchmal bei Problemen keine Antwort dass sie etwa ein paar Ideen ob es Community Mensch auf GitHub geben soll für die App so dass die Leute mit denen wir reden Sie erinnern sich irgendwie ständig gibt es da Ansätze? Ja, da arbeiten auf jeden Fall Leute daran an Community Management und es gibt auch viel Feedback und Kommentare aus der Community also mir ist auf jeden Fall klar dass es Leute gibt die daran arbeiten zum Beispiel ich bekomme mal Fragen von denen dass ich bei den bestimmten Fragen dazu komme wo aus einer Architektur Sicht eine Frage anguckt werden muss wenn man sich GitHub anguckt es gibt auch ein paar Punkte die ich selber antwortet habe auf GitHub selber weil das Community Team mich gebeten hat da also einzugehen aber das Feedback dass Leute sich nicht vollkommen glücklich sind damit es die Mitglieder wird dass es auf jeden Fall etwas das sich auf jeden Fall mit unserer Team nehmen und wo wir dann reden können also dass da Leute ein paar Antworten bekommen vielleicht eine letzte etwas konkrete Frage von Tafne aus dem Eiersee ist es das die App nicht zeigen kann wann genau am Tag die Infektion für die Infektion stattgefunden hat ist das eine Entscheidung der Architektur oder ist es eine politische Entscheidung quasi also die Informationen wann das stattgefunden hat ist das Datum der Exposure und das ist immer das UTC Datum das heißt also wir bekommen nicht die tatsächliche Zeit der eigentlichen Exposure und wenn man direkt zu den Exposurewindows geht gehen wir einfach nicht drauf ein das heißt wenn die App tatsächlich den genauen Zeitpunkt des Teffens am meisten Menschen wissen wann sie wo gewesen sind um 11.15 Uhr da habe ich mich getroffen mit ein paar Freunden und dann bekomme ich die Informationen um 11.15 Uhr also das Treffen mit einer Infektion und dann wäre es sehr einfach wer der Freund war der die Infektion hatte und das ist etwas das nicht gewünscht ist dass man das auf einzelne Personen zurückführen kann also das würde im Grunde heißen dass wenn eine Person Infizien könnte und es ist wir haben noch Zeit für letzte Frage tschüchzt fragt auf SE auf der SE Channel ob man eine Maschinenlearning Ansatz benutzen könnte auf dem einen zu sagen also die Klasse Verzierung der Risikenkassen durch Maschinenlearning ist etwas das ich jetzt noch nicht weit von Also das Problem, das basiert auf der Zusammenarbeit mit dem Fraunhofer-Institut, wo Sie also bestimmte Situationen nachgespielt haben, da Messungen gemacht haben, was passiert ist und das ist ein Risikomodell reingekommen. Also das ist abgeleitet von praktischen Tests, also kein Machine Learning zurzeit. Alles klar, also danke. Das war unsere letzte Frage. Und nochmal vielen Dank, nochmal virtuellen Applaus für dich. Danke Thomas für den Talk und Teil dieses Remote. Es ist zu sein. Und vielen Dank für deine Einsichten, Linus Beggart. Und Dankeschön. Das habe ich gerne gemacht.