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.
Interesting. Everyone seems so sure that DP-3T (the protocol that Google and Apple are adopting for their API) will work sufficiently well that the use of the PEPP/ROBERT protocol which is being used by NHSX, the French, and the Italians will be unnecessary. Since DP-3T discloses less information about your social graph to the central party (although in some edge cases more about your social graph to everyone in the network) this would mean that DP-3T is superior.
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.
Further more, any contact tracing app that uses a technological solution is limited in its usefulness anyway. Viral transmission is not well modelled by radio packet transmission. Bruce Schneier has views on this [1], as do the Uni of Cambridge Digital Research team who consulted on the NHS app [2].
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.
True. Jonathan Van-Tam was saying in the daily briefing a few days ago that they are definitely not relying on this as a magic bullet, there will have to continue to be substantial old school manual contact tracing.
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.
Great comment, nice to see some rational/balanced thinking on this.
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.
> 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
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.
The HSJ article really looks like it is both written by and sourced from people who are not too close to either this process no to software development.
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.
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.
> 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.'
It was apparently removed due to redevelopment, and the pump is not the original anyway. Given they later reinstated the memorial, this isn't quite the act of historical vandalism it may first appear.
I'm not 100% sure, but I don't think it's run by the same people as it was back then. It just stuck in my mind a particularly nasty thing to do so I never went back.
The technical aspects discussed are slightly wrong because they are different between iOS and Android.
>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.
On Android the broadcasting bit is fine. But to effectively scan for advertisements you need to start a foreground service and actively scan for them continuously. That will keep the phone awake all the time and rinse your battery. It also don't really work very well because Android's Bluetooth stack is shockingly unreliable.
iOS is muchmuch 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.
Thanks for the link. They assume that Android devices can scan in the background but my experience is that whilst this is theoretically achievable, the experience is unreliable in practice. See this guide which shows how to make things more reliable https://openpathsupport.zendesk.com/hc/en-us/articles/360024...
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.
> 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.
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.
Could someone explain how the new APIs that are being proposed by Google/Apple will actually be delivered to Android handsets? I'm running a 2 year old Android device which generally gets security updates 2-3 months behind Google devices. Will I be at the mercy of my phone manufacturer before I'll be able to use the new Google/iOS apps?
Not definitive but I think they push APIs out in Google Play Services, which is a big blob of an APK. They did this a few Android versions ago so that they could bypass the lack of OS updates from manufacturers.
> Despite what the NCSC has continued to imply, the app will not, as it stands, work all the time on iOS and Android since version 8. The operating systems won't allow the tracing application to broadcast its ID via Bluetooth to surrounding devices when it's running in the background and not in active use.
> 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.
-I'd be surprised if some unknown exploit was being used to gain access to Bluetooth - basically, it would probably be too useful for other, more nefarious purposes, so it would be unlikely to be used in an app deployed to millions.
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!
Germany turned on a dime, and is going to use the Google/Apple solution. Denmark is about to turn on the same dime, as our solution mirrored the Norwegian solution, but had the same iOS problems (I only read that the government was strongly considering the Google/Apple solution, but no verdict yet).
They're testing app on the Isle of Wight now, we'll soon see how effective it is. If it doesnt work, then I'm assuming they'll fall back to the Apple/Google option?
'the disastrous “herd immunity” policy'.
I think it is to early to say that before seeing how countries that locked down earlier do in the comming months.
That sentence has no scientific meaning whatsoever. In January China had 99% of all global deaths. But hey, Kieren McCarthy from San Francisco is an "Inter all-rounder" journalist and surely a person with profound insights into virology to make grand remarks like that.
Anyone from the Isle of Wight here to confirm how they are installing it for iOS specifically? I've not seen it in the iOS App Store and am very curious to see if they are side loading it.
The technical explanation[1] provided by the NCSC is a lot more interesting than the casual write-up on El Reg, IMHO. As a strong advocate of privacy and limiting government surveillance, I was somewhat reassured reading those details.
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.
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.
>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?
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?
Where in the technical document does it say anything about a "phone model number"? It explicitly describes what data is to be sent at the different stages, and I see no mention of anything like that.
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...
I stand corrected. In fact, the report we were actually discussing does mention collection of the device model during initial registration, in one brief reference at the bottom of page 9.
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.
Although there are no perfect solutions, there are systems which willingly connect to and distribute contact data to government servers, and there are systems which do not.
As the paper notes, there are also systems that are vulnerable to various kinds of abuse by malicious actors and there are systems that are not. The price of using an unauthenticated, distributed system instead is likely to be greater vulnerability to some of those forms of attack and/or a dependency on verifiable test results that causes possibly very damaging delays in sending out notifications.
I'm sure they do. Under some conditions, I might even be one of them.
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.
Of course not. I just think the threat if the government straight-up lie and then abuse the contact graph is obvious and not particularly interesting as a conspiracy theory.
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.
The problem is they're not straight-up lying: they're admitting to MPs that this data will be used for "research", people will have no right to delete their own data, and that Peter Thiel's Palantir is involved and basically giving away the services for free.
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.
> However, the people designing this system aren't morons
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.
> However, the people designing this system aren't morons
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.
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.