[DISCUSSION] Solution without closed source dependencys

[theScrabi]

EDIT: tl;dr: We are working an an open implementation of the Google/Apple protocol (I call it PPCP, which may be wrong). You can find and contribute to our repository here: https://github.com/theScrabi/CoraLibre-android-sdk

Dear Corona-Warn-App developpers we have read your code and documentation. We like your effort and your open mind for the community. As there is a small but willing comunity of people who refuse to use closed source Google or Apple dependency and so can not use the Corona-Warn-App, I'd like to discuss the posibility of a Google Free FLOSS solution.

What we know so far is that it's currently hardly possible to create the corona app without the use of the closed source GMS. This comes along with the nearby android exposure notification API, which implements the PPCP protocol. From what we can see in the code so far, the contact points between the android exposure notification API and the Corona-Warn-App are few as for the most common calls to the API a wrapper class is used. That's great! Also there are only about 14 code files that include parts from the GMS library. We therefor think it might be feasible to create a version of the app that does not require GSM services.

As statet in this issue the current maintainer have no plans to implement an own exposure notificatoin API, but might be open to support an alternative if available. What we understand so far is that the part that runs the actual BLE contact tracing as well as providing a highlevel API for exposure likelihood and key handling would need to be reimplemented. We had several thoughts about how this might be possible.

• As its offtenly staded that PPCP is close to DP-3T, I question if it is possible to reuse some parts of the prestandard DP-3T android sdk.
• Prestandard DP-3T used forground services. Would it be possible to implement a GMS free non root version that would always display a notificatino while running the advertising and receiving service? Now i know this is not a good idea as people tend to close this notificaion, but was it techinically feacable to replace GMS by such a sollution?
• A solution that would work on phones with root access such as Lineage-OS or /e/ could maybe be to introduce a privileged extentsion like the one used by the fdroid app. This might make it possible to expose functions to the Corona-Warn-App that would normally only be accessible for higher privileged applications. Maybe this could be a replacement for GMS.
• One other way was to compleatly break loose from Smartphones and focuse on microcontroller based tracing beacons. For example on ESP32 or the CCC Card10. This way not only users with Lineage-OS or rooted smartphones could profit from an alternative implementation but also people who don't use a smartphone at all.

If a community based solution is possible what would be the next steps to go?

---

Internal Tracking ID: EXPOSUREAPP-5775

[uschindler]

I agree, there should maybe some abstract wrapper class or interface that encapsulates the Google Play Services stuff. Especially as Google already mentioned that the play services stuff may move to core Android (maybe AOSP). Also Huawei may have another variant of the same API without play services on their newer phones. So I tend to think that another abstraction here would be a good idea, so it's easy to add more exposure notification API code. On the other hand: If Google moves the stuff away from Google Play Services on newer devices, I am sure the API will stay the same and Google Play services will delegate to the Andoid layer.

[ttobsen]

Here is a good example of a GSM free fork:

https://f-droid.org/de/packages/org.telegram.messenger/

While the original Telegram app uses GSM, in example for location sharing, the fork is 100% GSM free, without losing any functionality (in this case they use Open Street Maps iirc).

Removing the Google dependency could also improve the user acceptance by wiping concerns against US big data companies.

[MalteJ]

Personally, I can only encourage you to build a libre version of the ENA API for Android. But to be crystal clear: In the foreseeable future the Corona-Warn-App project will rely on the official Google and Apple APIs!

My personal advice to you: Fork this repo, give it a new name (e.g. CoraLibre or CoronaLibre) and integrate it with your libre ENA API. Try to change as few as possible of the upstream code so you can stay really close to this upstream repository. If you have a working fork, completely libre, and some minor changes in the upstream code base would help you to integrate the upstream commits (e.g. by doing some Dependency Injection here and there) feel free to create PRs. We will definitely accept no code changes that have impact on the UX (e.g. the mentioned Android notification hack).

All the best, Malte

PS: Please be careful when publishing your app: Afaik you may not use the Corona-Warn-App name, brand, logo and designs.

[ttobsen]

In the foreseeable future the Corona-Warn-App project will rely on the official Google and Apple APIs!

Then in the foreseeable future, it will not be possible for everyone to use the app. I'm using a Fairphone 2 with their Google free Fairphone Open OS, no GSM available.

So the question is: Why is it necessary to use the Google APIs for this app? Are there any technical reasons?

I think the most important feature for such an app is, to make it available to the biggest user spectrum possible. But when using Google APIs this target can't be reached. :-(

[theScrabi]

@MalteJ That is great! Thank you for the reply. So I guess the next thing is to somehow be able to write a libre ENA API that is compatible to Privacy-Preserving Contact Tracing. The question was can it be pulled off and has someone experiment with it already?

[marcauberer]

In the foreseeable future the Corona-Warn-App project will rely on the official Google and Apple APIs!

Then in the foreseeable future, it will not be possible for everyone to use the app. I'm using a Fairphone 2 with their Google free Fairphone Open OS, no GSM available.

So the question is: Why is it necessary to use the Google APIs for this app? Are there any technical reasons?

I think the most important feature for such an app is, to make it available to the biggest user spectrum possible. But when using Google APIs this target can't be reached. :-(

I think using Googles / Apples solution is the only option for now, since the development of an own "Google free" solution would cost time and money. Please read the Notification Exposure Documentation in this project for more information.

[MalteJ]

@MalteJ That is great! Thank you for the reply. So I guess the next thing is to somehow be able to write a libre ENA API that is compatible to Privacy-Preserving Contact Tracing. The question was can it be pulled off and has someone experiment with it already?

I do not know any project that is trying to create a compatible API. But I know a few folks that would be very interested in such a project and maybe could also help. @theScrabi Are you an Android developer? Can you start developing such an API?

[theScrabi]

I am an android developer, however I am not sure if I could write such an API as I have little experience with bluetooth and that API (yet). I started to read my self into the documentation and prestandard DP-3T and I think to see some parallels, so maybe by modifying prestandard DP-3T android sdk it might be possible to create a compatible API, but I don't know for certain right now. If I tried it I'd need help.

[MalteJ]

@theScrabi you will find most of the documentation here: https://www.apple.com/covid19/contacttracing/

I think when you start developing a lib there will appear some helping hands from the community 🙂

Feel free to post a link to your project in this thread!

[theScrabi]

So I've been researching a bit more, as I try to persue the idea of modifying the prestandart dp-3t android sdk. So here is a comparison of both based on what I found out so far (no assurance for accuracy, please correct me if I am wrong): DP-3T and PPCP are both decentralized and generate a new Token every ~15 minutes. In both protocolls that token derives from a general key that will be newly generated every 24h. On DP-3T that key derives from a $SK_0$ which will be generated only once when the app is installed. Then every 24h a new $SKi$ is derived from it by applying a HMAC function on $SK{i-1}$. At PPCP this equivalent is the Temporary exposure key $Tek_i$. It will be generated by a random function so no deriving here. For DP-3T $SK_i$ and a Constand string are then Hashed and put into a stream cipher function. From this stream every 15 minutes 16 bytes are taken and used as Ephermal ID which is the id that gets broadcasted via Bluetooth. The equivalent for the EPhid for PPCP is the Roling proximity identifier. First the Rolling Proximity identifier key $RPIK_i$ is derived from $Teki$ together with the string "EN-PRKI" using an HKDF function. About every 15 minutes a rolling proximity identifier $RPI{i,j}$ is then derived from it by encrypting the $RPIK_i$ together with $PaddingDataj$ padding data contains several information including a counter that will represent the time that $RPI{i,j}$ was generated. The $RPI{i,j}$ is then concatenated together with the Associated Encrypted Metadata $AEM{i,j}$ which contains encrypted information about the sending power and the protocol version. The concatinated data is then broadcasted via Bluetooth.

The Broadcasting in both cases is send as Payload of the BLE Advertising packages. If someone was found to be Corona positive he/she must upload all $SK_i$ and Timestamps $i$ of the past 14 Days for DP-3T, and all $Tek_i$ for the past 14 Days for PPCP.

One thing that concerned me a little is that the App apparently can not see the received $RPI{i,j}$. The app can only give the infected $Tek$s it received from the server to the framework, and ask how high the risk is that the user got infected. That the app has no access to the $RPI{i,j}$ is ok, but here it says that an algorithm calculates the risc based on the exposure duration, however I could not yet find any information about this algorithm.

The next thing I will do is frok the prestandard DP-3T android sdk and try to get it working so we can start modifying it :)

[theScrabi]

Here is the repository of the CoraLibre-android-sdk. So far it still contains the prestandard DP-3T android sdk.

[theScrabi]

@MalteJ you said we can not use the name or the package name of "Corona-Warn-App" which is ok. We will not, but can we leave the paths of the package names of the java files? If not pulling changes from this repo will get harder as files are going to be stored in different locations.

[MalteJ]

You just shouldn't use the name for any marketing stuff. I don't care about path names. :)

[theScrabi]

We are making progress. The prototype of the encryption core for the Apple/Google is done. It needs to be verified by a security expert: https://github.com/theScrabi/CoraLibre-android-sdk/tree/master/coralibre-sdk/sdk/src/main/java/org/coralibre/android/sdk/internal/crypto/ppcp

@MalteJ According to this file, page 11, Apple/Google hand out test vectors if you kindly ask them. Do you know if these testvectors are public available or who I can kindly ask to get them?

[ra0e]

Great project and amazing work so far, thanks for the effort @theScrabi. One question: Does the work need to have location services on all the time to ensure the background scanning?

[theScrabi]

Good question. I'd guess if the app uses a "priviliged extention" then no, if you install it on a phone without root access that probably yes.

[MalteJ]

@theScrabi Unfortunately I cannot provide you any data that we got under NDA. But you can install the Apturi Covid app and receive their BLE beacons: https://www.apturicovid.lv/

[mh-]

@theScrabi

but here it says that an algorithm calculates the risc based on the exposure duration, however I could not yet find any information about this algorithm.

The Apple documentation on ENExposureConfiguration explains that algorithm.

[mh-]

@theScrabi

According to this file, page 11, Apple/Google hand out test vectors if you kindly ask them. Do you know if these testvectors are public available or who I can kindly ask to get them?

I don't have official test vectors either, but when I wanted to verify that this implementation is correct, I used a "live" Android device (Android 9, GMS 20.18.17) to generate TEKs, RPIs and AEM (and the Raspberry Pi setup to receive RPIs and AEM). Malte asked me to provide some of these values for reference:

TEK: 2765f41dbaa6306a264391913bf48723
Derived RPI Key: 34fbbd748ee78bb386d1bab2df7b4165
Derived AEM Key: e01962eba7d4b5f40226e91ef9f6c050
RPI: 31fc2cf219fe6dc6765d860e979ba9e5 (decrypted: 454e2d525049000000000000bb772800) --> interval: 0x002877bb == 2652091; * 600: 1591254600 == GMT: Thursday, June 4, 2020 7:10:00 AM
AEM: 10413a43 (AES-ECB-encrypt of RPI using the AEM Key: 50b33a43150b72c90c1d8756eb9f864b - 50b33a43 XOR 10413a43 == 40f20000 --> TX Power Level 0xf2 == -14dBm

Another valid combination is this

TEK: 7921b817fdb92074df5345594273756f
RPIK: eae8956644770f952871daf549c0ce7e
AEMK: a1d0bd6f94b053cf622ca88194e20611
padded data: 454e2d5250490000000000005b6d2800 --> RPI: 5811408cf8d88d2b33f73773a7c6d45f
metadata: 400c0000 --> AEM: a3e9517f

Hope this helps - any questions, let me know :)

[ra0e]

Great project and amazing work so far, thanks for the effort @theScrabi. One question: Does the work need to have location services on all the time to ensure the background scanning?

I found the answer. Seems like you have to enable location mode in order to get Android to locate the Bluetooth device. It is a privacy orientated feature. if its disabled, every Android device will send the same Bluetooth-ID 02:00:00:00:00:00

[mh-]

Seems like you have to enable location mode in order to get Android to locate the Bluetooth device. It is a privacy orientated feature. if its disabled, every Android device will send the same Bluetooth-ID 02:00:00:00:00:00

You are right, it's a privacy oriented feature. What Google wants to prevent is this scenario: An app does not get permission from the user to access location, and then still tracks the user's location by BLE-scanning for fixed-position BLE beacons (iBeacons in stores, museums, etc). Totally different use case, but leads to the requirement to ask the user for location permission, even though the location isn't used within the app.

Regarding the BDADDR: I found that my Android device (MTK chipset) advertises random BDADDR like 4f:31:14:1c:d7:20, 59:7b:48:03:e7:c9, 60:a5:86:6f:9a:d3, 77:11:8d:93:f9:d4, ... Generally it starts with 4, 5, 6, or 7, i.e the most significant bits are 01. This is a resolvable private address, see e.g. Bluetooth Core Spec 4.2. Whereas iPhones advertise these beacons with a random BDADDR where the msbs are 00 (non-resolvable private address). BTW, if you advertise with an undefined random BDADDR (msbs 10, such as 80:...), Android devices will happily scan the beacon, but iPhones will ignore them, so be careful with that.

[uschindler]

Seems like you have to enable location mode in order to get Android to locate the Bluetooth device. It is a privacy orientated feature. if its disabled, every Android device will send the same Bluetooth-ID 02:00:00:00:00:00

You are right, it's a privacy oriented feature. What Google wants to prevent is this scenario: An app does not get permission from the user to access location, and then still tracks the user's location by BLE-scanning for fixed-position BLE beacons (iBeacons in stores, museums, etc). Totally different use case, but leads to the requirement to ask the user for location permission, even though the location isn't used within the app.

That's unfortunately also different to the "official" Google Play Services: There your app is NOT allowed to have location services.

This is one reason why the official CWA app can't implement both things at same time:

• if you use the official Google/Apple API, you are NOT allowed to access Location - that's clearly stated. This is to prevent countries like France to track infected users.
• if you implement your own BLE scanning (as proposed here), you have to access Location for the reasons above.

Both at same time wont work as you app would not be accepted for Play Store.

Actually the approach with Google Play Services is in my opion better for privacy! It sounds strange, but actually the app itsself can't track the location of users if you separate the BLE tracking from the COVID19 app (what Apple and Google do). The play services are a separate service implemented on a lower level in the operating system. Those have all required permissions to do the BLE scanning, but don't expose any privacy critical information to the COVID19 app. That's well thought!

[mh-]

@uschindler While I think you are right regarding the standard approach "Corona-Warn-App on a GMS Android Device", this thread is about an approach where people compile everything from source. They could easily see what the software does with their privacy critical information.

[kbobrowski]

I think it may be good to consider possible consequences of publishing open implementations of EN, normally I'm on board with fully open-source solutions, but it seems that in this particular case (distributed approach) it will enable easy "nerd attack":

The DP3T app collects as little information as possible by design, but operates with an open protocol. This means that anyone can develop his own DP3T-like client, and possibly decide to collect more data than what DP3T meant. There could be “enriched apps” which collect more information for each encounter such as the geographic location, the exact time, more information about the Bluetooth message. The app would make its best effort to link changing EphIDi, which would not be too hard from Bluetooth metadata and signal strength if there are not many neighbors in proximity and they are all static. The app could further invite the user to enter more data such as if he knows the person, their gender, approximate age, visible ethnicity, etc, or in which circumstance this encounter occurred (e.g. in bus line x, in the elevator of building y). The enriched app could easily create a huge database. With this, an isolated malicious user could start identifying many reported cases.

It's already easy to build an app on e.g. Raspberry PI zero W which collects RPIs together with exact timestamp and GPS location, and then matches these RPIs with published TEKs (which can be continuously fetched with simple curl cron job since it seems that there will be no safeguards like Device Attestation). Then adversary will be able to determine exact time and location of contact with infected person, which in turn may result in easy identification of this person. This capability could be limited to developers who can implement this from scratch, but with open implementation I guess this attack vector may be much more popular.

Keep in mind that users of official app are told that:

Die App ist so konzipiert, dass so wenig personenbezogene Daten wie möglich verarbeitet werden. Das bedeutet zum Beispiel, dass die App keine Daten erfasst, die es dem RKI oder anderen Nutzern ermöglichen, auf Ihre Identität, Ihren Gesundheitsstatus oder Ihren Standort zu schließen.

and right before turning on broadcasting of RPIs further assured that:

Die verschlüsselten Zufallscodes geben nur Auskunft über das Datum, die Dauer und die anhand der Signalstärke berechnete Entfernung zu Ihren Mitmenschen. Persönliche Daten wie Name, Adresse oder Aufenthaltsort werden zu keiner Zeit erfasst.

This is true if only official apps will be in use, but once we have enriched apps (developed based on open EN implementation) which provide fine-grained information about the encounters then above statement no longer holds.

I'm a big supporter on fully open-source / libre software and I think a solution where users don't have to create Google account in order to participate in contact tracing would be much better, but unfortunately current approach does not ensure full privacy by design and open implementation may enable more adversaries to violate privacy of others.

For those who don't want to use Google products one possible solution is to get cheap used Android phone from eBay, create fake Google account and carry it in another pocket (e.g. Motorola G2 which is capable of running EN costs 25-30 EUR).

If you decide to go forward with publishing EN implementation just make sure that it does not violate any licenses from Google / Apple (e.g. Beacon Simulator app developer had to remove iBeacon format implementation from public source code, despite the fact that iBeacon specification is open)

[mh-]

@kbobrowski One opposing view would be "Theoretically, it would be possible to follow a user, collect the user's RPIs, connect them with person-identifying data, and then check if the person is ever marked as infected. Yet, in practice, this attack vector to deanonymize a user requires a high amount of effort just to gain little additional information compared to the one already gathered while following the user." (quoted from here)

Also we should consider that the CoraLibre-android-sdk discussed above aims at replacing the GMS EN API, not the corona-warn-app. A "nerd attacker" could already today use either GMS EN, or other cheap hardware like you mentioned, and doesn't need to wait for this open/libre implementation of the API.

[kbobrowski]

@mh- I don't fully agree with this quote from documentation, adversary just need to get a single RPI to determine if person who broadcast this RPI was within infectious period during encounter, there is no need to follow this person with "high amount of effort", couple of seconds in the same room is enough.

You are of course right that already today "nerd hacker" could use custom implementation of EN, but as long as there is no popular open EN implementation this attacker would at least need to know how to implement it from scratch. This is not black or white situation, I'm sure some people would be doing these "nerd attacks" anyway, but with easily accessible open implementations of EN the situation may have a bit darker shade of grey.

I just wonder about risk-reward ratio of developing alternative EN implementation as open-source, it's fine if someone who can do it does it for own responsible use, it's simple enough that it does not require community effort to develop. Developing it in open will enable more Google-free users to participate in contact tracing effort but at the same time will increase number of adversaries who otherwise would not have enough coding skills to perform "nerd attacks", potentially undermining trust in this system. Difficult to judge net outcome.

[mh-]

@kbobrowski "nerd attacker" could already today use the original Google EN implementation, once an official app is installed and activated, it will start collecting RPIs.

[kbobrowski]

@mh- I don't exactly see how attacker could use official app for "nerd attacks", maybe by turning Bluetooth only next to the person whose infectious status attacker wants to determine but it would be very error-prone and require "high amount of effort" due to longer time required to stay in close contact. With custom EN implementation it's much more precise and require much less effort. Or do you mean reverse-engineering like using Frida to hijack some functions which interact with Google's EN? Or disabling signature check such that custom app can interact with Google's EN? But then again it requires higher level of skill which limits potential attackers.

[mh-]

Well, you are talking about nerds... Google makes efforts to access-control the RPIs that its EN implementation stores, not to encrypt them. Nerds will likely be able to override access control on their own device.

[MalteJ]

OK guys, thanks for your thoughts regarding nerd attack and Open Source philosophy. But please let us focus again on the tech, here. If you like you can create an issue in the documents repo and discuss this topic there. Here in the Android repo all discussions should be tech-only :slightly_smiling_face:

[zukunft]

It looks to me that this is also related to https://gitlab.com/LineageOS/issues/android/-/issues/1949 and https://github.com/DP-3T/dp3t-app-android-ch/issues/59

[kbobrowski]

Well, you are talking about nerds... Google makes efforts to access-control the RPIs that its EN implementation stores, not to encrypt them. Nerds will likely be able to override access control on their own device.

@mh- right, there is no obfuscation in GMS data. So unless Google is not encrypting / decrypting TEKs with some hard-coded / rolling key on the fly when sharing it with CWA and when matching with stored RPIs then it's easy to implement and validate EN framework. I have no doubt that nerds are able to access whatever on their phones and build EN, making implementation open just significantly lowers the bar ;) but perhaps it's inevitable anyway, and maybe "enriched" apps won't be a big issue after all.

Perhaps a good idea for open-source implementation would be to keep the same leveldb/protobuf structure as original one.

[theScrabi]

Speaking about storage. We might need help with securely storing the keys, as non of the current contributors know how to do this the proper way on android. Can/Should Android KeyStore be used for this?

[mh-]

Speaking about storage. We might need help with securely storing the keys, as non of the current contributors know how to do this the proper way on android. Kan/Should Android KeyStore be used for this?

You might want to have a look at the original Google implementation; at least in GMS 20.18.17 Google stores them in a LevelDB database in the /data/data/... section of the file system. They are access controlled, i.e. other applications cannot access this file system area. And if the user chooses File Encryption or Full Disk Encryption, they are also encrypted by that. If you want to add your own encryption layer, you should carefully consider how this would really protect from which attacks; I think the only additional value that an Android Keystore could bring, would be to require a separate user approval for access - this could be used for the TEK storage, but not for the RPI storage, because you want the RPI matching to happen at night in the background.

[MalteJ]

Also the TEK storage should be accessible to the app without user interaction. You need to store the daily keys.

[mh-]

Also the TEK storage should be accessible to the app without user interaction. You need to store the daily keys.

@MalteJ I'm glad you asked :) You can't store the TEKs themselves in an Android Keystore, because the Keystore will not return the raw key material to you, it will protect it from extraction (and you might need to upload the raw key material later). So you would store the TEKs somewhere else (like a LevelDB) and encrypt them using a storage key. You can put this storage key into an Android Keystore. And you can do it twice: Put the storage key into a Keystore with the restriction that it can only be used for encryption, but always accessed (for the storage of a new TEK at 2am). And put it there a second time with the restriction that it can only be accessed for decryption if the user explicitly agrees (for the upload in case the user is infected).

[mh-]

@kbobrowski When looking at artefacts like Diagnosis Keys or Android Scan Records, this script might help: https://github.com/mh-/diagnosis-keys

[kbobrowski]

@mh- thanks, nice job :) I'm running my own stack for reading leveldb, parsing export.bin etc., in C++ but nice to see similar stack in Python

[theScrabi]

@mh- thanks for your vectors, we tested them against our implementation and it seems to work :)

Also what do you think about using SQLcipher?

[xpcone]

Seems to help progress with #490 too

[jedie]

See also discussion "Exposure Notification (Corona) #1057" in MicroG project.

[darkdragon-001]

The difference between DP-3T and Apple/Google framework is also discussed in DP-3T/documents#128.

[theScrabi]

All right so people keep asking me whats the current situation with our implementation. We finished the crypto part, that part that handles the generation of the private keys and the keys that get send off. Also the comparison, meaning the part that checks weather ans exposed key was collected or not has been finished (not yet completely tested). We did tests with some test vectors from @mh- and it seems to work.

So here about the unfinished parts

We are currently stuck with the development of the database, I hope we can finish this by the end of the weekend.

I've tried to integrate our crypto implementation into the bluetooth part here. However I found out that my knowlage about Bluetooth is very limited, and I have the fear that I do things the wrong way. I don't have the time right now to work myself into the Bluetooth stack, so we will need someone with bluetooth experience on android.

The API that later connects the app with our sdk is currently implemented by @haitrec.

Eventually the google contact tracking implementation needs to be striped form the app, so we can integrate our sdk.

EDIT: The algorithem that decides wather you got exposed or not is also not yet implemented, but it is described here in this podcast where @MalteJ and @tklingbeil, two of the official developer of the Corona-Warn-App where interviewed by @timpritlove.

More support

All in all we do need more support. Weather its just about the code of the app itself, things like setting up a website, do cooperate identity things, documentation or comunity management.

If someone is willing to help feel free to open an issue or write me a mail on schabi (at) schabi (dot) org

[HerrBert233]

Currently a lot of people are angry at the government because the warn app does not work with older Android versions. For example here: https://www.merkur.de/politik/coronavirus-warn-app-dorothee-baer-handy-smartphone-hartz-iv-aussage-kritik-richtigstellung-twitter-zr-13805451.html "Mega Shit-Storm" it says. This is because this app is just a front end for an API that was developed by Google. And Google of course wants to sell more phones, so they only implemented it for newer Android versions, not for the old ones. Also the dependency on Google API is a major point of critique: https://www.nachdenkseiten.de/?p=62113 The solution is quite simple: Implement your own API, then you can make it available for older phones as well.

Here, a single person now tries to fill this gap in his spare time. The motivation is different, he wants to get rid of Google API to make a true FOSS solution. But I see a lot of synergy here. A true FOSS solution of course also would allow to back-port the algorithm to older phones. There will be no limits any more, everything can be customized then. I am surprised that this has not been realized so far. Telekom and SAP should team up with this project discussed here. This would be a win-win for all. SAP and Telekom can make their employer happy (the employer is the German government, and the government are the people) and FOSS will be strengthened.

[ljl-covid]

@HerrBert233 older phones just don't have BLE (Bluetooth Low Energy), which is required for this whole concept to work, since standard Bluetooth consumes a lot more battery and requires pairing for exchange of information, something unfeasible for when you just meet other people around.

I do not believe it's a conspiracy by Google to sell more phone, and I don't think a FOSS alternative would possibly solve this intrinsic hardware issue (although I definitely root for one).

[HerrBert233]

Seriously? Let me describe it with a quote from Telekom ( https://www.t-online.de/digital/id_88070154/corona-warn-app-darum-werden-aeltere-handys-nicht-unterstuetzt.html ):

Die hier benötigte Android-Version 6.0 wurde im Herbst 2015 vorgestellt. [...] Damit dürfte es wohl einige Geräte aus 2014 geben, auf denen die Corona-Warn-App funktioniert. Viele günstigere Geräte aus 2015 und vermutlich selbst einige aus dem Jahr 2016 dürften hingegen nicht mehr geeignet sein. Warum haben SAP und Telekom nicht an ältere Geräte gedacht? Tatsächlich liegt die Ursache nicht bei SAP und der Telekom, die die App im Auftrag der Bundesregierung entwickelt haben. Sie sind letztlich auf die sogenannte Softwareschnittstelle angewiesen, die Google und Apple dafür bereitgestellt haben. [...] Die Corona-Warn-App an sich setzt keine leistungsfähige Hardware voraus und Bluetooth Low-Energy ist bei Smartphones vielfach auch schon länger Standard-Ausstattung.

To summarize: Bluetooth Low-Energy was introduced a long time ago, 2009 it was officially part of the standard, but Android 6.0 (minimum required) was introduced much more recently in 2015, and given the slow update cycle, even phone from 2016 may not have received that update. So the Android version requirement is a far stronger issue than Bluetooth LE. Secondly, what about the many phones without Google Play service? Just think of Fairphone. some use a custom Android without Google play service. Owners of Fairphone 3 are currently also locked from the Corona app. (not because of mussing Bluetooth LE)

Yes, a FOSS alternative would possibly solve those issues. Please get the facts right before downvoting me.

To give you also some examples of phones where Bluetooth 4.0 is present but Android 6.0 not, here is a list:

• Sony Xperia Z/Z1/Z1C
• Samsung Galaxy S3/S4
• HTC One S/M7
• Asus ZenFone 1st gen
• LG Optimus 4X
• ...

[qoheniac]

When a small company like Fairphone is able to update Snapdragon 801 phones to Android 9, why on earth are others not able to update their old phones to newer software if not to sell more phones? This was already irresponsible behaviour in context of sustainability but now it is risking people's health.

[HerrBert233]

From an economic perspective, you sell more phones by not updating your old phones already on the market but at the same time implement new features only for the most recent firmware. This is called planned obsolescence. You should not blame the companies, they just follow the path which maximizes profit. You should blame the system. If you think this is a bad behavior, then you should let your government pass anti planned obsolescence laws like France did. If we had such a law, then yes I would agree, then is no need to support older operating systems. But in Germany, politicians do not have the courage to implement such laws. So that's the situation we now have to deal with. Instead, our politicians say things like people are "too lazy" to buy a new phone. (Dorothee Bär) This cannot be. They cannot blame the citizens. I do not want to be called lazy just because I refuse to buy a new phone each year. This is a very arrogant statement I cannot believe how this can be tolerated.

The solution is clear and simple: Either back-port the algorithm to older phones, or pass laws that require all companies to update their phones. Both of those alternatives would be possible. But I think the first alternative is much more realistic and given that theScrabi already started the implementation, this could even be solved in a realistic time frame.

[ttobsen]

Here, a single person now tries to fill this gap in his spare time. The motivation is different, he wants to get rid of Google API to make a true FOSS solution. But I see a lot of synergy here. A true FOSS solution of course also would allow to back-port the algorithm to older phones. There will be no limits any more, everything can be customized then. I am surprised that this has not been realized so far. Telekom and SAP should team up with this project discussed here. This would be a win-win for all. SAP and Telekom can make their employer happy (the employer is the German government, and the government are the people) and FOSS will be strengthened.

What I can't believe is, that the SAP earns 9.5 mio € for this App and is not able to support developers to build a Google API free version. This amount of money is roughly equal to 100 man years working capacity (with a german based salary). I can't see this amount of work in this repo (and dependency repos), so there should be a huge part of the cake available for supporting the Google API free FOSS development.

[ironjan]

@qoheniac they are able to but don't want to. Selling new phones brings in money, providing updates doesn't. Sounds stupid, is stupid but that's the current state. In addition, some companies have a highly adapted Android which complicates them updating their phones even further.

This update fragmentation is IMHO one of the biggest problems in Android. It is in fact one of the reasons why the contact tracing API was released as part of Google play services before adding it to the OS. Play services can be updated solo, without requiring a system update (which, as you might already guess, might never be released for a lot of phones). There have been mitigations, e.g. Google requiring some years of guaranteed OS updates to have the phone "Android certified", but unfortunately this does not fix the problem completely.

On Sun, 21 Jun 2020, 11:28 qoheniac, notifications@github.com wrote:

When a small company like Fairphone is able to update Snapdragon 801 phones to Android 9 https://www.fairphone.com/en/2020/06/18/fairphone-2-gets-android-9/, why on earth are others not able to update their old phones to newer software if not to sell more phones? This was already irresponsible behaviour in context of sustainability but now it is risking people's health.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/corona-warn-app/cwa-app-android/issues/75#issuecomment-647103484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM6YFACYQ772HBGT7ETBVDRXXHFNANCNFSM4NPVHKHQ .