"The NHS contact-tracing app must not be rolled out across the UK until the government has increased privacy and data protections, an influential parliamentary committee has said".
The app requests location permission on Android, something that Google doesn't allow when using their implementation.
I suspect this app, in this form, is DOA and will be quickly replaced. Even if they do somehow roll it out widely, there are concerns in [2] about its effectiveness working in the background. This app is a complete disaster, and will be unviable for the mass tracing they will want to conduct. They've pushed and pushed for "why" a centralized approach is the "right" one, made blog posts, issued justifications.
Yet the app isn't likely to see mass adoption and isn't going to work due to restrictions within the OS. This app represents the disastrous approach the government took to this virus. Flip flopping around, shutting down way too late, no clear guidelines or approach, and a high death rate to solidify their failure. Then, they decide the official approach is "wrong" or "not good enough".
Heads should roll over this.
[1]: https://www.theguardian.com/world/2020/may/07/uk-coronavirus...
Lots of people keep saying the app can't work due to restrictions. Maybe, I'm not sure that has really been shown yet. A lot of the criticism doesn't really withstand the light of day.
1: people see "government app wants your location"
2: the government possibly using that location access at a later time
I don't want to accept location on a government app, and the UK has some history with facial recognition cameras and other privacy invasive laws. So there's no way for me to know this location is only for them to use BT LE and they won't make an API call to getLocation and uploadLocationToServer. I assume once you grant location permission even for BT LE purposes it can be (ab)used in some other way.
They've made their own bed with their actions, public confidence might not trust an app like this with a permission like that.
Without a location requirement, an app could claim to use only Wi-Fi and BLE permissions, yet it could combine beacon scanning and data access to de-anonymize user locations.
This permission requirement was introduced in Android 6.0 (see the release notes[1]) in October 2015, so it's been around for a while.
If you have some suggestions around how to improve the tracking of permission usage (static analysis? run-time requests (preferably avoiding times when users are under duress and likely to click 'OK' by default)?) then you may wish to file some requests with them and/or contribute to other projects that you feel are taking a better approach.
Your concerns around trust in app developers -- regardless of whether they are a government or any other entity -- are best handled by two means:
- Open sourcing the code (which NHSX have done)
- Enabling reproducible builds[2] so that users can confirm they have an authentic binary build of the source code
[1] - https://developer.android.com/about/versions/marshmallow/and...
This is why Google and Apple developed the Exposure API, which is more private because it doesn't save as many metadata than the classical BLE permission, and at least Google does _not_ allow apps to declare both the Exposed API and the location permission at the same time.
This gives more guarantee to the users than just trusting the app developers.
In other words, any serious privacy-focused contact tracing apps should use the Google/Apple Exposure API, and not a custom made solution on tops of the older BLE permissions.
However, I still think digital contact tracing, even private, is a bad idea.
The location permission you refer to is related to Bluetooth and is standard.
Just because the collected data is stored centrally it does not mean that it is not anonymised.
And finally I would suggest the Guardian is not the best place to get a balanced view of privacy implications!
I think it's an odd situation to be in where a foreign company is able to hold an elected government to ransom over its healthcare provider's technology choice.
That particular issue is a bit of a niche case, which I argue is rendered less of a problem by behavioural psychology. If your devices are locked with screen off for long periods of time, you're probably at home, or generally not moving. The kind of people who are going to willingly download an app onto their smartphone like this are probably going to be actively using their devices enough throughout the day that the app can at least get a _reasonable_ sample. The best use of the data gathered from this app is supporting mass scale epidemiology, after all -- tracking contact rates on public transport and so on.
This is also specific to iOS devices. Given that the current UK market share is roughly 50/50 between iOS and Android, it's unlikely your device is _only_ going to encounter other iOS devices daily, so the Android "wake up iOS devices" workaround comes into play here.
> The app requests location permission on Android, something that Google doesn't allow when using their implementation.
I think this is going to be less of an issue than you think it is -- even lots of tech-savvy people gleefully accept app permissions without really caring about it. It's not ideal, but Google/Android could have simply made a separate permission for bluetooth beacons instead of piggybacking on FINE_LOCATION, and have had several years to do so, yet have not chosen to do so. Every now and then there's some tech-blog outrage piece that gets into mainstream media about how "[social media] app is always listening because it asks for mic permissions" and lots of otherwise privacy conscious people just kinda shrug and carry on with it.
Bit different with a government-backed app, I know. Which is why I'm glad the infosec community will be tearing into this - it's one thing open-sourcing the code, and I trust NHSX themselves, but for all we know it's been intercepted by GHCQ on its way to the app stores...
Disclosure: nah, I don't have anything to do with the app, though my last 3 comments on HN have been defending it. Working in a research council, I just like seeing civil service software projects done in-house. The NHS has suffered horrifically in the past from putting out IT/software contracts out to tender to private companies, horrible waterfall dev, millions of pounds wasted. Stuff like NHSX, the team behind uk.gov and the parliament petitions site are a breath of fresh air, and I'd like it to be future proof that no you don't need to outsource everything to private companies, cough cough like trusting Google and Apple's "decentralised" (how is it decentralised??? There's no p2p networking, you're still eventually uploading data to their private databases...) approach.
Outsourcing stuff to private companies is how the current gov have completely fucked this whole thing up, after all.
To add to this, I think that this is where the "keepalive" feature kicks in too - it seems to me that, on the whole, even sporadic proximity to other devices should keep the system working. When device A sees device B (via advertisement), it does the usual ping. This prods the app on device B, keeping it slightly in the foreground again. Device B then has the ability to prod device A via the keepalive mechanism, and so on...
That means that this momentary contact should keep both devices "more awake". As you say, it's the bigger picture that matters, and if this reduces the "edge cases" to 0.1% of occurrences, that's a load better than the alternative (Australian approach). Important to also benchmark this with the reality that many people don't have a phone with BLE, or won't install the app. And yet an app may still work and help, even with non-universal adoption.
> Google/Android could have simply made a separate permission for bluetooth beacons instead of piggybacking on FINE_LOCATION, and have had several years to do so
Absolutely. I fear they lack incentive/motivation to fix permissions. Android's permissions system is mostly still inherited from the original version seen on Cupcake (Android 1.5) in 2009! Only recently did we see any granularity (i.e. the ability to allow location when an app was open)!
Only recently is scoped storage really kicking off on Android. There's still no proper scoping of contacts. That Bluetooth is not a separate permission has its relics back in old Android, before BLE beacons and similar existed. Someone clearly realised Bluetooth beacons could be used for locating people, so said "someone could scan for Bluetooth devices and work out the device location from beacons" and threw this under the location permission, as it could leak location. The obvious issue is that granting "location" permission gives access to network and GPS location. The old Android model had "fine" and "coase" location; not sure if that's died out.
It's in Google's interests not to make permissions too granular on Android however - they and their clients (advertisers) benefit from lead tracking, SDKs having access to advertising IDs, and having ability to easily access a user's contacts and data with minimal restraint etc.
Clearly there's a usability trade-off, but the Apple model of pushing people to use a "select which photo you want to let this app get" is probably better than letting apps access all photos, for example.
> It's one thing open-sourcing the code, and I trust NHSX themselves, but for all we know it's been intercepted by GHCQ on its way to the app stores...
Fortunately, this is fairly easy to address by comparing the app (fetched via the store from your device) against the source. The Android app isn't obfuscated at all that I can see - it's pretty straightforward to compare the Kotlin to the "reversed" Java, though admittedly not quite as easy as comparing Java to "reversed Java".
RE NCSC being involved in the project, from what I've seen their brief has been to try to ensure the app can't be taken advantage of by external adversaries like nation-state attackers looking to cause panic or unnecessary concern over exposure that didn't happen. For the most-part, it seems they have done a good job at this app. It's withstood the first 24 hours of scrutiny, but as always, time will tell. It also seems NCSC helped work around the iOS BLE background "hidden broadcasting" and finding a way for Android to be able to reach devices in this state.
Can anyone confirm this?
There's fear of people trolling this service by maliciously marking themselves positive, potentially forcing others to self-isolate repeatedly, perhaps without pay.
I wouldn't say it's better/worse than Apple/Google, but it did have the advantage of not building policy into the design. If the A/G policy is wrong/not enough, the whole thing delivers little value.
In the "Google/Apple" decentralised approach, someone who is infected submits a list of their own historical identifiers, and this is broadcast to everyone to check against their own observation list.
All you can really do is, on the client side, count up the number of occurrences of "infected" identifiers, and trip a client-side threshold for "after X contact instances, alert the user". You could get fancy and make X tweakable by the health service via that routine check-in for a new infected person list.
This is basically calculating the risk to someone.
The issue with this approach is that you have to create an public(ish) "infected" register. And even if it's not officially public, it takes 2 minutes to extract the API keys needed to fetch it, and a further 2 minutes to write and post a cron script to check the list into a git repo hourly.
In the NHS approach, there's no big "infected list" you can look at, or publicise. If you spend time with someone, you can't get an identifier that will let you (forever more) determine if they test positive from the "infected list". This raises the privacy for someone who is infected. While some may think "well, I am not infected, they can lose privacy", the system only works if people feel willing to report symptoms or infection without repercussions. So privacy of the infected is important!
Since the "upload" you make if infected or experiencing symptoms is of a list of other users you (the suspected infected person) saw, this makes it possible to look at the "risk from" aspect of infection - the hypothesis is that you can give advice to the potentially exposed users, based on their risk from you. And that can include how many infected people you were exposed to.
When someone has symptoms and is told to isolate, some people they were in contact with might be told to as well. The NHS app approach will survey them regularly (daily?) about symptoms. This data is fed back in to determine, based on those you might have infected, whether you actually have the virus. When you have a meaningful sample, and none have symptoms after a certain date, this allows you to let people out of self-isolation sooner, at least in theory.
The final point that is relevant is that the NHS believes it is essential to gather "self reports" for an app to work - if we assume an approx. 5 day mean/median incubation period, and if the research suggesting someone is most infective a day or two before symptoms is true, this means at the first sign of symptoms, you need to isolate someone and those they may have infected. Waiting for a test + result would mean you're potentially leaving people in the community, unaware, at their "most infectious" day or two.
Clearly there's risks of "Sybil" attacks. But as per the NCSC paper, there's been quite a bit of thought put into this design. More than I think many realise.