cwa-app-android
cwa-app-android copied to clipboard
corona-warn-app
F-Droid release and reproducible builds
Avoid duplicates
- [x] This enhancement request has not already been raised before (it has, but the situation has changed, see below)
- [x] Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
- [x] If you are proposing a new feature, please do so in CWA-Wishlist
Current Implementation
App can only be downloaded from the Google Play Store.
Suggested Enhancement
Either:
- publish the app on the official F-Droid store (and/or)
- self-host a F-Droid repo and publish it there (like e.g. Tagessschau did)
Then:
- Do built that (your APK) reproducibly.
- Optionally, attach the APK to your GitHub releases. (And/Or upload them elsewhere.)
What has changed?
I saw https://github.com/corona-warn-app/cwa-app-android/issues/477 and https://github.com/corona-warn-app/cwa-documentation/issues/5, however, these were asked months ago. The main reason for declining it was that the api is from Google and requires Google Play Services anyway. However, this is not the case anymore. Since September 2020, the Exposure Notification API can be used without Google Play Services on Android, if you use microG, which is a 100% FLOSS replacement for these Google Play Services. The reason is microG added support for the API in v0.2.12.203315.
Expected Benefits
F-Droid is an Android app store specifically for free/libre open-source apps. It would be great if your app could be released there, as it is the number one for getting FLOSS Android apps for many people. F-Droid also builds all apps from source (optionally even reproducible), so downloads from there can be trusted. This possibility then allows people to update the app both from Google Play and F-Droid as the signature is the same.
The app developer FAQ or the quick start guide may help you to get started. If you want to self-host your repo, you can use Repomaker by F-Droid.
Anyway, now the advantages:
- it improves trust to have reproducible builds, see this website on reproducible builds. This is often overlooked when providing the source code of applications. You can then assure (i.e. verify) the binary also belongs to the source code you publish.
- it is good to have an alternative way of distribution (via F-Droid), and again this is a factor of trust (many people that do not use Google on Android trust F-Droid much more than the Google Play Store)
- Building reproducibly via F-Droid would then use a third-party to verify that the binary you get (from Google Play or elsewhere) is genuine (i.e. really built from the source code you publish). Note for this to be effective you should use the official F-Droid repository, because then you do have an neutral third-party building the source code (instead of youself doing it and just publishing the APK).
- Reproducible builds allow users to choose and switch the download channel at any time, i.e. you can download from Google Play, but later update via F-Droid.
- it is then possible to use it with a 100% FLOSS Android CustomROM. You can e.g. use it with CalyxOS, which is a ROM aimed at providing enhanced privacy even for non-experts. So all arguments against the F-Droid release that you "have to trust your OS anyway" are not applicable anymore, because in such a ROM you do not even have to use Google services at all on your Android device and starting from the group up (in the extend that it is technically possible today, i.e. the OS) it is 100% open-source. Some ROMs go beyond that like Replicant OS and I guess even on them you can install microG and thus use this app.
- You provide anyone who does not use Google Play a method for easily retrieving and updating(!) the app. Currently, this can only be done by apps like Aurora Store or so, which access the Google Play Store, but where updates is a bit harder (no auto-updates unless you manually flash another package etc. and IMHO it is slower than F-Droid). For F-Droid auto-updates many ROMs do have the privileged extension preinstalled like LineageOS4microG. Thus, in summary, you would allow more users to (easily) use the app, extend the user base and - which would be a legal argument one may even bake with constitutional law (Grundgesetz) - allow all people (in Germany) to easily use the app. Currently you do force them to use the Google Play Store, which is not resonable anymore given the app is easily deployable on F-Droid (or as an APK in general) and people can use it without Google Play (Services). I know of course you can self-compile the app from source, but then the official Google Play Services do not accept it anymore (I'm not sure whether microG also enforces this) and of course you cannot expect people to do that, not everyone is tech-savvy enough to compile an app and even if you are, it takes time and makes updates a pain. And before you now argue that only tech-savvy people could use an Android phone without Google (and microG), that is fundamentally wrong, as e.g. you can buy a Fairphone 3 with /e/ (eOS) or other partially re-flashed devices with eOS, which do have microG preinstalled - and do not have any Google Play Store nor Google Play Services - just to name one example. Furthermore, issue https://github.com/corona-warn-app/cwa-documentation/issues/5 shows there is a quite high demand for this on GitHub at least.
Again, I'd like to stress that the situation has changed fundamentally since this has last been proposed, so please don't close this as a duplicate. I understand why the issue was closed when the app development was started and never imagined microG would implement the exposure notification API, but as they did, I see no reason anymore to not publish the app on F-Droid. As I elaborated, actually I see many advantages in doing so.
/cc @IzzySoft @henrykrumb @jugendhacker @Bubu
Internal Tracking ID: EXPOSUREAPP-3447
Let me emphasize the 3rd bullet point of the "expected benefits" once more – before you bring your argument of the RKI not having given its "green light": As it stands now, sceptics could claim the app you deploy via Google Play is not (entirely) based on the code you publish – and rightfully say your word alone does not prove otherwise but, as you continue refusing to have a reproducible build, you might do so because there's something you need to hide.
I urge you to prove otherwise – for the reasons @rugk pointed out already: improve trust, improve availability to a larger audience (doesn't the RKI want as many people as possible running the app? My device now supports it, thanks to microG, but I will NOT connect it to any Google service to do so; many other people I know think the same way), thus gaining more coverage.
If you want so, tell the RKI users are pressing you. It is not clear to us whether the RKI is aware of that – or if it was asked for this at all (they might not have agreed because no one asked them to).
I think this issue is less about the "not needing google play services anymore", as introduced above, but about access to the App by non google play store means. The app still needs google play services or a fake of it. As a fake, like microg can't be bundled with the app, RKI will not be able to provide a "google play services free" version.
However where @rugk is right, it would be great for the no-google community, if there would be access to the app via means not being the google play store. Like a download on the RKI website or a F-Droid repository.
Based on how I understand it, it is unlikely that the official F-Droid repo will include CWA, because it depends on a Google Play Services API – no matter whether that is implemented by proprietary or free software. A release channel with automatic updates independent from the Play Store would have to be a dedicated CWA F-Droid repo. Regardless of whether that may be feasible or not, I also think that GitHub releases should have APK builds attached for anyone to manually download who may need it.
I think reproducible builds and attaching APKs to github releases is a great idea, but the problem may be keeping microG up-to-date with Play Services implementation, especially in case Google won't be promptly releasing code for the next versions of ENF (as it was not doing so far). CWA cannot wait for microG to implement necessary features, so difficult to see how this mode can be "officially" supported
I think reproducible builds and attaching APKs to github releases is a great idea, but the problem may be keeping microG up-to-date with Play Services implementation, especially in case Google won't be promptly releasing code for the next versions of ENF (as it was not doing so far). CWA cannot wait for microG to implement necessary features, so difficult to see how this mode can be "officially" supported
That is not connected to an alternative download. CWA should not and is not waiting for microg right now. Microg users know that and it should not be an issue for CWA, but more for microg. Having an alternative download option would just remove the hassle of forced app store registrations and apps to fake the store itself, promoting a free way of software distribution.
That is not connected to an alternative download. CWA should not and is not waiting for microg right now. Microg users know that and it should not be an issue for CWA, but more for microg. Having an alternative download option would just remove the hassle of forced app store registrations and apps to fake the store itself, promoting a free way of software distribution.
I know, but "F-droid as alternative download option" could be provided already at the launch of CWA, but it was refused. Not sure how microG changes anything here, but let's see what would be SAP / RKI response
As a fake, like microg can't be bundled with the app
That's also not needed. Just ship the very same APK that is deployed to Google Play. If microG is installed on a device, it takes care for the rest – as would Google Mobile Services on a device that ships with the entire Google framework.
Again, to make it clear: No changes to the APK are required. We're just asking to make the very same APK you deploy to Play Store available outside of Play Store. Ideally using reproducible builds, to increase trust etc. as pointed out in the initial post.
CWA cannot wait for microG to implement necessary features, so difficult to see how this mode can be "officially" supported
So it's better to leave the entire "privacy community" entirely outside? I cannot follow that reasoning. No offense meant, but sometimes it looks like a search for excuses not to provide the app outside Google Play. That's pretty much frustrating, and makes us privacy folks think to abandon the idea of contribution altogether – because we're getting tired of begging. Looks like we're not wanted to "join forces fighting Covid".
but let's see what would be SAP / RKI response
Yes, please! And it would be great to have that transparent as well – what ever the answer might be, make it a "headline". And hopefully that headline isn't "RKI refuses…" – as that would feeding the "the APK they ship does not correspond to the code they show" idea, and we want to avoid that, right? :wink:
Thanks!
I know, but "F-droid as alternative download option" could be provided already at the launch of CWA, but it was refused.
Well, the stated reason (as linked above) was, that it just made no sense at that time: Without Google Play Services you literally had no way at all to use the app. This changed and using the app from F-Droid is now possible (if you have microG). That is the main point.
@svengabr Oh, great to see progress here! :tada: :smiley: Is there any statement/idea what you plan to do?
IMHO, as explained above, I would of course prefer an reproducible build and release in the official F-Droid repository.
As a fake, like microg can't be bundled with the app
That's also not needed. Just ship the very same APK that is deployed to Google Play. If microG is installed on a device, it takes care for the rest – as would Google Mobile Services on a device that ships with the entire Google framework.
That was more aimed on if RKI could advertise/promote it, that no GSF is needed. If they would do so, you really would need to be able to install it into a fresh AOSP without anything else.
I am a microg user myself and would be happy to not go through the google play store. However I guess the reason for RKI to deny it in the first place was a cost/benefit analysis: The software itself depends on GSF, hence the google play store gives you a good filter that only people download it that have it.
I think for RKI, SAP, Telekom, etc. it would be important to know, that the microg users and privacy hardcore friends do not expect anything big here. It would already help tremendously if you could offer a non play store download. It can even include the "for this you get no support" tag if it helps.
No one said, they should/have to promote that exact feature. Even if you don't advertise it, for everyone who uses microG (and judging from the upvotes here, these are not so few people that would like this) this would help a lot.
So it's better to leave the entire "privacy community" entirely outside? I cannot follow that reasoning. No offense meant, but sometimes it looks like a search for excuses not to provide the app outside Google Play.
I'm all for releasing it outside Play Store, it's just that to officially support microG mode CWA team would need to work closely with microG developer to ensure that microG implements properly v1.5 / v1.6 and future iterations of ENF. Of course it's possible to release CWA as APK on github / to F-droid, without any official reference to microG, and this would be already beneficial for privacy whether microG exists or not, but so far has been refused. Curious to see the official statement of SAP / RKI on this, maybe circumstances has changed indeed
Yes, please! And it would be great to have that transparent as well – what ever the answer might be, make it a "headline". And hopefully that headline isn't "RKI refuses…" – as that would feeding the "the APK they ship does not correspond to the code they show" idea, and we want to avoid that, right?
Well this is trivial to verify as there is no obfuscation ;)
CWA includes this binary, would it even make it eligible for F-droid?
https://github.com/corona-warn-app/cwa-app-android/blob/master/Corona-Warn-App/libs/play-services-nearby-exposurenotification-1.6.1-eap.aar
Just to reference it: Related Issue: https://github.com/corona-warn-app/cwa-wishlist/issues/57
If at least official checksums could be provided. Is that really too much to ask? I don't see what stands against that.
Hello community members and @rugk,
Thank you for the renewed feedback on the F-Droid support. Since the situation regading Google Play Services seems to have changed, we have forwarded this feature request along with the new information to the development team and the contracting entities. They will now evaluate whether (and how) it would be possible to implement F-Droid support and reproducible builds under the changed circumstances.
This thread can be used for further community discussions on the feature request. If we get any news or updates from the development team regarding this request, we will also post them here.
Best Regards, CH
Corona-Warn-App Open Source Team
I guess the reason for RKI to deny it in the first place was a cost/benefit analysis
I see no extra cost not worth the benefit in simply providing the very same APK e.g. attached to Github releases. So:
I think for RKI, SAP, Telekom, etc. it would be important to know, that the microg users and privacy hardcore friends do not expect anything big here. It would already help tremendously if you could offer a non play store download. It can even include the "for this you get no support" tag if it helps.
This I'd sign!
@kbobrowski
I'm all for releasing it outside Play Store, it's just that to officially support microG mode CWA team would need to work closely with microG developer to ensure that microG implements properly v1.5 / v1.6 and future iterations of ENF.
I just read that Marvin is working on a FOSS library to replace the proprietary parts required in the app itself. While that would certainly be very, very welcome (don't let me stop you!) – let's focus on the "easy part" first: to provide the APK as-is outside Google Play. Without any "support promises" for "non-standard installations", fully understood. It's reported to work fine with microG.
Of course it's possible to release CWA as APK on github / to F-droid, without any official reference to microG, and this would be already beneficial for privacy whether microG exists or not, but so far has been refused. Curious to see the official statement of SAP / RKI on this, maybe circumstances has changed indeed
Full ack: please urge them to make their decision public. They're speaking so much about transparency, let them live it :wink:
Well this is trivial to verify as there is no obfuscation ;)
I cannot tell, I'm not an Android dev (or security researcher). But I believe you (otherwise, why should I press so much for that APK? :smile:). Whether conspiration folks do is another matter :wink:
CWA includes this binary, would it even make it eligible for F-droid?
Nope, that's what's considered a "blob"; F-Droid insists on being able to build every component from sources.
For clarification, as some things got a little "mixed up" here: F-Droid currently can NOT build the app itself. THAT will change when Marvin's FLOSS replacements for the GMS libs are used. So the "reproducible builds" by F-Droid have to wait for that (other parties might be able to do the "reproducible builds", though).
Thanks for your commitment!
@IzzySoft interesting, so CWA would need to depend on FLOSS lib instead of Google-provided binary, in order to be eligible for F-droid. I guess this would need to be another flavor. In the meantime APK attached to github release would be very welcome ;)
No one said, they should/have to promote that exact feature. Even if you don't advertise it, for everyone who uses microG (and judging from the upvotes here, these are not so few people that would like this) this would help a lot.
That was why I tried to clarify. The app is GSF dependent and nothing can be done about it. You can now argue for an easy access channel for users that use alternative GSF implementations and that is good.
My view on this: Having worked for Telekom and with SAP, a simple download or release on github will be the easiest and hence most palatable for RKI. No one there will discuss right now sinking a few days work into a fdroid reproducable release repository to reach a few tens of thousand of users. Developing the app and improving will always have priority.
So if you wish to have alternative access, ask for the simplest solution, that does involve a minimum of work.
I just want to briefly state that I also urgently demand a release in the F-Droid Store!
CWA includes this binary, would it even make it eligible for F-droid?
Nope, that's what's considered a "blob"; F-Droid insists on being able to build every component from sources.
Of course @IzzySoft is right here that this would make it ineligable for the official F-Droid repo as-is, and I would like to add that CWA additionally depends on these proprietary google librares (per build.gradle):
// Play Services
implementation 'com.google.android.play:core:1.7.3'
implementation 'com.google.android.gms:play-services-base:17.3.0'
implementation 'com.google.android.gms:play-services-basement:17.3.0'
implementation 'com.google.android.gms:play-services-safetynet:17.0.0'
implementation 'com.google.android.gms:play-services-tasks:17.1.0'
I'm not sure what precisely is the purpose of these; specifically, I'm not sure why there is a dependency on safteynet, as cwa does not require SafteyNet to pass.
Yeah, I also was made aware of that proprietary dependency, though, as people have noted, they can certainly get rid of many – which would be very useful in general, because only then the app is 100% FLOSS and can thus be trusted. I like how F-Droid always makes such issues transparent. So let's think of it: We want CWA to be free/open-source, not only 99%, all of it. Regardless of where users download the app. Ideally, at least… Also I don't know why Google decided that the exposure notification API needs a proprietary client-side lib in your app – especially as they published many other internals of the API as FLOSS, just why? ~~Actually, as far as I see, in their reference implementation they do not include any of these libs.~~ Oh, actually they do, but not the SafetyNet one. But if the API is really easy maybe this part can indeed be re-implemented as FLOSS, but I'm no expert in these technical issues, so I'll let others comment here.
Anyway, it seems this overlaps with https://github.com/corona-warn-app/cwa-app-android/issues/75, the now second most-upvoted issue in this repository, which has the same aim of de-googlefying the app.
BTW another cross-link. Reproducible builds were previously discussed in https://github.com/corona-warn-app/cwa-backlog/issues/21 and https://github.com/corona-warn-app/cwa-backlog/issues/21. The community (namely @gutjuri, credits to them) even already did some initial work in form of a Docker file: https://github.com/corona-warn-app/cwa-app-android/pull/468
Based on how I understand it, it is unlikely that the official F-Droid repo will include CWA, because it depends on a Google Play Services API – no matter whether that is implemented by proprietary or free software. A release channel with automatic updates independent from the Play Store would have to be a dedicated CWA F-Droid repo. Regardless of whether that may be feasible or not, I also think that GitHub releases should have APK builds attached for anyone to manually download who may need it.
@Schyrsivochter to the best of my knowledge, based on talking to F-Droid people before, this is not true. A version of CWA that only includes free software would be eligible for including in the main F-Droid repository, even if it makes use of the Play Services API (whether it be implemented by the "real thing", or microG). The problem is that in order to to be able to use the Play Services API, an app normally includes a proprietary client library that Google provides. That cannot be released in the main F-Droid repository. However, it would be possible to write a free replacement for such a wrapper, and microG has had an incomplete one for a long time (yes, that GitHub repo is archived now, and I'm not entirely sure if this is now available in the main GmsCore repo, but maybe @mar-v-in can clarify that). The thing is that no one, so far, has seemed to take an application, fork it, and actually make it use that client library and maintain it, and then propose it for inclusion in F-Droid. Until it happens, there won't be an application using microG in F-Droid, but it's not, per se, due to F-Droid policies! It basically boils down to nobody having done it.
Note that this is all relating to the main, official F-Droid repository, where things are built from source by the F-Droid team; much of this issue (the original issue) seems to have an underlying assumption that reproducible builds should be used, in which case, provided the proprietary client library is done away with, the app could be in both the official F-Droid repository and in a third-party F-Droid repository with the same signature, hence identical; but if that were not the case (and considering reproducible builds can be tricky), then I want to note that an app provided in binary form, and possibly included proprietary parts, in a third-party F-Droid repository provides no higher "factor of trust" for anyone, unless someone misunderstands the mechanisms: getting the app from a third-party F-Droid repository or getting it from Play Store, possibly using a third-party client to avoid the proprietary one (e.g. Aurora Store), would provide the same app with the same level of trust. Of course, it can simply be more convenient to have it in an F-Droid repository for people who don't have the Play Store or Aurora Store installed, but convenience and trust are different. I just wanted to clarify this, as this issue covers several combinations of possibilities that are not all equivalent.
@rugk
But if the API is really easy maybe this part can indeed be re-implemented as FLOSS
Marvin is already on it, just scroll up a little.
And @ljl-covid is correct: if implemented fully FLOSS it would be acceptable to F-Droid (disclosure: I'm one of the maintainers there). Even if it would interact with some non-free API. For things like that F-Droid has AntiFeatures, so the app might be marked NonFreeDep then (depending on some non-free stuff that must be installed on the device for the app to work).
would provide the same app with the same level of trust
Disagreed, partly at least. Concerning the APK itself, yes. But fetching it from Play requires direct interaction with Google servers. Fetching it from a (3rd party) F-Droid repo does not. Again, let's focus on the availability of the APK first, as that's not too hard to achieve (technically) – and leave the rest for later. Step by step we're getting there. Don't ask for too much too soon (but ask it at the appropriate time :wink:).
So it's better to leave the entire "privacy community" entirely outside? I cannot follow that reasoning. No offense meant, but sometimes it looks like a search for excuses not to provide the app outside Google Play.
I'm all for releasing it outside Play Store, it's just that to officially support microG mode CWA team would need to work closely with microG developer to ensure that microG implements properly v1.5 / v1.6 and future iterations of ENF. Of course it's possible to release CWA as APK on github / to F-droid, without any official reference to microG, and this would be already beneficial for privacy whether microG exists or not, but so far has been refused. Curious to see the official statement of SAP / RKI on this, maybe circumstances has changed indeed
Even without microG the App is useful. Contact tracing won't work, but it can still be used to see test results. And for many, the App is the only way to see their test result: https://github.com/corona-warn-app/cwa-app-android/issues/1587
As it has also been said in a related issue, is there any information about the status of this – very popular – feature request? @svengabr, you are assigned and it is tagged with “in progress” and somewhere in the GitHub Kanban/project (in TODO, then "mirrored to Jira").
The last update was from @heinezen:
If we get any news or updates from the development team regarding this request, we will also post them here.
Well… it has been a month now. So what should "in progress" actually mean? Do you still have no reply from RKI or whoever needs to decide that or whatever input you still need?
Hu? :astonished: What does this bot do? Move everything to "ToDo" when someone comments? :sweat_smile:
As the BfDI was just interviewed on this topic, I've asked them to "animate" the RKI in this direction. Maybe it helps a bit if the voice comes from "upstairs" instead just from us "peasants below" :roll_eyes:
To repeat what for sure already has been said: looks a bit schizophrenic to complain about not enough people participating – when you don't make it available to them. And yes, this goes in direction of the RKI or whoever is holding this back, not the dev team here.