Exposure Notification (Corona)

[SirLemyDanger]

Hi,

everybody is speaking about a corona app these days. It seems that the plan by google is to provide initial support via the google play services and only later (if at all) include support in Android itself.

https://www.blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf

This document provides the detailed technical specification for cryptographic key scheduling for a new privacy-preserving Bluetooth protocol to support Exposure Notification. Exposure Notification makes it possible to combat the spread of the coronavirus — the pathogen that causes COVID-19 — by alerting participants about possible exposure, through someone they have recently been in contact with who has subsequently been positively diagnosed. This specification complements the Bluetooth specification, which contains further information about the scheduling of broadcasts and the higher-level life cycle of the Bluetooth protocol.

Is there a chance that a corona app using Exposure Notification will be supported by mircog?

Cheers,
Lemy

[SirLemyDanger]

And the API docs: https://www.blog.google/documents/68/Android_Exposure_Notification_API_documentation_v1.2.pdf

[chris42]

I think this is highly unlikely. @mar-v-in has not nearly enough time to cover other API aspects, so I doubt he will concentrate on a possible temporary part.
Of course it is up to him to decide...

[SirLemyDanger]

On the other hand one doesn't have to maintain it too long. So introducing this new API now doesn't mean a loss of time for the next years to come. Also code qualitiy (in terms of maintainability) doesn't have to be as high as for long standing projects.
This could

1. speed up development
2. allow for more external help.

[ArchangeGabriel]

May I add that this is not good for privacy (for many reasons), so I for one would not advocate implementing it, and if so at least behing a toggle.

[rugk]

On the other hand one doesn't have to maintain it too long. So introducing this new API now doesn't mean a loss of time for the next years to come.

Depends on your perspective: That heavy cryptographic are likely not easy to implement. As such, especially as it is only useful for some time to come, it is not really useful to be implemented in microG and one may rather need to focus on maintaining the other parts instead of implementing a new feature.

Also code qualitiy (in terms of maintainability) doesn't have to be as high as for long standing projects.

I'd also challenge that, because if it has a low quality, that could mean an increased likelihood for a) false-positives (you get an alarm, although you should not) or b) false negatives (you do not get an alarm, although you should). That's certainly not what we want for such a medical topic…

[SirLemyDanger]

Don't get me wrong, I cannot argue against you if you say that implementing this is work. It is. But implementing a fuctionallity (even with tests and stuff) and implementing a functionallity in a way that it is easily maintainable are two different classes of programming.

The reason for my proposal is that I believe this has a high social impact and that in a world wide crisis like we are now all pepole should do what they can to help each other. And it looks to me that this project is in a position to help.
If there is no time to do this I find it sad but I won't blame anyone. It is not the end of the world.

[froho975]

Please don´t, i repeat do NOT implement the new API in MicroG/GMSCore.

If anybody wants to use googles new API, he/she should just go back to goole-play-services instead of mutilating a perfectly good service.
There are many people that do NOT want to have googles API on their phone, BECAUSE of the social impact it will have.
Hopefully this fine Service stays free of any unnecessary API´s already available elsewhere.

[rugk]

The social impact won't be changed regardless of whether this is implemented or not.

Also, of course it should go without the need to say, it should be optional – if someone really would implement this, whcih i still doubt. Just like all the other features of microG, which all have a toggle…

Also, this feature may be implemented in AOSP by Google (see here), making this feature request obsolete.

[alexandruchircu]

Vote my post down. Give me the thumbs down. I don't give a damn you wankers.

Mate, you're confusing GitHub with Reddit.

[adamschmalhofer]

If I understand this thread correctly this is a 'patch or won't happen' issue. This isn't a top priority of the currently most active developers who -- as all of us -- have limited time and have the freedom to decide what they want to spend it on (and nobody should take that freedom away from them). If somebody however does implement it will be reviewed with thee goal to merge it. Am I correct?

[mar-v-in]

@adamschmalhofer I wouldn't say it's a top priority, but it's at least high on the list. However I'm really not an expert on Bluetooth things, so I'd highly appreciate a helping hand.

I see that @theScrabi is working on a compatible implementation of the sdk, so maybe it makes sense to join forces? https://github.com/theScrabi/CoraLibre-android-sdk

[JokerGermany]

Can someone tell me why everything is tried to be bundled in one package?
I want the really basics and everything else (like a Exposure API) should be optionally usable...

[mar-v-in]

@JokerGermany everything needs to reside in the same package name and thus in the same binary. Apps using an API cannot see which API is implemented, they check for a version number. Each version number is supposed to implement certain APIs and thus apps may crash if an API is not implemented but the corresponding version announced.

However, each feature can be made optional, such that it's not functional if not enabled explicitly. This is already done for several APIs (like push notification, device checkin and so on) and certainly can be expanded. Nearby Exposure API will have to be enabled by the user explicitly for each app trying to use it (afaik this is done similarly in the Google implementation).

On top I'd like to make it transparently visible when and what data is shared through this API with gov apps. As far as I understand, most criticism from people regarding Nearby Exposure API is not based on facts for the specific protocol, but is rather caused by a general (not completely irrational) distrust against governments and big tech. In this case, transparency is key to show people what the API is really doing, so they can build an educated opinion on the tech independent of whom is providing it.

[theScrabi]

Helping us would be very good. We are kind of slow right now as @poschi3 and I are only sometimes working on it.

[jedie]

See also the "Solution without closed source dependencys
#75" Discussion in #CoronaWarnApp project.

[Schyrsivochter]

Please don´t, i repeat do NOT implement the new API in MicroG/GMSCore.

If anybody wants to use googles new API, he/she should just go back to goole-play-services instead of mutilating a perfectly good service.
There are many people that do NOT want to have googles API on their phone, BECAUSE of the social impact it will have.
Hopefully this fine Service stays free of any unnecessary API´s already available elsewhere.

But … that’s the whole point of GmsCore – reimplementing the Google Play Services in free software! By your logic, aren’t the Maps API or NLP also ‘unnecessary APIs already available elsewhere’? Should every GmsCore user who uses apps that rely on these go back to the proprietary Google Play Services, too? If you want to complain about the concept of GMS per se, you’ve come to the wrong place.

I know that if people don’t have the time or energy to implement this, there’s nothing to be done. We can’t force anyone. Still, I think implementing Exposure Notifications in GmsCore is important, and a matter of urgency.

For those concerned about malicious apps abusing this API for tracking users, there could be a setting to disable it. But honestly? That’s a pretty unlikely scenario, given how much effort would be involved – an app needs BLE permission for this API to work, and once you have BLE access, you can use beacons to track people’s location, so why bother with tracing the constantly changing exposure keys and rolling IDs?

[ljl-covid]

The code is open. That's a huge difference compared to the Google Play Services. If someone doesn't want the exposure notifications, they can disable them and be sure that they are disabled by auditing the freely available source code. This is the same with other features that are perceived as invasive; nothing new here to complain about.

[eggercomputerchaos]

@ljl-covid
the app source is open - yes -
but not the google api interface and imho - that's the problem for privacy.
Here is a very god explanation (unfortunately only in german):
https://digitalcourage.de/blog/2020/corona-warn-app

[ljl-covid]

@eggercomputerchaos I'm not talking about the contact tracing app's source code or any library it contains, I'm talking about the microG source code. The contact tracing apps vary by country, and it would make no sense to focus just on the German one (I'm in Italy, and Italy has its own, it's also open source, it also uses the exposure API, but it's different), but most importantly for the purposes of this issue, installing those apps is entirely optional, so any concern is unrelated to microG.

The concern I was addressing is about having an implementation of the exposure API within microG, and as I said, if we had that, it could be disabled, or the user could simply not install any app that uses it, much like everything else inside of microG. I note also that apps that use microG not being fully open source is typical, because the GMS client library is itself not open source, but is included in the apps. This has never been something that stopped microG from implementing those services that these app use.

[eggercomputerchaos]

@ljl-covid
sorry - was a misunderstanding from my site ;-)
which services will implement - that's the decision of the dev's

[theScrabi]

@ALL we need help to implement the open corona tracing implementation. If you have knowledge about bluetooth on andorid (or else), please come over :)
https://github.com/theScrabi/CoraLibre-android-sdk

[SteffenGerdes]

Google just released the code of the exposure notification API. May be helpfull
https://github.com/google/exposure-notifications-internals

[cgrigis]

@mar-v-in @ljl-covid Thank you for your valuable insights! I'll discuss with the people here to agree on a way forward.

[ljl-covid]

@mar-v-in don't know if this can be useful to you for testing, or if you maybe already know about it, but XDA has a list of applications using the exposure notification API with Play Store links.

[cgrigis]

@mar-v-in Would you have a guestimate of the extent of work that it would take to complete the client library? I understand it is not in your priorities, but I am willing to work on it if possible (and if we decide to go in this direction)...
Looking at it, I saw the implementation of provideDiagnosisKeys() is missing, and tried to fill this in (I have no device to test yet though ;-) ). Is there a lot more I am not seeing?

[mar-v-in]

The implementation is fully functional and ready for release. I am closing here.
There are some improvements/additions pending, which are now tracked in various issues with tag 🦠 Exposure Notifications.

[rugk]

and ready for release.

I don't want to rush, but is thee an ETA for the release?

[mar-v-in]

@rugk Yesterday. https://github.com/microg/android_packages_apps_GmsCore/releases/tag/v0.2.12.203315

[schiessle]

And it is already available in F-Droid... 🎉 I just installed it and the German Corona App seems to work fine 🙂

[rugk]

Oh okay, even more awesome! 😊

[qoheniac]

It's also available through the F-Droid repo. Corona-Warn app seems working fine. Great job! :)

[ljl-covid]

Immuni is also working apparently fine. You had already confirmed that, but I'm confirming the confirmation.

[Tomptez]

Hello,
unfortunately I don't get the Corona Warn App to work. It might very well be due some misconfiguration on my side, but maybe anybody has any pointers?

Microg seems to be configured correctly

But the warn app throws this error

It's the most recent version of the corona warnapp 1.3
I am using Android 9, Havoc-OS 2.9 on a Moto-G4

Any ideas what could be the problem? (I tried reinstalling and rebooting)

[piegamesde]

@Tomptez The second screenshot reads "Exposure Notifications: Off"

In MicroG, all features are opt-in

[mar-v-in]

@Tomptez you need to install FakeStore and grant signature spoofing permission to it in system settings. That's the one thing that is not ticked in your self-check screenshot.

[Atemu]

@piegamesde EN have to be enabled by opening and "registering" an app which uses them. You can't turn it on otherwise.

[Tomptez]

@mar-v-in Wow that was easy. Thanks for all the hard work and the quick reply! It works perfectly!
(I had searched f-droid for phonesky before but didn't quite know what was meant by that)

[iliis]

I'm running the SwissCovid app since Thursday evening and it seems to be running fine :) Thank you very much for your work on this and for microG in general!

[rugk]

BTW, I'm commenting here, because I guess many people following this might be interested in this:
To make it possible to switch from a Google Play Services to microG, one important thing (which is AFAIK still missing), would be to be able to import your tracked encounters/exposure data. Fortunately Google does have an export, so only an import in microG is missing AFAIK.
Please follow/I've opened #1208 about this topic.

[mh-]

No, Google does not export RPIs or TEKs, only reports.

[rugk]

Yeah, sorry I was wrong about that export before. But that is explained in that other topic.

---

Anyway, another cross-link for all German/CWA users reading thie issue here. IMHO the German CWA app should now be on F-Droid (as it is usable without Google Play Services). So please have a look at corona-warn-app/cwa-app-android#1483 and upvote it, if you agree.
This shows them that there is a user base that needs this feature.

Edit: Also opened issue for Belgian fork: covid-be-app/cwa-app-android#117

[chris42]

I don't think that matches with F-Droids idea of "not needing google play services" and I am not sure it is right to label it that way. CWA does need google play services, we have just found a workaround with microg. If you install the app, it will need google play services or a fake of it.

RKI would need to support microg then with all sorts questions on how to make faking google play services work. To get rid of the google play store, it would probably be easier for RKI to just publish a download on their website.