- 与澳大利亚的 COVIDSafe 应用不同，NHS COVID-19 应用在 iOS 设备上于后台运行时似乎能正常工作
- 该应用通过向出现症状的用户提供参考码来防止虚假报告：在采取行动之前，该参考码会与正式的检测结果相关联
- NHS COVID-19 指示医护人员在穿戴个人防护装备（PPE）期间关闭设备的蓝牙，并解释说：“your interactions at work should not be captured when you are wearing PPE”
- 更新：英国夏令时 5 月 7 日 09:25：我们在下方新增了“这款应用究竟如何做到在后台保持有效？”一节，解释了该应用在与 Android 设备通信时如何保持存活，并介绍了 iOS 到 iOS 通信中的一些挑战和技术
- 更新：英国夏令时 5 月 7 日 11:45：我们在下方新增了“这款应用会收集个人数据并泄露我的身份吗？”一节。
当应用不显示在屏幕上时，接触者追踪面临的挑战
当应用不在用户设备的最前台时，开发者让应用保持“存活”的选择寥寥无几。Apple 小心地管理这些选项，以确保应用不会侵犯用户隐私，也不会过度消耗用户的电池。具体来说，他们区分应用是否拥有焦点（即是否显示在屏幕上），还是在后台运行。iOS 最近的更新限制了开发者在后台访问数据的能力：例如，在能够如此有效地限制后台数据收集之前，Uber 甚至在用户不在出租车上时也能追踪用户的行踪。
要想在后台以有意义的方式运行，应用的发布者在向 App Store 提交应用时，需要通过标记一组“Background Modes”来获得 Apple 的许可。这些后台模式仅限用于从一台设备向另一台设备传输视频、收集位置更新、充当电话或使用蓝牙。例如，正是这些模式让你的手机能在后台运行 AirPlay，在 Spotify 不一直显示在前台的情况下播放音乐，用 WhatsApp 给别人打电话后再把它放到后台，或者用 Strava 记录你的跑步。
NHS COVID-19 应用
不过，这些模式是有限的，用户可能对 iPhone 上询问是否允许应用在后台访问你的位置的通知并不陌生。即使用户授予了这些权限，手机也可能继续请求确认这样做是否正确。
接触者追踪应用基于低功耗蓝牙（BLE）构建，简单来说，它让设备能够互相识别。从理论上讲，Apple 的“Uses Bluetooth LE accessories”和“Acts as a Bluetooth LE accessory”模式非常适合这一用途，并允许在后台使用 BLE。然而，虽然使用这些模式的后台应用能够继续与它已经在通信的任何 BLE 设备（例如蓝牙智能门锁）通信，但它无法控制广播速率，去轮询它此前没有见过的设备。在后台时，这使得寻找新设备的迹象、与它们进行有意义的通信，尤其是识别非 Apple 设备变得更加困难。这相当程度上妨碍了必须在后台持续运行的接触者追踪应用。
引用 Apple 的该服务文档：
All service UUIDs ... can be discovered only by an iOS device that is explicitly scanning for them. ...and for apps that are advertising are in the background, the frequency at which your peripheral device sends advertising packets may decrease
追踪的变通办法和替代方案
当然，这对开发者来说并不是新的挑战：他们长期以来一直在设法让应用保持在后台并收集受限的追踪数据。开源的 AltBeacons 等框架应运而生，试图解决这个问题，但它们并不适用于接触者追踪，因为设备必须持续寻找新设备。正如 ABC 在澳大利亚发现的，在研究其全国性的 COVIDSafe 应用时，对此还没有切实可行的解决方案。有一些漏洞利用方式或许可以暂时派上用场，比如把自己的应用注册为音频播放器并让它播放音乐，但这类做法以及其他同类做法都为 Apple 所不齿，可能给用户带来不便，也很少能通过 App Store 的审核。
与此同时，Apple 一直在准备发布 iOS 13.5，目前已有测试版。Apple 能够对自己的系统做出有利于这种追踪的改动。13.5 将带来一些更显眼的功能，例如为戴口罩的用户提供 FaceID 支持，或者至少提供更快捷的输入密码的途径，也会带来一些不那么显眼的功能，比如 ExposureNotification 框架，它正好提供了接触者追踪应用所需要的能力。当然，这不会形成完美的系统：并非每位用户都能受益，因为像 iPhone 6（2015 年）这样的设备无法运行 iOS 13。虽然 Apple 的系统使用全球标准的标识符，但每个实施它的国家都使用各自独立的国家数据库。因此，如果一名来自某国的受感染欧洲人接触了另一个欧洲国家的公民，他们不会通过接触者追踪发现这一点。
Apple 的 COVID-19 ExposureNotification 为这里的需求提供了解决方案，但也有一些前提。最重要的是，Apple 已表示只有他们自己的应用才能使用它，以防止其他人滥用这项技术。
那么 NHS 是如何用他们的 COVID-19 应用 做到的呢？
那么，英国的 NHS COVID-19 如何能够在后台有效追踪新设备，同时又不会“睡着”（技术上称为“被挂起”）而失去效力呢？从我们对“NHS COVID-19”应用 1.0.1b341 版本的测试来看，它确实能在后台有效通信。这似乎是通过一系列使用保活信号和通知的巧妙变通办法实现的。
强制退出应用将停止后台追踪，不过，如果改为将手机关机再开机，它会继续在后台正常通信。这种变通办法是否会触犯 Apple 的规定，目前尚不确定，但到目前为止它尚未被披露，而且 Apple 已经批准了他们所见过的该应用的各个构建版本。
我们将继续研究此事，并随着情况发展发布更多细节。
NHS COVID-19 应用会存储敏感数据吗？
不会。这款应用的构建似乎非常出色，采用了合理的安全做法，也没有存储不必要的数据。它围绕着为应用的每次安装生成的 linkingId 展开。这个 ID 在应用重新安装后依然保留，因此卸载再重新安装并不会重置该标识符。
用 iPhone Backup Extractor 查看 uk.nhs.nhsx.sonar 路径下该应用的数据，可以看到有一系列与 Google Firebase 相关的文件，以及一批小型 Plist（配置文件），用来存放应用的其余数据。
在备份中查看 NHS COVID-19 应用的文件
用户可以虚假地自行报告自己感染了 COVID-19 吗？
如果用户报告了症状，应用会提供一个可拨打以安排检测的号码，以及一个参考码。其思路是，检测结果随后会与用户的参考码相关联。如果用户虚假报告症状，在 NHS 把检测结果更新为与用户的代码相匹配之前，确认是不会发生的。
这款应用会请求位置权限吗？
不会。
NHS 在使用 Google API 的问题上误导了公众吗？
没有。NHS COVID-19 应用与 Google 业界标准的 Firebase API 深度集成，用于数据存储和管理。（NHS 并未使用 Google 或 Apple 的接触者追踪框架；且不说别的，在 iOS 13.5 发布之前，该框架都无法使用。）
这款应用与哪些服务通信？
与 Android 应用一样，所有重要的通信都通过 NHS 的 COVID19 API 进行，该 API 托管在 *.covid19.nhs.uk 之下。由于使用了 Microsoft 的 AppCenter 服务，应用还发出了一些其他请求，但都不涉及重要或敏感内容。
如果 NHS 工作人员使用这款应用，不会导致误报吗？
该应用会提示医护人员在穿戴 PPE 期间关闭设备上的蓝牙，并表示：“your interactions at work should not be captured when you are wearing personal protective equipment”。
NHS COVID-19 应用的 PPE 蓝牙提示
我们很高兴能更深入地研究 NHS 的 COVID-19 应用。虽然外界对它的功能有很多猜测，但我们所看到的是一款构建完善、安全的应用。后台追踪似乎有效，不过这能否持续有效，仍然完全取决于 Apple。因此，英国抗击 COVID-19 的成效，现在也掌握在 Apple 手中。
是单打独斗还是使用 Apple 的框架，这个选择想必很艰难。追随 Apple 的步伐，可能会是争议较小的选择。然而，iOS 13.5 尚未发布，而英国的应用明天就会以测试版发布，而且没有什么能阻止英国在后续更新中转而追随 Apple。从这个角度来看，为什么不先在怀特岛发布一次试点呢？
这款应用究竟如何做到在后台保持有效？
我们在 5 月 7 日英国夏令时 09:25 加入了这个回答，以解答我们收到的关于应用保持存活的具体细节的问题。NHSX 在这里采用了一些巧妙的技术来取得更好的效果。
The Sun 昨晚报道称该应用使用了私有蓝牙 API，但我们没有看到任何迹象，而且他们此后已修改报道，撤回了这一断言。NHS COVID-19 应用使用的是 iOS 中的公开蓝牙 API，似乎没有利用任何特殊权限。相反，它用了一些巧妙的技术。
第一种技术是针对 iOS 对挂起应用的蓝牙行为而设计的。我们注意到，Apple 会改变应用在挂起时扫描新设备的方式。挂起的应用无法正确识别它们此前没有见过的设备。正如我们在上文所写，这会使应用“更难寻找新设备的迹象、与它们进行有意义的通信，尤其是识别非 Apple 设备”。
NHSX 以相反的方式应对非 Apple 设备的挑战：他们意识到自己无法影响 iOS 在这方面的行为，于是在 Android 应用中构建了一些巧妙的功能，用来识别 iOS 设备上的后台应用会发出的那些受限的、Apple 特有的消息。这让 Android 设备获得了足够的信息，能够与 iOS 设备对话，把它重新唤醒到可以通信的状态。
没有 Android 时，情况略有不同：NHS COVID-19 应用在后台停留一段时间后，存在一个可能静默的阈值，设备日志中也能看到这方面的例子。在这种情况下，应用已被推到后台，但仍能继续扫描（技术上称为“广播”）一个半小时以上。手机上的其他事件，包括其他使用蓝牙的应用，可能会延长这段时间。
Session uk.nhs.nhsx.sonar-peripheral-11919-319 can advertise in background for 6240 seconds
因此，不可能说“应用在经过 X 段时间后，在 iOS 到 iOS 的通信中会失效”：应用有一个宽裕的可变窗口来保持存活，而且有一些合理的因素可以触发该窗口被延长，包括蓝牙的其他用途、Android 设备的存在，以及通知的有效性。
在一些不太常见的情况下，iOS 可能会尝试完全挂起后台应用，例如系统内存不足时。发生这种情况时，服务的可靠性会受到影响。应用试图通过触发推送通知，请求用户重新打开应用来解决这个问题，但这并不总是奏效，具体取决于设备的状态。在我们的测试中，运行该应用的 iOS 设备都在夜间持续保持着后台服务的运行。
这款应用会收集个人数据并泄露我的身份吗？
我们在 5 月 7 日英国夏令时 11:45 加入了这个回答，以解答我们收到的关于应用收集和传输数据的问题
iOS 应用捕获的数据真的非常少：一切都围绕着用户的 linkingId。只有当用户报告症状，并使用该 ID 与 NHS 安排检测时，这个 ID 才可能与某个人联系起来。
检测结果呈阳性并与某个 ID 编码在一起，实际上就是触发追踪警报的机制。那么问题在于，NHS 是否会在中央层面，把检测时收集的个人详细信息与该 ID 一并存储。这对应用的运作来说并非必要，也不是应用本身固有的部分。正如我们之前所写，除了用户邮政编码的前几位数字（由用户在设置时输入，且不经验证）之外，应用无法访问位置数据。
因此，这里的问题不在于应用存储了什么，而在于 NHS 在预约检测时索取哪些信息，以及这些信息是如何存储的。
如果用户报告了症状，却没有安排检测（或者安排检测时没有提供其 ID），这两类信息就绝对无法关联起来。当然，在这种极端情形下，这也会让应用无法在用户感染 COVID-19 时发出提醒。
我们将继续研究此事，并随着情况发展发布更多细节。
