客户端扫描：APK 验证能证明什么

客户端扫描会检查用户设备上的内容，而这些内容在发送之前或接收之后可能已处于可读状态。因此，它可能在加密投递通道之外形成信息泄露路径。比较 APK 校验和并不能证明应用不含扫描代码。 它回答的是一个更有限的问题：所选字节是否与某个特定摘要匹配。

将这些主张区分开来，能让加密和软件验证都更有价值。

为什么设备上的扫描会改变隐私边界

应用必须处理明文，才能显示消息或准备要发送的照片。扫描功能可以在这一环节运行，即使随后通过网络发送的消息采用了端到端加密。哪些信息会离开设备，取决于扫描器的设计：它可能报告匹配结果、上传选定内容，或发送其他派生信息。

研究论文 Bugs in our Pockets 探讨了滥用、误报和新增攻击面等风险。这些风险说明有必要检查拟议扫描系统的数据流和治理方式。但它们并不能证明每一种设备端功能都是监控，也不能证明某项法律已经施加普遍的扫描要求。

由用户控制的本地功能，并不自动等同于强制报告。应询问由谁选择分析方式、什么会触发分析、谁能更新其规则，以及哪些数据可以离开设备。

Android 的 apksigner 文档解释了软件包验证和证书信息报告。可复现构建的定义则解释了为什么在复现构建产物时，源代码、构建环境和操作说明都很重要。

仅有一份源代码归档，以及印在它旁边的校验和，并不构成可复现构建结果。同样，恶意版本上的有效签名，依然是有效签名。

首先确定要获取的发布版本，并通过可信的分发途径取得 APK 和预期摘要。在本地计算摘要。如果不一致，在差异尚未解释清楚之前不要安装文件：不同版本、下载不完整或篡改，都可能导致不匹配。

如果匹配，请记录发布版本和结果。你证明的是文件字节与该参考值一致，而不是不存在客户端扫描。如果同一个攻击者能同时替换下载文件和显示的校验和，比较仍然可能通过。独立参考信息、签名密钥的连续性和发布透明度，有助于处理这一信任问题的不同部分。

对于源代码与二进制对应的主张，应寻找针对实际发布版本的构建说明文档和独立复现结果。不要仅凭“开源”二字推断它具备这种属性。

软件分发可能遭到攻击，但无限期回避安全更新并不是可靠的通用防御方式。更新也会修复可被利用的漏洞。请使用可信的更新渠道，阅读有实质内容的安全公告，并在你的风险状况有此需要时验证发布证据。一个存在已知缺陷的旧版本，不会仅因为校验和曾经匹配就更加安全。

Livara 的 Proof Lab 提供本地 APK 摘要比较和浏览器密码学演示。该页面明确表示，它不运行完整的 LVR1/LGS1 棘轮机制，也不构成协议审计。其威胁模型还解释了攻击者能同时替换文件及其预期摘要时的局限。

这些检查在其范围内是有用的。但它们不能证明安装应用的手机没有恶意软件，不能证明 Livara 拥有可独立复现的发布版本，也不能证明其应用不可能包含未披露的行为。有关所声称的消息保护边界，请另行阅读安全文档。

正确的问题不是某个徽章是否写着“已验证”，而是：测试了哪项主张，以哪个可信参考为依据，针对的是哪个确切的发布版本。