> 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.
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.