ROBERT-proximity-tracing / documents

Protocol specification, white paper, high level documents, etc.
Other
247 stars 21 forks source link

Recipe for disaster and impossible implementation #61

Open llebout opened 4 years ago

llebout commented 4 years ago

Hello,

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 commented 4 years ago

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:

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 commented 4 years ago

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.