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

Availability in F-Droid #5

Closed
henrykrumb opened this issue May 13, 2020 · 48 comments
Closed

Availability in F-Droid #5

henrykrumb opened this issue May 13, 2020 · 48 comments
Labels
wontfix This will not be worked on

Comments

@henrykrumb
Copy link

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

@henrykrumb henrykrumb changed the title Availability in F-Droid store Availability in F-Droid May 13, 2020
@mojoaxel mojoaxel mentioned this issue May 13, 2020
@codedust
Copy link

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

MalteJ commented May 13, 2020

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.

@raethlein raethlein added the wontfix This will not be worked on label May 13, 2020
@zoobab
Copy link

zoobab commented May 13, 2020

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

MalteJ commented May 13, 2020

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

zoobab commented May 13, 2020

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

mritzmann commented May 13, 2020

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. 🤷‍♂️ 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
Copy link
Author

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

But calling my question "completely pointless" is disrespectful.

Sorry, that was rude. My bad.

@IzzySoft
Copy link

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

MalteJ commented May 13, 2020

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

codedust commented May 13, 2020

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).

@corona-warn-app corona-warn-app deleted a comment from peter-giese May 13, 2020
@smartens
Copy link

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

rugk commented May 13, 2020

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: microg/GmsCore#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
Copy link
Member

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

frogg commented May 13, 2020

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

mipimipi commented May 13, 2020

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

frogg commented May 13, 2020

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

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

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

kripton commented May 13, 2020

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

LukasMasuch commented May 13, 2020

@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 #5 (comment) 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.

image

@heeplr
Copy link

heeplr commented May 13, 2020

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

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

rugk commented May 13, 2020

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

rugk commented May 13, 2020

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.

@simontb
Copy link

simontb commented May 14, 2020

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

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

image

😘

@dadosch
Copy link

dadosch commented May 14, 2020

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

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 #5 (comment) and #5 (comment).

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

heeplr commented May 15, 2020

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

kbobrowski commented May 15, 2020

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

zoobab commented May 16, 2020

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

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

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

heeplr commented May 16, 2020

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

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

kbobrowski commented May 16, 2020

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

heeplr commented May 16, 2020

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

niklas2810 commented May 16, 2020

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

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

rugk commented May 17, 2020

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. 😃

@MikeJayDee
Copy link

MikeJayDee commented May 17, 2020

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

kbobrowski commented May 19, 2020

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

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

mynchau commented May 27, 2020

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

@corona-warn-app corona-warn-app locked and limited conversation to collaborators May 27, 2020
@SebastianWolf-SAP SebastianWolf-SAP pinned this issue Jun 16, 2020
@dsarkar dsarkar unpinned this issue Dec 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests