Availability in F-Droid

[henrykrumb]

Dear ladies and gentlemen,

since the app is going to be OpenSource software, are there any plans to make it available on alternative platforms, for instance on F-Droid (https://f-droid.org)? That would enable users of alternative or modified Android images to use and regularly update the app.

Best regards Henry

[codedust]

Many Android users, e.g. those using LineageOS or Replicant, do not use Google Play Services for privacy reasons. In order to achieve broad adoption of the app and enable anyone to use the app it is inevitable to have the possibility to use the app without proprietary Play Services installed.

Please make sure it is possible to compile the app without any non-free dependencies. This would allow the app to be included in F-Droid. See F-Droid's inclusion policy for details:

We cannot build apps using Google’s proprietary “play-services”. [...] We cannot build apps using proprietary tracking/analytic dependencies like Crashlytics and Firebase. [...] We cannot build apps using proprietary ad libraries. [...] We cannot build apps requiring Non-Free buildtools, including Oracle’s JDK or some pre-release toolchains. [...]

Thanks in advance!

[MalteJ]

We are not planning to deploy to any App Stores except Google's and Apple's. However the community is free to contribute. All libraries used by the iOS or Android apps will be under an open source license - maybe you will have to implement your own BLE beacon implementation as this is part of the iOS operating system or the Google Play Store Services.

[zoobab]

You can't audit the code of the entire iOS operating system, so it is pointless to rely on it for your privacy.

The same remark is valid for Android, many parts are not open source, including the firmware of the baseband processors, where governments, law enforcement agencies and telcos might have access to the end terminals.

So they are both non-starter platforms if you want to audit the entire code base from a privacy perspective.

[MalteJ]

@zoobab if you don't trust your smart phone you are free to build an implementation on the hardware device of your choice (e.g. ESP32). The BLE specs will be released by Google/Apple and also the API to our backend.

[zoobab]

@MalteJ the ESP32 is a bad example, the wifi stack is also a binary blob. In the earlier versions of the wifi stack, I found hardcoded addresses of an IOT server in China.

[mritzmann]

Sure, a Google Play loose app would be cool, but that's just not technically possible. Because the API that does everything in the background comes directly from Google and Apple.

https://blog.google/documents/70/Exposure_Notification_-_Bluetooth_Specification_v1.2.2.pdf

Also, the app has to work for 99.9% of the population and not for 0.01% Lineage-OS users. :man_shrugging: Therefore, this issue is at the moment completely pointless... Maybe this possibility will be available in the future, once the API has been implemented by LineageOS and others.

[henrykrumb]

Also, the app has to work for 99.9% of the population and not for 0.01% Lineage-OS users. Therefore, this issue is completely pointless...

I was just wondering whether I (one of the 0.01%) will be able to use the app. Not being able to install the app might have an impact on my life, as I might be excluded from certain social activities in the future if I continue refusing to use Google services.

If this issue is not pressing at the moment, that's fine. But calling my question "completely pointless" is disrespectful.

[mritzmann]

But calling my question "completely pointless" is disrespectful.

Sorry, that was rude. My bad.

[IzzySoft]

@MalteJ quoting, emphasis mine:

All libraries used by the iOS or Android apps will be under an open source license - maybe you will have to implement your own BLE beacon implementation as this is part of the iOS operating system or the Google Play Store Services.

Now taking a look at Wikipedia: Google Play Services we see: "License Proprietary". Somehow doesn't match. Just for info: this is a blocker for F-Droid inclusion.

Note: I'm not arguing here, just pointing out to keep any "hopes" for F-Droid inclusion on a realistic level. Some of you might have wondered about the wontfix label – so this comment hopefully gives some background.

[MalteJ]

Sorry, we use the APIs that Google and Apple provide. Further we use libraries that are under open source licenses ;)

To make it clear: SAP and Telekom are not going to work on F-Droid support. The apps developed will use the Apple and Google Contact Tracing APIs. Still, the community is welcome to fork the apps and replace the Google/Apple APIs by an open implementation and distribute this app via open app stores.

[codedust]

To make it clear: SAP and Telekom are not going to work on F-Droid support.

F-Droid support follows naturally by not including any proprietary libraries. This is not about replacing the Apple and Google Contact Tracing APIs, which should be a completely different issue. I'd be happy to see a corona warn app that does not include any proprietary library (which would indeed require the Contact Tracing APIs to be accessible without any proprietary library).

[smartens]

Seems other countries have problems because they are not using the APIs provided by Google or Apple https://www.theverge.com/2020/5/5/21248288/uk-covid-19-contact-tracing-app-bluetooth-restrictions-apple-google

[rugk]

Sorry, we use the APIs that Google and Apple provide.

The big question would be: Does Google include these in the Google Play Services library or in the Android OS (in an update)? Or both? In case of the first, this app would likely need a proprietary dependency. The latter case would allow the app to be 100%ly FLOSS and be distributed on F-Droid/outside of the Google Play Store.

---

To answer this question (partially) by myself: In the first case, of course it could also be implemented in microg – an FLOSS Google Play services replacement, which would allow that feature, at least. Looking into it, there actually already is an issue: https://github.com/microg/android_packages_apps_GmsCore/issues/1057

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.

[lukasmasuch]

As far as I know, DP-3T and TCN Coalition are considering to provide open-source clients compatible to the Apple/Google specification. There could be definitely a fork of the Corona-Warn-App integrating those clients instead of the Exposure Notification API from Google.

[frogg]

Sorry, we use the APIs that Google and Apple provide.

The big question would be: Does Google include these in the Google Play Services library or in the Android OS (in an update)? Or both? In case of the first, this app would likely need a proprietary dependency. The latter case would allow the app to be 100%ly FLOSS and be distributed on F-Droid/outside of the Google Play Store.

Google plans to release the first version directly through an update of the Google Play Services. This ensures a quick and broad adoption among Android users. Later on, an Android OS update should become available as well. Source: https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/

[mipimipi]

Persons who don't have the Google Play Store installed on their Smartphone could use the app Aurora Store to install apps from the Google Play Store (at least apps that don't require a payment). The Aurora Store app is available at F-Droid and allows anonymized access to the Play Store.

[frogg]

Persons who don't have the Google Play Store installed on their Smartphone could use the app Aurora Store to install apps from the Google Play Store (at least apps that don't require a payment). The Aurora Store app is available at F-Droid and allows anonymized access to the Play Store.

From my understanding, Google Play services include the crucial bluetooth tracing SDK. Without those, the app cannot function.

[IzzySoft]

@mipimipi that wouldn't help if those persons are running "Google free" on-purpose: as the required (GMS) API isn't there then, the app could not work.

[panoptikum]

Also, the app has to work for 99.9% of the population and not for 0.01% Lineage-OS users. Therefore, this issue is completely pointless...

I was just wondering whether I (one of the 0.01%) will be able to use the app. Not being able to install the app might have an impact on my life, as I might be excluded from certain social activities in the future if I continue refusing to use Google services.

If this issue is not pressing at the moment, that's fine. But calling my question "completely pointless" is disrespectful.

The emphasis lies on "might". There are even people who do not own a smartphone or even a mobile phone at all. At this moment, it is very unlikely that these apps will be required by law to pursue your life. We need an adoption above 60-70 percent that the tracing app has a significant impact, for which F-droid support is not needed. It's important that the work gets done and that we can completely audit the apps externally. To cover every niche or every problem that might surface beforehand is in my personal opinion less important.

[kripton]

Quoting from the Readme:

The data will be stored locally on each device preventing access and control over data by authorities or anyone else. We will meet the applicable data protection standards and guarantee a high level of IT security. By doing so, we are addressing people's privacy concerns and thereby aiming to increase the adoption of the app.

Even though the data is only stored locally, how do you plan to "meet the applicable data protection standards" if the data is coming from a proprietary, closed-source component with an "open API"? Since the contact detection is done via BTLE, I assume that location access must be enabled on the device at all times? How will you, as app developers, be sure that the API you are using is not sending the user's location to anyone?

So, basically, even though the app and the backend are open-source (which is a great step in the right direction), I and many others won't be able to use the app since it was decided to rely on non-open-source dependencies. Sad story.

[lukasmasuch]

@kripton Indeed, the Apple/Google components are currently not open-sourced, so it is not possible to fully check the implementation. However, everyone who is using Android with Google Play Services or iOS already needs to trust Apple/Google to a certain degree to not do harmful actions with the device sensors & APIs. The Exposure Notification API would not really be different from many other existing closed-source device APIs. But I would definitely like to see a fork using only open-source technologies as mentioned in https://github.com/corona-warn-app/cwa-documentation/issues/5#issuecomment-627886828 addressing Android devices without Play Services.

I assume that location access must be enabled on the device at all times?

Based on the additional terms document from Google, the app is not allowed to request the location permission. And I think there is no requirement for location access to use the Exposure Notification API.

[heeplr]

@panoptikum

We need an adoption above 60-70 percent that the tracing app has a significant impact, for which F-droid support is not needed. It's important that the work gets done and that we can completely audit the apps externally. To cover every niche or every problem that might surface beforehand is in my personal opinion less important.

I'd like to point out that, while F-Droid availability might be a less important niche problem regarding adoption and function, it surely isn't when regarding privacy/security concerns.

A reproducible build is vital for generating trust when deploying an app at this scale and with this level of privacy concerns in the general public. An F-Droid release would be a step in the right direction, since F-Droid supports reproducible builds. The pure availability on F-Droid without closed-source dependencies would generate trust for the same app in the Play Store.

I'm not fully aware of the details of the APIs provided by google and whether it's technically feasable at all. If it is (and even if 100% of the code can never be covered because of firmware blobs), it should be approached. If anyone can take the huge efforts of releasing such an app in a timely manner AND bundling the (open source) APIs from google, it would be SAP and Telekom, I suppose.

If you (or AOSP, microg etc.) can't actually use the source code that Google will release, then open sourcing the APIs code doesn't add a lot to trust (if I understand correctly) but has merely educational value. In the end, everyone would need to trust a non-reproducible binary provided by Google.

[IzzySoft]

everyone who is using Android with Google Play Services or iOS already needs to trust Apple/Google to a certain degree

with health data? No, thanks. That's an entirely different thing altogether. Apart from that, this issue was raised by someone who (like me) does NOT trust those companies. Saying "well, you trust for that, so just add a little more" is a step-by-step undermining of all privacy (nobody asked us if we "trust" – we simply cannot go to a shop and purchase a device coming without that, so where's the choice for the "average Joe and Jane"). In German there's a saying of "if you offer a little finger, they take your entire arm". While the majority is certainly ignoring such issues, it doesn't mean "it's fine".

Oops, I didn't want to argue. Again fell into the trap… Apologies.

[rugk]

Additional link for the reproducible builds, which are a good idea – regardless of whether it is released on F-Droid or not: https://f-droid.org/en/docs/Reproducible_Builds/

Edit: new issue found at https://github.com/corona-warn-app/cwa-documentation/issues/14

[rugk]

As some seem to claim that app will not work without Google Play Services: That is likely not true.

As said earlier by @frogg (highlighting by me):

Google plans to release the first version directly through an update of the Google Play Services. This ensures a quick and broad adoption among Android users. Later on, an Android OS update should become available as well.

If they keep their plan, that – to my understanding – would mean this gets into the AOSP code, is thus open-source and thus allows one to use it without Google Play Services (e.g. on LineageOS). It could will just take more time…

That is the theory and only based on the claims of the previously linked articles.

[ghost]

That's a good start. GitHub (any small open source developer can raise their own privacy-friendly Git instance) and no publishing in F-Droid. At least the source code is publicly available. Conclusion: 👎

[rekire]

Just because I'm annoyed about the dozens mails I got here is my feedback for you: If you don't care for the Google eco system then you are very likely to use side loading anyway. So please use apkmirror or similar services.

[jugendhacker]

Just because I'm annoyed about the dozens mails I got here is my feedback for you: If you don't care for the Google eco system then you are very likely to use side loading anyway. So please use apkmirror or similar services.

The whole conversation here is not just about not using the Play Store.... it's about that the app won't work without Play Services installed and that many people can't / won't use it because of this.

[simontb]

Yes, at least for now it looks like Google will build the functionality into Play Services first. In their example app there is already the eap version of play-services-nearby-18.0.2: https://github.com/google/exposure-notifications-android/tree/master/app/libs

[stefan-it]

@rekire Feel free to use this awesome GitHub feature, if you're not interested in (whatever)

😘

[dadosch]

A good idea would be to have two separate build flavors: one for Google Play Store with Google's API and one with DP3T, in case those are compatible to each other.

The aim for this should be to reach as many people as possible, without unresonable efforts.

[SebastianWolf-SAP]

Really an interesting discussion, but I'm sorry to tell you that there is no additional information from our side beyond the comments that @MalteJ already made in https://github.com/corona-warn-app/cwa-documentation/issues/5#issuecomment-627834039 and https://github.com/corona-warn-app/cwa-documentation/issues/5#issuecomment-627860999.

Deutsche Telekom and SAP have the task to develop an application based on the Google/Apple framework which can be delivered to the public via the respective stores. Any functionality/capability which goes beyond that can't be guaranteed by us and would probably need to be implemented by the community by code/reuse or an alternative implementation of the specification.

[heeplr]

Maybe it's worth to note, that the problem seems to be the tender/contract not enforcing reproducibly built APKs in the first place.

It serves as a good example, that there are important differences between various definitions of "open source".

Let's hope there are enough reverse engineering eyes on the final builds, so malicious activity will be detected and prevented early.

[kbobrowski]

Also, the app has to work for 99.9% of the population and not for 0.01% Lineage-OS users.

It's worth to note that user don't need to sign with Google account on the Android system and still can use internet / email / mobile network / camera / maps etc, so this issue applies to broader population than just Lineage-OS users. Would be nice if they were able to side-load APK, or visit some government office where someone would do it for them (from couple of cases I know this way of using the phone may be more prevalent among older population). But I guess creating Google account in order to download the app won't be a big issue.

It might cause larger problems for people coming to Germany (once it is possible) from places like China where nobody is using Play Store, but Tencent / Huawei / Baidu stores (they are also used to side-loading APK), they simply won't be able to participate in contact tracing effort - hopefully it won't lead to any discrimination.

Of course it is not SAP issue to resolve, as @SebastianWolf-SAP mentioned.

[zoobab]

"Also, the app has to work for 99.9% of the population and not for 0.01% Lineage-OS users."

Nor Apple nor Google can be trusted with our privacy in this case.

They do not provide source code for their entire stack, and they live on personal data to profile end users.

[niklas2810]

"Also, the app has to work for 99.9% of the population and not for 0.01% Lineage-OS users."

Nor Apple nor Google can be trusted with our privacy in this case.

They do not provide source code for their entire stack, and they live on personal data to profile end users.

What does the one argument has to do with the other? The API will most probably be rolled out via Google Play Services (because system updates tend to be very slow) and therefore Lineage users wont be able to use the app anyway. The specification is open source, so even if the code is propietary, we can be certain that they don't collect personal data from this.

[kbobrowski]

@niklas2810 there is no way to be certain that they don't collect personal data, we can verify that input/output of the API works according to the specification, but proprietary implementation of this API could attach your email address (that you sing in to Play Store with) to every sent/received temporary exposure key and beam this information to external server - building detailed social graph. That said I don't believe that Google would do something like this, but it's up to anyone's own judgement to trust it.

[heeplr]

@niklas2810

The specification is open source, so even if the code is propietary, we can be certain that they don't collect personal data from this.

I wonder what leads you to this conclusion. The one is not a consequence of the other. Imagine a simple scenario: Google adds some additional, secret piece of code to their Play Services that directly transmits raw bluetooth data to their servers. Now even if you trust google, what if this is done by a malicious third party? What if there are bugs in Play Services that can be exploited?

It's a lot easier to trust software if the entire stack is open and the end result is reproducible. Also: If anything goes wrong, vulnerabilities must be fixed as quickly as possible to limit potential damage, so auditing (peer review) shouldn't be harder than absolutely necessary.

There are more aspects but generally, @zoobab has an important point in my opinion. At this scale (60% of population) and this importance (the ultimate contact tracing and movement database™) you definitely want a waterproof concept in terms of trust.

[niklas2810]

@kbobrowski @heeplr The key fact you are missing out is that Android and iOS devices need to and will be interoperable. Therefore, it's not possible that Android devices send additional infos (e.g. their email address) without breaking the compatibility.

The only possible scenario is that Apple and Google cooperate on absusing user data; which I don't think will be the case (as Apple is very focused on privacy and this would be a PR nightmare).

Additionally, you could read the bluetooth traffic with an external program in order to verify that only the cryptographic keys are sent. A malicious use from Google/Apple would become obvious pretty quickly.

[kbobrowski]

@niklas2810 I meant that email (or whatever identifying information) can be attached to Bluetooth frame about-to-be-sent or just-received (and then sent over internet to external server), not that it can be encoded inside Bluetooth frame.

To be more specific, malicious Google Play services implementation could work like this:

• Bluetooth frame is constructed according to specification
• user email is packaged together with this Bluetooth frame and sent to external server
• broadcast of Bluetooth frame constructed in first point, according to specification

this way you are not breaking any specification compatibility, and from outside everything looks fine. If you do the same for all received Bluetooth frames you obtain very detailed social graph.

Perhaps we can still ensure as a community that the implementation is not malicious / hacked, but it would require significant and continuous reverse-engineering / snooping effort.

[heeplr]

@niklas2810

Therefore, it's not possible that Android devices send additional infos (e.g. their email address) without breaking the compatibility.

You assume, that Play Services can send infos only to one server? There are tons of different attack scenarios but a malicious actor somehow adding own code is always a concern. When Play Services, as a "black box" is part of the stack, another weak link is created.

The only possible scenario is that Apple and Google cooperate on absusing user data;

I doubt that. An advanced malicious 3rd party has to be taken into account. As said, this could be a data treasure trove.

which I don't think will be the case (as Apple is very focused on privacy and this would be a PR nightmare).

Agreed. But there's still a chance that companies get forced by authorities to cooperate. I'm not sure about Google, but I bet the overall mobile device vendor supply chain wraps nicely around the globe.

Additionally, you could read the bluetooth traffic with an external program in order to verify that only the cryptographic keys are sent. A malicious use from Google/Apple would become obvious pretty quickly.

We have to rely on Android security on that but I suppose most of it is reviewable in the AOSP. But Play Services are not as far as I know.

[niklas2810]

@heeplr I wont participate on any speculations about possible attack vectors on Google Play Services, as this has nothing to do with the corona warn app itself. I just want to point out that compromising the Play Services infrastructure without Google noticing is not very probable and I will keep it there, think about that however you want.

Concerning your last paragraph: I meant that you could intercept the bluetooth traffic and read the data yourself. I'm pretty sure some security researchers will do that, that's why I claimed that Google and Apple won't share any details between devices as this would be detected. If the data packets are larger than they need to be, this will be noticable.

Edit: This discussion has nothing to do with the original issue anymore. Regarding any other concerns I'd recommend opening a separate issue.

[kbobrowski]

@niklas2810 Google Play services will simply have access to all the components necessary to perform large-scale tracking of who-meets-who: exposure keys, identity data of the user's Google account and internet access. It is not necessary at all to exchange any extra information using Bluetooth, or to deviate in any way from API specification - these data can be simply sent directly to external servers over the internet. That said I judge this threat as extremely improbable, and since decision has been made to rely on Google / Apple API it's probably not very productive to discuss it. I won't have a problem to trust it, and the same applies most likely to significant majority of users.

[rugk]

Do you all really think discussion hypothetical attack vectors Google or Apple could employ in their protocols makes sense here?

I've subscribed to this issue to see news when there is something about this app getting/being open-source or on F-Droid. This is what this issue is about. Threat modelling is important to do and discussing this topic at large is likely not bad, but I'd like to urge you to do it somewhere else than in this GitHub issue. Thanks. :smiley:

[MikeJayDee]

@kbrobowski

Google Play services will simply have access to all the components necessary to perform large-scale tracking of who-meets-who: exposure keys, identity data of the user's Google account and internet access. It is not necessary at all to exchange any extra information using Bluetooth, or to deviate in any way from API specification - these data can be simply sent directly to external servers over the internet.

If you don't trust Google to stick to their exposure notification documentation and keep all information on the phone, you should not be using Google Play Services in the first place. Google could have implemented all this secretly already and not only transmit to their servers boring anonymous BT identifiers but your location, photos, recordings of your microphone, etc. - without any corona apps or any exposure notification framework.

Hence, I don't think this is an issue.

More to the point of the issue, it may be possible to recreate the whole exposure notification API in LineageOS or similar (at the latest once included in AOSP). However, whilst it should be possible to check for possible contact events using an app forked and built separately, I would expect that only the original app would be able to submit diagnosis keys.

[kbobrowski]

@MikeJayDee you are 100% right, if you don't trust Google you should not use Google Play services at all as it has access to all information anyway. What you quoted was just part of academic discussion on whether we can be certain that implementation is not malicious if it has open-source API specification - but this was indeed off-topic, sorry for that.

On the point of F-Droid - I think it will also be possible to upload diagnosis keys using forked version, I don't see at the moment security mechanism which would validate that you are sending it from "original" app, if TAN is valid it should be accepted by Corona-Warn-App Server. Perhaps Device Attestation will be implemented for uploading Diagnosis Keys, which would prevent forked app from doing so.

[feinstaub]

I won't have a problem to trust it, and the same applies most likely to significant majority of users.

When it comes to human rights (https://www.amnesty.ch/de/themen/ueberwachung/dok/2019/ueberwachung-durch-facebook-und-google) one cannot argue with "the majority". Maybe you know the satirical saying "9 out of 10 people like mobbing" (https://en.wikipedia.org/wiki/Mobbing).

Also, there is a difference between really trusting a third party or just not having (or seeing) an alternative. I doubt that the majority of Google users really believe that their data is safe there. It is currently just too hard to use something else.

Not supporting privacy-friendly alternatives can also be justified by using the "Nothing to hide" argument: https://en.wikipedia.org/wiki/Nothing_to_hide_argument, https://www.amnesty.de/informieren/artikel/7-gruende-weshalb-ich-habe-nichts-zu-verbergen-die-falsche-reaktion-auf

[mynchau]

Thanks for your contribution. Since this issue is closed and conversations are distancing from the original issue I recommend opening a new issue. Best regards MC Your Corona Warn-App Open Source Team