Reference to DP-3T Difference with
Opened this issue · 4 comments
It seems that today, the DP-3T is more developped.
What are the differences ?
Why you do not collaborate with them ?
That's a good question.
My take on this is that as academics, we must be open-minded.
We should also realize that there are lots of difference between ROBERT and DP-3T in terms of privacy protection and it is not clear (at least to me) that DP-3T is better.
ROBERT takes as an assumption that the server's key will be honestly used. It is a big assumption and it really stinks if it can me misused. We must trust the authority for that.
Conversely, DP-3T opens the way to massive deanonymization of diagnosed cases. So far, there is no protection to that applications such as social media apps or even the OS of the phone itself will not transmit the ephemeral identifier which could later be matched to a publicly reported diagnosed case. It stinks too. DP-3T makes the assumption that neither installed apps nor Apple/Google will collect identifiers.
Conversely, DP-3T opens the way to massive deanonymization of diagnosed cases. So far, there is no protection to that applications such as social media apps or even the OS of the phone itself will not transmit the ephemeral identifier which could later be matched to a publicly reported diagnosed case. It stinks too. DP-3T makes the assumption that neither installed apps nor Apple/Google will collect identifiers.
As far as I understand, the protocol and the discussion in #6 DP-3T still would allow the deanonymization via these attack vectors. (by just creating a lot of backend accounts 🤷)
@LilithWittmann Weaknesses depend on the exact version of the protocol used, but in any case this is not a democratic choice since Apple and Google are only agreeing to release some APIs, in particular they have not agreed so far in releasing the APIs that would enable safer versions of DP3T to be deployed. We are all playing in someone else's garden here, which is a problem.
@vaudenay thanks for your work on those issues so far. the discussion between DP-3T, ROBERT and Apple/Google could be greatly facilitated if a proper data protection analysis was done. Both the DP-3T and ROBERT protocols seek to achieve multiple purposes and pretend to exist in a vacuum. If those purposes are analyzed more granularily, it would be possible - I strongly suspect - to carefully design a more complex protocol whereby consent-to-upload and consent-to-be-uploaded are decoupled, and both operate under different trust assumptions at different stages, some of this trust delegation being implemented by punting back to the end user. Both approaches could be strengthened by enacting stronger law protecting Bluetooth data (to address #6 ). A model for this are the US legal protections around census data (jail time!). Of course this is all dependent on the Giants enabling this through more evolved APIs, which we can certainly force them to do if there is strong unified will behind the idea. Unfortunately at the moment a privacy/security first approach (which is a classic mistake by technologists, particularly when they are playing on strong political contacts), is leading to more fracture than anything, and has preempted any good discussion around the common objectives of such systems and how to achieve them. This focus on competition between security researchers is preventing a recently-unfathomable strong coalition of political leaders, security experts, and civil society human rights advocates(!) to emerge and bend the Giants (be them American or Chinese) to their democratic will.
ROBERT takes as an assumption that the server's key will be honestly used. It is a big assumption and it really stinks if it can me misused. We must trust the authority for that.
Everything resides in this sentence - Maybe you do, but very few people trust the authority.
Maybe people should... But I bet that they never will.