4 ms·
The problem is, there's no way to disassociate the two flaws with this: 1: people see "government app wants your location" 2: the government possibly using th
by aboringusername 6y ago
The problem is, there's no way to disassociate the two flaws with this:
1: people see "government app wants your location"
2: the government possibly using that location access at a later time
I don't want to accept location on a government app, and the UK has some history with facial recognition cameras and other privacy invasive laws. So there's no way for me to know this location is only for them to use BT LE and they won't make an API call to getLocation and uploadLocationToServer. I assume once you grant location permission even for BT LE purposes it can be (ab)used in some other way.
They've made their own bed with their actions, public confidence might not trust an app like this with a permission like that.
- bigfudge 6y agoI agree with you and won’t be installing the app. However I think you may Misjudge public mood on this. If told this ends the lockdown early it will at least be downloaded by a lot of people. Whether they keep it running when it hammers their battery is another question.
- ngcc_hk 6y agoTotally agreed. You cannot trust a government as there would not be oversight. An independent one with explicit safeguard against anybody other than health tracing not contact tracing will be possibly first stage. Still abuse is possibly even then. But get the institution barrier right first before we talk about technical issues.
- jka 6y agoIt'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 [1] - https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-hardware-id https://developer.android.com/about/versions/marshmallow/and... [2] - https://reproducible-builds.org/ https://reproducible-builds.org/
- antpls 6y agoI 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.