Corona Warn App: Open source version available – soon at F-Droid

The completely open source version of the Corona Warning app developed by members of the F-Droid team is available in a first version and has been stable on the author’s device since then. Instead of Google’s Exposure API, it is based on the free implementation by Marvin Wißfeld. The app automatically detects which type of Exposure API is available on the device and uses it. Success reports came from all three groups: those with Google Services, those with microG – and also those “without”. If you had already installed the original app and now want to switch to the free version, you can simply install the app additionally

If you switch to the open source version of the Corona Warning app, you should let the original app run in parallel for 14 days (period for which IDs are saved), then it can be uninstalled. With the microG-based, the previously collected data is adopted, so the original app can be uninstalled immediately. With microG it is also possible to use apps from different countries (for example, if you are temporarily abroad) in parallel – something that the Google API does not allow. If the Exposure API integrated directly in the app is used, the counting will of course start again at “day zero”.

If the app shows an “unknown status” forever, you don’t have to get nervous: it takes between 24 hours and three days, depending on the principle, before a concrete estimate can be made. For the author, it turned “green” after two days – others reported it after just one day, others after three days. In the “main repo” of F-Droid, the app should also be available by the weekend. If you want to stay up to date on the development, you can CCTG team on Mastodon follow or the RSS-Feed des Accounts subscribe to.

Why does the app need GPS?

Not at all. The app does not use GPS. It is correct: it requires authorization for site access. This is system-dependent under Android and has the background that a location can also be determined via Bluetooth (via so-called stationary “Bluetooth beacons” or iBeacons, for example for “in-door navigation”).

Another battery eater?

The author cannot confirm that. In the four days since the app has been in use, the author has not noticed any * significant * additional battery consumption. It is not for nothing that the technology used is called BLE (Bluetooth Low Energy).
How noticeable this is of course depends not least on which other apps are used. Gadgetbridge, for example, also runs on the author’s device, so that Bluetooth was already “permanently in use”.

Why does the app need at least Android 6?

This is because BLE was only “officially introduced” with this Android version. In fact, however, a number of devices already support BLE from Android 5 – which is why a corresponding adaptation is in progress for the F-Droid version. If supported by the device, the app should also work there under Android 5.

Why did the first article say “SAP and DTAG … apparently failed”?

Of course, that wasn’t because of * ability * – it wasn’t even * wanting. * Rather, it was * being allowed. * After all, the developers work on behalf of the RKI and have to adhere to their “specification” accordingly.

Is that a spy app?

This is precisely why it was important to disclose the sources of the last components. At least with the app from F-Droid, anyone ™ can use the source code to check what is happening. And since the app is also built to be “reproducible”, it is also possible to check whether it corresponds to the source code.

What exactly is being transmitted now?

The describes Marvin Wißfeld as follows. As with the CWA, different Telekom Cloud servers are contacted:

  • To synchronize the infected keys
  • To generate traffic for the purpose of plausible deniability towards ISP / network
  • To generate an authentication token
  • To get test results
  • For uploading the BT keys after infection

With 4 and 5, the token from 3 is sent. With 3, the ID from the test QR code or the TeleTAN is also sent. In addition, points 3 to 5 must be actively triggered by the user.

Does the app solve the corona problem?

No she does not. It also does not protect against infection. That’s what you need GMV-App, some social skills and a sense of responsibility. Don’t forget “sneaker sweaters” – and remember to hide your nose “underneath”.

Can I also participate with older smartphones?

See above: In some cases this will also be possible – as long as they support BLE. With Android 5, the chances of this are still quite good – before that, rather bad. But you also have to say: Android 5 was released in November 2014, 6 years ago. Here, the fault lies more with the manufacturers, who seldom provide their devices with updates for more than 18 months – but sometimes deliver them with a completely outdated Android version on the day of publication. And to be honest: who still has an Android phone in daily use today that was manufactured before 2012?

Didn’t Google release the API source code months ago?

Not really. Just a few incomplete snippets, even under pressure. Essential parts are missing – for example for Bluetooth functionality, for storing IDs, for key matching and of course for telemetry. Since everything takes place within the Google Services Framework, one can confidently ask which other Google components have access to the data. And what they might do with it. Google makes its money with advertising; “Pure altruism” is certainly not to be expected. And what about “who has nothing to hide …”?

Does that also work with reporting?

Of course: The interfaces for this are also open. And since the question arose as to whether a “malicious user” could not trigger massive amounts of false positives: Only if the fax machine was sent to the authorities … Seriously: A report is only possible if you have the appropriate authentication token. This is not generated by the app, but assigned after the test – either via a QR code that can be scanned with the app – or by telephone by transmitting a TAN, which you then have to enter manually.


To home page