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

Dependency on GMS #10

Open
fynngodau opened this issue Apr 16, 2020 · 11 comments
Open

Dependency on GMS #10

fynngodau opened this issue Apr 16, 2020 · 11 comments

Comments

@fynngodau
Copy link

The current implementation does not use the as yet unreleased "Contact Tracing" API of Apple/Google

Our immediate roadmap is: […] support the actual Apple/Google API […]

As I read this, I understand that this project will depend on a coming-soon API which will be part of Google Play Services (GMS) from Android 6 and onwards¹.

However, I see this in a stark contrast to the promise that this project is "truly open-source", as the GMS are proprietary and non-free by design. In the free software community, it is generally consens that a true free software application cannot depend on a proprietary component to operate. For example, F-Droid, the repository for truly free Android applications, does not include applications that contain a proprietary library. Many users who care about free software take care to only use software that respects this high standard.

Secondly, the GMS automatically come with other means of tracking the user in potentially unwanted ways, which I see as a conflict to the promise of a privacy-preserving contact-tracing application. For example, Googles "push" notification service polls Google servers for new notifications for ones device constantly, thereby leaking metadata and, depending on the application that registers for this service – usually without the user's knowledge – notification content to Google. It also typically comes with other software that Google demands vendors to install on devices that are shipped with GMS, which are seen as bloatware by some. This is why some users decide to remove this piece of proprietary and non-free software from their systems, and they should not be hindered from using an implementation of a contact tracing application.

Lastly, I believe a contract tracing application should work independently from commerical providers. Google is a company with commercial, for-profit interests. Driven by profit, they could abuse the collected data by combining them from all devices that use their API and de-anonymize its users. This is a reason to support independent implementations instead of ones depending on the grace of for-profit entities.

In conclusion, I belive it is important that a truly free and indepentent contact-tracing application exists. Even if there may be downsides to not using the GMS API, a dependency on it would be a major trust issue that will cause the technical privacy-aware community to reject this application.


¹I am not sure why Android 6. I saw that this SDK has its minSdk set to API 23 (Android 6). Is this related to Google's announcements, or are there other reasons? BLE is available from Android 4.3 (API 18). I believe it is important to support old devices as well. I will have another look at this.

@DC7IA
Copy link

DC7IA commented Apr 16, 2020

Like he says: To be truly open it should not depend on closed source.

Also, I do not use Google Play services, so there will be no way to contribute.

@marado
Copy link

marado commented May 7, 2020

This has been raised a few weeks ago, and it would be nice to have some feedback on it from the maintainers of this repository.

If this is a compromise that they deem acceptable, a clear statement on that should be made.
If this is something still being considered, it would be nice to know that is the case (a comment to this issue would probably suffice).

@marado
Copy link

marado commented May 19, 2020

As #109 implements this dependency, it seems to me that a decision on this issue becomes more pressing.

@oscaropenness
Copy link

The Pilot app released today to be tested by swiss federal institutions is dependant on GMS and does not work without Play Service installed!

This makes this app completely useless to me. It becomes very hard for me as well to recommend it to people I know.

I am truly disappointed with this decision and in my opinion ruins my trust in this software. Who can tell what data Google is collecting with this App? Nobody, since we cannot check the code!

I do not understand, why one needed to include this dependency as the technology seemed to work just fine without it before...

@simonroesch
Copy link
Contributor

The reason for this decision is simple: Without the support of the OperatingSystem it is really hard to create a reliable solution that does bluetooth scans in the background. We had trouble with multiple OEMs killing our scanning-process or just disabling bluetooth scanning (returning just no results) when the device was in idle mode. Therefore we are very happy to get the support of the operating system and are thus able to create a more reliable version. The protocol that Google uses is public and can be implemented by a third party, so it will be possible to create at some point a version of the app that does not rely on the Google PlayServices and thus runs on the remaining devices - but there you will have the trouble with the unreliability.

@oscaropenness
Copy link

Is there a timeline of when this truly open source version of the app will be available?

Because as it is now, it does not live up to the promises of being open and transparent.

Google is also not bound to the privacy laws of Switzerland, so they might be violating them with their play store tracking implementation for all we know.

@oscaropenness
Copy link

oscaropenness commented May 25, 2020

I am confused and maybe you can further clarify:
I found this statement in the FAQ from the BAG:

  1. The app from the Federal Institutes of Technology in Zurich (ETHZ) and Lausanne (EPFL) works with its own protocol. This will then be replaced by the Apple or Google protocol. Will data security still be guaranteed?

The Apple/Google application interface (API) is not a mobile phone app. It is a standard proposed by Apple/Google in order to achieve a more accurate estimate of the distance between two mobile
phones via Bluetooth, and to reduce electricity consumption by Bluetooth Low Energy. Data security remains guaranteed – the Apple/Google standard is also based on the DP-3T concept drawn up by the Federal Institutes of Technology in Zurich and Lausanne.

Is this statement correct? Because the Google Play Service Framework is basically an app with system privileges, so if you rely on the Google's implementation you are in fact using an App from Google.
Why did you not implement the protocol yourself?

Or am I not getting this right?

@marado
Copy link

marado commented Jun 16, 2020

While this issue isn't solved, someone decided to create a fork to tackle it:
https://github.com/theScrabi/CoraLibre-android-sdk

@fralau
Copy link

fralau commented Jun 23, 2020

Note that on the 25th, the NSCS (National Cyber-Security Centre) of MELANI administration in Switzerland is starting a Public Security Testing.

The concern here, what is really possible to test with this app, if the public cannot compile it for lack of access to proprietary SDKs?

@fralau
Copy link

fralau commented Jun 23, 2020

Additionally, there is a problem with that clause:

"Participants are allowed to publish their findings after the respective finding is published on NCSC’s website. "

What assurance do we have that NCSC will faithfully release the security test reports, considering that, it did not disclose, on its website the entirety of the LASEC report mentioned in DP-3T/documents#325 (comment) , but only a heavily-edited extract, which has been accompanied by rebuttals?

In other words, is there not an apparent conflict of interest in NCSC's role of both "tester" and "defender" of the security of the DP-3T application toward the Swiss Federal Administration?

@oscaropenness
Copy link

There is now an open source FLOSS implementation of the Exposure notification available which can be used as a drop-in replacement of the Google API.

I am not familiar with the role of the SDK and the SwissCovid app. Would this new dependency need to go into the App or into the SDK?

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

No branches or pull requests

6 participants