This isn't a project developed for the public sector really. Afaik it's a privately funded, for profit, product that has been licensed by several states in Germany by now.
Apart from that the official (indeed publicly funded) Corona-Warn-App did a much better job at this. (They actually did follow all the recent best practices in software-develoment + it's (mostly) run as a free software project, taking community contributions seriously, reacting to feedback and issues, etc.)
Have you looked at the beta versions yet? The UI was overhauled over basically the last 1.5 years and the points mentioned in the blog post are the bits missing to release that as a stable version (IMAP IDLE mostly): https://github.com/k9mail/k-9/releases
I've been running the betas since more than a year without any problems whatsoever. (If you don't need push obviously)
I think where it went wrong here is that when it asked you for your "passphrase" (which is called a recovery key) it's very likely it wanted your login password instead. (Because that is indeed needed to reset the recovery key).
The recovery key (whitespace doesn't matter btw, it's just a 48 char string) is only needed when you logout of all devices and subsequently want to restore your encrypted messages.
> removes one layer of Google code, but keeps building on the Google layers beneath it.
Well, the layers beneath it are AOSP and free software. The situation is certainly not great, with source drops, nonfree firmware blobs, etc. But it is relatively easy to grab an AOSP source-tree for your device, make some changes, rebuild the OS and install this to your phone, given an unlocked/unlockable bootloader. In my opinion this is a highly desirable property of any system I'm using. It also enables things like GrapheneOS and CalyxOS which are Android distributions which focus explicitly on security and privacy.
> Can the Exposure Notification Framework be trusted less than the rest of Android?
ENF is part of Google Play Services and thus proprietary software. It is also a hugely scary and absolutely giant bundle of software you need to keep running in it's entirety, you cannot use just the ENF part. Play services can remotely update any software on your phone, they have also been known to "accidentally" not respect users (location)-tracking opt-out choices. So while I personally don't consider googles ENF implementation problematic (from their docs, the sources are ofc not available) the rest of play services most certainly is.
> Or does this support more hardware?
Apart from the already mentioned gapps free ROMS it supports modern Huawei phones (which also come without gapps). Making it work on Android 5 will probably happen (Google ENF supports Android 6+ afaik)
The package description doesn't do a particularly great job at explaining what this is:
This is the German "Coroana Warn App"[1], the official German contact tracing app but instead of using Google's Exposure Notification Framework (ENF) it relies on the microG implementation of the same API. It can either use a system-level microG implementation or fall back to the bundled implementation running purely as an app without any system permissions.
This makes the app fully free and 100% compatible with the upstream google based version.
A google account is not required for using the android SDK.
You have to agree with the TOS if you download the prebuilt SDK from google, yes. Building the SDK from source is unfortunately quite hard but Debian has made some progress with this.
Alternative repositories are a first-class feature of F-Droid. Alternative app stores aren't really a first class feature of Android (though they are obviously possible, in contrast to iOS)
> bans your Android Studio account
Don't give them ideas. (there's thankfully no such thing as an Android Studio account)
The solution to the background limitations for now is running as a foreground service. This shows a persistent notification (which can be hidden by the user) but can then run indefinitely. The other option is to integrate this at the system level (via a custom rom, root, magisk, etc.).
> I'm curious to know if anyone is using this framework in the wild.
The client side implementation of this is still WiP, so it's not used yet in the wild. I hope to be at a point where I can work with some apps on integrating it there in the next few months.
> That is, half of Android devices were on an OS that hadn’t seen an update in at least 2 years.
This seems quite wrong, older Android versions do receive some security maintenance releases from google. It's of course up to the device vendor if a particular model gets it though.
This is info is a bit hard to find but it seems like KitKat was supported until October 2017, Lollipop until March 2018 and Marshmallow until August 2018. (taken from wikipedia and here: https://www.quora.com/Will-the-Android-5-Lollipop-still-exis...)
So you could be running a phone with KitKat, which was released in 2013 but still got the last update 1.5 years ago.
Agreed on that. Although in Canada the OSM data seemed really, really good when it came to national parks and trails. Not so much inside Vancouver. (Still enough for navigation by car and on foot, but finding addresses was a major PITA.)
Apart from that the official (indeed publicly funded) Corona-Warn-App did a much better job at this. (They actually did follow all the recent best practices in software-develoment + it's (mostly) run as a free software project, taking community contributions seriously, reacting to feedback and issues, etc.)