Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exposure Notification (Corona) #1057

Closed
SirLemyDanger opened this issue May 4, 2020 · 64 comments
Closed

Exposure Notification (Corona) #1057

SirLemyDanger opened this issue May 4, 2020 · 64 comments

Comments

@SirLemyDanger
Copy link

SirLemyDanger commented May 4, 2020

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
Copy link
Author

SirLemyDanger commented May 4, 2020

@chris42
Copy link

chris42 commented May 4, 2020

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
Copy link
Author

SirLemyDanger commented May 4, 2020

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
Copy link
Contributor

ArchangeGabriel commented May 4, 2020

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
Copy link

rugk commented May 13, 2020

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
Copy link
Author

SirLemyDanger commented May 13, 2020

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
Copy link

froho975 commented May 26, 2020

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
Copy link

rugk commented May 26, 2020

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.

@cherryland

This comment has been minimized.

@alexandruchircu
Copy link
Contributor

alexandruchircu commented May 31, 2020

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
Copy link

adamschmalhofer commented Jun 6, 2020

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
Copy link
Member

mar-v-in commented Jun 6, 2020

@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
Copy link

JokerGermany commented Jun 6, 2020

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
Copy link
Member

mar-v-in commented Jun 6, 2020

@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
Copy link

theScrabi commented Jun 8, 2020

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

@jedie
Copy link

jedie commented Jun 16, 2020

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

@Schyrsivochter
Copy link

Schyrsivochter commented Jun 17, 2020

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
Copy link

ljl-covid commented Jun 17, 2020

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
Copy link

eggercomputerchaos commented Jun 17, 2020

@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
Copy link

ljl-covid commented Jun 17, 2020

@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
Copy link

eggercomputerchaos commented Jun 17, 2020

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

@theScrabi
Copy link

theScrabi commented Jun 18, 2020

@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
Copy link

SteffenGerdes commented Jul 23, 2020

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

@cgrigis
Copy link
Contributor

cgrigis commented Sep 4, 2020

@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
Copy link

ljl-covid commented Sep 6, 2020

@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
Copy link
Contributor

cgrigis commented Sep 7, 2020

@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
Copy link
Member

mar-v-in commented Sep 10, 2020

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
Copy link

rugk commented Sep 11, 2020

and ready for release.

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

@mar-v-in
Copy link
Member

mar-v-in commented Sep 11, 2020

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

@schiessle
Copy link

schiessle commented Sep 11, 2020

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

@rugk
Copy link

rugk commented Sep 11, 2020

Oh okay, even more awesome! 😊

@qoheniac
Copy link

qoheniac commented Sep 11, 2020

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

@ljl-covid
Copy link

ljl-covid commented Sep 11, 2020

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

@Tomptez
Copy link

Tomptez commented Sep 12, 2020

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

Screenshot_20200912-115714
Screenshot_20200912-115749

But the warn app throws this error
Screenshot_20200912-115832

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
Copy link

piegamesde commented Sep 12, 2020

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

In MicroG, all features are opt-in

@mar-v-in
Copy link
Member

mar-v-in commented Sep 12, 2020

@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
Copy link

Atemu commented Sep 12, 2020

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

@Tomptez
Copy link

Tomptez commented Sep 12, 2020

@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
Copy link

iliis commented Sep 12, 2020

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
Copy link

rugk commented Oct 4, 2020

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-
Copy link

mh- commented Oct 4, 2020

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

@rugk
Copy link

rugk commented Oct 26, 2020

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
Copy link

chris42 commented Oct 27, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests