coralibre / coralibre-android-sdk Goto Github PK

In order to integrate the Coralibre SDK into a frontend (for example our frontend) we need to distribute it. I suggest we use JitPack as it is simple, F-droid complient and over at NewPipe we have some experience with it.

Since Google just released the source code to their implementation of the Exposure Notification API, is there still a place for CoraLibre?

source: https://github.com/google/exposure-notifications-internals

We need to provide the tables, which contain the TX/RX power of the different devices, to the sdk. This is important since we have no other way to find out what the TX power of a device could be.

This is required for #28 to work properly however does not block it atm.

Related pullrequest: #46

I guess it's save to say we will not do any calibration. Also for testing this app is not required as we have the testapp which is an actual module of the SDK.

Hi, I wanted to post this here to not blow up the main thread, as an answer to this post: corona-warn-app/cwa-app-android#75 (comment) where you also asked for support. Especially you asked for support for corporate identity and explained the difficulties with your limited resources.

I was quite surprised that you shut down the discussion about legacy devices here I don't see why it should bring in additional effort to compile your app with an Android 5 SDK so that also Android 5 users could install your app (which would be an unique selling point of your approach then). I want to emphasize: Doing so could be an important strategic decision.

I'm just trying to give you the arguments you need to create a corporate identity that will attract a lot of people for your project. To be realistic, I don't think the idea to just replicate an existing functionality in a FOSS way will attract a lot of people (unfortunately). You have to identify shortcomings of the existing solution and how your approach would solve them. If you go around and tell that currently ~20% of Android users are locked from the app and with your solution, you could bring the majority of them also on board, this could be identified as a game changer.
Here is how I would make the argument: The app is only effective if we have 70% (or 60%, this is under debate) coverage. This is what research tells us. This sounds more or less realistic. But subtracting 20% with incompatible phone means 87% from the remaining compatible phones have to install the app to reach 70% overall coverage. This is a much, much higher bar. I don't think we will come close to this. So whether we leave out 20% of all users or not can make the difference between success and failure. Just imagine what's on stake. "Failure" can mean a new, drastic lockdown which would be devastating for the economy. "Success" could mean we could avoid a second wave and start to rebuild our economy.
If you make this as the main talking point of your corporate identity, you will be successful and attract a lot of supporters also from outside the FOSS community.

Of course it is unclear whether the app will be of such high importance. But our world is chaotic. Small changes can have a big effect (butterfly effect). So you cannot disprove that maybe those additional 20% could just avoid that we get over the tipping point that would start a second wave. It is possible with small probability, so it is not a lie.

We are building a corporate identity here, not a scientific lecture, we do not have to take all evidence equally into account. It's ok to emphasize those evidence that supports our hypothesis. Our goal is to strengthen FOSS. This is a noble goal. It is never a bad thing to get people to support FOSS. Always remember this. So I would advise you to stop talking your project down. Be confident, be bold. You are doing great things here, you probably save free open source Android (as someone else pointed out).

Here: Our government is telling blank lies: "aber es gibt da technische Gründe, die durch ein politisches Wollen der Bundesregierung nicht wegzuwischen sind." They say it is technically not possible to support the older phones, but it is! As outlined here: corona-warn-app/cwa-app-android#75 (comment) the largest blocker is the Android version, not missing Bluetooth LE. Most phones have Bluetooth LE. You could emphasize this and maybe even make it to the news headline this way.

Maybe there are also other arguments to make. Like how relying on a Google API is a big privacy impact. How Google could secretly log all requests to that API to create an ultimate movement profile of every citizen. But here I wanted to focus on the strategic decision to explicitly advertise this project for older (Android 5 and below) operating systems could help to build a large coalition to secure the future development of this project. I was trying to spin public opinion in a way that many others and maybe SAP and Telekom would have officially supported your project, it already worked, here: corona-warn-app/cwa-app-android#75 (comment) This was a reaction directly to my post. Quote: "What I can't believe is, that the SAP earns 9.5 mio € for this App and is not able to support developers to build a Google API free version" This is the mindset I wanted to create.

Hi guys,

when I first heard about the German Corona warn app uses the Exposure API from Google / Apple I was very disappointed. Since I have LineageOS with no Google services I had the fear that I will not be able to actually use the app, despite it was discussed as a key factor to control the pandemic. Also people without this app could be locked from public life, directly or indirectly via. social pressure. Everyone could be forced to give up their Android alternatives and return to the official play service from Google.

Now I saw that there is a project to create your own Exposure API service that will work on phones without Google. I found you via. corona-warn-app/cwa-app-android#75

I think your project is very valuable, this has the potential to save free open source Android alternatives from extinction. Probably you don't even know how key your project is, but it is, everyone who has an interest in keeping free open source Android alternatives alive should support this project.

I have no time, I work all day despite corona, but I have money. Is there a way to donate?

Best,
Mario

How much is already done, how much is still missing, how long will it take roughly? It would be great if an estimated time schedule could be published e.g. on the CoraLibe website. I don't want to rush anyone, I just want to know what the current progress is. Thanks for your work!

From the official website (CTRL+F for "API 21"), version 1.1.0 of androidx-security-crypto supports Android API level 21, thus allowing us to lower the minimum API level. That version is still in an alpha phase, with the latest alpha-2 released on August the 5th, but I don't think it would be a problem to start using it even though it is an alpha

These methods are inside main/.../internal/database/PersistentDatabase.kt.
While they are so simple that they should probably work, it would not harm to have small tests for these as well. Look at the existing database tests if unsure how to start.

The CryptoModule and all the corresponding Unit Tests need to be updated to PPCP.
I recommend writing the Module from the ground up aside the original Module so existing code does not brake.

Make the actual EN API control the internal parts of our PPCP implementation. The API calls should not just be a Mock but a full working implementation. Meaning it can trigger the BLE server/client and ask the exposure algorithm what the propability for corona exposure is.

CAUTION: This requires #34 to be implemented.

• create documentation repository
• write functioning mkdocs site

Create an API and corresponding tests that is compatible to the original Exposure-Notification Interface.

Hi,
I am really loving this aproch, but will the app up to date with the forked version?

Making the app send and receive actual bluetooth data. This is based on the implementation of the databaseinterface and the cryptomodule.

• Transofmr dp3t so it works like ppcp

Currently the different modules that exist in the sdk are implemented as singletons. This bad for testing and dependency injection. It's rather suggested to have factory class which I can give implementations through a static init() function. Then use PPCP.getModule() instead of Module.getInstance().

I think enabling the issue tracker in the app project would be helpful for collaboration and general approachability of the project.

Test if coralibre interects with bluetooth headphones.
Through this we check if we can use 20 secons scan time or if we should stay with 5.
Test can be done with the test application.

From what I have found in the internet, we should be quite safe against any thinkable copyright complaints from google when publishing the EN API reimplementation. All information I have used for the reimplementation so far is available in the source code of the Corona-Warn-App. However, the Google APIs Terms of Service explicitely prohibit reverse engineering. Thus I would be glad if an expert in this field could provide some more information here. Also feel free to contact me via mail, if you have (professional) experience in this field and want to work through the topic with me.

I found some differences between the real GMS types and the fakeGMS types, namely:

• Most classes expose fields as public and mutable instead of making the fields private final and exposing the values using a getter
  • Changing to getters will presumably look the same to Kotlin callers
• ExposureConfiguration is missing all weight parameters (is this intentional?)
• ExposureNotificationStatusCodes is an enum instead of an uninstantiable class with public static final int status codes
  • This is probably not a huge deal, but it's limiting compatibility
• Some classes haven't actually been implemented

We need some data to test the actual matching algorithm, i.e. the computation of ExposureInformation and ExposureSummary objects from diagnosis keys and their associated bluetooth payloads / metadata.
More precisely we need:

• a set of diagnosis keys, each with a set of captured data (doesn't matter if the asociated metadata is encrypted or decrypted)
• correct ExposureInformation data computed from these data sets (probably multiple ExposureInformation items)
• data for an ExposureSummary item computed from these data sets

It would be awesome to have ExposureInformation/Summary items computed with the actual EN framework to be sure that everything is correct.
If that is not possible, we could use the microg implementation to generate ExposureInformation/Summary items from a set of manually created diagnosis keys and bluetooth payloads. Thus we could at least verify that the CoraLibre and microg implementations yield the same results.

By Injecting an AdvertisingService mock and BluetoothLeScanner mock we could write some automated tests for the Tracing service as well as BleServer/BleClient. Currently there is 0% coverage.

Depends on #28 and #34

This should be done before release, and the discussion that went on in #43 should be kept in mind.

This module is completely missing so far. We didn't yet start to implement the algorithm that calculates the probability and risc factor of an exposure. By now we can only tell weather we saw an infected key or not.

Webpage descirbing the algorithm:
#16

Also you can take a look at it here:
corona-warn-app/cwa-app-android#75 (comment)

Implement the highlevel API that should be used as a Mockup. This way tests with the frontend can already be conducted although its not yet functional. The inerface in question is described here. It is used by the App mostly in the InternalExposureNotificationClient class.

Kotlin is the first choice for new Android projects and offers quite a few quality-of-life improvements. I think we should transition the project to Kotlin to make it more attractive to new developers.

If others agree with me on this, I'd be glad to update the Gradle config myself.

Pros

• A lot of nice language features
• Less prone to nullability bugs
• Full Java interoperability
  • Transition can be done one file at a time

Cons

• Kotlin standard library dependency
• (A little) extra effort to keep the API usable for Java clients

The Task API is only defined in a very limited fashion right now, a lot of the various methods are missing. While I don't aim to implement the full API, expanding on the tiny API subset that's currently available will make it easier to adopt the CoraLibre SDK for tracing apps, as the Task API is used extensively in the ExposureNotificationClient interface.

Check if coralibre ceps working wehen phone goes into deepsleep mode.
Try with force idle command via adb.

Some Log.d() commands critical information that should not be exposed to LogCat. This may be necesary for debugging but should be prevented in production. Other Log commands should be checked as well.

Is:

Currently, the covid api as of Google suffers severe limiation in high multipath environments https://www.scss.tcd.ie/Doug.Leith/pubs/luas.pdf - https://www.heise.de/news/Corona-Warn-App-Studie-findet-Probleme-bei-der-Kontaktverfolgung-im-OePNV-4871811.html the RSSI by no means correlates with the actual distance. Furthermore, SARS-CoV-2 transmission in these enviroments is a subject of active reasearch. This regards for example ventilation systems and aerosols.

However, contact tracing apps are seen as a potential tool especially in the context of public transport.

Should:

CoraLibre should not rely on RSSI measurements in high-multipath environments.

Notes:

• Implementation details are open research questions - however, there is research on that.
• An intuitive way is to access positioning data (e.g. BL 5.1 direction finding, IEEE 802.11mc), but the privacy and technological implications are very challanging.
• As the offical CWA appears to be a Google / Apple only thing, CoraLibre may step in. But ... I hardly believe that you get a single Euro out of their 68000000 € project budget :-(.

Can we remove some of the (old) classes?

In particular:

• internal.crypto.CryptoModule with tests
• the other classes in internal.crypto (not internal.crypto.ppcp)
• the classes in internal.misc
• internal.bluetooth.BleCompat

related to #50

Bouncycastle is only partially supported by Android. In its function as a Java Security Provider, it should be replaced by conscrypt.

As far as I can tell, Bouncycastle is only ever explicitly used for its HKDF implementation right now, which isn't part of the Java Cryptography Architecture and therefore not included in conscrypt. Bouncycastle is however a massive dependency just for HKDF, so I suggest using Tink for HKDF, as it's actually already a transitive dependency through the androidx.security:security-crypto library.

If you agree with changing this, I'd be happy to implement it.

Hi,

I don't know if this might be of any use, I just wanted to point out in case it could be useful.
The french StopCOVID app is Play Services independent, it doesn't use the Exposure Notification API, so maybe you could find some useful code in there:

Bluetooth Low Energy SDK for Android

When a token is removed from the database, the following data associated with the token should be deleted automatically:

• all diagnosis keys for this token
• the ExposureSummary object for the token
• all ExposureInformation objects for the token

While this behavior is implemented, it is not fully tested, so we cannot be sure it works flawlessly. Inside androidTest/.../database/DatabaseTests.java we have a function testDeleteToken(), which currently only tests deletion of associated diagnosis keys. It should be extended or reworked to cover deletion of the other data as well.
(The method to be actually tested is inside main/.../internal/database/PersistentDatabase.kt)

DP-3T apparently also Defines also a protocol to communicate with a server providing the keys of infected people. We don't need this as we only need he bluetooth part. Therefore all the cloud connection parts can be striped from the sdk.

So far we only have an interface for a database, but there is only a mock implementing it. We need a proper persistent database.

In main/.../internal/database/PersistentDatabase.kt we have untested methods:

• getExposureSummary(token: String)
• getExposureInformation(token: String)

The DatabaseTests.java should be extended to cover these methods as well.
(The exposure summary and information data can be added to the database via putExposureMatchingResults(...) inside PersistentDatabase.kt.)

The minimum Android SDK level is 26 right now. We should lower that to at least 23, which would be the same as the official API.

Inside main/.../internal/EnFrameworkConstants.kt there are some constants set to values which have more or less been guessed. These constants are:

• MAX_EXPOSURE_INTERPOLATION_DURATION_SECONDS
• INTERPOLATION_ENABLED
• MIN_BUCKETIZED_DURATION_SECONDS

Somewhere in the EN framework documentation or the google code there should be hints to which values we should set these constants. We need to find out where to find this information, set the values correctly and document (in the code), where we got the values from.
The links under "Exposure Notifications" here should help. There are also some comments in our source code already pointing to google code, where the constants are used.
Even finding and documenting the correct value for one of these constants would be a great help!

(I marked this as a good first issue since it forces one to read through the EN documentation and the google code. However, if you did not look into that yet, it might take some time to get comfortable with.)