To cut a long story short and not trip up anyone in the process, Germany made an announcement on Sunday, April 26, that it would begin development of its own contact tracing anti-coronavirus application based on the common API of Apple and Google, something which Germany ruled out at first. A reversal in opinion could be explained by software blocking issues imposed by Android, as well as iOS concerning Bluetooth activation in the background - a move that is crucial for contact tracing apps to function to its full potential, where this particular API is the only recourse.
France did take a different step by working on its own Stop COVID application. The country decided not to bow in pressure to in order to maintain their technical sovereignty and data security, and has requested for GAFA (Google, Apple, Facebook, Amazon) to lift whatever software restrictions in place so that they do not have to fall back on the controversial API. This was an arm-wrestling match that was lost from the beginning against Apple, with Cupertino more than happy to leave the FBI hanging high and dry when they made a similar request related to terrorist acts.
Faced with what seems to be a technological impasse, the question then arises: should France take its cue from Germany and put aside its Gallic pride in order to prevent Stop COVID from becoming a total fiasco? The answer is not that simple. There are no winners or losers, good guys or enemies in this case. However, the balance does seem to tilt in favor of a decentralized "German-style" solution with Apple and Google.
A choice "more reasonable from a technical point of view and in terms of comparison of the dangers for our data", as Damien Stehlé, professor of computer science at the ENS in Lyon mentioned. He is also the co-signatory of an open letter to the government that alerted them on the risks that arise from contact tracing applications.
Leaving your data to Apple/Google or to the state: there is no winner...
The current point of contention centers around the question of the method chosen by France to deploy contact tracing. One can roughly distinguish between two protocols: a centralised or ROBERT protocol (the French solution), and a decentralised one (the Google/Apple method, the German DP3T, PACT, and many others).
"The centralised/decentralised terminology is confusing," says Damien Stehlé. "The question is not whether I leave my data to Apple/Google or the state, but whether I leave it to Apple/Google or Apple/Google AND the state - it's either one or both." Hence, it is important to consider who processes the collected data. In the case of ROBERT, this processing is done by the State at the central server level.
The ROBERT protocol, which stands for ROBust and privacy-presERving proximity Tracing, is a contact tracing method developed by researchers at Inria, the French National Institute for Research in Digital Science and Technology. The data collected here are then stored on a central server.
"The key element of the protocol requires users to declare themselves as infected via the application, but this information is not stored on the state's servers. In essence, nobody can then trace the patient: not a company, the State, a hacker, none of them. Only the hospital that keeps health data of this trace," as my colleague from Numerama, Julien Cadot, summed it up very well.
Indeed, Inria proposes to never dissociate from a set of Bluetooth identifiers. Assuming your smartphone collects 10 identifiers from people whom you came into contact with during your trip, it will send 10 identifiers to the central server, and your handset as well. Assuming one of the people came into contact with declares himself sick, the central server will then locate his identifier, and consider all other identifiers to be at risk. Everyone will, therefore, receive a notification without knowing who is sick. However, the patient will still be digitally registered by other means at a hospital, complete with all his actual identity details.
"In the other solutions, known as decentralised (Apple/Google's API, among others), the processing of whether one is at risk is done locally on the smartphone that receives an encrypted list of sick people. From there, it will go through the list of people whom you have come into contact with, before the app determines whether you are at risk or not," says Damien Stehlé.
But there is no definitive conclusion as to whether this is more protective of our data compared to the other, according to Damien Stehlé. He pointed out that each protocol presents a similar set of dangers, albeit at different proportions.
Between the plague and cholera...
The only indisputable fact in this argument is that a centralised contact tracing application cannot work properly without the Google/Apple API lifting restrictions on Bluetooth activation. The Singaporean example was a clear demonstration of this.
The argument for better data protection enabled by the ROBERT protocol is, however, not as strong. "Each model, whether decentralized or centralized, presents the same three types of risks, but not within similar proportions," says Damien Stehlé. These risks are mass surveillance, neighborhood espionage, and false alarms.
With both protocols, the risk of false alarms remain the same. This is an inherent flaw due to the inaccuracy of Bluetooth. Hence, there will be false negatives and false positives (you are notified to be at risk when you have not had physical contact with a sick person, although that person might have been close enough to be detected via Bluetooth).
"The decentralised model brings more risk of neighborhood espionage, as I would then want to know who's sick in my building, and where I ran into him. The centralized option presents a greater danger in terms of mass surveillance," detailed our expert.
Such mass surveillance includes the collection and generating a social graph. In layman's terms, Damien Stehlé explained, "in the ROBERT solution, when you are sick, you trace all of the Bluetooth contacts you have had over the last 14 days. It tracks who you've been in contact with and how often, in order to notify them. The social graph would be a set of social links between individuals. When applied in such a manner, the central server could reconstruct a large part of this social graph using data collected by the state."
Decentralised thus brings more risk of neighborhood espionage while centralised brings more risk of mass surveillance. However, these two risks do not disappear in either solution. In addition, their seriousness depends heavily on the degree of minimisation of the data collected, which itself is not precise enough.
On a more personal note, Damien Stehlé believes that "the risk of mass surveillance is far more serious than the risk of neighborhood espionage. So if you have to choose between the two, it is better to choose the second." In this sense, the professor considered that for the state, the decentralized DP3T solutions or that of Apple/Google are more praiseworthy than the centralized Robert protocol. "Germany has made the reasonable choice, at least from a technical point of view and in terms of the risk analysis."
As for me, I think that technical limitations and the protection of personal data are only tips of the iceberg. The human element and volunteerism on which these applications rely upon (in compliance with the RGPD) are a serious hindrance to their effectiveness in a context where there is general mistrust toward the GAFA and the State. However, these questions will not arise anyway if Stop COVID malfunctions from the outset because of this technological impasse.
So maybe for once, we could learn from the German model.
Read More Open link https://ift.tt/2xjAMax
0 Response to "Stopping COVID: Should we all be using Apple's contact tracing app?"
Posting Komentar