search

microg / GmsCore

Free implementation of Play Services
https://microg.org
Apache License 2.0
8.2k stars 1.69k forks source link

Exposure Notification (Corona) #1057

Closed SirLemyDanger closed 4 years ago

SirLemyDanger commented 4 years ago

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 commented 4 years ago

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

chris42 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@SirLemyDanger there is no virus you CIA shill

This API is the NSA's wet dream. All in the name of ‘ Healthcare ’ and the ‘ Good Doctors ’. These government lowlifes pulled the same shit in response to the September 11 attacks with the PATRIOT Act 18 USC § 2712. First they created mass hysteria. Muh Al-Quaeda. Then they forced the largest surveillance system in mankind's history upon us.

Federally mandated healthcare tracking systems and databases will weaken the privacy for all of us. A global database of all our movements in control of a bunch of nameless, faceless bureaucrats.

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

image

alexandruchircu commented 4 years ago

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

Mate, you're confusing GitHub with Reddit.

adaschma commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

jedie commented 4 years ago

See also the "Solution without closed source dependencys

75" Discussion in #CoronaWarnApp project.

Schyrsivochter commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

theScrabi commented 4 years ago

@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 commented 4 years ago

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

SirLemyDanger commented 4 years ago

under Apache 2.0 That must be helpful!

CFPrulez commented 4 years ago

Just in case that the API will be included into MicroG (personally I hope that this will not happen, but I see that there are different opinions):

Would it be possible to decide at build time whether to include the API or not?

If this is an option at build time, someone who does not want that functionality to be included can just compile with the corresponding option and there would be no need for a fork or cherry picking.

mar-v-in commented 4 years ago

@CFPrulez please read https://github.com/microg/android_packages_apps_GmsCore/issues/1057#issuecomment-640044663. There is definitely no need to put additional work into excluding things at compile time that have to be enabled explicitly anyway.

FestplattenSchnitzel commented 4 years ago

Google has uploaded the source code of the Exposure Notification API on GitHub. Maybe now it is easier to implement such an API in case it is desired. Source: Golem

mar-v-in commented 4 years ago

5f70d943cbceabcd9d2c72f8460ea58cba7e08fb

schiessle commented 4 years ago

5f70d94

@mar-v-in I just wanted to ask about the current state here and if someone is actively working on it... :smile: Thanks for working on it! :rocket:

lennartschoch commented 4 years ago

@mar-v-in Wow, awesome work! Is your implementation of Exposure Notifications already working and could theoretically be used (e.g. by the German Corona-Warn-App)? Or is it still WIP?

mar-v-in commented 4 years ago

@lennartschoch the implementation should be functional but not very user friendly and not yet feature complete. TODOs:

So WIP, yes, but supposedly already somewhat usable. I'm running it now (with CWA) on my main phone to get some real life data.

poshul commented 4 years ago

@mar-v-in , do you have any specific requests so far as testing to conduct? Also, is it possible to put together a release as soon as this is implemented? Thanks for all the hard work.

ljl-covid commented 4 years ago

Has this been tested, by any chance, with the Italian Immuni open-source app yet? If not, would it be possible to have a signed build ("release", if you will) to test it independently? I am not really able to compile and use my own build.

mar-v-in commented 4 years ago

I installed the Immuni app to my test device and so far it looks like it's working as intended, but to really know, I'd have to wait a few days.

The release 0.2.12 with EN API will probably be available in the next days anyway.

Tomptez commented 4 years ago

Thank you so much for your work!

Is there any news as to when this will be released and be available via f-droid?

SirLemyDanger commented 4 years ago

Thank you so much for your work!

Is there any news as to when this will be released and be available via f-droid?

There is the possibility to become a sponsor of @mar-v-in . Just sayin'... https://github.com/sponsors/mar-v-in

Tomptez commented 4 years ago

That's sincerely a great idea!

There is also the possibility to support his work via liberapay which I currently do!

cgrigis commented 4 years ago

@mar-v-in Hello! We are looking for a way to run the SwissCovid app (https://github.com/DP-3T/dp3t-app-android-ch) on phones without Google Services (e.g. open OS, or manufacturer OS without Google Play), and looking at what is out there before starting a new implementation. I am very impressed with how far you got in your work, congrats!

Here is my current understanding and some questions (please correct me if I am wrong):

We are willing to commit resources to help in any of these points, as it looks close to allow us to reach our goal.

Thank you for your insights.

ljl-covid commented 4 years ago

In order to use the microG EN implementation, one must have a device with microG installed, which requires Signature Spoofing. What is missing to be able to use it directly as a library from an app?

@cgrigis microG provides an alternative implementation of the Google mobile services, which means that apps can and do use the existing proprietary client app to access it, and that's why it requires spoofing the signature of the real Google mobile services. If you want to skip this step and use something directly from a customized version of the app, you may want to have a look at CoraLibre, although I don't believe the implementation is complete and working yet. It requires adapting apps and cannot be used as a 100% drop-in replacement.

tobru commented 4 years ago

In order to use the microG EN implementation, one must have a device with microG installed, which requires Signature Spoofing. What is missing to be able to use it directly as a library from an app?

Have a look at https://lineage.microg.org/ which actually is a LineageOS distribution with microG pre-installed.

mar-v-in commented 4 years ago

@cgrigis

cgrigis commented 4 years ago

Thank you everyone for your answers.

@mar-v-in

mar-v-in commented 4 years ago

@cgrigis

ljl-covid commented 4 years ago

Note that if you do what @mar-v-in says i.e. complete the microG client library with the ability to use this feature, then the application should be eligible for inclusion in F-Droid, as the build wouldn't contain the proprietary code anymore (assuming the rest of the app is open source, of course). So since there would likely be a need to distribute two different versions due to Play requirement, the version using the microG client library could be distributed via F-Droid, which many people who use microG already have installed, partly due to LineageOS for microG including it.

cgrigis commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 :microbe: Exposure Notifications.

rugk commented 4 years ago

and ready for release.

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

mar-v-in commented 4 years ago

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