App tracks your location

[guruevi]

Problem: This app tracks your GPS location in the background.

Expected: App does not track your GPS location

[robputt]

Isn't that the point?

The app provides a list of anonymised Bluetooth beacons in a given location at a specific time and then if one of those devices marks itself as having symptoms is can alert all other devices in that area at that time and provide anonymised metrics to NHSx about spread etc...

[hithomasmorelli]

The app does not track location. Android requires location permissions to be granted for Bluetooth LE access (don't ask me why)

https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions
https://stackoverflow.com/questions/33045581/location-needs-to-be-enabled-for-bluetooth-low-energy-scanning-on-android-6-0
https://issuetracker.google.com/issues/37065090

[ghost]

Also explained in the FAQ on the app's website:
https://faq.covid19.nhs.uk/article/KA-01037/en-us

[guruevi]

It would be one thing if it was just the permission. It is implementing a whole class to query GPS location.

If it just needed permission, this would only be in the Base class as a permission, not implemented.

uk.nhs.nhsx.sonar.android.app.ble.LocationProviderChangedReceiver uk.nhs.nhsx.sonar.android.app.util.LocationHelper

[steffandroid]

Neither of those classes query GPS location, they're used to check whether or not location services are enabled and location permissions are granted. Location services must be enabled for Bluetooth scanning to work reliably, and the permission must be granted.

[hithomasmorelli]

LocationProviderChangedReceiver just performs actions through LocationHelper, which in turn just checks if location permissions are granted & location is enabled - as @steffandroid pointed out, location services need to be enabled for reliable Bluteooth scanning.

[guruevi]

It's a small code change or some JavaScript sourced remotely that could enable tracking still. The original point stands, the app requires permission it does not need.

Google actually has an API for this:
Bluetooth functionality, including all broadcast and scanning for BLE beacons and local
database storage, happens within Google Play services on-device. Your app will need to
have the BLUETOOTH permission in its manifest, but does not require ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, or BLUETOOTH_ADMIN

https://blog.google/documents/74/Android_Exposure_Notification_API_documentation_v1.3.pdf

[hithomasmorelli]

Google actually has an API for this

What you are referencing is the Apple-Google API (which, I might add, is still in development - the document you link is preliminary). It was an NHSX policy decision to not use this API and instead opt for a centralised model - whether or not they made the "correct" decision is an entirely different discussion. Because of this, the app does need these location permissions in order for it to work - so it is not true to say that the app requires permissions that it does not need.

As with everything, it is possible that code could be changed to enable location tracking. However, I highly doubt that NHSX would even consider doing that - it would go against everything they (and the NCSC) have said about the app's privacy, the change would gather huge media attention and would stop masses of people from installing and using the app (defeating the overall public health purpose).

[xdjoshuaaz]

Hi all, hope you're having a great bank holiday (in the UK that is).

I installed the app yesterday and woke up to the following notification.

While I get the fact that ACCESS_FINE_LOCATION (and background on Q+) is needed for Bluetooth to work on Android, this notification really does make it look like the app is tracking my geographical location. Have you experienced this notification yourselves?

I am unable to find information online about this notification being triggered by Bluetooth APIs, only Location APIs. Android dev documentation for this notification found here - no mention of Bluetooth. I have CTRL+F'd every link above in this issue for "notifi" and found nothing relevant to the notification I got (I wouldn't expect users to go digging through those links anyway!)

I'd like to suggest addressing this notification directly. The statement "You will not be tracked" is seemingly contradicted by the notification above hours later which will raise concerns for some people.

I.e. "You may receive a notification soon after installing the app stating that your location was retrieved in the background. This is due to a built-in Android feature that identifies Bluetooth usage as location retrieval. Rest assured, your geographical/GPS location will never be accessed."

On the other hand, that paragraph literally sounds like a cover-up for it actually getting your physical location... You can't win really when Google forces location permissions for Bluetooth.

---

edit: I've spent a little bit of time looking at the AOSP source code to see how this notification is triggered. It is triggered by granting the fine location runtime permission. Code here.

My point about this notification needing clarification still stands however.

[guruevi]

@xdjoshuaaz Your statement is accurate. The thing about any radio usage is that it can be used to map your location. If I know the MAC address of static Bluetooth and WiFi locations, there is a database you can query as to the location of them. That's how WiFi/Bluetooth being enabled makes your maps application more accurate.

All the UK Gov has to do is to enable the BT chip on the massive network of devices they already have everywhere (cameras, traffic lights etc) which often come with BT/WiFi chips on the chipset and have it broadcast an ID compatible with this app. Then the app simply sends it all back to the government including how far you and people around you were.

Besides that, this information gets sent to NHS:
"deviceModel"
"deviceOSVersion"
"postalCode"
"secretKey"
"publicKey"

What's more, this app already brings you to https://111.nhs.uk/Location which has code that requests GPS locations, which, if tracking is enabled, the app will simply pass.

[Xenoamor]

"deviceModel"
"deviceOSVersion"

What's the case for logging this information?

[adarrel753]

"deviceModel"
"deviceOSVersion"

What's the case for logging this information?

According to the documentation for this app, bluetooth signal strength is being used to determine the distance between devices. Given that different phone models have different bluetooth signal strengths (natively), it would seem that the app will need to take the phone make/models into account when calculating distances for accuracy...

[Xenoamor]

If they have that data then it should be built into the app and the transmitted TxPower variable normalised with it.

For example, if you use your home WiFi to register the device the government could request that IP from your ISP and would be able to use your phone model and OS version to determine who you are even in a house of multiple occupancy. This is a bigger issue for android where there is a greater variety of handsets

[adarrel753]

If they have that data then it should be built into the app and the transmitted TxPower variable normalised with it.

...good point and I think I know what you mean, the necessary adjustments for each make / model could be hard-coded into the app instead of the make / model being sent to the central server, thus still resolving the signal strength accuracy problem but increasing privacy, yes?

For example, if you use your home WiFi to register the device the government could request that IP from your ISP and would be able to use your phone model and OS version to determine who you are even in a house of multiple occupancy. This is a bigger issue for android where there is a greater variety of handsets.

...a gov requesting that info which could be used to assist in proving someone guilty of a crime, or could be used to prove someone's innocence when accused...this point is valid but exceeds the scope of this project I think

[adarrel753]

I just inspected the source code of the app more closely and unless I have missed something it looks like the distance calculation isn't taking place on the devices themselves, so they must be taking place on the central server later on, i.e. after the contact events have been submitted. One possible reason for designing the system this way could be to help tackle the following scenario:

• Bob and Alice are sitting on a park bench.
• Bob's phone calculates that they are 2.2 meters apart.
• Alice's phone calculates that thet are 1.8 meters apart.

[guruevi]

Which seems to indicate the government is planning on creating a graph analysis of people's movements and analyzing the data in detail before even before events such as an infection are indicated that makes them necessary.

If the phone can't calculate who is actually nearby, the government will need to analyze all data to actually figure out who was nearby. Since BTE has ~500m radius, the overlapping coverage covers pretty much the entire UK and the data can triangulate anyone for any reason whatsoever.

[passdan]

In the documentation they state that BLE contacts data will be local until the user notifies of symptoms/infection and then uploaded to the central server, which means that it can only be one-way. Unless the release was wrong on that.

[pzboyz]

If they have that data then it should be built into the app and the transmitted TxPower variable normalised with it.

But when there are new make/models of phones which are not known the installed version of the app, what information should be sent? We should not have potentially significant encounter data discarded due to this.

[Xenoamor]

If they have that data then it should be built into the app and the transmitted TxPower variable normalised with it.

But when there are new make/models of phones which are not known the installed version of the app, what information should be sent? We should not have potentially significant encounter data discarded due to this.

Send the data unmodified would be the usual step, much like it currently is. It's a trade off for privacy though, if this level of privacy loss is acceptable then it can obviously remain as it is. It could always be an opt out feature during registration for those that it does concern

There might be an in-between option where the BLE hardware used is shared rather than the phone model/make although that doesn't account for the antenna design and such

[adarrel753]

If allowing the phone make/model/OS to be kept private (i.e not sent to the central server) results in inaccurate distance calculations being made, which are then fed into the central risk analysis that is done to decide if notifications are to be sent to someone or not then allowing the end-user to decide whether this is kept private or not doesnt sit right with me, only because most end-users are unlikely to realise the hidden consequences of making that choice.

[mcb30]

Distance calculations based solely on Bluetooth signal strength are accurate only to the nearest ten metres or so anyway. Even with knowledge of the device characteristics, it's not useful for detecting whether or not someone is within infection range. The impact of hiding this information upon risk modelling is negligible.

[adarrel753]

Distance

Distance calculations based solely on Bluetooth signal strength are accurate only to the nearest ten metres or so anyway.

If that's true then I dont see how a contract tracing app could work whether the system is centralised or decentralised. If I walk 10 meters away from my phone, my bluetooth headphones start losing connection. That doesn't mean that bluetooth signal strength can't be used to make accurate distance calculations necessarily.

Where are you getting this info from?

[adarrel753]

I have just raised a separate issue about this as it is off-topic from the original thread of this post. Here is the new issue: #30

[Xenoamor]

Have done similar for discussion on the phone make/OS_version #31

[mcb30]

If that's true then I dont see how a contract tracing app could work whether the system is centralised or decentralised. If I walk 10 meters away from my phone, my bluetooth headphones start losing connection. That doesn't mean that bluetooth signal strength can't be used to make accurate distance calculations necessarily.

Where are you getting this info from?

Experience of designing and building indoor positioning systems. Bluetooth was abandoned early on since it's nowhere near accurate enough to get a meaningful distance figure.

Will continue discussion on your new issue #30

[edent]

This thread has drifted off topic, so I'll close it for now. I hope the source code has reassured you that GPS and location data are not being gathered.