When the application receives a request to forcibly upgrade, it cannot do so because the Play Store is likely not available on a non-GMS phone, and even if it were, it would not provide the correct app version.
From then on the application is no longer usable.

Possible resolution: investigate how to redirect to F-Droid, provide instructions for the user to install new app.

This is a continuation of #26 using a Huawei Y6p phone, which runs the proprietary system from Huawei but does not contain Google Mobile Services.

There are two bluetooth activities:

1. advertising BLE
2. scanning for BLE

Implement one of the exposure calculations

Add an Android project to the repo

• simple start screen
• 2 activities
  • send beacons
  • receive beacons

App is always active, don't work on background for the moment

A few points have been discussed:

• Rename the app to LibreCHovid
• Change the applicationId
• At startup, display an alert to the user, requiring the user to accept or exit:
  • If GMS are not installed on the device, display that it is an unofficial free version modified to run on devices wihout GMS.
  • If GMS are installed on the device, display that GMS are installed on the device, it is an unofficial free version modified to run on devices wihout GMS, it is suggested to use the official SwissCovid

Create necessary classes with empty definitions for full GAEN API, so we can discuss which calls need to be implemented.

-> how to link this GAEN API with the two activities from the android app?

Use the file from

https://github.com/CoraLibre/CoraLibre-android-sdk/blob/master/sdk/src/main/java/org/coralibre/android/sdk/internal/crypto/CryptoModule.java
or
https://github.com/mh-/exposure-notification-ble-python/blob/master/lib/en_crypto.py (converting to java)
or
https://github.com/DP-3T/gaenlib/tree/master/impl-python (converting to java)

to implement the crypto-specification.

Is part of the implementation of #3

Some test-vectors are here: corona-warn-app/cwa-app-android#75 (comment)

Might be good to verify they match the impl-python, too.

Use file from 2020-09-30

F-Droid is a very popular app store for Free and Open Source Software.
Publishing a version of SwissCovid bundled with the microG EN libraries to F-Droid will increase its visibility and make it easier for people to install it.

This issue tracks the various tests to be done on the modified SwissCovid app to ensure that it works as expected.

Functionalities:

1. The application correctly advertises RPIs
2. The application correctly scans other devices' RPIs
3. The application can declare a positive diagnosis
4. The application notifies the user of an exposure
5. The crypto is correct
6. The exposure computation is correct
7. End-to-end with mixed phones.

Environments:

1. The application runs on a phone with an open OS without any Google Play services installed
   →Pixel 4 installed with stock LineageOS 17.1
2. The application runs on a phone with a commercial OS lacking Google Play services
   →Huawei?

Existing implementations

microG

Open-source project aiming to provide a free implementation of Google Play Services.

• Requires an OS with a "Signature Spoofing" patch applied (or microG preinstalled, such as LineageOS for microG).
• Provides a transparent "drop-in" replacement, allowing original apps to run unmodified on non-GMS phones. The app is linked with the GMS client library, and the "Signature Spoofing" allows to redirect to microG.
• Appears to be 1 main developer (microG's author) + some others.
• The GAEN implementation (gms.nearby) started about 1-2 months ago. It targets "v1 mode" only so far (as it seems to be what all existing apps use, including the current version of SwissCovid).
• GAEN is fairly advanced, able to run existing corona apps (Germany's Corona-Warn-App, Italy's Immuni).
• Without installing microG, there is a possibility for an "almost transparent" approach by bundling the EN-relevant part as a library, along with a client library, and packaging all together with an existing app. However, such an app would likely not be accepted on Google Play due to it not using the official lib, but it could possibly be made to be accepted on F-Droid. The client library has been started but is not yet complete and requires further work.

Interesting issue with discussion regarding EN.

CoraLibre

Open-souce project aiming to provide a free implementation of an EN SDK for corona contact-tracing apps

• Started with a pre-GAEN version of the DP3T SDK, and is working to adapt it.
• Wishes to also produce a fork of Germany's Corona-Warn-App using the SDK.
• Aims to provide an API as close as possible to GAEN. It targets "v1 mode" only so far.
• Applications will require some (hopefully minor) changes to adapt to the library.
• Crypto and Bluetooth parts are fairly advanced, client API (along with some implementation of the Tasks API) is just at the beginning.

Matrix channel for CoraLibre discussion. The microG main developer is also connected and participates to the discussion.

Google libraries

Contains a snapshot of code from Google Play Services' Exposure Notifications module.

• This is not a usable product, but is provided as a reference that can be used with the GAEN specs.
• Doesn't build (issue opened) (fixed now).
• Some parts (key matching) are implemented in C++ via JNI for performance reasons.

TODO

• is it possible to have an android device for @cgrigis ?
• update README.md with this information

The original dp3t uses GitHub workflows using Bintray and AppCenter.

See if we can reuse some of those.

Move the following repositories, currently forked at C4DT, to the DP-3T organization:

• https://github.com/c4dt/dp3t-sdk-android
• https://github.com/c4dt/dp3t-app-android-ch

The code changes are currently in the microg-nearby branch.

See microg/GmsCore#1200

Goals

• Have a GAEN-compatible library for testing and for apps that don't use the GMS. Targeted uses:
  • Phones that do not have the Google Play services installed (e.g. Huawei).
  • Phones running a free OS.
• Developing a new complete library from scratch would be a significant amount of work (~2-3 months).
• Optimization axes to pursue:
  • Minimum amount of dependencies on other code.
  • Smallest amount of changes in the Covid App.

The exposure key files provided by servers are signed using a PHA-specific private key, whose public counterpart is provided to Google for allowlisted apps.
When an app receives exposure key files from a server, it passes them to GAEN via an API that validates them and checks their signature before seeking for matches.
As microG does not have the PHA-specific public signature keys, the exposure key files are currently not verified before matching is attempted.

Add a README providing extensive details regarding:

• What is this library
• Why we are creating it
• etc.

Also, make sure that the readme links to the security analysis explaining which of those attacks would it enable and that people should not do them.

This issue tracks the steps needed to produce a version of the SwissCovid app that can run on phones that lack the Google Play services, by bundling the subset of microG relevant to EN as libraries.
This follows an approach suggested in a discussion with the microG developers, and is also tracked there.

• Finish implementation of EN client library in microG.
• Copy EN-relevant microG modules into a fork of the SwissCovid sdk; use this in a fork of the SwissCovid app.
• Make required updates to microG, SwissCovid sdk, and SwissCovid app to have a working app.
• Document the changes in this repo

Huawei has developed their alternative to Google Mobile Services:

https://huaweimobileservices.com/
https://en.wikipedia.org/wiki/Huawei_Mobile_Services

Investigate what API they use for their replacement of GAEN.

Check eventual infection, get new keys, ...

In the best case, SwissCovid has an option to use this API and then do all the backend communication.

Multiple-phone test by @francozappa, started on 2020-11-02

[2020-11-02 10:20:20] I'm running calibration-app.apk on the Pixel 4, calibration-app-gms.apk on A40 id14 and calibration-app-official.apk on A40 id13

[2020-11-02 17:09:40]at 17:09 I self-infected the Pixel 4 and I'm waiting for the notifications on the other two devices.

[2020-11-03 09:04:50] id13 received the exposed notification, still waiting for id14

[2020-11-03 10:45:44] I've erased the data from Pixel 4 and id13 and I've restarted tracking. In a couple of hours I will self-infect id13 to see if the Pixel 4 is notified. id14 is still tracking with its old identity and didn't get a notification (it might be because of gps and micro G conflicts)

[2020-11-03 15:49:59] I've self-infected id13

[2020-11-04 09:50:56] Pixel 4 was not notified and id14 was not notified. It looks like there is a problem with the micro-g apps when they synch with the backend.

From @gannimo:

Have you looked at the battery optimization issues and are you aware of any optimizations microG does so that it does still get scheduled periodically even if the phone is in doze mode?

In normal microG, this is configured using the EN settings.
The current bundling of microG contains no UI nor settings, and grants all permissions to requests originating from the same package (e.g. ch.admin.bag.dp3t).

Do we need a UI?

A possible improvement over regular GAEN would be to adapt the frequency of scanning depending on the number of advertisements received within a scan period:

• If we receive many advertisements, we would benefit from increasing the frequency of scanning, as it indicates that there are many people around.
• If we receive very few (or no) advertisements, we can reduce the frequency of scanning, thereby saving batteries.

From @gannimo:

We could have a thin thin thin interposition layer. That, when initialization happens, checks if these GAEN APIs are available using reflection. If they are not available, go for our implementation.
Consider this a "nice to have" not a "must", so low priority for now I guess.
I'm curious if it's possible though.

The app requires ACCESS_FINE_LOCATION and ACCESS_BACKGROUND_LOCATION permissions in order to be able to perform Bluetooth scans, and fails silently (except from errors in logcat) if they are not granted.
These must currently be added by hand (Settings - Apps - Permissions - ...), but should be properly requested and granted interactively.

• @cgrigis proposes next meeting with Daniele and Matthias

• Where should the repository forks be hosted?
• Is it OK to document the changes in gaenlib?
• What are the next steps?