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.
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.
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.
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.
> 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!
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.
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.
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.
> 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.
[+] [-] galadran|5 years ago|reply
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.
[+] [-] Mvandenbergh|5 years ago|reply
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.
[+] [-] kitd|5 years ago|reply
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...
[+] [-] tomduncalf|5 years ago|reply
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.
[+] [-] DanBC|5 years ago|reply
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...
[+] [-] hazeii|5 years ago|reply
I also note that exactly 2 participants decided not to disclose their participation.
[0] https://www.gov.uk/government/publications/scientific-adviso...
[+] [-] drcongo|5 years ago|reply
[+] [-] gorgoiler|5 years ago|reply
> 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
[+] [-] dTal|5 years ago|reply
[+] [-] AJRF|5 years ago|reply
[+] [-] barbegal|5 years ago|reply
>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...
[+] [-] jka|5 years ago|reply
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...
[+] [-] 72deluxe|5 years ago|reply
[+] [-] steffandroid|5 years ago|reply
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.
[+] [-] aclelland|5 years ago|reply
[+] [-] 72deluxe|5 years ago|reply
[+] [-] samizdis|5 years ago|reply
[+] [-] rjknight|5 years ago|reply
> 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.
[+] [-] lb1lf|5 years ago|reply
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!
[+] [-] drumhead|5 years ago|reply
[+] [-] jon889|5 years ago|reply
[+] [-] yadco|5 years ago|reply
[+] [-] drcongo|5 years ago|reply
I don't think it's too early to say.
[+] [-] AJRF|5 years ago|reply
[+] [-] amaccuish|5 years ago|reply
[+] [-] Silhouette|5 years ago|reply
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....
[+] [-] szc|5 years ago|reply
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.
[+] [-] sigwinch28|5 years ago|reply
[+] [-] FartyMcFarter|5 years ago|reply
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.
[+] [-] dingaling|5 years ago|reply
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.
[+] [-] jamespeters168|5 years ago|reply