Dependency on GMS

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.

[simonroesch]

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]

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.