摘要

  • W3C 于 2026 年 9 月 15 日启动 Browser Data Portability Community Group，目标是就浏览器数据导入、导出原则形成社区组报告；小组明确不制定刚性实现标准，也不发布 Specification。
  • 五人支持创建、加入小组、形成共识、发布报告、进入标准轨、承担法律义务、作出厂商承诺和通过互操作测试，是彼此独立的状态，不能逐级自动推定。
  • 欧盟 DMA 背景下的 iOS 数据迁移以及 Safari 到 Chrome 的现有流程说明实施已经发生，但不证明新小组获得监管授权或行业采用。小组应为每项主张附上“可携带权限回执”。

一条已经运行的路径

这件事最好从具体操作讲起，而不是从机构名称讲起。

Apple 的 iOS 27 支持文档允许用户选择导出 Safari 的书签、历史记录、扩展、信用卡和密码，生成 Downloads 目录中的 ZIP 文件。Apple 特别提醒，这个文件没有加密，完成导入后应删除。Chrome 的 iPhone 与 iPad 帮助页接上了另一端：用户选择 Safari 导出文件，预览内容，处理密码冲突，然后导入。BrowserKit 文档又展示了系统介导的接口面，包括历史、书签、阅读列表、扩展以及导入导出错误。

这是一组可验证的产品事实。它们有设备、操作系统版本、数据类别、方向和安全边界。它们没有证明所有浏览器之间都已互通，也没有证明 Apple、Google 或 Chrome 已经加入新社区组，更没有证明它们会采用未来某一版本的报告。

新小组处理的是更靠前的问题。公开范围说明希望浏览器开发者和实现者就用户跨浏览器迁移数据的需求形成共识，最终成果是一份提出导入和导出原则的 Community Group Report，以改善跨设备、平台和浏览器结果的一致性。同一份说明也主动收紧权限：小组不寻求规定刚性的实现标准，页面明确写着不会发布 Specifications。

这不是一句可有可无的免责文字，而是当前授权的边界。

五名支持者不是行业表决

Tom Fish 于 9 月 11 日提出创建该组。启动通知列出 Dominique Hazaël-Massieux、Johannes Ernst、Bruce Lawson、Chris Riley 和 Tom Fish 五名支持者。根据 W3C FAQ，五人支持足以触发社区组的创建。

门槛数字只证明门槛被满足。支持创建不等于加入；个人加入不等于代表其机构；成为参与者不等于对一段文本作出正式贡献；讨论不等于共识；共识更不等于厂商承诺部署。

截至 9 月 20 日，公开主页显示一名参与者 Tom Fish，主席仍为“None yet”。这只是时点快照，小组以后完全可能扩员并选出主席。但快照至少禁止我们把一则启动通知叙述成成熟联盟。当前公开记录里没有主席、首份报告草案、已记录的决定、版本化数据模型或互操作测试计划。

社区组的开放性也值得准确描述。加入需要 W3C 账户，但不要求成为 W3C 会员。W3C 还明确表示，托管一个社区组不代表 W3C、其会员或员工认可该活动的观点。平台、流程和机构背书不是同一件事。

报告不能越过的线

W3C 对不同组别的比较把权限分得很清楚。社区组在 scope statement 内开展工作，主要成果是非标准轨的 Community Group Report。社区组不制定 W3C 标准。若工作未来要进入标准轨，需要具有相应范围的 Working Group 接收，并走另一套程序。

因此至少要保留六层状态：开放讨论、社区组报告、W3C 标准、监管义务、厂商承诺、经测试的互操作实现。它们可以相互影响，却不存在自动传导。

报告能够证明的是某个群体在某个版本里愿意发布什么。标准需要标准轨授权。法律义务来自具体法律、管辖区、受规制主体与主管机关。厂商承诺需要厂商自己的可核验表述。实现需要产品和 API 版本。互操作则需要两端版本、测试环境、成功标准与失败记录。缺了哪一层，都不能用“W3C”三个字补齐。

反过来也一样：产品里已经存在迁移按钮，不等于多利益相关方程序批准了它的设计。

DMA 是另一条权限来源

欧委会 2026 年 5 月的案例页为这一区分提供了现实样本。页面把 iOS 与 iPadOS 的浏览器数据可携带描述为两年监管对话后的 DMA 相关成果。路径是应用到应用、由操作系统和用户介导的双向机制，覆盖书签、历史、密码、信用卡数据和扩展等类别；欧委会称部分第三方浏览器已经支持从 Safari 导入。

这项证据很强，但范围很具体。DMA 第 6(9) 条针对 gatekeeper 的终端用户数据可携带，涉及用户授权、免费工具，以及适用情形下的持续与实时访问。它的约束力来自欧盟法律、指定与监管，而不是社区组报告。未来报告也不能把欧盟范围的义务悄然扩展成全球、全平台、全浏览器规则。

合理的因果顺序是：监管可以向特定主体设定义务；产品团队可以落实迁移路径；社区论坛可以整理实践、需求和原则。三者可能互相学习，却不共享一张授权书。

给每项主张一张权限回执

社区组若想让报告真正可用，应让每项可携带主张都带着一张可追溯回执。第一部分记录成果类型、状态、版本、不可变 URL 与日期；列明起草者、支持创建者、当前参与者、组织代表身份、利益披露、主席和编辑；说明决策程序、异议及其处置。

第二部分记录数据类别，尤其是密码和支付资料等敏感信息；导出方、导入方、方向与触发者；设备、操作系统、浏览器、配置文件和账户边界；格式、加密和保留策略。若引用法律，还要写明法律依据、地域、受规制主体、主管机关和生效日期。若声称厂商采用，就要保留承诺原文及其指向的报告版本。若声称互操作，就要留下产品或框架版本、测试环境、成功标准、已知失败、冲突处理、取消与回退路径。

尚未证明的字段应当明确为未知。机构托管、知名公司名称或一个导出按钮都不是填空答案。

这张回执不会把早期讨论变成沉重的认证程序。它只负责阻止状态在传播中偷换身份：“准备讨论原则”不能变成“已发布第一版报告”；“产品文档描述导入”不能变成“厂商承诺采用报告”；“一对版本测试成功”也不能变成“浏览器数据已经普遍互操作”。

怎样才算近期成功

这个小组近期最可信的成功，不是宣布行业已经达成一致，而是交出一份边界清楚、可复查的报告。它可以描述用户目标而不伪装成强制实现；把高风险凭据与书签、历史分开；把导出能力与导入能力、单向与双向分开；并清楚标出设备、账户或平台造成的限制。

这样的报告还可以改善后续交接。厂商能够准确说明接受哪个版本、哪项原则和哪些数据类别；工作组能够识别哪些内容需要规范性工作；监管者可以引用证据而不把法律解释外包给社区论坛；测试者则知道应比较哪些实现和失败路径。

先发布回执，再发布宏大标题。浏览器数据可携带已经部分存在，却范围不一、权限分散。新小组可以帮助描绘这片地形。此刻它拥有的是召集、讨论和报告的权限，仅此而已。

来源