3 ms·
I am inclined to agree, but I think we need to be careful not to paint the "decentralised" approaches as perfect. Neither solution is perfect, as both make diff
by g_p 6y ago
I am inclined to agree, but I think we need to be careful not to paint the "decentralised" approaches as perfect. Neither solution is perfect, as both make different trade-offs. I share your privacy concerns and whether it's a "bad idea" or not.
The UK has no plan to make the app "mandatory", and they are well aware of the demographic issues that would cause, especially with large areas of elderly populations. That's why there's such a focus on the traditional approach to contact tracing.
RE decentralised vs centralised, the trade-off isn't so simple though in my view - the decentralised app requires the creation of a list of the "infected", which is synced to everyone. That means those who get infected suffer a fairly large "loss" of privacy compared to those not infected. The centralised approach "averages" the two by not broadcasting an infected list. It isn't hugely difficult to use time-based correlation with a calendar or diary to work out if a given person was infected etc, if you have access to the list and database (which we should assume in a threat model people have). The question is if this is a design goal or not.
In addition to the app is traditional "public health authority" contact tracing. That in itself is very privacy-invasive though, and I think people are ignoring it in favour of talking about the app - collecting names and contact info of everyone someone was in contact with, storing this into an IT system, then contacting them etc. Data retention concerns etc and privacy risks here seem significant, yet there has been more focus on the apps than on this traditional approach.
- jnxx 6y ago> - the decentralised app requires the creation of a list of the "infected", which is synced to everyone I don't think it works that way. Here the requirements on privacy which became the accepted base for the German app: https://www.ccc.de/en/updates/2020/contact-tracing-requirements https://www.ccc.de/en/updates/2020/contact-tracing-requireme...
- g_p 6y agoInteresting - every version I've looked at to date still creates a form of "infected list". You could try bloom filters but at risk of many false positives, at a time you really don't want false positives. Looking at the Apple + Google spec though, this is happening - see https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf https://covid19-static.cdn-apple.com/applications/covid19/cu... I can't really see a way to avoid creating an "infected tokens" list, if you want a decentralised approach where the uninfected are not interacting with the protocol on an ongoing basis as well. The UK approach (centralised) was different though, as it was based on the infected person telling the server "who" (based on the tokens) it saw, and they take the steps to notify those users by decrypting the tokens etc, and working out who needs notified. In the decentralised apps, your phone squawks a changing "identifier", everyone stores the squawks they hear, and periodically checks their list of squawks heard to see if any are flagged on the infected list.