UK centralised contact-tracing app probably won't work well, may be illegal
theregister.co.uk
theregister.co.uk
Some observations on their design:
They refresh the identifiers broadcast by each device every 24 hours. So any 3rd party can track an individual using the app for 24 hours before they rotate their identifier. No privileged access required.
The payloads look huge (>100 bytes), so it looks like every interaction needs to be connection based (i.e. pairwise) rather than broadcast based (one to many). That's going to be hell on the battery.
They broadcast a country code in plaintext, so any international deployment would reveal the probable nationality of nearby users. Can't see that ending well.
They hold a master key which they can use to reveal the identifier of any individual using the system. Significant risk of mission creep e.g. a warrant / subpoena to reveal who was near person X during the time period Y.
Clearly if they both work well, then the one that discloses less data is better.
It is important that we maintain context here: these are both "minimally disclosive" protocols which were designed to transmit as little information as possible while being effective tools. Compare this with the absolutely pervasive tracking being done in South Korea and other places. The difference is that NHSX and the designers of PEEP/ROBERT thinks that a higher level of disclosure is required than DP-3T to be effective. At the moment, we do not know if either of these will work, so it's not the case that we can say: "they both work, therefore only a surveillance state would pick the one that discloses more information". It is a balance and that will always lead to different people making different decisions.
I suspect we will know this week whether the app as currently setup will work from the IoW trials. If it doesn't work, kills the battery, etc. then I hope NHSX has a DP-3T alternative in the background. Given current levels of infection in the UK, this will become important in the last week of May onwards for releasing lockdown measures so they have a few weeks to get a solution that works.
To me it seems overly paranoid to suggest that the UK government would be doing this merely so they could track citizens movements or whatever - and I'm pretty sure the intelligence services are capable of doing that already if they want to. There are definite upsides to their approach from a surpressing the infection point of view, obviously they believe they are worth the trade-offs.
It will be interesting to see how the trial plays out vs. other countries using the Apple/Google approach. I don't think the government would risk having another potential large failure in handling this crisis if the evidence clearly points to the Apple/Google approach being better.
I did see a quote yesterday to the effect that nothing is set in stone and they can change the approach they are using if necessary, can't find the source right now.
I agree, but don't ignore the rest of the argument, which is that the beta versions of the app failed the requirements to be included in the NHS App library; they're using weird version control so NHSX can't do correct tests on the app; it's already failed some security testing; and the contract was awarded to someone on Sage, who has a brother that works for Cummings.
I would expect at least some beta versions not to pass all tests, it is not even clear whether they have submitted it for formal testing yet.
They're not using "weird version control", they're using continuous release during development which is totally standard. They'll have to switch to version numbers and formal change control once they enter the NHS Digital approval process but I don't think they have yet.
NHSX is delivering the app. Faculty (which is run by Marc Warner) has other government contracts but I don't think building mobile apps is really what they do.
In fact, this is a benefit of the centralised matching model proposed by the NHS. The algorithm, eg number of packets received, time window in which they are received, can be tailored to improve the model.
But in any case, using Bluetooth to model virus transmission risks becoming a massive red herring.
[1] - https://www.schneier.com/blog/archives/2020/05/me_on_covad-1...
[2] - https://www.lightbluetouchpaper.org/2020/04/12/contact-traci...
I think if we did know exactly the mechanics of transmission then we could afford to be super minimalist about how much data was disclosed and restrict it only to the very least required. The problem is that we don't know what that minimum is. I think one difference between critics of this approach (and indeed Google/Apple) and the NHSX/Ministerial decision makers here is that the former are not accountable for controlling transmission. If it doesn't work then they tried to help and regrettably it didn't work. The latter are trying to thread a course between how many people will die, how many years we'll be paying off debt or suffering from economic chaos, and privacy implications. That doesn't mean we can just ignore the latter, that is too easy and only leads in one direction, but it also means that decision makers have to balance competing concerns.
If it were me (but I am neither an expert nor do I have the full set of data that they do) I would pursue the same course as they are but also have a team working on an alternate implementation as a plan B. I would also make binding public commitments about what we would do with this data, introducing new statute law if really required. Again though, that's easier said than done because they don't yet know exactly how they'll need to use this data.
HSJ (a specialist news source for healthcare in the UK) has an article here: https://www.hsj.co.uk/technology-and-innovation/exclusive-wo...
I might have installed something created by Google and Apple, or by NHS X. But I'm not going to install this thing.
> Ben Warner a data scientist advises the govt & sits on SAGE meetings. His brother called Marc. Who's also also very pally with Dominic Cummings. Surprisingly he won a £250m NHS contract not long ago. Now he has the contract for NHS tracking app. This needs to be questioned.
https://twitter.com/JonJonesSnr/status/1257369738281463809?s...
> NEW: Critics, including doctors & MPs, are warning that govt is using the pandemic to accelerate the privatisation of the NHS without proper scrutiny. "Deloitte, KPMG, Serco, Sodexo, Mitie, Boots and the US data mining group Palantir are all involved.'
https://twitter.com/Mandoline_Blue/status/125741028793165824...
I also note that exactly 2 participants decided not to disclose their participation.
[0] https://www.gov.uk/government/publications/scientific-adviso...
> There is a plaque and a [water] pump, and the John Snow pub opposite
The plaque and pump were removed several years ago, much to my dismay as an amateur London tour guide.
The pump was then reinstated in 2018 but it was still jaw dropping that such a landmark was removed in the first place.
https://lookup.london/john-snow-water-pump/
Quite interesting
>The NHS has insisted its engineers have worked around this problem "sufficiently well" by waking the app after it detects itself running on a nearby phone emitting an ID: the software is blocked from sending out its ID when in the background but it can passively listen for IDs of apps still allowed to broadcast. However, this assumes there are a sufficient number of phones running the tracing app nearby still broadcasting to keep enough people's apps awake: there needs to be a critical mass of users while we're all supposed to be socially distancing. If two or more people pass each other and their apps have stopped broadcasting, the software will never know they came in contact.
Bluetooth LE has four main states: scanning, advertising, peripheral connection, and central connection. In order to exchange the data that the app needs it needs one device in the peripheral connection mode and the other in the central connection mode. This means one device must have previously been advertising and the other scanning. The two important states are advertising and scanning.
Android devices can advertise in the background but they can't scan reliably, they can do this for a short period of time enforced by the Android time limits on apps running in the background and possibly manufacturer specific power savings measures. These limits are not well documented and cause issues on any device using Bluetooth.
iOS devices can't advertise in the background, however they do advertise an Apple specific advertisement which can't be controlled by the app but can still be connected to. iOS devices also can't reliably scan in the background however they can scan more reliably for iBeacons (special adverts) [1]
Combined this makes it difficult to work well in the background, Android devices can't reliably connect to any device, iOS devices can't connect to each other but iOS devices may be able to connect to Android devices.
[1] https://developer.apple.com/documentation/corelocation/deter...
I'm by no means an expert, and would refer to the TCN Coalition's current explanation of their approach to cross-platform device communication:
https://github.com/TCNCoalition/TCN/blob/37add39f7ddb91fade9...
And they state that for iOS in background mode:
> A nearby Android device acts as a bridge. It receives TCNs through “central” write operations and adds them to a rotating list to broadcast alongside its own TCN.
Which doesn't sound that reliable or accurate.
iOS is much much better. You can scan for iBeacons (a restricted subset of advertisements) continuously in the background and it works extremely well. Their Bluetooth stack is a million times faster and more reliable than Android's. But I'm pretty sure there is no way to scan for, or broadcast non-iBeacon advertisements in the background.
There are waaaay too many gotchas to do this reliably without OS support.
Since Android 8.0 there are no time limits for background scanning if you're calling startScan() with a PendingIntent. It's not 100% reliable, particularly on devices which aren't on stock Android as you mention, but it works reasonably well.
> The UK's coronavirus contact-tracing app is set to use a different model to the one proposed by Apple and Google, despite concerns raised about privacy and performance.
> The NHS says it has a way to make the software work "sufficiently well" on iPhones without users having to keep it active and on-screen.
> That limitation has posed problems for similar apps in other countries.
> Experts from GCHQ's National Cyber Security Centre have aided the effort.
At the time, I definitely saw people assuming that this meant that some kind of exploit was being used to achieve access to Bluetooth while the app was inactive, even though regular APIs do not permit this. The new technical information doesn't directly address this point, though the Register article does suggest a plausible alternative, whereby one user with an actively-running app can cause the app to wake on other users' phones by sending out a Bluetooth LE broadcast. I've no idea how this would perform in practice.
The Norwegian NHS equivalent had a similar app developed, running off-screen on both Android and iOS, using Bluetooth - though I have no idea how they pull it off.
Edit: The above paragraph is incorrect; my apologies. I did some research and found that the app only uses Bluetooth on iOS when the phone is unlocked; however the app itself may be off-screen.
While the phone is locked, it relies on GPS for positioning and presumably correlates location and time data to indicate whether you may have been exposed to an infected person or not.
Irrelevant anecdote - as I am typing this, Spotify put on The The's 80s hit 'Infected'. Hah!
Criticism of the centralized model from both Left and Right political parties, so the government would get nothing but flak if they didn't change course (1 May): https://www.dr.dk/nyheder/penge/dansk-corona-app-er-forsinke...
Government have formed an advisory board to focus on security and privacy of the app and its use (1 May): http://sum.dk/Aktuelt/Nyheder/Coronavirus/2020/Maj/Smittesto...
Google [palantir £1 nhsx] to confirm.
I don't think it's too early to say.
In particular, that paper identifies several specific threats to the operation of the system, some of which have not been widely discussed in the media and a few of which raise potential concerns about decentralised systems as proposed or recently adopted elsewhere.
TL;DR: Yes, there are some rational privacy concerns about the NHS app being centralised in nature. However, the people designing this system aren't morons and there is no perfect solution that is invulnerable to all conceivable attacks and abuses.
[1] https://www.ncsc.gov.uk/files/NHS-app-security-paper%20V0.1....
Some people consider GCHQ themselves to be malicious actors when it comes to the privacy of the UK public.
However, the drawback if data from a centralised system for coronavirus tracing is abused by central authorities contrary to their explicit public statements is obvious and not particularly interesting or enlightening, so I suggest we all stick to discussing the substance of the article rather than conspiracy theories. If the government wanted to track people centrally via their mobile phones, it's not as if there aren't more reliable ways they could do it anyway.
I don’t think so, and the NHSX described system also seems vulnerable to a degree.
I also think that in this particular case, it's not really that much of a threat, for the simple reason that more effective means are already trivially available for the government to track people using their mobile phones if it wants to.
Whataboutmanship isn't an excuse either, to me. Just because the government is capable of hacking our phones, getting our phone records, and sending men in black cars to watch our houses doesn't mean we should also invite them in via an app we choose to install.
Edit: I agree with you: I don't think this is a conspiracy and I don't think a centralised contact tracing app is a security concern if its used just for that.
However, I do not trust the British government at all, especially given their beyond-satire record. Don't give the state an inch: they'll take a mile.
I don't think anyone insulted them as such. Bur smart people can sti make unwise decisions under the pressures of time, politics and conflicting requirements.
That is exactly the problem. I fully trust the designers and implementers of this system to know how to exploit the data for "unintended" purposes at any point.
The summary, from my perspective is that this approach is terrible.
It builds a social graph. If you get sick, and a LOT of people are going to get Covid-19, then you reveal your social graph.
There are "technical" parts of the description that do not make sense -- why is your "phone model number" important, Covid-19 doesn't care. Why is that data being collected?
If you read closely, an "installation ID" is created and ends up being recorded. This is a unique tracking identifier. When you get sick, you reveal this ID and put a name to it -- along with a "fuzzy" geographic location.
Now that I've looked at the PDF, some of the crypto includes the "Country Code". Which is "recoverable" on the server side. The trite explanation for that is "and the country code allows for multiple countries to interact".
Why is "Country Code" in the crypto and not in the questions you ask the patient?
[edit: to remove bad linking] I do not believe this is a good design.
Caveat, it is far, far easier to criticize than it is to create a good design.
Where does it say anything about associating a name with the installation ID?
The risk of potentially commingling the graph built from notifications with other data sets is explicitly acknowledged and discussed, and is obviously the big drawback of a centralised notification system like this. Precautions to be taken to prevent abuse are also discussed.
It seems to me that most of your objections here, and in your comment on the other thread, are attacking straw men and ignoring the technical details and logical arguments presented in the document.
In the section subtitled Here comes the crypto, second paragraph, it says "it records the model of your phone (for example ‘Apple iPhone 10,2’)."
So, you're wrong about these arguments being straw men. However, the reason for doing this is reasonable enough: you need to model what the bluetooth signal strength measured by each phone actually means in terms of physical distance; and that means knowing the phone model.
The real argument is not technical; it is that the UK government has proven itself repeatedly incapable of avoiding mission creep in these kind of laws and systems. My go to example "Half of councils use anti-terror laws to spy on 'bin crimes'" – https://www.telegraph.co.uk/news/uknews/3333366/Half-of-coun...
That feels deceptive, not least because it directly contradicts an earlier statement in the section about the app's operation on page 4, which states explicitly that the extra data collected is currently limited to the first part of a postcode and some clinical questions about symptoms.
To be fair, that brief reference on page 9 does also answer szc's question about why that data is collected, though: as suggested, it's used to normalise the RSSI values to determine realistic distances.
I still haven't seen anything in that document about trying to associate a name with the tracking ID or otherwise commingling data sets, so those still look like straw men as far as that document is concerned. Of course with other information that's been coming out over the past few days, that app is looking worse and worse all the time. For me personally, any reduction in scepticism about the app when the technical details were published has now passed and my usual caution about anything that might represent a threat to privacy is now back in full effect.
Off the cuff, I would think it would be useful to give some idea of the Bluetooth range of the device being used? There may be performance changes or mitigations needed for whatever it is they're planning to allow this to work?