Suggested new risk for DPIA: tracking by bluetooth

[floort]

Unauthorized tracking due to enabled bluetooth

• Fase: app usage
• Category: Enviroment
• Incident: Because Bluetooth has to be enabled to use the notification app, it is possible to track users of the app through traditional bluetooth tracking techniques. The most common advise to prevent this unlawful tracking is to disable bluetooth (and WiFi) is not possible to follow in public spaces while also using the notification app.
• Impact: High. There is evidense tracking data in this context have been used by police to look for suspects of crimes. It's also hard or impossble for data subjects to exersise ther rights when being tracked in public.
• Probability: Medium. While this tracking is unlawful, there is significant evidence companies and gouvernment have been using bluetooth tracking in public.
• Risk: High-Medium
• Measures:
  • Some or most modern smartphones have MAC adres randomisation features to make tracking via this method more difficult. This measure isn't available on all phones and all contexts.
• Impact after measures: Medium. Most users of the app are probably safe from tracking, however not all of them will be.
• Risk after measures: Medium-Medium

[dirkx]

In general on iOS and Android; when the CoronaMelder is used - the addresses are set to a nonsense value; which is changed every time the RPI is changed (roughly every 10 minutes). And at the same time (so you cannot reconstruct the change).

So if the CoronaMelder is all you'r using; and your vendor has done the right things - you are good. I am currently not aware of any Apple or Android phones that are able to run the CoronaMelder and fail on this point. But there are many android phones!

Secondly - for most paired devices - something similar happens through the IRK (Identity Resolving Key). With this you are able verify if given Bluetooth Device Address was generated by the particular IRK or not. That way you can identify a device as it changes addresses on each connection.

This is the theory.

There are three important caveats (that we know of):

*) There are reports that some Android phones do not change the mac address. We've been able to observe this for Wifi; but not for bluetooth though. So we're not sure.
*) If you have an ongoing connection with, for example, a headset.
*) Your may also be running other apps which are looking for bluetooth accessories; such as a BLE-lost&found tag. Older/occasionally some of these use a fixed address (they are not supposed to). This applies to both iOS and Android (who are making this increasingly hard for apps to do).

So in the last case - an observer sees the random CoronaMelder mac addresses but the static address for the tag seek calls. Based on direction and signalstrength (or if you are the only one in the area) you can then surmise that they are one and the same.

Note though that is not the norm; most phones and apps (iOS better than Android) change their address on the bluetooth layer after every connection. And in general, a well behaved bluetooth devices need to use the Identity Resolving key from the pairing to re-construct if the given Bluetooth Device Address was generated by the right peer. Apples closed ecosystem does better here than Android.

For the headset case - some similar caveat applies (even though the address may actually change - the stream continues- making it easy to guess what is what if there are not too many people in range).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.