LWN: 开源的密切接触者追踪app，第二部分！

关注

转载最新推荐文章于 2026-11-08 21:13:07 发布 1k 阅读 AI 写同款· GEO 优化 ›

一次实时数据链路丢数排查：从 MQTT 队列积压到 SQL 统计开销本文通过一次实时数据链路压测，排查了从MQTT到ClickHouse的端到端数据丢失问题。核心方法是为每条消息添加序号，建立独立观察点（MQTT订阅端、Kafka消费者），结合转发服务阶段统计与线程栈分析，定位到下游处理速度不足源于Druid SQL合并统计的高开销。优化措施包括关闭SQL合并、扩容代理队列、增强生产侧失败处理，并验证15分钟内实现全链路对账一致，显著缓解积压与丢包。关键收获：数据可对账、明确各阶段“成功”定义、关注客户端队列状态。阅读详情

关注了就能看到更多这么棒的文章哦～

Open-source contact tracing, part 2

July 20, 2020This article was contributed by Marta Rybczyńskahttps://lwn.net/Articles/825992/DeepL assisted this translation

接触者追踪（contact tracing）是一种帮助防止疾病（例如 COVID-19）传播的方法，通过识别感染者曾经接触过哪些人，通知他们知晓自己的感染风险。在本系列的第一部分中，我们介绍了为应对当前流行病而开发的开源接触者追踪应用程序，并介绍了它们的工作原理。在这一部分中，我们将探讨其中一些集中式和分散式设计方案的细节。这些应用项目都公布了他们的源代码，但他们在实现细节、使用的许可证（license）以及是否接受用户的请求或 patch 等方面各有不同。文章的最后，我们将围绕这类追踪应用的争议以及应对措施进行总结。

TraceTogether/OpenTrace(Singapore)

2020 年 3 月，第一款接触者的追踪应用发布，它就是新加坡的 TraceTogether。截至 2020 年 7 月初，在仅约 580 万人口的新加坡，这个应用的下载量已超过 210 万次。这款应用使用了一个名为 BlueTrace 的协议。改名为 OpenTrace 后发布了该协议的参考实现；它提供了 Android 和 iOS 应用以及服务器部分的代码。所有这些代码都是在 GPL v3 下发布的。

初次发布后，Git 仓库似乎很安静，比如说，算上 Android 的应用程序，总共也只有 5 个提交。看起来很有可能是 public 的代码和 private 代码走向了不同的分支。在我们分析 Frank Liauw 的二进制 TraceTogether 应用程序，并将结果与 OpenTrace 源代码进行比较时，这一点似乎得到了证实。例如，OpenTrace 有着相同的数据库结构，但并不包含 TraceTogether 中的更新。这意味着安装的应用与发布的源代码并不一致，这可能意味着应用程序里的一些隐私特性发生了变化。

除了源代码之外，设计文档中还描述了协议的主要思想和细节。用户通过其手机号码进行身份确认，全局和临时 ID 都由中心服务器生成。应用程序可以提前下载批量的临时 ID，以便继续离线工作。近距离追踪是通过蓝牙完成的，BlueTrace 协议中会发送手机型号（用于距离校准），以及临时 ID。

该应用会记录所有相遇事件（根据临时 ID 来判断），而不会按距离进行过滤。它们被存储在用户的手机中。当此人被感染时，卫生当局会联系他们上传数据。然后，卫生部门会对联络记录进行处理，找出可能存在风险的人，并通过电话联系他们。每个用户都可以要求删除他们存储在服务器上的所有数据（包括全球 ID 和电话号码），但他们需要通过电子邮件提出要求。

由于 TraceTogether 是第一款应用，该项目面临着一些挑战。其中最主要的是使用蓝牙进行距离估算比较困难，因为不同手机的信号强度不同，所以需要进行校准，根据测量值获得实际距离。项目组公布了其所做实验的详细说明和获得的数据（https://github.com/opentrace-community/opentrace-calibration/blob/master/Trial%20Methodologies.md）。

2020 年 6 月初，新加坡部长 Vivian Balakrishnan 宣布了一款独立的令牌设备（token device），名为 TraceTogether Token。它不使用互联网连接，但可以与 TraceTogether 手机应用互通。该令牌的目的是帮助没有智能手机的人，以及 iPhone 用户（因为 iPhone app 必须保持在前台才有效——不过这一点在 TraceTogether 2.1 版本中得到了 fix）。在 2020 年 6 月的最后一周，开始在老年公民中发放这种令牌设备。

令牌会广播它的临时 ID，并记录它遇到过的其他 ID。如果用户被感染，他们会被要求将设备交给卫生部门，以便导出数据。在发布之前，该设备本身被提交给了一组专家。在这些专家中的一位 Andrew "bunnie" Huang 给出了他对这个令牌设备的印象。总之由于担心隐私问题，他赞成使用令牌而不是智能手机和应用程序来进行联系人追踪。此外，Sean "xobs" Cross 也出席了会议，他在演讲中给出了检查设备和观察设备拆解的过程的技术细节，由此他得出结论，该设备在硬件方面不太可能隐藏任何令人不快的硬件功能。

BlueTrace 协议已经过修改，方便令牌使用全局 ID 和时间的 Hash 值自行生成临时 ID，而不是从中央服务器下载。其他的变化旨在降低功耗，令牌会广播临时 ID，而不是与对端进行双向连接。截至 2020 年 7 月初，firmware 的源代码和协议的改动细节都还没有公布。Cross 和 Huang 注意到，该令牌的设计与他们的 Simmel 硬件令牌相当相似，也是用于联系人追踪；Simmel 的细节可在 GitHub 上获得，包括软件和硬件都有提供。

COVIDSafe（Australia）

COVIDSafe 是一款基于 OpenTrace 的澳大利亚应用程序。维基百科页面有关于 COVIDSafe 的更多信息。它使用类似 BlueTrace 的系统进行近距离追踪。Android 和 iOS 应用的源代码已经发布，但服务器端代码没有发布出来。自从发布以来，代码一直在更新；有少量的提交，看起来是其他地方正在进行的开发被汇总之后提交在这里，它们包含了应用程序的多个版本。

COVIDSafe 和 OpenTrace 的区别集中在用户的隐私方面。例如，用户可以在应用内删除存储的关于他们的数据，而新加坡的应用则没有这种功能。

COVIDSafe 的 license 中的条款与一般的开源项目有很大区别。它使用的是自定义许可证，这不是一个自由软件许可证，因为它包括以下几点要求：

I agree to stop all access and use of the App Code if requested by the DTA [Digital Transformation Authority of the Australian Government].
I will not use the App Code for any product development purposes.
(译文：
如果 DTA[澳大利亚政府数字转型局]提出要求，我同意停止对 App 代码的所有访问和使用。
我不会将 App 代码用于任何产品开发目的。
)

COVIDSafe 没有公开的 bug tracker。但是，由于它是基于 GPL 的 OpenTrace，所以在 OpenTrace 的 bug tracker 中有人提出了一个问题，即是否已经进行了正当的重新授权。新加坡政府有可能对 OpenTrace 代码进行了重新授权，但目前还没有回答这个问题。

澳大利亚政府一直在研究将 COVIDSafe 使用的框架改为暴露通知框架（Exposure Notification framework，Apple 和 Google 开发的一个项目），这在第一部分中已经介绍过，但在撰写本文时，还没有做出决定。

StopCovid（France）

StopCovid 是一款法国应用，于 2020 年 6 月初发布（含源代码）。在该应用的准备过程中，许多专业机构给出了建议。值得注意的是，其中至少有两个机构（数据隐私组织 CNIL 和计算机安全组织 ANSSI）建议将该应用的源代码作为开放源码发布。

该应用在法国引起了争论，特别是隐私问题方面。公众的主要担心是它可能根据收集到的数据查出人们的身份，比如感染者或可能感染过他们的人的身份。另一个担心是，这种监控可能成为永久性的措施。

此设计是一个中心化的设计，由中心服务器生成全局 ID。选择的是独立开发协议，不使用 Exposure Notification framework。

Android 和 iOS 应用的源代码，以及服务器软件的一些工具都可以直接使用。Android 和 iOS 应用是以 Mozilla Public License（MPL）发布的，这替代了源码中看到的 ad hoc restrictive license。服务器代码中的一部分使用 MPL 发布，部分使用 custom restrictive license 允许一年的访问并且只限于测试和科学评估。目前还不允许外部人员贡献代码，但预计将来会可以接受。

StopCovid 的开发者使用了假名（pseudonyms）。在一次关于假名透明度的讨论中，一位开发者透露，使用假名的原因之一是因为从事该应用的人受到了骚扰。

bug tracker 从一开始就有应用起来，其中既有包括错误报告也有开发团队的修复。例如，报告了一个问题，在感染的情况下，应用程序会发送完整的联系人列表，而它应该被手机过滤，只包括那些具有较高感染风险的人（至少 15 分钟的接触并且距离小于 1 米）。该问题在后续版本中得到了修复。

当用户安装应用程序时，界面上会显示解释以及跳转到隐私相关的 FAQ 的链接。他们可以在任何时候打开或停用该应用程序。还有一个选项可以直接从应用中删除他们在手机和服务器上的数据，但没有地方显示实际存储了哪些数据。

当用户被诊断为被感染时，他们的诊断结果将包括一个编码（二维码和和字母两种形式都有），以便在应用程序中使用。用户可以决定在应用程序中输入代码，或者选择不输入。输入代码将导致最近几天所有的密切接触者的临时 ID 被传输到中央服务器。这些其他用户将被应用程序通知，请他们咨询他们的医生。他们不会知道感染者是哪位。二维码是预先生成的，并分发给实验室，所以它们也不会链接到特定的用户。

StopCovid 应用程序的另一个有趣的方面是推出了一个错误赏金计划（bug bounty program），以帮助开发者找到更多的错误。

部署后的首批结果低于预期。前三周的激活数量约为 180 万，而总人口约为 6700 万。这个阶段中，有 68 人发出自己被诊断为阳性的信号（有 14 人被告知其曾经与患者密切接触过），与法国同期每天几百个确诊检测结果数字相比，这个比例很小。

Corona-Warn (Germany)

德国官方应用程序 Corona-Warn 于 6 月中旬发布，因为推出得太晚，政府受到了批评。同样也有人提出了隐私问题，有人质疑有多少人会真正下载它。自推出以来，在总共约 8300 万人口的国家中，它的下载量[德语]约为 1440 万次（截至 7 月 2 日）。

与新加坡和法国的应用有一点不同的是，它使用了 Exposure Notification framework 和去中心化的方式。ID 由用户的手机生成，只有在被感染时才会上传。而中央服务器则存储了感染者的 ID 数据库，所有应用都会定期下载。应用程序会进行检查看是否有匹配的人，如果有匹配的人，会向用户显示通知。

所有的源代码都是在 GitHub 上使用 Apache-2.0 许可证发布的，项目网站的副标题写明了 "Open Source Project"。Corona-Warn 可以接受外部人员的代码，它有一个贡献指南和行为准则。其开发相当活跃，从最近的提交情况来看，以 Android 应用为例，截止到 7 月 3 日，已经有近 400 个提交。看起来部分开发工作是用其他的 source tree 来进行的，然后以少量很大的 commit 来提交上来。

它的 bug tracker 上面非常繁忙，有些问题引起了长时间的讨论，比如只向德国 Google Play 账户提供应用。当初这个 app 曾经导致从其他国家搬过来的人无法使用此应用，在其他欧盟国家工作和生活的人也同样无法使用。好在这个问题已经解决了。

Controversies

Covid-19 的这些追踪应用面临着多种争议。一个大问题是它们对用户隐私的影响。其他的技术挑战包括：需要使用该应用的人口比例够高才能使其产生价值；应用商店中一些有害 "类似 "应用会带来的风险，以及距离测量的准确性。

最大的顾虑可能还是对隐私的影响，以及位置数据被用于其他监控的风险。另外还有数据泄露和被第三方恶意使用的风险。关于应用的安全分析有很多论文，包括 DP3T 白皮书和 ROBERT protocol specification（法国应用所使用的协议）。我们在本文中只介绍主要概念，以及所提到的应用采取的措施。有兴趣的读者请查看研究论文中的细节。

所有的系统都不会广播自己的全局 ID，只发送临时 ID（每十到二十分钟变化一次）。对未感染和未处于风险中（未与任何感染者接触）的用户进行追踪的风险应该是很小的。并且也没有获取绝对位置数据，所有的应用都只是使用蓝牙来测量距离。

对于感染者的记录则是有区别的。在集中式和分散式系统中，感染者的整个日志都会被上传到单个服务器上，所以有可能根据这些数据能识别出他是谁。在集中式系统中，服务器还可能有额外的信息来识别用户的身份（如电话号码），因此中央服务器必须是可信的。此外，还有一个问题，就是大流行后数据库是否会被删除。在分布式系统方案中，服务器没有更多的信息，但所有设备上都有整个感染者的 ID 数据库。

然而，另一个身份信息泄漏的来源可能是近距离协议。某些协议(例如 OpenTrace)会广播手机型号信息，这可能被用于识别目的，特别是如果用的是那些不太流行的型号的话就容易被确定出来他是谁。如果有位置数据的话，也可能确定出用户身份。通常情况下，协议不会上传这些数据。然而，攻击者可以嗅探周围的 ID 并将其与位置信息一起存储下来。不过这种攻击可以通过定期更换 ID 来尽量减少它的影响，这里提到的所有应用都做了这件事。

商店中的有害应用，在一定程度上可以通过 Exposure Notification framework 来管控起来，每个国家只允许一个应用在应用描述中包括特殊信息。对于没有使用这个 API 的应用，用户需要注意官方应用的名称和发布机构。应用商店已经做了一些尝试以改善这个乱摊子，但用户必须小心，只安装所在地区的官方应用。

另一个重要的挑战是应用的有效性。目前可用的数量相当少，而且应用通常只覆盖一小部分人群。

Conclusions

接触者追踪应用在短短几个月内就取得了很大的发展。其中一些应用程序仍在开发中。我们还没有数据表明它们的实际效果如何，以及在大流行期间将发现多少病例。这些数据要在一段时间后才能获得。

从 open-source 的角度来看，很有意思的是，许多这类应用确实是使用这种模式发布的，而且从安全的角度来看，它已经被推荐为最佳实践之一。然而，项目的开发进程总是公开的，项目的管理也是集中性的。拥有活跃的 bug tracker 的项目（Corona-Warn，StopCovid）确实依赖于用户的参与，不过我们希望它们的开发更加开放。

目前这些应用互相之间并不兼容。开发团队已经从早期部署的经验中吸取了教训，但开发工作仍然是有许多重复。欧洲正在进行一些工作想统一起来，但目前还看不到效果。Exposure Notification API 成为了最近这些发布出来的应用的标准框架。

contact-tracing app 的最终效果还远未可知。幸运的是，它们大多发布了源代码，独立专家可能会对它们进行分析。最后，用户要考虑到可能的风险和收益来决定是否要使用这些应用。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～