Recipe for disaster and impossible implementation

[llebout]

Hello,

• It is impossible to ensure that the theoretical basis is flawless in such little time and without an implementation to attack
• It is very likely that the implementation will not strictly conform to the specification and also likely that no one will notice before it is too late
• It is not possible to implement, mobile phones have limited batteries and bluetooth is energy intensive. Additionally, bluetooth access is restricted on all mobile phones and exchanging actual data is not possible without user interaction. The only things you have is the hardware address and device name which you can't change from an application. If you had direct radio access (root) it would be more viable but here nope
• It is very likely that once the system is live, a successful attack will be conducted by an interested party
• "Honest-but-curious" threat model for a centralized server is not serious
• Network layer metadata seems to be completely ignored though it today is the primary means for identification (and using Tor or others would drain battery even faster)
• Initiatives such as this essentially fool the general public into believing the privacy goals can be even met under the requirements, which in my opinion is ethically wrong
• Considering the reliability of the technology, even ignoring privacy concerns, it is likely that the false positives and negatives will render such a thing completely useless and irrelevant from a health standpoint. The false positives and negatives will only ever increase the overall error of the whole system over time, ultimately making it's error rate one hundred percent.

I would suggest stopping work on this and instead tell the truth that it's not possible technically even while ignoring privacy concerns and an illusion to believe it is possible to achieve while respecting privacy

Thank you

[chegewara]

I would like to agree with this, in most points, but i believe it is possible to build app that will keep most important thing in this case which is privacy. In case of bluetooth le solution, apart from privacy protection, is false positive result achieved by replay attacks. Im not saying i am bluetooth guru, but lets consider situation when we not protect against replay attacks properly:

• its very easy to sniff advertising packets next to hospitals or other places where covid19 infection is very likely, send over internet and advertise in crowd place
• is it possible to encode bluetooth MAC in advertising packet to avoid replay attacks? NO, because it is very easy to duplicate MAC address.

The option to avoid replay attacks and false positive spreading may be to use timestamp and GPS coordinates, but here is question about privacy protection. First things first. There is already existing bluetooth le protocol that helps protecting against replay attacks, but for obvious reasons it cant be used in this case, it is ble mesh. To protect against replay attacks it is using encode message ID and replayed messages are dropped. In our case suck message ID can be timestamp and deviation of few seconds between encoded timestamp and recipient clock will cause drop advertising data. This can protect against replay attacks after hours or days. Next question is how it can protect against replay attacks over internet within very short time, when timestamp will be still valid? Here is the point of using GPS data encoded in advertising. I know there will be concerns about privacy, but the point of using GPS data is only to correlate recipient own position with advertised packet. If it will be replayed over internet (with valid timestamp) it will be dropped because of GPS data not match.

The most important question in this solution is privacy. Sending GPS data will let others to track my position over the time. Thats true, but using bluetooth le and constantly advertising even without GPS data will give the same opportunity, because receiver will know its own GPS position. The whole point of using GPS data is to make it volatile, and after validating advertised data just drop it and keep stored on client device only sender ID number. Here is next question, how to avoid tracking ID numbers. Im sure there may be few solutions, one of them may be to randomize it every day or every few hours.

I am totally against letting authorities to let people tracking, even now and especially in USA, because they like precedence very much and will abuse it in future. We have to agree such kind of app can be installed and used only by people who accept its functionality, cant be forced to install it. Here in Poland government is forcing infected people in quarantine to install tracking app.

Now last but not least question is about false positive and negative results. There is no option to protect against false negative results, because app user will decide to activate information about being infected and this is his/her good will or not. To protect against false positive results publication there is option that positive result publication can be allowed with some special code from medical unit that confirm infection and only when infected person decide to publish result.

There is one more thing. There is no option to protect against false positive results, because of GPS inaccuracy and bluetooth advertising distance. Even with using RSSI its not possible to calculate accurate proximity, and GPS is accurate with 2-5 meters accuracy (on open space), which means it wont work in buildings. So, false positive results will be reported in case we were even 5 meters from infected person or more.

[milstan]

IMHO the false negatives are not really an issue. The protocol offers the possibility to alert a person of a potential risk. It does not offer to reassure the person of the absence of a risk. The absence of risk alert does not imply the absence of a risk.

The false positive is an issue, but the risk calculation can be improved over time. However this is also very challenging privacy-vise, if feedback from the alerted individuals is needed after they have been tested.