Cwa-documentation: Bluetooth cannot be used to measure distances

[Covid19Fighter]

Where to find the issue

The whole idea of this app is to use Bluetooth to get the list of persons that are near to you (<1,5m).
This will not work, the concept is wrong. I have studied telecommunications and any student will tell you.

Describe the issue

Using Bluetooth to measure distance is only possible:

• On a lab
• After calibration of both antennas
  To use it on a dynamical environment is not possible.
  If you want to measure all persons on a radius of 2m you will also get persons on a radius of 28m.
  Even the PEPP-PT project performed an study by the Frauenhofer IIS (Steffen Meyer) and got results that show this:
  https://github.com/pepp-pt/pepp-pt-documentation/blob/master/12-proximity-measurement/distance-measurements-and-classification-20200406.pdf
  The gauss curves of the RSSI measures for distances <1,5m and >3,5m are overlaping by more than 50%. On some tests I have measure it and you can get persons that are 28m away. No AI, machine learning or any other tech can change that.

Suggested change

Do not use only Bluetooth. Google and Apple are good developers but even these developers are limited by physics.
I do not think you can fix with the delivered API. If you still want to carry on with this concept. Please at least perform good physical tests before publishing the app. Do not take the quality of this API for granted only because it is released by Google and Apple.

[MikeJayDee]

I think it is well known that distance cannot be measured exactly by Bluetooth. The PEPP-PT study you linked shows that there is in fact a clear correlation between signal strength and distance, which means that a sensibly set cut-off would result in many correctly identified contacts. Mistaking 28 metres for 2 metres (as you seem to suggest) appears to be extremely unlikely though. Remember that the app does not need to be perfect in order to be useful.

However, you are probably aware that the scope of the project is to develop an app for the Google/Apple API, so this issue will undoubtedly be closed by a team member.

[kbobrowski]

I also have some concerns about Bluetooth, just putting it in the back pocket results in 10 times higher distance measurement: https://www.youtube.com/watch?v=SAi24ctpyZQ

The thing is that even if this system is not very effective it could have big impact, depending on what would be the reproductive number with and without the system. If without deploying this app R = 1.05 and with R = 0.95 - it would make a huge difference.

[Covid19Fighter]

[Covid19Fighter]

Sorry, correct me but on the red triangle you need a magic wand to know the distance.
And the red triangle is big.
On this study the author did not even write a summary, I think it was because the results were not really what they expected.

[Covid19Fighter]

28m means you will get everyone on a train station. Not really that helpful.

[MikeJayDee]

In this example, I would probably choose a cut-off at -85 RSS. This would give you few false positives where the distance was more than 3.5 metres. But you would still catch 2/3 of the close contacts. This seems perfectly acceptable to me. For longer contacts, there will also be several measurements, which will make the data more precise.

Most likely, in this example, values below -85 for close distances are caused by shielding of the body, which is nothing you can fix really; you need to accept a certain level of false negatives. But remember that the counterfactual (no app) is 100% false negatives for unknown contacts.

[Covid19Fighter]

I thought the main target of the project is create a good app for Germany, not to follow blind instructions from Google and Apple.

[MikeJayDee]

The scope of the project is to develop apps for the Google Play Store and the Apple App Store that can make use of the Google/Apple Exposure Notification API. Not using Bluetooth is therefore out of scope.

The signal strength cut-off to be used to determine the risk level can be set by the RKI, and I'm sure they will be aware of the false positive/false negative trade-off.

[Covid19Fighter]

Yes -85dbm, would be my choice. But I would use more technique than only Bluetooth. False positives are bad, false negatives are not acceptable if you have exponential virus expansion. I am not questioning the use of Bluetooth, I am questioning the use of Bluetooth as single technology and to tell people it is the only effective way and you cannot use anything else. This is not true. Frauenhofer was even suggesting persons they can really measure the distance with Bluetooth.

Google and Apple are blocking any other kind of technology and closing their stores and there is not even a decent study on the Bluetooth effectivity of their API. It is not serious.

I am just asking you to test the API and publish the results. It will not only good for the Tracing Idea, but also for your reputation and all the millions of persons that may use the app. To say you are following Google and Apple instructions and is the best you can do is not enough for this project.

[Covid19Fighter]

[Covid19Fighter]

By the way, here -85dbm is not doing the job. Same document, PEPP-PT git.

[Covid19Fighter]

Furthemore, you should maybe read what the French government thinks about Google and Apple instructions on this.

[Covid19Fighter]

And please keep in mind I am a believer an app could really make a difference, but it has to be a good engineered app based on sciences and not on politics.

[MikeJayDee]

That's a different phone. Transmit strength will be sent along the rolling proximity identifier as part of the augmented encrypted metadata. Receiver sensitivity is known as well, so your point that a single cutoff does not work, is moot.

I for one am grateful that Google and Apple provide this API on which a decentralised service can be built, and a centralised model would not really work. Otherwise I would have to decide between giving up some of my privacy and helping combat COVID-19.

[Covid19Fighter]

If you are an infected person, you are giving a lot of privacy with the decentralized model. I don't understand why the GDPR people were convinced decentralized = data privacy.
But this is another topic: https://github.com/corona-warn-app/cwa-documentation/issues/102

[gregorte]

One more concern I keep trying to figure out (more a typically UX train of thought): Considering that the Bluetooth signal strength was being used in a described model to determine the distance between two phones and this model - even if not perfect - works satisfying for phones in plain sight...

Don't you think it could be quite a misleading measurement for all the circumstances users usually handle their phones, i.e. in backpacks, pockets, purses, or if just physical objects might influence the signal spread but not necessarily the potential spread of a virus via air, like big desks for example?

The issue to alarm too many users with a potential threat of having crossed paths with an infected user has been discussed above. My concern would be a bit the opposite, that the signal strength was weaker / misleading due to blocking objects / phone environments so that, technically, the app recognizes phones in a bigger distance to each other than the actual distance was.

I could consider this a potential issue by relying on Bluetooth strength to achieve misleading results, but maybe you thought this issues through already? You mention above that it is something that is hard to avoid and that Google and Apple are limiting the set of option, but I would suggest raising these concerns since the number of missing results could be quite hight and an app with very limited results is probably in no one's interest.

[Covid19Fighter]

@MikeJayDee : yes it is a different phone. It is always a different phone if you are not in a lab. It is also a different position (ear, pocket,...), different walls and ground reflections and we are talking about two antennas, not one so you don't even know what the other device is doing. To get this right you will need a pretty incredible software or a magic wand. Please test it properly before distributing and ruining the trace idea forever.

[mynchau]

We are working with the assumption that it works with Bluetooth which is especially assisted by the risk score calculation as outlined in the solution architecture document. I'm closing this issue with kind ask to refrain from speculations.
Thanks and best regards
MC
Your Corona Warn-App Open Source Team

[Covid19Fighter]

@ mynchau- You are closing without an answer and with assumptions that are not backed by any study or test?
Which kind of quality criteria do you use here?

[s-martin]

I'm not an SAP employee.

The answer is probably that this project is tasked to implement the Exposure Notification API.

General discussions about the effectiveness of this API are not useful here, but could take place elsewhere.

[gregorte]

Aren't we all developers, who try to consider a potential best practice for achieving the highest effectiveness of an application that is supposed to help all of society?

Building the app for the provided API interface to move is one important task, considering and fixing flaws in the UX / UI should be another task on this project as well.

[SebastianWolf-SAP]

Several teams in several institutions and companies have been performing tests (you mentioned the PEPP-PT paper and it's actually more promising than you claim) in the last weeks and continue doing so as we talk and - of course - also in the next weeks.

After evaluating several options - also based on this research, using BLE with a decentralized approach was the most promising way forward with the existing hardware which is out there in the wild while taking privacy and data avoidance - especially with any central authority - into account.

Of course, we are aware of the limitations (also mentioned in the Solution Architecture document), but we are also confident that the project and the algorithms will evolve and become better and better over time - and everybody is encouraged to participate in that process.

However, please understand that we won't question the very basic foundation the whole project is built on - based on previous research and the infrastructure which we need to work with. Moreover, as @mynchau already said, we avoid speculations. As a consequence, this issue with the clear title "Bluetooth cannot be used to measure distances" is misleading/speculation and therefore we closed it.

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

[Covid19Fighter]

Hi Sebastian,

please make only sure you test and publish the test results before you go live.
If you don't do it, someone will do it. It would be better you know before it is on the news.
I probably will not have the time to do it, but someone will.
To keep the ticket open until the test would be a nice reminder, but you can close it.
By the way, it is not misleading speculation. I have studied this stuff, I have read the studies and I have discussed this with university profs. that teach this stuff. Even MIT is not really that optimistic.

BR

I have now performed the tests myself. It is not that difficult, the BLE libraries are open (not the API).
On 2 Samsung Galaxy devices:
-61dbm at 10cm distance.
-70dbm at 1m distance
-82dbm at 5m distance with a wall behind both persons and a close walls on the sides (walls behind reflects the waves, walls on the sides creates a tube effect)
-88dbm if two persons are sitting on a table at 1,2m distance and the mobile phones are on their rear pockets. (people bodies and table are stopping waves).
So, if you take into account that these are the same devices and that I have previously calibrated them you conclude using this signal for this purpose is not going to work if you don't use other sensors or information on the mobile phones. This is the same conclusion serious studies showed.
If on the other hand you use all the possibilities and sensors of the mobile phone (GPS, WiFi, etc) you probably will get a much better result.
So you are going to broadcast the IDs of all infected persons to all devices against GDPR law and Google and Apple will be able to know who they are, because the main encryption logic and security is done by the non public, non open source API and no one can control it. On the other side Google and Apple will also be able to use their already existing location services to match the persons.
Again, seriously test this API, you can do it better than anyone else and please switch off all other signals to make sure only Bluetooth is used by the Google API.

And by the way, read this:

https://mashable.com/article/bluetooth-is-bad/?europe=true
https://qz.com/1169760/phone-data/

These articles show you what is going on and they are not really conspiracy theorists.
Trust me, you should recheck what you are doing before going live.
And even if you probably don't think so I am trying to help you, the German Government, DTAG and SAP.

And the DP-3T group, the defenders of decentralized "secure" system and data privacy, seem to be collaborating with Google since 2018:

https://actu.epfl.ch/news/epfl-strengthens-its-research-collaboration-with-3/

I have posted this to the GDPR authorities of NRW, BW and the EU and also to SAP and Telekom privacy instances. I also sent a copy to political parties in Germany and EU. I hope you stop this madness and create a GDPR conform and technical efficient solution as it should be.

[pdehaye]

@Covid19Fighter the PEPP-PT study gives more hope than you give it credit for, because you can collect many measurements over time, you don't have to rely on just one measurement.

This being said, you are absolutely right that it is definitely moving back for PEPP in terms of precision to go to the Google/Apple API, since they only give access to a very averaged value for the attenuation.

I give a lot of details here.

https://medium.com/personaldata-io/inferring-distance-from-bluetooth-signal-strength-a-deep-dive-fe7badc2bb6d

[Covid19Fighter]

@pdehaye Thank you! Yes, this is the kind of work I call serious. Not testing the API and following blind instructions of Google is not. On behave of PEPP-PT: They did a lot of innapropiate media coverage and they told people things that were extreme exagerated and did a stupid Bundeswehr show on the Tagesschau (bizarre scientific event), but even these guys were a lot more trustful as Google is handling with data (https://www.nytimes.com/2019/01/21/technology/google-europe-gdpr-fine.html). In my opinion Google does not care about solving the Bluetooth problem correctly because they don't have to. They already have quite good location services (based on a lot of stuff and a lot of data people are giving away for free) they can use, the only piece of information missing is the list of infected persons and with the API they have now a way to get it without GDPR fines, because DTAG, SAP and the government will send them the data while broadcasting to everyone. Come on, this is really a farce and the governments are buying it. If people know this data is going to Google they would never accept to give it away.

And three things on the study:

• Yes you can try to measure more often, but this will affect battery consumption
• Even so if you have the typical german "biergarten" with one table and people sitting on both sides with the mobile phones on their pockets you will have a problem.
• I got your shadowing value for 2 bodies instead of one, so I think you cannot add the shadowing of non-wall objects that easily (again I am quite sure because I worked on such models years ago). The whole thing is a mess because of the reflections, again the Bluetooth protocol was not invented for this. It is like you try to land an aeroplane with a blind pilot and a walkie talkie. Yes, you can try but it is not how you should do it and the chances are not that good you get it right. If instead of doing it for one plane you do it for all the planes you will for sure create a chaos.

[Covid19Fighter]

I think I got their attention, maybe there is some true in what I am telling. Don't you think?

[seanlilmateus]

@Covid19Fighter

Bluetooth BLE

I believe we all know that BLE is not a perfect solution for this purposes, but for the moment the best compromise between Date privacy and availability that we have. Do you agree, that it if this solution works on 60% of the time, we can consider it as success?

GDPR

So you are going to broadcast the IDs of all infected persons to all devices against GDPR law and Google and Apple will be able to know who they are, because the main encryption logic and security is done by the non public, non open source API and no one can control it.

According to your understanding of the GDPR any App running on Android or iOS that use the default _encryption logic_ are not GDPR compliant. There is a chain of trust and it have to start somewhere. People that use iOS, Android or any other Android distribution (e.g: LineageOS), they indirectly state their trust to its vendors respectivily. - If you don't trust the software, you should also mistrust the Hardware.

[pdehaye]

@seanlilmateus there is some validity to the argument that trust has to start somewhere, and we will have to have trust in the hardware and the software if we are to deploy anything.

However, before we can deploy something, we have to make sure it is legally compliant, which involves a complex process of assessing which data gets transmitted, and what risks are associated to the transmission of this data. In turn, that risk assessment will depend on careful consideration of the hardware and the software, and the trust we should place in them.

In this latter discussion, there are many corners that are left unaddressed. For instance AFAICT, the Google/Apple recent iOS upgrade includes the filtering at OS level of the packets scanned through Bluetooth, so apps that have nothing to do with the Exposure Notification API but who have Bluetooth permission cannot "see" the Exposure Notification packets. This is a bad thing for interoperability with COVID apps not directly using the Google/Apple API, as it leads to interoperability problems with solutions deployed in some countries (France, UK, Norway), but a positive thing for privacy, as it prevents malevolent SDKs from spying at scale on the Exposure Logging protocol, for instance. On the whole that filtering of packets certainly seems to me like a positive net outcome.

However that filtering is not perfect, and will indeed not be there in many circumstances:

• Not all phones will do the OS updates, so paradoxically those who don't will have more ways to see the Exposure Logging traffic. This keeps the SDK threat, but also threats from popular apps with Bluetooth permissions.
• Not all phones run Google or Apple controlled OSes. For instance it is my understanding that Huawei could do its own COVID-related OS update, which could include components tied to scanning also for those packets. This would then require extending trust to them, beyond just Google and Apple.

[MikeJayDee]

I really don't see a GDPR issue. The Rolling Proximity Identifiers are truly random and as such not an issue (otherwise using a Bluetooth headset would be a problem as well as the Bluetooth MAC reveals the same kind of information; you can track it until it is changed 10-20 minutes later). The Rollying Proximity Identifiers only become mildly interesting once someone is tested positive and then decides to actively upload his daily tracing keys. Since this is an active action the user needs to take (and the implication is presumably explained), how would this be problematic under the GDPR?

[kbobrowski]

@pdehaye thanks for the in-depth article! Regarding your comments on filtering BLE frames - I think it would be a good move, and if they restrict it only to Google/Apple EN frames (with type identifier 0xfd6f) it should not interfere with alternative solutions in other countries. Not sure if this update can be pushed to Android though, system on vast majority of devices is not updated fast, or not updated anymore (Google Play services update most likely won't be able to patch it).

[SebastianWolf-SAP]

While it's certainly interesting to continue discussing all the details, we made already clear in https://github.com/corona-warn-app/cwa-documentation/issues/103#issuecomment-631356756 that we won't question the very foundation of this project and that we will do the best with the existing infrastructure while adhering to some basic privacy principles.

As this discussion has become quite off-topic now, I need to lock it in addition to closing it some days ago. Thank you for your understanding. Moreover, @Covid19Fighter please check your language, "stop this madness" is certainly not a professional way of discussion important issues - especially when we continue with the GDPR discussion in #102.

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team