Availability in F-Droid #5
Comments
|
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:
Thanks in advance! |
|
We are not planning to deploy to any App Stores except Google's and Apple's. However the community is free to contribute. |
|
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. |
|
@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. |
|
@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. |
|
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. |
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. |
Sorry, that was rude. My bad. |
|
@MalteJ quoting, emphasis mine:
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 |
|
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. |
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). |
|
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 |
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? To answer this question (partially) by myself:
|
|
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. |
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. |
|
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. |
|
@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. |
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. |
|
Quoting from the Readme:
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. |
|
@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.
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.
|
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. |
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. |
|
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 |
|
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):
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 That is the theory and only based on the claims of the previously linked articles. |
|
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 |
|
@rekire Feel free to use this awesome GitHub feature, if you're not interested in (whatever)
😘 |
|
A good idea would be to have two separate build flavors: The aim for this should be to reach as many people as possible, without unresonable efforts. |
|
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. |
|
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. |
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. |
|
"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. |
|
@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. |
I wonder what leads you to this conclusion. The one is not a consequence of the other. Imagine a simple scenario: It's a lot easier to trust software if the entire stack is open and the end result is reproducible. 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. |
|
@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. |
|
@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:
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. |
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.
I doubt that. An advanced malicious 3rd party has to be taken into account. As said, this could be a data treasure trove.
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.
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. |
|
@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. |
|
@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. |
|
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. |
|
@kbrobowski
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. |
|
@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. |
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 |
|
Thanks for your contribution. Since this issue is closed and conversations are distancing from the original issue I recommend opening a new issue. |
and others
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
The text was updated successfully, but these errors were encountered: