阿隆自留地

文章摘要

2025 年 11 月，谷歌宣布推行一项新政策：所有开发者如需在 Google Play 之外分发 Android 应用（包括自有网站、第三方应用商店、企业内部分发和直接传送 APK），都必须先向谷歌进行强制注册，内容包括：同意谷歌条款、支付费用，以及上传政府颁发的身份证明文件。

2026 年 2 月 24 日，以 EFF（电子前哨基金会）、Tor 项目、Proton、F-Droid、FSF（自由软件基金会）为代表的 37 个机构和组织联署了一封公开信，强烈要求谷歌撤回这一政策。签署方覆盖了数字权利倡导团体、开源软件项目、隐私工具开发者及独立软件公司。

这封信在 Hacker News 上引发了 407 点赞、325 条评论的热烈讨论，争议焦点集中在：谷歌的安全理由是否站得住脚？这一政策边界在哪里？如果允许单一公司管控平台外的所有软件分发，对软件生态的长期影响是什么？

背景与问题

Android 的「开放」并不是理所当然的

和 iOS 不同，Android 从设计上就允许用户从 Google Play 以外的来源安装应用，这被称为「sideloading」（侧载）。用户只需要在设置中开启一个选项，就可以直接安装 APK 文件——这和在 Windows 上双击 .exe 安装程序的逻辑是一样的。

这种开放性孕育了一个丰富的生态系统：F-Droid（全开源应用商店）、Aurora Store（Google Play 镜像，保护隐私）、Amazon Appstore（针对火棒设备）、以及大量直接提供 APK 下载的独立开发者。Signal、Telegram 都曾在 Google Play 之外提供过独立的 APK 下载，允许用户绕过 Google 的版本审核获得更快的更新。企业也广泛使用侧载来分发内部工具，避免把公司内部应用暴露在公开商店中。

谷歌 2025 年 11 月的公告改变了这一默认状态：它不是要完全禁止侧载，而是要求所有想通过侧载分发应用的开发者必须先向谷歌注册。注册要求：签署条款协议、支付费用、提交政府颁发的身份证件。

谷歌的官方理由是安全。他们描述了一个在东南亚非常普遍的诈骗手法：骗子冒充银行客服，欺骗用户安装「验证 App」，实际上是拦截二次验证码的恶意软件。谷歌的论点是：如果所有侧载 App 的开发者都需要用真实身份注册，诈骗者将无法快速批量生成新的恶意 App，从而打破「打鼹鼠」式的持续对抗。

这个理由听起来合理，但触发了一连串的反驳。

公开信的核心关切

联署公开信的 37 个机构列出了六个主要关切，简单梳理如下：

关切一：谷歌的管控边界从自家商店扩展到了整个 Android

谷歌有权管理 Google Play——没有人能强迫它接受任何应用。但这项政策要求开发者在自己的网站上、自己的服务器上分发应用，也需要向谷歌注册并获得许可。这相当于谷歌把 Play Store 的门卫权力延伸到了整个 Android 分发生态，而与谷歌服务毫无关系的人也必须向它汇报。

关切二：创新和多样性的门槛大幅提高

强制注册对以下群体影响最大：

资源有限的独立开发者和小团队
依赖志愿者贡献的开源项目
访问谷歌注册基础设施受限的地区（部分受制裁国家的开发者无法注册）
隐私保护型开发者——他们开发工具的本意就是不纳入监控体系
紧急响应组织（灾难救援软件需要快速部署）
在制裁地区或威权政府下工作的政治活动人士

关切三：隐私和监控风险

强制实名注册意味着谷歌将持有全球所有 Android 独立开发者的数据库，无论这些开发者是否使用谷歌的任何服务。这个数据库面临政府信息请求、数据泄露、以及谷歌自身将其用于商业分析的风险。

关切四：现有安全机制已经足够

Android 已有多层安全机制：沙盒、权限系统、用户安装警告、Google Play Protect（可选启用）、开发者签名证书。公开信认为，没有证据表明这些机制不足以保护用户——如果谷歌真的关心安全而不是控制，应该优化现有机制而非增加中心化注册节点。

关切五：单点失效风险

如果谷歌可以注销一个开发者的注册，那么这个开发者的所有 App 在所有「已认证」的 Android 设备上都将无法分发。一个公司错误、一个算法误判，或者基于政治/竞争考量的决定，就能全局封禁一个开发者的作品。这个权力过于集中，且缺乏有效的申诉机制。

关切六：反竞争隐患

谷歌可以获取所有 Android 开发活动的完整信息，包括竞争对手的产品开发动向、替代分发渠道的商业模式、与谷歌服务竞争的新应用。这种信息不对称赋予谷歌了解和抑制竞争威胁的预警能力。

核心内容解析

3.1 核心观点提取

1. 谷歌的安全案例在逻辑上有漏洞

谷歌描述的诈骗场景是真实的。在东南亚、非洲等 Android 占主导地位的地区，恶意 APK 诈骗确实造成了巨大损失。但对这个问题的分析，需要区分两件事：

目标受害者是技术不熟悉的普通用户，他们被欺骗安装了恶意 App
攻击载体是侧载——绕过 Play Store 安装

强制注册只影响开发者，不影响普通用户是否会被欺骗。一个已经上当的用户，他不知道也不在乎开发者有没有向谷歌注册。注册要求可能让诈骗者稍微麻烦一点（需要用新身份注册），但不会根本改变这个社会工程攻击的成功率。

HN 上一个值得关注的讨论分支提供了另一个视角：「如果真正的问题是「用户愿意按照陌生电话里的指示操作」，那么注册开发者数据库完全不是解法。实际有效的方法包括：更难绕过的安装警告、受信任的 App 白名单、更严格的高权限 API 审批，以及更好的用户教育。」

2. 现有机制确实有改进空间，但不需要中心化注册

公开信声称「现有机制已足够」，但这个说法过于绝对。Android 现有的安全机制有明显弱点：

安装警告容易被社工攻击者引导用户忽略
Google Play Protect 只有在谷歌服务框架存在时才能运行
侧载 App 的权限和沙盒保护与 Play Store 无异，本质上无法区分「正常侧载」和「恶意侧载」

谷歌的问题不在于它想解决这个安全问题，而在于它选择的解决方案恰好也给自己带来了大量权力——这让「安全理由」的纯粹性变得可疑。HN 上有人提出了更平衡的替代方案：

对特定高风险权限（拦截通知、读取短信）要求开发者注册，而不是对所有分发
实施冷却期（如 24 小时）才能安装新的侧载来源
要求「扩展验证」证书而不是政府 ID 注册
通过更好的 UI 解释高风险操作的含义

这些方案都能在一定程度上降低恶意软件风险，同时对正当开发者的负担远低于全面强制注册。

3. 政策的核心矛盾：安全还是管控？

公开信最犀利的一点是「谷歌现有的应用审核已因不透明、执行不一致和申诉机制不完善而饱受批评，把这套系统扩展到所有 Android 分发，只会将这些问题放大」。

这触及了这个问题的核心：不是说安全目标本身不合理，而是说谷歌作为执行者的可信度存疑——它同时是裁判员、是商店运营者、是竞争者，现在还要成为整个平台外分发的许可机构。

4. 「自由软件」在现实中的脆弱性

这件事也暴露了一个令人不安的现实：即使是鼓吹「开放」的 Android 生态，其开放性本质上也是谷歌可以随时收回的特权，而不是法律层面或技术层面的保障。在欧盟 DMA（数字市场法案）的压力下，苹果被迫开放了 iOS 的侧载——而谷歌如今似乎在走反方向。

相比之下，F-Droid 的逻辑是「根本不需要谷歌批准」，它是一个独立运行的、基于开源验证的应用分发基础设施。但 F-Droid 的运行依赖 Android 本身允许侧载，如果谷歌的政策进一步收紧到设备层面的强制验证，F-Droid 的生存空间将被彻底压缩。

5. 签署方的质量比数量更重要

37 个签署方里包括了 EFF、FSF、Tor 项目、Proton、F-Droid、/e/ 基金会、Nextcloud、Fastmail、自由软件基金会欧洲（FSFE）……这些不是随便找来凑数的小组织，它们代表了数字隐私和自由软件运动的核心机构。这封信的象征意义在于：整个数字权利生态已经把这个问题视为需要集体发声的重大政策边界事件。

3.2 技术深度分析

Android 侧载的实现机制

Android 上的侧载通过「未知来源」选项实现，在 Android 8.0 之后变为「按应用授权」——用户需要明确指定哪个应用（如文件管理器或浏览器）被允许安装 APK。安装过程中，系统会显示权限列表和安全警告，用户确认后安装。

APK 的安全性依赖开发者签名证书（developer signing certificates），每个 APK 都由开发者的私钥签名，系统会在安装时验证签名。这确立了软件的来源（你不能伪造另一个开发者的签名），并防止 APK 在传输过程中被篡改。

但签名证书解决的是「来源真实性」，不解决「来源是否可信」——任何人都可以生成一个自签名证书，用于分发恶意软件。电子邮件 S/MIME 证书解决这个问题的方式是依赖 CA（证书颁发机构）信任链；Android 目前没有要求 APK 签名证书来自任何可信 CA，只要求证书一致性（更新时签名不变）。

谷歌的「强制注册」政策，本质上是在这个机制上增加了一层：只有注册过的开发者的签名证书，才被认为是「可安装」的。这将谷歌变成了 Android 生态的 CA，而不是一个可选的应用商店。

Google Play Protect 在这里的角色

Google Play Protect 是 Android 设备上谷歌提供的恶意软件扫描服务，每天会扫描设备上的所有应用（包括侧载的），并与谷歌的恶意 App 数据库对比。它可以识别已知恶意软件，但对全新的恶意 App（「零日」样本）无能为力。

问题是：Play Protect 依赖谷歌服务框架（GMS），在 Google Play 之外分发的 Android（如线刷版的 AOSP）上并不可用。全球有相当数量的 Android 设备（据估计数亿台，主要在中国市场）没有安装谷歌服务框架，这些设备上的用户完全在 Play Protect 的保护范围之外，而谷歌的注册政策也无法覆盖这类设备。这本身就说明单纯的注册机制无法解决全球 Android 生态的安全问题。

DMA 与这一政策的潜在冲突

欧盟《数字市场法案》（DMA）要求被认定为「守门人」的平台提供更高的互操作性和开放性。在 iOS 上，苹果因为 DMA 被迫允许侧载。如果谷歌通过强制注册实质上限制了 Android 的侧载自由，欧盟监管机构有理由审查这一政策是否违反了 DMA 的精神——即使 Android 技术上从未完全禁止侧载。

公开信已经在这个方向埋下伏笔，提到「希望欧盟委员会、美国司法部和各司法管辖区的竞争监管机构关注这一问题」。

3.3 实践应用场景

场景一：F-Droid 的未来

F-Droid 是一个完全开源、不依赖谷歌服务的 Android 应用商店，专注于开源应用。它的工作方式是：接受开发者提交的源代码，由 F-Droid 自己编译为 APK，并用 F-Droid 的签名证书发布。这意味着在 F-Droid 上的 App，签名证书是 F-Droid 的，而不是原始开发者的。

如果谷歌的注册政策要求所有「非谷歌注册」的签名证书都被阻止，F-Droid 需要以组织身份注册，并且所有通过 F-Droid 分发的应用都会受到 F-Droid 注册状态的约束。这使得 F-Droid 成为了一个注册状态可以被撤销的单一控制节点——而这恰好是公开信所说的「单点失效风险」的一个具体体现。

场景二：企业内部应用分发

许多大型企业通过 MDM（移动设备管理）系统分发内部 Android 应用，这些应用通常用企业自己的证书签名，从公司内部服务器直接推送到员工设备，完全绕过 Google Play。如果这些企业也需要向谷歌强制注册，涉及政府机构、军队、医疗机构等的内部应用可能面临向商业公司强制披露存在的隐患。

企业通常通过 Android Enterprise 和 Google Workspace 管理设备，这部分可能会有豁免条款，但具体边界目前还不清楚。

场景三：开发者的应对策略

如果政策最终落地，有几个应对路径：

注册：注册成本和合规风险取决于你在哪个国家、谷歌如何执行政策，但对于大多数独立开发者这是最直接的路径
切换到 web app：PWA（渐进式 Web 应用）不需要侧载，可以在浏览器层面实现大多数移动端功能
使用替代发行渠道：F-Droid（如果它本身能继续运作）、或直接通过无谷歌服务的 LineageOS 等平台分发
专注 iOS：对于拒绝向谷歌提交身份证件的开发者，重心转向 iOS 并通过 AltStore 等工具利用 DMA 开放的 iOS 侧载渠道

深度分析与思考

4.1 价值与意义

这封公开信的意义，不只在于它是否能改变谷歌的决定，而在于它为公众理解「平台权力」划出了一条清晰的红线：当一个平台的控制权从自有商店延伸到平台外的所有分发渠道，「开放平台」就已名存实亡。

Android 作为全球约 70% 的移动操作系统，如果实施全面的开发者注册，其规模效应将产生全球性的影响——包括对所有依赖 Android 进行安全通信、规避威权审查的记者、活动人士、异见群体的影响。

4.2 对读者的实际应用价值

对 Android 开发者：密切关注这一政策的落地细节，特别是豁免条款的范围、申诉机制是否存在，以及是否要求实名证件。考虑将自己的 App 提交到 F-Droid 作为备选分发渠道，建立不完全依赖谷歌的分发能力。

对隐私工具开发者（VPN、加密通信、广告拦截器等）：这类工具是谷歌和各国政府最可能借助这一机制打压的对象。考虑将签名密钥和分发渠道多元化，F-Droid、GitHub Releases 以及自有网站的直接下载都是有意义的备选。

对企业 IT：评估自有 Android 应用的分发方式是否依赖侧载，以及是否需要向谷歌注册。如果使用的是 Android Enterprise 模式，向 MDM 供应商确认这一政策对企业分发通道的影响。

对监管政策研究者：这是一个把「平台安全」和「平台竞争中立义务」直接碰撞的典型案例，是研究数字市场法案（DMA、DOJ 反垄断案）实际效果的好观察窗口。

4.3 实践场景

技术替代：PWA 能走多远？

渐进式 Web 应用在近年有了很大进步，支持离线缓存、推送通知、后台同步，理论上可以替代大多数移动应用。但在 Android 上，PWA 在以下方面仍有限制：

无法访问 NFC、蓝牙 GATT、USB 等底层硬件（尽管部分已通过 Web APIs 开放）
使用的是浏览器沙盒，无法实现全屏通知或复杂的后台服务
需要用户手动「添加到主屏幕」，没有商店分发的便利

对于不需要底层硬件访问的应用，PWA 可以是摆脱 App 分发管控的有效路径。

4.4 个人观点

读这封公开信，有一种奇妙的感觉：它写得非常克制、非常理性，甚至承认了谷歌所描述的安全问题是真实存在的。但克制的表达掩盖不了事件本身的严峻性。

谷歌在 Google Play 外的 Android 应用分发上没有任何运营角色——它不提供下载带宽、不处理安装流程、不提供任何服务。但它要求开发者必须向它注册并提交身份证件，才能「合法地」让用户在自己的设备上安装软件。这种权力的合理性从何而来？

HN 上一位开发者说得很到位：「这不是谷歌在做坏事，这是谷歌在做一件它可以做的事。区别在于，强大到一定程度以后，你能做到的事和应该做的事之间的落差变得令人不安。」

我对谷歌最终落地这一政策是否真的是为了安全，保持相当大的怀疑。Android 开放侧载的属性，本来是它相对 iOS 的核心差异化价值之一。过去五年里，Play Store 在独立应用分发上的竞争压力越来越大——来自 Epic、Spotify 等大厂对分发费用的挑战，来自 F-Droid 等替代商店的存在，来自被 DMA 强制开放侧载的 iOS 的竞争。这个时机选择的动机，很难让人完全排除商业竞争考量。

技术栈/工具清单

Android 应用分发渠道现状

渠道	是否需要谷歌注册	特点
Google Play	是（现有机制）	最广覆盖，标准分发渠道
F-Droid	待定（视政策落地）	完全开源应用，F-Droid 自编译
Aurora Store	不需要（客户端绕过）	匿名访问 Google Play 目录
GitHub Releases	待定（APK 下载）	开发者直接分发
Samsung Galaxy Store	不需要（三星独立商店）	三星设备优先
Amazon Appstore	不需要	面向 Fire 设备，也可用于普通 Android

工具	用途
F-Droid	开源 Android 应用商店
Aurora Store	匿名访问 Google Play 目录（不上传真实账号）
Obtainium	直接从 GitHub/GitLab/官网追踪 APK 更新
AltStore（iOS）	DMA 框架下的 iOS 第三方应用商店，类比参考
LineageOS	无谷歌服务的 AOSP 发行版
/e/ OS	更进一步的隐私保护 Android 发行版
Android Enterprise	谷歌官方的企业设备管理框架
MDM（Mobile Device Management）	企业设备管理，如 Jamf、Microsoft Intune