[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:12.99,Default,,0000,0000,0000,,{\i1}rC3 preroll music{\i0}
Dialogue: 0,0:00:12.99,0:00:20.40,Default,,0000,0000,0000,,Herald: All right, CWA - three simple\Nletters, but what stands behind them is
Dialogue: 0,0:00:20.40,0:00:25.36,Default,,0000,0000,0000,,not simple at all. For various reasons. The\NCorona-Warn-App has been one of the most
Dialogue: 0,0:00:25.36,0:00:30.16,Default,,0000,0000,0000,,talked about digital project of the year.\NBehind its rather simplistic facade there
Dialogue: 0,0:00:30.16,0:00:34.96,Default,,0000,0000,0000,,are many considerations that went into the\NApp's design to protect its users and
Dialogue: 0,0:00:34.96,0:00:39.12,Default,,0000,0000,0000,,their data, while they might not be\Nvisible for most users, these goals had a
Dialogue: 0,0:00:39.12,0:00:43.28,Default,,0000,0000,0000,,direct influence on the software\Narchitecture. For instance, the risk
Dialogue: 0,0:00:43.28,0:00:48.08,Default,,0000,0000,0000,,calculation. Here today to talk about some\Nof these backend elements is one of the
Dialogue: 0,0:00:48.08,0:00:53.20,Default,,0000,0000,0000,,solution architects of the Corona-Warn-App\N- Thomas Klingbeil. And I'm probably not
Dialogue: 0,0:00:53.20,0:00:59.52,Default,,0000,0000,0000,,the only one here at rC3, who is an active\Nuser. And I'm pretty curious to hear more
Dialogue: 0,0:00:59.52,0:01:04.48,Default,,0000,0000,0000,,about what's going on behind the scenes of\Nthe App. So without further ado, let's
Dialogue: 0,0:01:04.48,0:01:11.64,Default,,0000,0000,0000,,give a warm virtual welcome to Thomas\NKlingbeil. Thomas, the stream is yours.
Dialogue: 0,0:01:15.32,0:01:18.96,Default,,0000,0000,0000,,Thomas Klingbeil: Hello, everybody. I'm\NThomas Klingbeil, and today in the
Dialogue: 0,0:01:18.96,0:01:23.28,Default,,0000,0000,0000,,session, I would like to talk about the\NGerman Corona-Warn-App and give you a
Dialogue: 0,0:01:23.28,0:01:27.76,Default,,0000,0000,0000,,little tour behind the scenes of the App\Ndevelopment, the underlying technologies
Dialogue: 0,0:01:28.32,0:01:33.52,Default,,0000,0000,0000,,and which things are invisible to the end\Nuser, but still very important for the App
Dialogue: 0,0:01:33.52,0:01:38.24,Default,,0000,0000,0000,,itself. First, I would like to give you a\Nshort introduction to the App, the
Dialogue: 0,0:01:38.24,0:01:41.60,Default,,0000,0000,0000,,underlying architecture and to used\Ntechnologies, for example, the Exposure
Dialogue: 0,0:01:41.60,0:01:45.68,Default,,0000,0000,0000,,Notification Framework. Then I would like\Nto have a look on the communication
Dialogue: 0,0:01:45.68,0:01:52.08,Default,,0000,0000,0000,,between the App and the backend and\Nlooking at which possible privacy threats
Dialogue: 0,0:01:52.08,0:01:57.28,Default,,0000,0000,0000,,could be found and how we mitigated them,\Nof course. And then I would like to dive a
Dialogue: 0,0:01:57.28,0:02:01.60,Default,,0000,0000,0000,,little bit into the risk calculation of\Nthe App to show you what it actually
Dialogue: 0,0:02:01.60,0:02:06.96,Default,,0000,0000,0000,,means, If there is a red or a green\Nscreen, visible to the end user. First of
Dialogue: 0,0:02:06.96,0:02:13.28,Default,,0000,0000,0000,,all, we can ask ourselves the question,\Nwhat is the Corona-Warn-App, actually? So,
Dialogue: 0,0:02:13.28,0:02:20.96,Default,,0000,0000,0000,,here it is. This is the German Corona-Warn-App, \Nyou can download it from the App stores and
Dialogue: 0,0:02:20.96,0:02:24.64,Default,,0000,0000,0000,,once you have unboarded onto the App, you\Nwill see the following: up here it shows
Dialogue: 0,0:02:24.64,0:02:28.88,Default,,0000,0000,0000,,you that the exposure logging is active,\Nwhich means this is the currently active
Dialogue: 0,0:02:28.88,0:02:34.16,Default,,0000,0000,0000,,App. Then you have this green card. Green\Nmeans it's low risk because there have
Dialogue: 0,0:02:34.16,0:02:39.52,Default,,0000,0000,0000,,been no exposures so far. The logging has\Nbeen permanently active and it has just
Dialogue: 0,0:02:39.52,0:02:45.20,Default,,0000,0000,0000,,updated this afternoon. So everything is\Nall right. Let's say you have just been
Dialogue: 0,0:02:45.20,0:02:51.20,Default,,0000,0000,0000,,tested at a doctor's, then you could click\Nthis button here and you get to the
Dialogue: 0,0:02:51.20,0:02:57.04,Default,,0000,0000,0000,,screen, we you're able to retrieve your test\Nresult digitally. To do this, you can scan
Dialogue: 0,0:02:57.04,0:03:01.60,Default,,0000,0000,0000,,a QR code, which is on the phone, you\Nreceived from your doctor, and then you
Dialogue: 0,0:03:01.60,0:03:08.56,Default,,0000,0000,0000,,will get an update as soon as the test\Nresult is available. Of course, you can
Dialogue: 0,0:03:08.56,0:03:12.88,Default,,0000,0000,0000,,also get more information about the active\Nexposure logging when you click the button
Dialogue: 0,0:03:12.88,0:03:16.80,Default,,0000,0000,0000,,up here, then you get to this screen and\Nthere you can learn more about the
Dialogue: 0,0:03:16.80,0:03:21.60,Default,,0000,0000,0000,,transnational exposure logging, because\Nthe German Corona-Warn-App is not alone.
Dialogue: 0,0:03:21.60,0:03:27.20,Default,,0000,0000,0000,,It is connected to other Corona-Apps of\Nother countries within Europe. So users
Dialogue: 0,0:03:27.20,0:03:32.72,Default,,0000,0000,0000,,from other countries can meet and they\Nwould be informed mutually about possible
Dialogue: 0,0:03:32.72,0:03:40.96,Default,,0000,0000,0000,,encounters. So just to be sure, I would\Nlike to quickly dive into the terminology
Dialogue: 0,0:03:40.96,0:03:45.76,Default,,0000,0000,0000,,of the exposure notification framework. So\Nyou know what I'm talking about during
Dialogue: 0,0:03:45.76,0:03:52.56,Default,,0000,0000,0000,,this session. It all starts with a\NTemporary Exposure Key which is generated
Dialogue: 0,0:03:52.56,0:03:58.93,Default,,0000,0000,0000,,on the phone and which is valid for 24\Nhours. From this Temporary Exposure Key,
Dialogue: 0,0:03:58.93,0:04:03.20,Default,,0000,0000,0000,,several things are derived. First, for\Nexample, there is the Rolling Proximity
Dialogue: 0,0:04:03.20,0:04:09.04,Default,,0000,0000,0000,,Identifier Key and the Associated\NEncrypted Metadata Key. This part down
Dialogue: 0,0:04:09.04,0:04:13.28,Default,,0000,0000,0000,,here, we can skip for a moment being and\Nlook at the generation of Rolling
Dialogue: 0,0:04:13.28,0:04:18.56,Default,,0000,0000,0000,,Proximity Identifiers. Those Rolling\NProximity Identifiers are only valid for
Dialogue: 0,0:04:18.56,0:04:24.16,Default,,0000,0000,0000,,10 minutes each because they are regularly\Nexchanged once the Bluetooth MAC-Address
Dialogue: 0,0:04:24.16,0:04:29.04,Default,,0000,0000,0000,,change takes place. So the Rolling\NProximity Identifier is basically the
Dialogue: 0,0:04:29.04,0:04:33.36,Default,,0000,0000,0000,,Bluetooth payload your phone uses, when\Nthe Exposion Verification Framework is
Dialogue: 0,0:04:33.36,0:04:38.96,Default,,0000,0000,0000,,active and broadcasting. When I say\Nbroadcasting, I mean every 250
Dialogue: 0,0:04:38.96,0:04:45.12,Default,,0000,0000,0000,,milliseconds your phone sends out its own\NRolling Proximity Identifiers, so other
Dialogue: 0,0:04:45.12,0:04:51.60,Default,,0000,0000,0000,,phones around, which are scanning for\Nsignal in the air basically can catch them
Dialogue: 0,0:04:51.60,0:04:58.40,Default,,0000,0000,0000,,and store them locally. So let's look at\Nthe receiving side. This is what we see
Dialogue: 0,0:04:58.40,0:05:02.24,Default,,0000,0000,0000,,down here and now, as I've already\Nmentioned, we've got those Bluetooth low
Dialogue: 0,0:05:02.24,0:05:07.28,Default,,0000,0000,0000,,energy beacon mechanics sending out those\NRolling Proximity Identifiers and they're
Dialogue: 0,0:05:07.28,0:05:13.12,Default,,0000,0000,0000,,received down here. This is all a very\Nsimplified schematic, just to give you an
Dialogue: 0,0:05:13.12,0:05:17.76,Default,,0000,0000,0000,,impression of what's going on there. So\Nnow we've got those Rolling Proximity
Dialogue: 0,0:05:17.76,0:05:23.60,Default,,0000,0000,0000,,Identifiers stored under receiving phone\Nand now, somehow, this other phone needs
Dialogue: 0,0:05:23.60,0:05:28.96,Default,,0000,0000,0000,,to find out that there has been a match,\Nthis happens by transforming those
Dialogue: 0,0:05:28.96,0:05:34.40,Default,,0000,0000,0000,,Temporary Exposure Keys into Diagnosis\NKeys, which is just a renaming. But as
Dialogue: 0,0:05:34.40,0:05:38.40,Default,,0000,0000,0000,,soon as someone has tested positive and a\NTemporary Exposure Key is linked to a
Dialogue: 0,0:05:38.40,0:05:43.44,Default,,0000,0000,0000,,positive diagnosis, it is called Diagnosis\NKey and they are uploaded to the server.
Dialogue: 0,0:05:44.24,0:05:51.76,Default,,0000,0000,0000,,And I'm drastically simplifying here. So\Nthey receive the other phone here they're
Dialogue: 0,0:05:51.76,0:05:57.68,Default,,0000,0000,0000,,downloaded, all those Diagnosis Keys are\Nextracted again. And as you can see, the
Dialogue: 0,0:05:57.68,0:06:06.08,Default,,0000,0000,0000,,same functions applied, again HKDF, then\NAES, and we get a lot of Rolling Proximity
Dialogue: 0,0:06:06.08,0:06:12.56,Default,,0000,0000,0000,,Identifiers for matching down here. And\Nthose are the ones we have stored and now
Dialogue: 0,0:06:12.56,0:06:16.56,Default,,0000,0000,0000,,we can match them and find out which of\Nthose Rolling Proximity Identifiers we
Dialogue: 0,0:06:16.56,0:06:23.34,Default,,0000,0000,0000,,have seen so far. And, of course, the\Nreceiving phone can also make sure that
Dialogue: 0,0:06:23.34,0:06:28.32,Default,,0000,0000,0000,,the Rolling Proximity Identifiers\Nbelonging to a single Diagnosis Key, which
Dialogue: 0,0:06:28.32,0:06:33.20,Default,,0000,0000,0000,,means they belong to one single other\Nphone, are connected to each other. So we
Dialogue: 0,0:06:33.20,0:06:37.84,Default,,0000,0000,0000,,can also track exposures which have lasted\Nlonger than 10 minutes. So, for example,
Dialogue: 0,0:06:37.84,0:06:42.64,Default,,0000,0000,0000,,if you are having a meeting of 90 minutes,\Nthis would allow the explosion
Dialogue: 0,0:06:42.64,0:06:46.96,Default,,0000,0000,0000,,notification framework to get together\Nthose up to nine Rolling Proximity
Dialogue: 0,0:06:46.96,0:06:52.32,Default,,0000,0000,0000,,Identifiers and transform them into a\Nsingle encounter, which you then get
Dialogue: 0,0:06:52.32,0:06:57.28,Default,,0000,0000,0000,,enriched with those associated encrypted\Nmetadata, which is basically just the
Dialogue: 0,0:06:57.28,0:07:04.56,Default,,0000,0000,0000,,transmit power. As a summary, down here. So\Nnow that we know which data are being
Dialogue: 0,0:07:04.56,0:07:10.00,Default,,0000,0000,0000,,transferred from phone to phone, we can\Nhave a look at the actual architecture of
Dialogue: 0,0:07:10.00,0:07:16.96,Default,,0000,0000,0000,,the App itself. This gray box here is the\Nmobile phone, and down here is the German
Dialogue: 0,0:07:16.96,0:07:23.12,Default,,0000,0000,0000,,Corona-Warn-App, it's a dashed line, which\Nmeans there's more documentation available
Dialogue: 0,0:07:23.12,0:07:28.56,Default,,0000,0000,0000,,online. So I can only invite you to go to\NGitHub repository. Have a look at our code
Dialogue: 0,0:07:28.56,0:07:34.32,Default,,0000,0000,0000,,and, of course, our documentation. So\Nthere are more diagrams available. And as
Dialogue: 0,0:07:34.32,0:07:38.96,Default,,0000,0000,0000,,you can see, the App itself does not store\Na lot of data. So those boxes here are
Dialogue: 0,0:07:38.96,0:07:43.60,Default,,0000,0000,0000,,storages. So it only store something\Ncalled a Registration Token and the
Dialogue: 0,0:07:43.60,0:07:49.84,Default,,0000,0000,0000,,contact journal entries for our most\Nrecent version, which means that's all the
Dialogue: 0,0:07:49.84,0:07:55.52,Default,,0000,0000,0000,,App stores itself. What you can see here\Nis that it's connected to the operating
Dialogue: 0,0:07:55.52,0:07:59.76,Default,,0000,0000,0000,,system API/SDK for the exposure\Nnotifications, so that's the exposure
Dialogue: 0,0:07:59.76,0:08:04.32,Default,,0000,0000,0000,,notification framework to which we\Ninterface, which takes care of all the key
Dialogue: 0,0:08:04.32,0:08:09.52,Default,,0000,0000,0000,,connecting, broadcasting and key matching\Nas well. Then there's a protocol buffer
Dialogue: 0,0:08:09.52,0:08:15.76,Default,,0000,0000,0000,,library which we need for the data\Ntransfer, and we use the operating system
Dialogue: 0,0:08:15.76,0:08:21.44,Default,,0000,0000,0000,,cryptography libraries or, basically, the\NSDK. So we don't need to include external
Dialogue: 0,0:08:21.44,0:08:30.72,Default,,0000,0000,0000,,libraries for that. What you can see here\Nis the OS API/SDK for push messages. But
Dialogue: 0,0:08:30.72,0:08:36.40,Default,,0000,0000,0000,,this is not remote push messaging, but\Nonly locally. So the App triggers local
Dialogue: 0,0:08:36.40,0:08:42.32,Default,,0000,0000,0000,,notifications and to the user, it appears\Nas if the notifications to push message
Dialogue: 0,0:08:42.32,0:08:50.26,Default,,0000,0000,0000,,came in remotely, but actually it only\Nuses local messages. But what would the
Dialogue: 0,0:08:50.26,0:08:56.24,Default,,0000,0000,0000,,App be without the actual backend\Ninfrastructure? So you can see here,
Dialogue: 0,0:08:56.24,0:09:01.84,Default,,0000,0000,0000,,that's the Corona-Warn-App server, that's\Nthe actual backend for managing all the
Dialogue: 0,0:09:01.84,0:09:07.71,Default,,0000,0000,0000,,keys. And you see the upload path here.\NIt's aggregated then provided through
Dialogue: 0,0:09:07.71,0:09:13.37,Default,,0000,0000,0000,,content delivery network and downloaded by\Nthe App here. But we've got more. We've
Dialogue: 0,0:09:13.37,0:09:19.21,Default,,0000,0000,0000,,got the verification server, which has the\Njob of verifying a positive test result.
Dialogue: 0,0:09:19.21,0:09:26.26,Default,,0000,0000,0000,,And how does it do that? There's basically\Ntwo ways it can either get the information
Dialogue: 0,0:09:26.26,0:09:32.66,Default,,0000,0000,0000,,that a positive test is true though a so-\Ncalled teleTAN, which is the most basic
Dialogue: 0,0:09:32.66,0:09:37.71,Default,,0000,0000,0000,,way, because people call up the hotline,\Nget one of those teleTAN, entered into the
Dialogue: 0,0:09:37.71,0:09:45.04,Default,,0000,0000,0000,,App and then they are able to upload the\NDiagnosis Keys or, if people use the fully
Dialogue: 0,0:09:45.04,0:09:49.89,Default,,0000,0000,0000,,digital way, they get their test result\Nthrough the App. And that's why we have
Dialogue: 0,0:09:49.89,0:09:54.84,Default,,0000,0000,0000,,the test results server up here, which can\Nbe queried by the verification server
Dialogue: 0,0:09:54.84,0:10:01.56,Default,,0000,0000,0000,,so users can get the test result through\Nthe infrastructure. But that's not all,
Dialogue: 0,0:10:01.56,0:10:06.76,Default,,0000,0000,0000,,because as I've promised earlier, we've also\Ngot the connection to other European
Dialogue: 0,0:10:06.76,0:10:11.46,Default,,0000,0000,0000,,countries. So down here is the European\NFederation Gateway Service, which gives us
Dialogue: 0,0:10:11.46,0:10:16.82,Default,,0000,0000,0000,,the possibility to a) upload our own\Nnational keys to this European Federation
Dialogue: 0,0:10:16.82,0:10:20.76,Default,,0000,0000,0000,,Gateway Service, so other countries can\Ndownload them and distribute them to their
Dialogue: 0,0:10:20.76,0:10:25.94,Default,,0000,0000,0000,,users, but we can also request foreign\Nkeys and, gets even better, we can be
Dialogue: 0,0:10:25.94,0:10:31.26,Default,,0000,0000,0000,,informed if new foreign keys are available\Nfor download through a callback mechanism,
Dialogue: 0,0:10:31.26,0:10:40.43,Default,,0000,0000,0000,,which is just here on the right side. So\Nonce the app is communicating with the
Dialogue: 0,0:10:40.43,0:10:48.57,Default,,0000,0000,0000,,backend, what would actually happen if\Nsomeone is listening? So we've got our
Dialogue: 0,0:10:48.57,0:10:58.90,Default,,0000,0000,0000,,dataflow here. And. Let's have a look at\Nit, so in step one, we are actually
Dialogue: 0,0:10:58.90,0:11:05.07,Default,,0000,0000,0000,,scanning the QR code with a camera of the\Nphone and extracted from the QR code would
Dialogue: 0,0:11:05.07,0:11:10.87,Default,,0000,0000,0000,,be a GUID, which is then fed into the\NCorona-Warn-App. You can see here it is
Dialogue: 0,0:11:10.87,0:11:14.88,Default,,0000,0000,0000,,never stored within the app. That's very\Nimportant, because we wanted to make sure
Dialogue: 0,0:11:14.88,0:11:19.47,Default,,0000,0000,0000,,that as few information as possible needs\Nto be stored within the app and also that
Dialogue: 0,0:11:19.47,0:11:23.94,Default,,0000,0000,0000,,it's not possible to connect information\Nfrom different sources, for example, to
Dialogue: 0,0:11:23.94,0:11:31.57,Default,,0000,0000,0000,,trace back Diagnosis Key to a GUID to\Nallow personification. It was very
Dialogue: 0,0:11:31.57,0:11:38.92,Default,,0000,0000,0000,,important that this step is not possible.\NSo we had to take care that no data is
Dialogue: 0,0:11:38.92,0:11:45.32,Default,,0000,0000,0000,,stored together and data cannot be\Nconnected again. So in step one, we get
Dialogue: 0,0:11:45.32,0:11:50.02,Default,,0000,0000,0000,,this GUID. And this is then hashed on the\Nphone being sent to the verification
Dialogue: 0,0:11:50.02,0:11:55.64,Default,,0000,0000,0000,,server, which in step three generates a\Nso-called Registration Token and stores it
Dialogue: 0,0:11:55.64,0:12:02.05,Default,,0000,0000,0000,,together. So it stores the hash(GUID) and\Nthe hash(Registration Token), making sure
Dialogue: 0,0:12:02.05,0:12:08.75,Default,,0000,0000,0000,,that GUID can only be used once and\Nreturns the unhashed Registration Token to
Dialogue: 0,0:12:08.75,0:12:17.92,Default,,0000,0000,0000,,the App here. Now the App can store the\NRegistration Token and use it in step five
Dialogue: 0,0:12:17.92,0:12:22.71,Default,,0000,0000,0000,,for polling for test results, but the test\Nresults are not available directly on the
Dialogue: 0,0:12:22.71,0:12:27.38,Default,,0000,0000,0000,,verification server, because we do not\Nstore it here. But the verification server
Dialogue: 0,0:12:27.38,0:12:32.71,Default,,0000,0000,0000,,connects to the test results server by\Nusing the hash(GUID), which can get from
Dialogue: 0,0:12:32.71,0:12:38.84,Default,,0000,0000,0000,,the hash(Registration Token) here, and\Nthen it can ask the test results server. And
Dialogue: 0,0:12:38.84,0:12:43.83,Default,,0000,0000,0000,,the test results server might have a data\Nset connecting the hash(GUID) to the test
Dialogue: 0,0:12:43.83,0:12:51.65,Default,,0000,0000,0000,,result. And this check needs to be done\Nbecause the test results server might also
Dialogue: 0,0:12:51.65,0:12:56.55,Default,,0000,0000,0000,,have no information for this hash(GUID),\Nand this only means that no test result
Dialogue: 0,0:12:56.55,0:13:01.44,Default,,0000,0000,0000,,has received yet. This is what happens\Nhere in step A, the Lab Information
Dialogue: 0,0:13:01.44,0:13:06.82,Default,,0000,0000,0000,,system, the LIS, can supply the\Ntest results server with a package of
Dialogue: 0,0:13:06.82,0:13:12.04,Default,,0000,0000,0000,,hash(GUID) and the test result - so it's\Nstored there. And if it's available already
Dialogue: 0,0:13:12.04,0:13:18.32,Default,,0000,0000,0000,,on a test result server, it is returned to the\Nverification server and here in step 7 and
Dialogue: 0,0:13:18.32,0:13:25.10,Default,,0000,0000,0000,,accordingly in step 8 to the App. You\Nmight have noted the test results is also,
Dialogue: 0,0:13:25.10,0:13:30.00,Default,,0000,0000,0000,,neither cached nor stored here on the\Nverification server, which means if the
Dialogue: 0,0:13:30.00,0:13:36.28,Default,,0000,0000,0000,,user then decides to upload the keys, a\NTAN is required to pass onto the backend
Dialogue: 0,0:13:36.28,0:13:41.88,Default,,0000,0000,0000,,for verification of the positive test. An\Nequal flow needs to be followed. So in
Dialogue: 0,0:13:41.88,0:13:48.82,Default,,0000,0000,0000,,step 9, again, the Registration Token\Nis passed to the TAN endpoint, the
Dialogue: 0,0:13:48.82,0:13:52.68,Default,,0000,0000,0000,,verification server once more needs to\Ncheck with the test results server
Dialogue: 0,0:13:52.68,0:13:56.88,Default,,0000,0000,0000,,that it's actually a positive test result.\NGets back here in step 11, TAN is
Dialogue: 0,0:13:56.88,0:14:02.06,Default,,0000,0000,0000,,generated in step 12. You can see the TAN\Nis not stored in plaintext, but it's
Dialogue: 0,0:14:02.06,0:14:08.39,Default,,0000,0000,0000,,stored as a hash, but the plaintext is\Nreturned to the App, which can
Dialogue: 0,0:14:08.39,0:14:12.77,Default,,0000,0000,0000,,then bundle it with Diagnosis Keys\Nextracted from the exposure notification
Dialogue: 0,0:14:12.77,0:14:17.49,Default,,0000,0000,0000,,framework and upload it to the Corona-\NWarn-App server or more specifically, the
Dialogue: 0,0:14:17.49,0:14:24.16,Default,,0000,0000,0000,,submission service. But this also needs to\Nverify that it's authentic, so takes it in
Dialogue: 0,0:14:24.16,0:14:30.60,Default,,0000,0000,0000,,step 15 to the verification server on the\Nverify endpoint. Where the TAN is
Dialogue: 0,0:14:30.60,0:14:36.77,Default,,0000,0000,0000,,validated and validation means it is\Nmarked as used already, so at the same
Dialogue: 0,0:14:36.77,0:14:41.80,Default,,0000,0000,0000,,time cannot be used twice, and then the\Nresponse is given to the backend here,
Dialogue: 0,0:14:41.80,0:14:48.37,Default,,0000,0000,0000,,which can then, if it's positive, which\Nmeans if it's authentic TAN can store the
Dialogue: 0,0:14:48.37,0:14:54.56,Default,,0000,0000,0000,,Diagnosis Key in its own storage. And as\Nyou can see, only the Diagnosis Keys are
Dialogue: 0,0:14:54.56,0:14:59.54,Default,,0000,0000,0000,,stored here, nothing else. So there's no\Ncorrelation possible between Diagnosis
Dialogue: 0,0:14:59.54,0:15:07.04,Default,,0000,0000,0000,,Keys, Registration Token or even GUID\Nbecause it's completely separate. But
Dialogue: 0,0:15:07.04,0:15:13.39,Default,,0000,0000,0000,,still, what could be found out about users\Nif someone were to observe the network
Dialogue: 0,0:15:13.39,0:15:18.81,Default,,0000,0000,0000,,traffic going on there? An important\Nassumption in the beginning, the content
Dialogue: 0,0:15:18.81,0:15:25.20,Default,,0000,0000,0000,,of all the messages is secure because only\Nsecure connections are being used and only
Dialogue: 0,0:15:25.20,0:15:32.55,Default,,0000,0000,0000,,the size of the transfer is observable. So\Nwe can, from a network sniffing
Dialogue: 0,0:15:32.55,0:15:37.80,Default,,0000,0000,0000,,perspective observe that a connection is\Ncreated. We can observe how many bytes are
Dialogue: 0,0:15:37.80,0:15:42.04,Default,,0000,0000,0000,,being transferred back and forth, but we\Ncannot learn about the content of the
Dialogue: 0,0:15:42.04,0:15:49.41,Default,,0000,0000,0000,,message. So here we are, we've got the\Nfirst communication between App and server
Dialogue: 0,0:15:49.41,0:15:55.52,Default,,0000,0000,0000,,in step two, because we can see: OK, if\Nsomeone is requesting something from the
Dialogue: 0,0:15:55.52,0:16:00.74,Default,,0000,0000,0000,,Registration Token endpoint, this person\Nhas been tested maybe on that specific
Dialogue: 0,0:16:00.74,0:16:08.70,Default,,0000,0000,0000,,day. Then there is next communication\Ngoing on in step five, because this means
Dialogue: 0,0:16:08.70,0:16:13.45,Default,,0000,0000,0000,,that the person has been tested. I mean,\Nwe might know that from step two already,
Dialogue: 0,0:16:13.45,0:16:18.50,Default,,0000,0000,0000,,but this person has still not received the\Ntest result. So it might still be positive
Dialogue: 0,0:16:18.50,0:16:25.97,Default,,0000,0000,0000,,or negative. If we can observe that the\Nrequest to the TAN endpoint takes place in
Dialogue: 0,0:16:25.97,0:16:33.33,Default,,0000,0000,0000,,step 9, then we know the person has\Nbeen tested positive. So OK, this is
Dialogue: 0,0:16:33.33,0:16:38.100,Default,,0000,0000,0000,,https, so we cannot actually learn which\Nend point is being queried, but there
Dialogue: 0,0:16:38.100,0:16:44.36,Default,,0000,0000,0000,,might be specific sizes to those\Nindividual requests which might allow us
Dialogue: 0,0:16:44.36,0:16:53.78,Default,,0000,0000,0000,,to learn about the direction the request\Nis going into. Just as a thought. OK, and
Dialogue: 0,0:16:53.78,0:16:58.61,Default,,0000,0000,0000,,then, of course, we've got also the\Nsubmission service in step 14 where users
Dialogue: 0,0:16:58.61,0:17:04.82,Default,,0000,0000,0000,,upload their Diagnosis Keys and a TAN, and\Nthis is really, really without any
Dialogue: 0,0:17:04.82,0:17:12.15,Default,,0000,0000,0000,,possibility for discussion, because if a\NApp-context, the Corona-Warn-App server
Dialogue: 0,0:17:12.15,0:17:17.93,Default,,0000,0000,0000,,and... builds up a connection - this must\Nmean that the user has been tested
Dialogue: 0,0:17:17.93,0:17:24.64,Default,,0000,0000,0000,,positive and is submitting Diagnosis Keys.\NApart from that, once the user submits
Dialogue: 0,0:17:24.64,0:17:31.69,Default,,0000,0000,0000,,Diagnosis Keys, and the App talks to the\NCorona-Warn-App backend - it could also be
Dialogue: 0,0:17:31.69,0:17:39.72,Default,,0000,0000,0000,,possible to relate those keys to an origin\NIP-address, for example. Could there be a
Dialogue: 0,0:17:39.72,0:17:45.82,Default,,0000,0000,0000,,way around that? So what we need to do in\Nthis scenario and what we did is to
Dialogue: 0,0:17:45.82,0:17:51.76,Default,,0000,0000,0000,,establish plausible deniability, which\Nbasically means we generate so much noise
Dialogue: 0,0:17:51.76,0:17:58.00,Default,,0000,0000,0000,,with the connections we build up that it's\Nnot possible to identify individuals which
Dialogue: 0,0:17:58.00,0:18:04.16,Default,,0000,0000,0000,,actually use those connections to query their\Ntest results to receive the test result,
Dialogue: 0,0:18:04.16,0:18:11.02,Default,,0000,0000,0000,,if it's positive, to retrieve a TAN or to\Nupload the Keys. So generating noise is
Dialogue: 0,0:18:11.02,0:18:18.58,Default,,0000,0000,0000,,the key. So what the App actually does is:\Nsimulate the backend traffic by sending
Dialogue: 0,0:18:18.58,0:18:24.16,Default,,0000,0000,0000,,those fake or dummy requests according to\Na so-called playbook. So we've got... we
Dialogue: 0,0:18:24.16,0:18:29.31,Default,,0000,0000,0000,,call it playbook, from which the App takes\Nwhich requests to do, how long to wait,
Dialogue: 0,0:18:29.31,0:18:35.23,Default,,0000,0000,0000,,how often to repeat those requests and so\Non. And it's also interesting that those
Dialogue: 0,0:18:35.23,0:18:40.32,Default,,0000,0000,0000,,requests might either be triggered by real\Nevent or they might be triggered by just
Dialogue: 0,0:18:40.32,0:18:45.82,Default,,0000,0000,0000,,some random trigger. So scanning a QR code\Nor entering a teleTAN also triggers this
Dialogue: 0,0:18:45.82,0:18:50.70,Default,,0000,0000,0000,,flow. A little bit different, but it still\Ntriggers it, because if you then get your
Dialogue: 0,0:18:50.70,0:18:55.60,Default,,0000,0000,0000,,Registration Token retrieve your test\Nresults and the retrieval of your test
Dialogue: 0,0:18:55.60,0:19:01.71,Default,,0000,0000,0000,,results stops at some point, this must\Nmean, OK, there has been the test result -
Dialogue: 0,0:19:01.71,0:19:06.12,Default,,0000,0000,0000,,negative or positive. If it's then\Nobservable that you communicate to the
Dialogue: 0,0:19:06.12,0:19:10.70,Default,,0000,0000,0000,,submission service - this would mean that\Nit has been positive. So what the App
Dialogue: 0,0:19:10.70,0:19:17.81,Default,,0000,0000,0000,,actually does is: even if it is negative,\Nit continues sending out dummy requests to
Dialogue: 0,0:19:17.81,0:19:24.66,Default,,0000,0000,0000,,the verification server and it might also,\Nso that's all based on random decisions
Dialogue: 0,0:19:24.66,0:19:31.73,Default,,0000,0000,0000,,within the App, it might also then\Nretrieve a fake TAN and it might do a fake
Dialogue: 0,0:19:31.73,0:19:36.94,Default,,0000,0000,0000,,upload of Diagnosis Keys. So in the end,\Nyou're not able to distinguish between an App
Dialogue: 0,0:19:36.94,0:19:43.71,Default,,0000,0000,0000,,actually uploading real data or an App just\Ndoing playbook's stuff and creating noise.
Dialogue: 0,0:19:43.71,0:19:49.81,Default,,0000,0000,0000,,So users really uploading the Diagnosis\NKeys cannot be picked out from all the
Dialogue: 0,0:19:49.81,0:19:56.37,Default,,0000,0000,0000,,noise. And to make sure that our backend,\Nit's not just swamped with all those fake
Dialogue: 0,0:19:56.37,0:20:01.60,Default,,0000,0000,0000,,and dummy requests, there's a special\Nheader field, which informs the backend to
Dialogue: 0,0:20:01.60,0:20:06.05,Default,,0000,0000,0000,,actually ignore those requests. But if you\Nwould just ignore them and not send a
Dialogue: 0,0:20:06.05,0:20:11.56,Default,,0000,0000,0000,,response - it could be implemented on the\Nclient, but then it would be observable
Dialogue: 0,0:20:11.56,0:20:17.28,Default,,0000,0000,0000,,again that it's just a fake request. So\Nwhat we do is - we let the backend skip
Dialogue: 0,0:20:17.28,0:20:22.32,Default,,0000,0000,0000,,all the interaction with the underlying\Ndatabase infrastructure, do not modify any
Dialogue: 0,0:20:22.32,0:20:28.02,Default,,0000,0000,0000,,data and so on, but there will be a delay\Nin the response and the response will look
Dialogue: 0,0:20:28.02,0:20:34.31,Default,,0000,0000,0000,,exactly the same as if it was to respond\Nto real request. Also on the data, both
Dialogue: 0,0:20:34.31,0:20:40.71,Default,,0000,0000,0000,,directions from the client to the server\Nand from the server to the client, get
Dialogue: 0,0:20:40.71,0:20:46.98,Default,,0000,0000,0000,,some padding, so it's always the same\Nsize, no matter what information is contained
Dialogue: 0,0:20:46.98,0:20:53.99,Default,,0000,0000,0000,,in this data packages. So observing the\Ndata packages... so the size does not help
Dialogue: 0,0:20:53.99,0:21:00.48,Default,,0000,0000,0000,,in finding out what's actually going on.\NNow, you could say, OK, if there's so much
Dialogue: 0,0:21:00.48,0:21:06.16,Default,,0000,0000,0000,,additional traffic because they're fake\Nrequests being sent out and fake uploads
Dialogue: 0,0:21:06.16,0:21:12.28,Default,,0000,0000,0000,,being done and so on, this must cost a lot\Nof data traffic to the users. There's a
Dialogue: 0,0:21:12.28,0:21:18.90,Default,,0000,0000,0000,,good point. It is all zero rated with\NGerman mobile operators, which means it's
Dialogue: 0,0:21:18.90,0:21:29.04,Default,,0000,0000,0000,,not charged to the end customers, but it's\Njust being paid for. Now, there is still that
Dialogue: 0,0:21:29.04,0:21:34.56,Default,,0000,0000,0000,,thing with the extraction of information from\Nthe metadata while uploading the Diagnosis
Dialogue: 0,0:21:34.56,0:21:41.12,Default,,0000,0000,0000,,Keys and this metadata might be the source\NIP address, it might be the user agent
Dialogue: 0,0:21:41.12,0:21:47.12,Default,,0000,0000,0000,,being used. So then you can distinguish\NAndroid from iOS and possibly you could
Dialogue: 0,0:21:47.12,0:21:52.48,Default,,0000,0000,0000,,also find out about the OS version and to\Nprevent it with introduced an intermediary
Dialogue: 0,0:21:52.48,0:21:58.32,Default,,0000,0000,0000,,server, which removes the metadata from\Nthe requests and just forwards the plain
Dialogue: 0,0:21:58.32,0:22:04.24,Default,,0000,0000,0000,,content of the packages basically to the\Nbackend service. So the backend service,
Dialogue: 0,0:22:04.24,0:22:17.70,Default,,0000,0000,0000,,the submission service is not able to tell\Nfrom where this package came from. Now,
Dialogue: 0,0:22:17.70,0:22:24.61,Default,,0000,0000,0000,,for risk calculation, we can have a look\Nat which information is available here. So
Dialogue: 0,0:22:24.61,0:22:30.66,Default,,0000,0000,0000,,we've got the information about\Nencounters, which calculated at the device
Dialogue: 0,0:22:30.66,0:22:34.82,Default,,0000,0000,0000,,receiving the Rolling Proximity\NIdentifiers as mentioned earlier and those
Dialogue: 0,0:22:34.82,0:22:39.82,Default,,0000,0000,0000,,information come into us in 30 minute\Nexposure windows. So I mentioned earlier
Dialogue: 0,0:22:39.82,0:22:45.48,Default,,0000,0000,0000,,that all the Rolling Proximity Identifiers\Nbelonging to a single Diagnosis Key. So
Dialogue: 0,0:22:45.48,0:22:50.48,Default,,0000,0000,0000,,single day UTC basically that is, can be\Nrelated to each other. But what the
Dialogue: 0,0:22:50.48,0:22:56.25,Default,,0000,0000,0000,,exposure notification framework then does\Nis split up those encounters in 30 minute
Dialogue: 0,0:22:56.25,0:23:05.53,Default,,0000,0000,0000,,windows. So the first scan instance, where\Nanother device has been identified, starts
Dialogue: 0,0:23:05.53,0:23:09.72,Default,,0000,0000,0000,,the exposure window and then it's filled\Nup until the 30 minutes are full. And if
Dialogue: 0,0:23:09.72,0:23:14.05,Default,,0000,0000,0000,,there's more encounters with the same\NDiagnosis Key basically, a new window is
Dialogue: 0,0:23:14.05,0:23:19.18,Default,,0000,0000,0000,,started and so on. The single exposure\Nwindow only contains a single device. So
Dialogue: 0,0:23:19.18,0:23:25.04,Default,,0000,0000,0000,,it's one to one mapping. And within that\Nwindow we can find the number of the scan
Dialogue: 0,0:23:25.04,0:23:32.90,Default,,0000,0000,0000,,instances. So scans take place every three\Nto five minutes and within those scan
Dialogue: 0,0:23:32.90,0:23:35.28,Default,,0000,0000,0000,,instances, there are also multiple scans.
Dialogue: 0,0:23:35.28,0:23:38.46,Default,,0000,0000,0000,,And we get the minimum and\Nthe average attenuation
Dialogue: 0,0:23:38.46,0:23:44.23,Default,,0000,0000,0000,,per instance, and the attenuation is\Nactually the reported transmit power of
Dialogue: 0,0:23:44.23,0:23:49.54,Default,,0000,0000,0000,,the device minus the signal strength when\Nreceiving the signal. So it basically
Dialogue: 0,0:23:49.54,0:23:55.40,Default,,0000,0000,0000,,tells us how much signal strength got lost\Non the way. If we talk about a low
Dialogue: 0,0:23:55.40,0:24:00.52,Default,,0000,0000,0000,,attenuation, this means the other device\Nhas been very close. If the attenuation is
Dialogue: 0,0:24:00.52,0:24:08.35,Default,,0000,0000,0000,,higher, it means the other device is farther\Naway and, from the other way around, so
Dialogue: 0,0:24:08.35,0:24:12.95,Default,,0000,0000,0000,,through the Diagnosis Keys, which have been\Nuploaded to the server, processed on the
Dialogue: 0,0:24:12.95,0:24:17.44,Default,,0000,0000,0000,,backend provided on CDN and came to us\Nthrough that way, we can also get
Dialogue: 0,0:24:17.44,0:24:22.16,Default,,0000,0000,0000,,information about the infectiousness of\Nthe user, which is encoded in something we
Dialogue: 0,0:24:22.16,0:24:30.00,Default,,0000,0000,0000,,call Transmission Risk Level, which tells\Nus how big the risk of infection from that
Dialogue: 0,0:24:30.00,0:24:38.24,Default,,0000,0000,0000,,person on that specific day has been. So,\Nthe Transmission Risk Level is based on
Dialogue: 0,0:24:38.24,0:24:43.36,Default,,0000,0000,0000,,the symptom status of a person and the\Nsymptom status means: Is the person
Dialogue: 0,0:24:43.36,0:24:49.08,Default,,0000,0000,0000,,symptomatic, asymptomatic, does the\Nperson want to tell about the symptoms or
Dialogue: 0,0:24:49.08,0:24:53.84,Default,,0000,0000,0000,,maybe do they not want to tell about the\Nsymptoms, and in addition to that, if
Dialogue: 0,0:24:53.84,0:24:58.64,Default,,0000,0000,0000,,there have been symptoms, it can also be\Nclarified whether the symptoms start was a
Dialogue: 0,0:24:58.64,0:25:02.72,Default,,0000,0000,0000,,specific day, whether it has been a range\Nof multiple days when the symptoms
Dialogue: 0,0:25:02.72,0:25:08.40,Default,,0000,0000,0000,,started, or people could also say: "I'm\Nnot sure about when the symptoms started,
Dialogue: 0,0:25:08.40,0:25:14.88,Default,,0000,0000,0000,,but there have been symptoms definitely".\NSo this is the first case people can
Dialogue: 0,0:25:14.88,0:25:20.16,Default,,0000,0000,0000,,specify when the symptoms started and we\Ncan say that the symptoms start down here
Dialogue: 0,0:25:20.16,0:25:27.84,Default,,0000,0000,0000,,and around that date of the onset of\Nsymptoms, it's basically evenly spread the
Dialogue: 0,0:25:27.84,0:25:36.16,Default,,0000,0000,0000,,risk of infection: red means high risk,\Nblue means low risk. See, when you move
Dialogue: 0,0:25:36.16,0:25:44.08,Default,,0000,0000,0000,,around that symptom start day also the\Ninfectiousness moves around and there's
Dialogue: 0,0:25:44.08,0:25:47.92,Default,,0000,0000,0000,,basically a matrix from where this\Ninformation is derived. Again, you can
Dialogue: 0,0:25:47.92,0:25:54.40,Default,,0000,0000,0000,,find that all in the code. And there's\Nalso the possibility to say, OK, the
Dialogue: 0,0:25:54.40,0:26:00.08,Default,,0000,0000,0000,,symptoms started somewhere within the last\Nseven days. That's the case up here. See,
Dialogue: 0,0:26:00.08,0:26:05.44,Default,,0000,0000,0000,,it's spread a little bit differently.\NUsers could also specify it started
Dialogue: 0,0:26:05.44,0:26:11.44,Default,,0000,0000,0000,,somewhere from one to two weeks ago. You\Ncan see that here in the second chart and
Dialogue: 0,0:26:11.44,0:26:18.56,Default,,0000,0000,0000,,the third chart is the case for when the\Nsymptoms started more than two weeks ago.
Dialogue: 0,0:26:18.56,0:26:23.76,Default,,0000,0000,0000,,Now, here's the case, that user specify\Nthat they just received a positive test
Dialogue: 0,0:26:23.76,0:26:28.24,Default,,0000,0000,0000,,result. So they're definitely Corona\Npositive, but they have never had
Dialogue: 0,0:26:28.24,0:26:32.64,Default,,0000,0000,0000,,symptoms, which might mean they are\Nasymptomatic or presymptomatic. And,
Dialogue: 0,0:26:32.64,0:26:40.16,Default,,0000,0000,0000,,again, you see around the submission,\Nthere is an increased risk, but all the
Dialogue: 0,0:26:40.16,0:26:48.40,Default,,0000,0000,0000,,time before here only has a low\Ntransmission level asigned. If users want
Dialogue: 0,0:26:48.40,0:26:52.32,Default,,0000,0000,0000,,to specify that they can't remember when\Nthe symptoms started, but they definitely
Dialogue: 0,0:26:52.32,0:26:59.52,Default,,0000,0000,0000,,had symptoms, then it's all spread a\Nlittle bit differently. And equally, if
Dialogue: 0,0:26:59.52,0:27:03.20,Default,,0000,0000,0000,,users do not want to share the\Ninformation, whether they had symptoms at
Dialogue: 0,0:27:03.20,0:27:10.16,Default,,0000,0000,0000,,all. So now we've got this big risk\Ncalculation chart here, and I would like
Dialogue: 0,0:27:10.16,0:27:14.32,Default,,0000,0000,0000,,to walk you quickly through it. So on the\Nleft, we've got the configuration which is
Dialogue: 0,0:27:14.32,0:27:18.72,Default,,0000,0000,0000,,being fed into the exposure notification\Nframework by Appe / Google, because
Dialogue: 0,0:27:18.72,0:27:24.40,Default,,0000,0000,0000,,there's also some mappings which the\Nframework needs from us. There is some
Dialogue: 0,0:27:24.40,0:27:28.88,Default,,0000,0000,0000,,internal configuration because we have\Ndecided to do a lot of the risk
Dialogue: 0,0:27:28.88,0:27:33.36,Default,,0000,0000,0000,,calculation within the App instead of\Ndoing it in the framework, mainly because
Dialogue: 0,0:27:33.36,0:27:39.52,Default,,0000,0000,0000,,we have decided we want a eight levels,\Ntransmission risk levels, instead of the
Dialogue: 0,0:27:39.52,0:27:44.72,Default,,0000,0000,0000,,only three levels, so low, standard and\Nhigh, which Apple and Google provide to
Dialogue: 0,0:27:44.72,0:27:51.28,Default,,0000,0000,0000,,us. For the sake of having those eight\Nlevels, we actually sacrifice the
Dialogue: 0,0:27:51.28,0:27:55.84,Default,,0000,0000,0000,,parameters of infectiousness, which is\Nderived from the parameter days since
Dialogue: 0,0:27:55.84,0:28:02.88,Default,,0000,0000,0000,,onset of symptoms and the report type,\Nwhich is always a confirmed test in Europe.
Dialogue: 0,0:28:02.88,0:28:08.00,Default,,0000,0000,0000,,So we got those three bits actually, which\Nwe can now use as a Transmission Risk
Dialogue: 0,0:28:08.00,0:28:13.44,Default,,0000,0000,0000,,Level, which is encoded on the server in\Nthose two fields, added to the Keys and
Dialogue: 0,0:28:13.44,0:28:20.08,Default,,0000,0000,0000,,the content delivery network, downloaded\Nby the App and then passed through the
Dialogue: 0,0:28:20.08,0:28:24.56,Default,,0000,0000,0000,,calculation here. So it comes in here. It\Nis assembled from those two parameters,
Dialogue: 0,0:28:24.56,0:28:30.96,Default,,0000,0000,0000,,Report Type and Infectiousness, and now it\Ngoes along. So first, we need to look,
Dialogue: 0,0:28:30.96,0:28:37.76,Default,,0000,0000,0000,,whether the sum of the durations at below\N73 decibels. So that's our first threshold
Dialogue: 0,0:28:37.76,0:28:42.64,Default,,0000,0000,0000,,has been less than 10 minutes. If it has\Nbeen less than 10 minutes, just drop the
Dialogue: 0,0:28:42.64,0:28:49.12,Default,,0000,0000,0000,,whole exposure window. If it has been more\Nor equal 10 minutes, we might use it,
Dialogue: 0,0:28:49.12,0:28:55.76,Default,,0000,0000,0000,,depending on whether the Transmission Risk\NLevel is larger or equal three and we use
Dialogue: 0,0:28:55.76,0:29:05.64,Default,,0000,0000,0000,,it. And now we actually calculate the\Nrelevant time and times between 60...
Dialogue: 0,0:29:05.64,0:29:12.97,Default,,0000,0000,0000,,between 55 and 63 decibels are only counted\Nhalf, because that's a medium distance and
Dialogue: 0,0:29:12.97,0:29:19.16,Default,,0000,0000,0000,,times at below 55 decibels, that's up here\Nare counted full, then added up. And
Dialogue: 0,0:29:19.16,0:29:24.08,Default,,0000,0000,0000,,then we've got the weight exposure time\Nand now we've got this transmission risk
Dialogue: 0,0:29:24.08,0:29:28.59,Default,,0000,0000,0000,,level, which leads us to a normalization\Nfactor, basically. And this is multiplied
Dialogue: 0,0:29:28.59,0:29:33.80,Default,,0000,0000,0000,,with the rate exposure time. What we get\Nhere is the normalized exposure time per
Dialogue: 0,0:29:33.80,0:29:39.82,Default,,0000,0000,0000,,exposure window and those times for each\Nwindow are added up for the whole day. And
Dialogue: 0,0:29:39.82,0:29:44.98,Default,,0000,0000,0000,,then that's the threshold of 15 minutes,\Nwhich decides whether the day had a high
Dialogue: 0,0:29:44.98,0:29:54.00,Default,,0000,0000,0000,,risk of infection or a low risk. So now\Nthat you all know how to do those
Dialogue: 0,0:29:54.00,0:30:00.88,Default,,0000,0000,0000,,calculations, we can walk through it for\Nthree examples. So the first example is
Dialogue: 0,0:30:00.88,0:30:05.12,Default,,0000,0000,0000,,here: it's a transmission risk level of\Nseven. You can see those all are pretty
Dialogue: 0,0:30:05.12,0:30:10.40,Default,,0000,0000,0000,,close so our magic thresholds are here at\N73. That's for whether that's counted or
Dialogue: 0,0:30:10.40,0:30:17.68,Default,,0000,0000,0000,,not. Then at 63, it's this line. And at\N55. So we see, OK, there's been a lot of
Dialogue: 0,0:30:17.68,0:30:23.28,Default,,0000,0000,0000,,close contact going on and some medium\Nrange contact as well. So let's do the
Dialogue: 0,0:30:23.28,0:30:29.36,Default,,0000,0000,0000,,pre-filtering, even though we already see\Nit has been at least 10 minutes below 73
Dialogue: 0,0:30:29.36,0:30:35.60,Default,,0000,0000,0000,,decibels. Yes, definitely, because each of\Nthose dots represents three minutes. So,
Dialogue: 0,0:30:35.60,0:30:40.96,Default,,0000,0000,0000,,for this example calculation, I just\Nassumed the scan windows are three minutes
Dialogue: 0,0:30:40.96,0:30:47.84,Default,,0000,0000,0000,,apart. Is it at least transmission risk\Nlevel three? Yes, it's even seven. So now
Dialogue: 0,0:30:47.84,0:30:54.00,Default,,0000,0000,0000,,we do the calculation. It has been 18\Nminutes a day low attenuation, so at a
Dialogue: 0,0:30:54.00,0:30:59.20,Default,,0000,0000,0000,,close proximity, so that's 18 minutes and\Nnine minutes those and those - three dots
Dialogue: 0,0:30:59.20,0:31:04.00,Default,,0000,0000,0000,,here at a medium attenuation. So a little\Nbit farther apart, they count as four and
Dialogue: 0,0:31:04.00,0:31:09.60,Default,,0000,0000,0000,,a half minutes. We've got a factor here\Nadding it up, it gets us to 25 minutes
Dialogue: 0,0:31:09.60,0:31:19.60,Default,,0000,0000,0000,,multiplied by 1.4 giving us 33... 31.5\Nminutes, which means red status. Already
Dialogue: 0,0:31:19.60,0:31:25.92,Default,,0000,0000,0000,,with a single window. Now, in this\Nexample, we can always see that's pretty
Dialogue: 0,0:31:25.92,0:31:30.56,Default,,0000,0000,0000,,far away and that's been one close\Nencounter here, transmission risk level
Dialogue: 0,0:31:30.56,0:31:37.68,Default,,0000,0000,0000,,eight even, pre-filtering: has it been at\Nleast 10 minutes below 73 decibels? Nope.
Dialogue: 0,0:31:37.68,0:31:43.36,Default,,0000,0000,0000,,OK, then we already drop it. Now that's\Nthe third one. Transmission risk level
Dialogue: 0,0:31:43.36,0:31:51.44,Default,,0000,0000,0000,,eight again. It has been a little bit\Naway, but there's also been some close
Dialogue: 0,0:31:51.44,0:31:57.04,Default,,0000,0000,0000,,contact, so we do the pre-filtering: has\Nit been at least 10 minutes below 73? Now
Dialogue: 0,0:31:57.04,0:32:03.20,Default,,0000,0000,0000,,we already have to look closely. So, yes.\NIt is below 73, this one as well. OK, so
Dialogue: 0,0:32:03.20,0:32:09.92,Default,,0000,0000,0000,,we've got four dots below 73 decibels.\NGives us 12 minutes. Yes, transmission
Dialogue: 0,0:32:09.92,0:32:14.88,Default,,0000,0000,0000,,risk level three. OK, that's easy. Yes.\NAnd now we can do the calculation. It has
Dialogue: 0,0:32:14.88,0:32:20.56,Default,,0000,0000,0000,,been six minutes at the low attenuation -\Nthose two dots here. OK, they count full
Dialogue: 0,0:32:20.56,0:32:25.76,Default,,0000,0000,0000,,and zero minutes at the medium\Nattenuation. You see this part is empty
Dialogue: 0,0:32:25.76,0:32:31.04,Default,,0000,0000,0000,,and the transmission risk level eight\Ngives us a factor of 1.6. If we now
Dialogue: 0,0:32:31.04,0:32:36.88,Default,,0000,0000,0000,,multiply the six minutes by 1.6, we get\N9.6 minutes. So if this has been the only
Dialogue: 0,0:32:36.88,0:32:41.68,Default,,0000,0000,0000,,encounter for a day, that's stil\Ngreen. But if, for example, you had two
Dialogue: 0,0:32:41.68,0:32:47.84,Default,,0000,0000,0000,,encounters of this kind, so with the same\Nperson or with different people, then it
Dialogue: 0,0:32:47.84,0:32:53.28,Default,,0000,0000,0000,,would already turn into red because then\Nit's close to 20 minutes, which is above
Dialogue: 0,0:32:53.28,0:33:00.64,Default,,0000,0000,0000,,the 15 minute threshold. Now, I would like\Nto thank you for listening to my session,
Dialogue: 0,0:33:00.64,0:33:05.40,Default,,0000,0000,0000,,and I'm available for Q&A shortly.
Dialogue: 0,0:33:12.51,0:33:18.64,Default,,0000,0000,0000,,Herald: OK, so thank you, Tomas. This was\Na prerecorded talk and the discussion was
Dialogue: 0,0:33:18.64,0:33:24.24,Default,,0000,0000,0000,,very lively in the IRC during the talk,\Nand I'm glad that Thomas will be here for
Dialogue: 0,0:33:24.24,0:33:36.08,Default,,0000,0000,0000,,the Q&A. Maybe to start with the first\Nquestion by MH in IRC on security and
Dialogue: 0,0:33:36.08,0:33:44.52,Default,,0000,0000,0000,,replay attacks: Italy and Netherlands\Npublished TAKs DKs so early today are
Dialogue: 0,0:33:44.52,0:33:50.38,Default,,0000,0000,0000,,still valid. We learned that yesterday and\Nthe time between presentation, how is this
Dialogue: 0,0:33:50.38,0:33:55.00,Default,,0000,0000,0000,,handled in the European cooperation and\Ncan you make them adhere to the security
Dialogue: 0,0:33:55.00,0:34:03.20,Default,,0000,0000,0000,,requirements? This is the first question\Nfor you, Thomas.
Dialogue: 0,0:34:03.20,0:34:07.98,Default,,0000,0000,0000,,Thomas: OK, so thank you for this\Nquestion. The way we handle Keys coming
Dialogue: 0,0:34:07.98,0:34:12.02,Default,,0000,0000,0000,,in from other European contries,\Nthat's through the European federation
Dialogue: 0,0:34:12.02,0:34:14.92,Default,,0000,0000,0000,,gateway service is, that they are handled
Dialogue: 0,0:34:14.92,0:34:19.72,Default,,0000,0000,0000,,as if they were national keys,\Nwhich means they are put in some kind of
Dialogue: 0,0:34:19.72,0:34:26.52,Default,,0000,0000,0000,,embargo for two hours until... so two\Nhours after the end of their validity to
Dialogue: 0,0:34:26.52,0:34:32.15,Default,,0000,0000,0000,,make sure that replay attacks are not\Npossible.
Dialogue: 0,0:34:32.15,0:34:37.86,Default,,0000,0000,0000,,Herald: All right, I hope that answers\Nthis actually. OK, and then there was
Dialogue: 0,0:34:37.86,0:34:43.40,Default,,0000,0000,0000,,another one on international\Ninteroperability: is it EU only or is
Dialogue: 0,0:34:43.40,0:34:48.71,Default,,0000,0000,0000,,there is also cooperation between EU and,\Nfor example, Switzerland?
Dialogue: 0,0:34:48.71,0:34:57.02,Default,,0000,0000,0000,,Thomas: So so far, we've got the cooperation\Nwith other EU countries from {\i1}audio glitches{\i0}
Dialogue: 0,0:34:57.02,0:35:06.88,Default,,0000,0000,0000,,the European Union, which interoperates\Nalready, and regarding the integration of
Dialogue: 0,0:35:06.88,0:35:13.84,Default,,0000,0000,0000,,non-EU countries, that's basically a\Npolitical decision that has to be made
Dialogue: 0,0:35:13.84,0:35:21.76,Default,,0000,0000,0000,,from this place as well. So that's nothing\NI as an architect can drive or control. So
Dialogue: 0,0:35:21.76,0:35:27.84,Default,,0000,0000,0000,,so far, it's only EU countries.\NHerald: All right. And then I have some
Dialogue: 0,0:35:27.84,0:35:32.64,Default,,0000,0000,0000,,comments and also questions on community\Ninteraction and implementation of new
Dialogue: 0,0:35:32.64,0:35:38.40,Default,,0000,0000,0000,,features, which seems a little slow for\Nsome. There was, for example, a proposal
Dialogue: 0,0:35:38.40,0:35:43.12,Default,,0000,0000,0000,,for functionality called Crowd Notifier\Nfor events and restaurants to check in by
Dialogue: 0,0:35:43.12,0:35:49.68,Default,,0000,0000,0000,,scanning a QR code. Can you tell us a bit\Nmore about this or what's there? Are you
Dialogue: 0,0:35:49.68,0:35:58.67,Default,,0000,0000,0000,,aware of this?\NThomas: So I've personally seen that there
Dialogue: 0,0:35:58.67,0:36:03.54,Default,,0000,0000,0000,,are proposals online, and that is also a\Nlively discussion on those issues, but
Dialogue: 0,0:36:03.54,0:36:10.31,Default,,0000,0000,0000,,what you need to keep in mind is that we\Nare also... we have the task of developing
Dialogue: 0,0:36:10.31,0:36:16.50,Default,,0000,0000,0000,,this App for the federal ministry of\NHealth, and they are basically the ones
Dialogue: 0,0:36:16.50,0:36:23.28,Default,,0000,0000,0000,,requesting features and then there's some\Nscoping going on. So I'm personally and so
Dialogue: 0,0:36:23.28,0:36:29.72,Default,,0000,0000,0000,,to say that again, I am the architect so I\Ncan't decide which features are going to
Dialogue: 0,0:36:29.72,0:36:34.71,Default,,0000,0000,0000,,be implemented. It's just as soon as the\Ndecision has been made that we need a new
Dialogue: 0,0:36:34.71,0:36:41.19,Default,,0000,0000,0000,,feature, so after we've been given\Nthe task, then I come in and prepare the
Dialogue: 0,0:36:41.19,0:36:46.84,Default,,0000,0000,0000,,architecture for that. So I'm not aware of\Nthe current state of those developments,
Dialogue: 0,0:36:46.84,0:36:49.59,Default,,0000,0000,0000,,to be honest, because that's out of my\Npersonal scope.
Dialogue: 0,0:36:49.59,0:36:55.56,Default,,0000,0000,0000,,Herald: All right. I mean, it's often the\Ncase, I suppose, with great projects, with
Dialogue: 0,0:36:55.56,0:37:02.22,Default,,0000,0000,0000,,huge project. But overall, people seem to\Nbe liking the fact that everything is
Dialogue: 0,0:37:02.22,0:37:08.60,Default,,0000,0000,0000,,available on GitHub. But some people are\Nreally dedicated and seem to be a bit
Dialogue: 0,0:37:08.60,0:37:14.00,Default,,0000,0000,0000,,disappointed that interaction with the\Ncommunity on GitHub seems a bit slow,
Dialogue: 0,0:37:14.00,0:37:20.40,Default,,0000,0000,0000,,because some issues are not answered as\Npeople would hope it would be. Do you know
Dialogue: 0,0:37:20.40,0:37:27.29,Default,,0000,0000,0000,,that about some ideas on adding dedicated\Ncommunity managers to the GitHub community
Dialogue: 0,0:37:27.29,0:37:32.99,Default,,0000,0000,0000,,around the App? So the people we speak\Nwith, that was one note in IRC, actually
Dialogue: 0,0:37:32.99,0:37:37.43,Default,,0000,0000,0000,,seem to be changing every month. So are\Nyou aware of this kind of position of
Dialogue: 0,0:37:37.43,0:37:40.96,Default,,0000,0000,0000,,community management.\NThomas: So there's people definitely
Dialogue: 0,0:37:40.96,0:37:45.26,Default,,0000,0000,0000,,working on the community management,\Nthere's also a lot of feedback and
Dialogue: 0,0:37:45.26,0:37:52.38,Default,,0000,0000,0000,,comments coming in from the community, and\NI'm definitely aware that there are people
Dialogue: 0,0:37:52.38,0:37:59.30,Default,,0000,0000,0000,,working on that. And, for example, I get\Nasked by them to jump in on certain
Dialogue: 0,0:37:59.30,0:38:03.80,Default,,0000,0000,0000,,questions where verification was needed\Nfrom an architectural point of view. And
Dialogue: 0,0:38:03.80,0:38:08.56,Default,,0000,0000,0000,,that's... if you look at GitHub, there's\Nalso some issues I've been answering, and
Dialogue: 0,0:38:08.56,0:38:14.51,Default,,0000,0000,0000,,that's because our community team has\Nasked me to jump in there. So but the
Dialogue: 0,0:38:14.51,0:38:19.80,Default,,0000,0000,0000,,feedback that people are not fully\Nsatisfied with the way how the community
Dialogue: 0,0:38:19.80,0:38:23.16,Default,,0000,0000,0000,,is handled, is something I would\Ndefinitely take back to our team
Dialogue: 0,0:38:23.16,0:38:27.51,Default,,0000,0000,0000,,internally and let them know about it.\NHerald: Yeah, that's great to know,
Dialogue: 0,0:38:27.51,0:38:33.84,Default,,0000,0000,0000,,actually. So people will have some answers\Non that. Maybe one last very concrete
Dialogue: 0,0:38:33.84,0:38:39.30,Default,,0000,0000,0000,,question by duffman in the IRC: Is the\Ninability of the App to show the time/day
Dialogue: 0,0:38:39.30,0:38:42.97,Default,,0000,0000,0000,,of exposures a limitation of the\Nframework or is it an implementation
Dialogue: 0,0:38:42.97,0:38:46.77,Default,,0000,0000,0000,,choice? And what would be the privacy\Nimplications of introducing such a
Dialogue: 0,0:38:46.77,0:38:51.05,Default,,0000,0000,0000,,feature? Actually, a big question, but\Nmaybe you can cut it short.
Dialogue: 0,0:38:51.05,0:38:56.54,Default,,0000,0000,0000,,Thomas: Yeah, OK, so the only information,\Nthe exposion notification framework by
Dialogue: 0,0:38:56.54,0:39:02.13,Default,,0000,0000,0000,,Google / Apple can give us - is the date\Nof the exposure, and date always relates
Dialogue: 0,0:39:02.13,0:39:08.44,Default,,0000,0000,0000,,to UTC there. And so we never get the time\Nof the actual exposure back. And when
Dialogue: 0,0:39:08.44,0:39:13.88,Default,,0000,0000,0000,,moving to the exposure windows, we also do\Nnot get the time back of the exposure
Dialogue: 0,0:39:13.88,0:39:19.35,Default,,0000,0000,0000,,window. And the implications if you were\Nable to tell the exact time of the
Dialogue: 0,0:39:19.35,0:39:24.26,Default,,0000,0000,0000,,encounter, would be that people are often\Naware where they've been at a certain
Dialogue: 0,0:39:24.26,0:39:30.23,Default,,0000,0000,0000,,time. And let's say at 11:15, you were\Nmeeting with a friend and you get a
Dialogue: 0,0:39:30.23,0:39:36.20,Default,,0000,0000,0000,,notification that at 11:15, you had that\Nexact encounter, it would be easy to tell
Dialogue: 0,0:39:36.20,0:39:44.21,Default,,0000,0000,0000,,whom you've met, who's been infected. And\Nthat's something not desired, that you can
Dialogue: 0,0:39:44.21,0:39:50.32,Default,,0000,0000,0000,,trace it back to a certain person. So the\Npersonification would basically then be
Dialogue: 0,0:39:50.32,0:39:53.68,Default,,0000,0000,0000,,the thing.\NHerald: All right, and I hope we have time
Dialogue: 0,0:39:53.68,0:39:58.08,Default,,0000,0000,0000,,for this last question asked on IRC:\Nhave you considered training a machine
Dialogue: 0,0:39:58.08,0:40:02.32,Default,,0000,0000,0000,,learning method to classified the risk\Nlevels instead of the used rule-based
Dialogue: 0,0:40:02.32,0:40:12.88,Default,,0000,0000,0000,,method?\NThomas: So, I mean, classifying the risk
Dialogue: 0,0:40:12.88,0:40:21.36,Default,,0000,0000,0000,,levels through machine learning is\Nsomething I'm not aware of yet. So the
Dialogue: 0,0:40:21.36,0:40:26.47,Default,,0000,0000,0000,,thing is, it's all based on basically a\Ncooperation with the Fraunhofer Institute,
Dialogue: 0,0:40:26.47,0:40:30.84,Default,,0000,0000,0000,,where they have basically reenacted\Ncertain situations, did some measurements
Dialogue: 0,0:40:30.84,0:40:36.40,Default,,0000,0000,0000,,and that's what has been transferred into\Nthe risk model. So all those thresholds
Dialogue: 0,0:40:36.40,0:40:44.95,Default,,0000,0000,0000,,are derived from, basically, practical\Ntests. So no ML at the moment.
Dialogue: 0,0:40:44.95,0:40:52.59,Default,,0000,0000,0000,,Herald: All right, so I suppose this was\Nour last question and again, Thomas, a
Dialogue: 0,0:40:52.59,0:40:58.33,Default,,0000,0000,0000,,warm round of virtual applause to you and\Nthank you again, Thomas, for giving this
Dialogue: 0,0:40:58.33,0:41:03.92,Default,,0000,0000,0000,,talk, for being part of this first remote\Ncase experience and for giving us some
Dialogue: 0,0:41:03.92,0:41:08.72,Default,,0000,0000,0000,,insight into the backend of the Corona-\NWarn-App. Thank you.
Dialogue: 0,0:41:08.72,0:41:11.66,Default,,0000,0000,0000,,Thomas: Was happy to do so. Thank you for\Nhaving me here.
Dialogue: 0,0:41:11.66,0:41:15.66,Default,,0000,0000,0000,,{\i1}rC3 postroll music{\i0}
Dialogue: 0,0:41:15.66,0:41:49.96,Default,,0000,0000,0000,,Subtitles created by c3subtitles.de\Nin the year 2021. Join, and help us!