It's probably exactly your concern about the ability for apps with network access to upload user data that led the Android team to introduce the locations permissions for BLE identifier scanning.
Without a location requirement, an app could claim to use only Wi-Fi and BLE permissions, yet it could combine beacon scanning and data access to de-anonymize user locations.
This permission requirement was introduced in Android 6.0 (see the release notes[1]) in October 2015, so it's been around for a while.
If you have some suggestions around how to improve the tracking of permission usage (static analysis? run-time requests (preferably avoiding times when users are under duress and likely to click 'OK' by default)?) then you may wish to file some requests with them and/or contribute to other projects that you feel are taking a better approach.
Your concerns around trust in app developers -- regardless of whether they are a government or any other entity -- are best handled by two means:
- Open sourcing the code (which NHSX have done)
- Enabling reproducible builds[2] so that users can confirm they have an authentic binary build of the source code
I may be misunderstanding this thread, but what the parent is saying is that the BLE permission in Android was _never_ meant for privacy focused contact tracing, and you are saying this is not a secret.
This is why Google and Apple developed the Exposure API, which is more private because it doesn't save as many metadata than the classical BLE permission, and at least Google does _not_ allow apps to declare both the Exposed API and the location permission at the same time.
This gives more guarantee to the users than just trusting the app developers.
In other words, any serious privacy-focused contact tracing apps should use the Google/Apple Exposure API, and not a custom made solution on tops of the older BLE permissions.
However, I still think digital contact tracing, even private, is a bad idea.
Without a location requirement, an app could claim to use only Wi-Fi and BLE permissions, yet it could combine beacon scanning and data access to de-anonymize user locations.
This permission requirement was introduced in Android 6.0 (see the release notes[1]) in October 2015, so it's been around for a while.
If you have some suggestions around how to improve the tracking of permission usage (static analysis? run-time requests (preferably avoiding times when users are under duress and likely to click 'OK' by default)?) then you may wish to file some requests with them and/or contribute to other projects that you feel are taking a better approach.
Your concerns around trust in app developers -- regardless of whether they are a government or any other entity -- are best handled by two means:
- Open sourcing the code (which NHSX have done)
- Enabling reproducible builds[2] so that users can confirm they have an authentic binary build of the source code
[1] - https://developer.android.com/about/versions/marshmallow/and...
[2] - https://reproducible-builds.org/