操作系统级年龄验证来了:一道账户层关卡,正把操作系统阵营劈成两半
得州的《App Store Accountability Act》已经生效,犹他州更早立法开了先例,加州则直接把年龄问题写进了操作系统账户本身。合规账单落在了发行平台头上,而供应链里有一半玩家根本付不起这笔钱。
先从罚则说起,因为正是罚则把操作系统级年龄验证从一场政策辩论变成了供应链问题。得州参议院法案SB 2420,即《应用商店问责法》,自2026年1月1日起正式生效。它要求应用商店运营方核实州内每个账户持有人的年龄,把未成年人账户关联到家长账户,并在未成年人下载应用或产生消费前取得家长同意。违规行为依据《得州商业与商务法典第17章》被认定为欺骗性交易行为,民事罚款单次最高10,000美元。法条从未说明的是:什么算'一次'违规,而这个空白正是风险所在。往窄了读,一个未核验的未成年人账户算一次,一家在得州坐拥一万名未核验青少年用户的商店,理论罚款上限就是九位数。往宽了读,一次未经同意的下载或消费就算一次,这个上限就不再是能规划的数字了。苹果能为这种不确定性定价,它有法务部门,也有API路线图。一个靠志愿者维护的软件项目,没有任何一个高于零的价格能接受这种风险。
得州并非第一个。犹他州的SB 142由州长斯宾塞·考克斯于2025年3月签署,是美国同类立法中的第一部,确立了基本模板:年龄核验发生在账户所在之处,而不是内容所在之处。英国的《网络安全法》走的是另一条架构,把义务压在每一项在线服务身上,Ofcom自2025年7月起要求'高度有效的年龄核验',违者最高罚款1,800万英镑或全球营业额的10%。美国这几部法律则把同样的义务往技术栈下方压,压到商店以及底层操作系统身上。年龄关卡正在离开网站,搬进机器本身。
加州现在已经把终点写进了法条。《AB 1043,即数字时代保障法案》于2025年10月签署,2027年起生效,直接把年龄问题放进操作系统本身:设备账户开通时,操作系统提供方须采集出生日期或年龄,随后向发出请求的应用开发者提供由此生成的年龄区间。系统层面不做证件核验,不做身份扫描,只给一个申报区间,这种克制也解释了为什么平台方最激烈的反对声音,其实是针对其他法案的。这也是迄今为止对这套架构终局最清晰的表述:你开通新设备时创建的账户,将成为其上所有年龄判定的锚点。
谁游说了应用商店年龄验证?
这里的证据链异常清晰。犹他州通过SB 142后,Meta、Snap和X联合发表声明,2025年3月被广泛报道,称赞犹他州'带了头',并敦促国会跟进,重申Meta长期以来的立场:家长应在商店层面批准青少年下载应用。这些公司花了十年时间抵制服务层面的年龄核验,如今却在平台层面积极游说要求核验。这背后没有什么谜团。平台层面的年龄信号,能把社交网络未来每一次年龄核验义务都变成一次API调用,同时把年龄数据的采集责任转移给发行商店和操作系统。
操作系统厂商也注意到了这一点。苹果2025年2月公布、如今已向开发者开放的申报年龄区间API,读起来像是一家预感自己会输掉这场争论的公司拿出的折中方案:家长的申报以信号形式传给应用,平台留着数据,开发者继承结论。当一个行业的一方在游说要求某项监管,另一方却在搭建机制以求在监管中存活,可以安全地假设:成本已经找到了新的落脚点。这一次,新落脚点是操作系统。
Linux发行版会跟进年龄验证吗?
没人知道,连各发行版自己也不知道。这些法条是围着苹果和谷歌起草的,但定义是功能性的:应用商店指的是向用户分发第三方软件的服务,而一个Linux软件包仓库每天做的正是这件事。法院是否会把条文拉伸到这个地步尚无定论,截至本文写作时,也没有任何一个主流社区发行版公开表态。这个问题看起来还没传到它们那里。以下因此是我们的预判,而不是任何一方已表明的立场。
供应链大概率会沿经济分界线一分为二。商业阵营会选择合规:苹果已公布其身份申报设计,谷歌也在把年龄保障机制接入账户体系,两者都能把成本摊到本就设有合规部门的业务线上。志愿者项目没有合规办公室,没有法务储备金,也没有能扛住一次单笔判决的收入,一旦定义真的延伸到它们头上,现实的选择只剩三个:按地域屏蔽、打官司,或者照常运营、赌执法不会找上门。非营利组织的诉讼路线已经有人在走,目前战果喜忧参半:维基媒体基金会在英国高等法院挑战了《网络安全法》分类条例,2025年8月被驳回,但主审法官强调此裁决并未给这套制度开绿灯,如果维基百科真被划入最严格分类,仍留有重新起诉的空间。地域屏蔽对代码几乎不管用,因为一个ISO镜像不像实体店面,它不知道自己被装在哪里。对志愿者项目而言,'拒绝合规'并不是选择一个更小的市场,而是选择一种法律姿态。目前来看,新加坡等亚太市场尚未出现对等的账户层年龄框架,这也从侧面说明这场变革眼下高度集中在美国与英国。
操作系统级年龄验证对企业意味着什么?
实际后果分两条线砸下来:连续性和数据。先说连续性:如果你的基础设施建立在某个操作系统之上,尤其是那些深埋在技术栈底部、平时根本想不起来的免费或开源系统,它的维护者未来对年龄申报要求的立场,现在就该被写进你的风险登记表。你所运营的司法辖区,平台还能不能继续分发?它的维护者更可能选择合规、拒绝,还是干脆小到无暇决定?这些都是采购层面的问题,理应和许可协议、支持周期一起被审查。梳理这条依赖链,正是技术战略评估该做的那类不起眼却必要的工作,在被迫迁移之前做,远比迁移进行中才做便宜得多。
再说数据:加州模式意味着年龄记录从设备账户开通那一刻起就存在,并向外流动。平心而论,一个申报区间确实比英国服务层面制度催生出的证件核验要小得多的数据蜜罐。但结构性的变化不会因载荷较小而消失。年龄数据如今落在技术栈中此前完全没有此类数据的一层,默认为所有人生成而非按服务自愿选择,并通过一个受官方认可的接口提供给任何提出请求的应用。如果贵组织正在为未来十年挑选要构建在其上的平台,'谁掌握着我员工的年龄数据,谁又能查询它',现在应当是一条硬性筛选标准。
这些法条宣称的目标是保护未成年人免受应用伤害。它们实际搭建出来的,是一层由平台厂商所有、默认覆盖所有人、并且在得州以每次10,000美元计价的年龄底层。评判政策,要看它搭建出的机制。它在说:你的操作系统正在变成一个数据控制者,而你的工作,是搞清楚你选的到底是哪一个。
常见问题
加州《数字时代保障法案》要求操作系统做什么?
自2027年起,AB 1043要求操作系统提供方在设备账户开通时采集出生日期或年龄,并向提出请求的应用开发者提供年龄区间信号。它基于申报区间而非身份证件运作,数据风险因此更小,但仍让操作系统账户成为该设备上所有应用年龄判定的锚点记录。
Linux发行版和开源操作系统会实施年龄验证吗?
目前还没有官方答案,而这本身就是最诚实的结论:没有任何主流社区发行版公开表态,一个志愿者维护的软件包仓库是否符合法条对'应用商店'的定义也尚无定论。商业厂商正在搭建身份申报层以保住市场准入,志愿者项目则没有合规预算,也没有能扛住单笔违规罚款的收入,一旦定义真的延伸过去,现实选择大概是拒绝合规、诉讼或重构分发方式。请关注各项目自己的治理渠道,不要假设整个生态会步调一致。
企业该如何为操作系统级年龄验证规则做准备?
盘点你技术资产中的每一个操作系统,包括那些嵌在设备和基础设施里、平时根本不会去想的部分。对每一个,弄清楚谁在维护它、它是否已就年龄申报要求表态,以及一旦该平台在你运营的司法辖区变得无法分发或失去支持,你的迁移路径是什么。把它当作任何其他供应链连续性风险来处理:现在梳理成本很低,等到出事才发现就贵得多。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。