Android 可能很快会限制设备内 ADB

原文 ↗ Hacker News 讨论 ↗

Google 看起来正准备限制 Android 的设备内 ADB（调试桥）——这个功能常被 Shizuku 等工具用来在不 root 的情况下给应用更高权限——许多人将其视为平台不断加锁趋势的一部分。评论者认为真正受益的是 Google 和大型应用厂商，并以广告拦截打压、侧载延迟、远程证明以及 Play Services 级别控制为例，指出“安全”被用来为更强控制和更少用户自由正名。少数人反驳说，移除这些隐蔽且高风险的能力有助于保护非技术用户免受恶意软件和 stalkerware 的伤害，但他们也承认，Google 几乎没有为这些变更会破坏的高级用户和开发者工作流提供官方替代方案。

正在讨论的变更

  • 这条讨论围绕 Google 的一个问题展开：一名员工建议将无线 ADB 限制在特定接口上（例如 wlan0），因为应用可以连接到 localhost 并提升权限。
  • 这会影响“设备内 ADB”的使用（手机上的应用通过回环接口与 ADB 通信），而这正是 Shizuku、通话录音器以及其他高级用户工具所依赖的。
  • 有人指出，这源于 ADB TLS 认证中的一个真实 CVE，相关问题已经修补；而这个回环限制是一个额外的后续想法，并不是最终决定。

安全理由与 CVE 背景

  • 支持变更的论点：
    • ADB 是一个强大的调试端口；允许应用借道它会绕过 Android 的权限模型，应被视为漏洞。
    • 僵尸网络（例如通过 proxyware 和不安全的电视盒子）以及 stalkerware 可能滥用开放的 ADB 或提权 API 来窃取数据。
    • 很多用户会照着他们并不理解的危险分步教程去做；默认设置必须保护他们。
  • 反对观点：
    • 利用设备内 ADB 通常需要多个明确的用户操作（启用开发者模式、启用 ADB over TCP、接受密钥），因此对“普通”用户的风险较低。
    • 现有恶意软件更容易滥用辅助功能、设备管理员以及广泛的应用权限。

批评：控制 vs 用户自由

  • 很大一部分人认为这是一种更广泛模式的一部分：Chrome 的 Manifest V3、更严格的侧载（24 小时延迟）、Play Integrity/证明、recaptcha 证明等。
  • 观点是：“安全”被用来：
    • 将设备对拥有者本身锁得更严，阻止广告拦截和通话录音，并强化 DRM/银行/内容利益。
    • 迫使所有人通过 Play 商店和 Google 服务，把 Android 变成类似 iOS 的围墙花园。
  • 也有人回应说，Android 的多方安全模型明确赋予应用与用户一样多的自主性；如果你想要不同的权衡，就该使用替代操作系统。

对开发者与高级用户的影响

  • 设备内 ADB 被用作一种最后手段的 API，用于操作系统不愿公开的事情：高级显示控制、更细粒度的 AppOps、通话录音、自动化、无 root 隐私工具。
  • 如果不提供替代方案就移除回环 ADB，会破坏非 root 设备上的这些工作流，并迫使开发者转向更脆弱的黑客式方案。
  • 也有人认为 ADB 本来就不是为这些用途设计的，正确的做法是添加合适的 API。

非技术用户、诈骗与 stalkerware

  • 一方强调真实伤害：亲属被诱导开启开发者选项或安装恶意 APK；具备广泛监控能力的 stalkerware。
  • 另一方反驳说，你不可能完全“工程化消除”社会工程攻击；如果把一切都锁得足够死来保护最不懂的人，就会毁掉所有人的可用性。
  • 有人建议用更醒目的、持续性的警告和“防蠢”模式，而不是直接移除。

替代方案与变通方法

  • 许多人提到或使用去 Google 化或替代系统：GrapheneOS、LineageOS、postmarketOS、Sailfish、Librem 5、PinePhone。
  • 但硬件支持面很窄，性能通常更差，而且关键应用（银行、交通、某些消息应用）越来越要求 Google 证明或 Play Services，这限制了实际可行性。
  • 有人建议自己构建并打补丁的定制 ROM，但也有人指出这会导致证明失败，并可能让你“无法使用银行服务”。

监管与更广泛的趋势

  • 普遍感觉是，如果 Google 继续收紧控制，技术上的绕过手段还不够；有人呼吁欧盟/美国反垄断，或行业特定规则（例如要求银行支持非手机或基于网页的认证）。
  • 也有人怀疑到目前为止罚款并未改变行为；有人把这看作朝着与身份证绑定、完全锁死的设备，以及一个分裂成“新网络”（可证明、付费才能进入）和只能从开放系统访问的“旧网络”的方向发展。