# 欧盟 DMA 第 6 条互操作性义务的技术边界：BirdyChat 的合规工程实践 > 解析欧盟数字市场法 Article 6 对'互操作性'的技术定义差异——协议级兼容与产品级兼容的边界，以及 BirdyChat 如何在不触碰 WhatsApp E2E 加密的前提下实现合规协议适配。 ## 元数据 - 路径: /posts/2026/01/25/dma-article-6-interoperability-technical-boundary/ - 发布时间: 2026-01-25T13:20:33+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 欧盟《数字市场法》（Digital Markets Act，简称 DMA）自 2024 年 3 月全面生效以来，围绕 Gatekeeper（守门人）义务的技术定义与工程实现边界问题，始终是监管方与被监管方博弈的核心战场。其中，互操作性（Interoperability）义务尤为复杂：它究竟要求Gatekeeper开放到什么程度？是仅需提供协议层面的技术接口，还是必须实现产品层面的功能兼容？BirdyChat 作为首批与 WhatsApp 实现互通的第三方应用，为我们提供了一个极具价值的观察窗口——它既展示了在严格加密约束下实现跨平台通信的工程路径，也揭示了 DMA 第 6 条在实际执行中的技术模糊地带。 ## DMA Article 6 互操作性义务的法律文本解读 DMA 第 6 条对 Gatekeeper 的互操作性义务作出了框架性规定，但其文本表述在技术层面留下了相当的解释空间。该条款要求 Gatekeeper 在技术层面为第三方开发者提供与其核心平台服务互操作的能力，但并未明确界定"互操作"究竟指向哪个抽象层级。从法律文本来看，欧盟委员会保留了通过补充性规范（Article 8）进一步细化具体技术要求的权力，这为后续的执法灵活性提供了法律基础，同时也给企业合规带来了不确定性。 在具体执行层面，欧盟委员会于 2024 年 9 月启动了两项规范制定程序，分别针对 iOS 与第三方连接设备的互操作性（DMA.100203），以及 Apple 处理互操作性请求的流程透明度（DMA.100204）。这两套规范涵盖了 9 项 iOS 连接功能的技术实现要求，但其适用范围主要聚焦于操作系统层面的硬件与软件特性，而非即时通讯这类应用层服务。这说明 DMA 的互操作性义务在不同的服务类型上可能存在差异化的执行标准，而消息类应用的互操作性要求尚未被细化到同等程度。 理解这一背景对于分析 BirdyChat 与 WhatsApp 的互通机制至关重要。WhatsApp 作为 Meta 旗下的核心平台服务，被认定为 Gatekeeper 的核心平台服务（CPS）之一，其互操作性义务应当遵守 DMA 第 6 条的框架性要求。然而，由于缺乏类似 iOS Article 6(7) 那样详尽的技术规范，Meta 在实现 WhatsApp 互操作性时拥有较大的工程裁量空间，而 BirdyChat 等第三方开发者则需要在这种模糊地带中寻找合规的技术路径。 ## 协议级兼容与产品级兼容的本质差异 在 DMA 互操作性义务的技术讨论中，"协议级兼容"与"产品级兼容"的区分具有基础性的理论意义，尽管法律文本中并未直接使用这两个术语。协议级兼容指的是技术层面的接口开放——Gatekeeper 提供标准化的 API、数据格式或通信协议，允许第三方开发者基于这些接口构建与其服务交互的应用。这种兼容模式的核心特征是：Gatekeeper 保持对其服务的完整控制，第三方应用仅能通过预定义的接口进行有限的功能调用，无法绕过这些接口直接访问或修改 Gatekeeper 服务的内部状态。 产品级兼容则提出了更高的要求，它不仅要求接口层面的开放，还要求第三方应用在功能体验上能够与 Gatekeeper 的原生服务达到某种程度的等价性。用户在使用第三方应用时，应当能够获得与使用 Gatekeeper 原生服务相似的核心功能，而不应因协议限制而遭受功能降级。这种兼容模式涉及更深层次的系统设计考量，包括但不限于：消息的实时传输、媒体文件的处理、用户身份的标识、以及跨平台的一致性体验等。 从 BirdyChat 与 WhatsApp 的互通实践来看，Meta 采取的是典型的协议级兼容路径。根据官方披露的信息，双方的互操作性实现支持一对一文本消息、图片、语音消息、视频和文件的传输，这些功能通过 WhatsApp 开放的接口层实现，而非让 BirdyChat 直接访问 WhatsApp 的内部消息系统。更重要的是，端到端加密（E2E Encryption）在整个互通过程中得以保留——这意味着 BirdyChat 无法解密 WhatsApp 用户之间的通信内容，它仅作为一个中继通道，将加密后的消息从一方传递到另一方。 这种设计清晰地体现了协议级兼容的工程边界：Gatekeeper（WhatsApp）掌握着加密密钥和消息解密能力的控制权，第三方应用（BirdyChat）只能在其授权的范围内进行消息转发，无法突破加密层去获取明文内容。这既是技术上的限制，也是合规上的要求——DMA 并未要求 Gatekeeper 为了实现互操作性而牺牲其安全架构，恰恰相反，欧盟委员会明确指出，任何参与互操作的第三方服务都必须提供与 WhatsApp 同等水平的端到端加密保护。 ## BirdyChat 的工程合规实现路径 BirdyChat 作为首批获得 WhatsApp 互操作能力的三方应用之一，其工程实现需要解决一系列复杂的技术挑战。这些挑战可以归纳为三个核心维度：加密协议的兼容性、用户身份的统一管理、以及消息语义的一致性处理。 在加密协议兼容性方面，WhatsApp 采用了基于 Signal Protocol 的端到端加密方案，这是一个成熟且被广泛认可的加密框架。要实现与 WhatsApp 的互通，BirdyChat 必须能够处理 Signal Protocol 的密钥交换机制、消息加密格式以及会话状态管理。然而，由于 WhatsApp 并未开源其完整的加密实现细节，BirdyChat 需要通过逆向工程或官方技术合作来理解这些协议细节。Meta 官方公告显示，双方的技术团队进行了小规模测试，以确保 WhatsApp 与 BirdyChat 的互通能够正确处理加密消息的转发和接收。这意味着 BirdyChat 很可能获得了 Meta 提供的协议文档或技术指导，而非完全依赖公开的 Signal Protocol 规范。 用户身份统一管理是另一个关键的技术挑战。在 WhatsApp 的生态中，用户通过手机号码进行身份标识；而 BirdyChat 可能拥有完全不同的身份系统。为了实现跨平台通信，双方需要建立某种身份映射机制，使得 WhatsApp 用户能够向 BirdyChat 用户发送消息，反之亦然。这种身份映射必须在不泄露用户隐私的前提下进行——例如，BirdyChat 不应被要求向 WhatsApp 提供其用户的详细身份信息，反之亦然。目前公开信息尚未披露这一身份映射机制的具体实现，但可以推测，双方很可能采用了某种联合身份验证协议，在保护各自用户隐私的前提下确认跨平台消息的收发方身份。 消息语义一致性处理涉及不同平台之间消息格式的转换与映射。WhatsApp 和 BirdyChat 可能采用不同的消息内部表示方式，包括文本编码、媒体文件格式、消息状态标识等。当一条消息从 WhatsApp 发送至 BirdyChat 时，需要将其转换为 BirdyChat 能够正确解析和显示的格式；反之亦然。这种转换必须在不破坏消息内容的前提下进行，同时还需要处理各平台特有的消息类型（如 WhatsApp 的回复引用、投票消息等）是否能够在 BirdyChat 上完整呈现的问题。从功能支持范围来看，BirdyChat 与 WhatsApp 的互通目前主要覆盖基础消息类型，尚未实现所有高级功能的跨平台兼容，这符合协议级兼容的典型特征。 ## 合规实施中的隐私与安全边界 DMA 互操作性义务的一个核心原则是：合规不得以牺牲用户隐私和安全为代价。欧盟委员会在审批 WhatsApp 第三方互通功能时，明确要求任何参与互操作的第三方服务都必须提供与 WhatsApp 同等水平的端到端加密保护。这一要求从法律层面锁定了 BirdyChat 等第三方应用的加密能力边界——它们必须支持 E2E 加密，但不能因此获得解密 WhatsApp 用户消息的权力。 这种设计体现了隐私保护与互操作性之间的微妙平衡。从用户角度看，他们与 WhatsApp 好友之间的通信仍然受到端到端加密的保护，第三方应用（包括 BirdyChat）无法窥探消息内容。从 Gatekeeper（Meta）角度看，它通过控制加密密钥和协议实现，维护了对自身生态的安全控制权，同时满足了 DMA 的互操作性要求。从第三方应用角度看，它们获得了与主流平台互通的能力，拓展了用户基础和功能边界，但也被限制在加密协议授权的范围内。 然而，这种平衡并非没有代价。协议级兼容的局限性意味着 BirdyChat 在某些场景下可能无法提供与 WhatsApp 原生应用完全一致的用户体验。例如，当 WhatsApp 用户发送一条"阅后即焚"消息时，BirdyChat 可能缺乏相应的功能支持来正确处理这条消息的销毁逻辑。再如，WhatsApp 的消息反应（Reaction）功能可能在 BirdyChat 上以不同的方式呈现，或者部分反应类型无法跨平台同步。这些功能差异是协议级兼容模式的固有特征，它们源于 Gatekeeper 对协议细节的部分保留，而非技术实现上的疏忽。 用户控制权是 DMA 互操作性义务的另一重要维度。Meta 明确表示，WhatsApp 用户将能够在设置中看到新增的"第三方聊天"选项，并可以选择是否启用与 BirdyChat 等应用的互通功能。用户可以选择完全禁用该功能，或者对特定联系人和群组启用或禁用互通。这种设计确保了用户对其通信隐私和体验的控制权——不愿与第三方应用互通的用户可以保持隔离，而愿意体验跨平台通信的用户则可以主动开启。这一机制也符合 DMA 强调用户选择权的立法精神。 ## 互操作性合规的技术演进趋势 从 BirdyChat 与 WhatsApp 的互通实践，我们可以窥见 DMA 框架下互操作性合规的技术演进方向。当前的实现主要停留在协议级兼容层面，第三方应用通过 Gatekeeper 开放的接口层与其服务进行交互，但无法突破加密层和安全边界获得更深层次的系统访问权限。这种模式在短期内可能是最务实的技术选择——它既满足了监管要求的互操作性，又避免了大规模改造现有安全架构的系统性风险。 然而，随着 DMA 执行的深入和案例的积累，更高层次的互操作性要求可能会被逐步明确。欧盟委员会在 iOS 层面的互操作性规范制定（Article 6(7)）已经展示了将框架性要求细化为具体技术指标的能力，这种经验可能未来会被复制到消息类应用领域。如果出现更详细的技术规范，Gatekeeper 可能需要开放更深层次的协议支持，甚至在某些场景下考虑产品级兼容的技术路径。 对于第三方应用开发者而言，当前的合规策略应当聚焦于充分利用现有的协议级兼容能力，在边界内最大化产品的功能价值和用户体验。BirdyChat 的实践表明，即使在协议级兼容的约束下，仍然可以构建有价值的跨平台通信解决方案。关键在于：清晰理解 Gatekeeper 开放的协议范围，在授权范围内进行工程创新，同时为未来可能的功能扩展保留技术灵活性。 从更宏观的视角看，DMA 的互操作性义务正在重塑欧洲乃至全球的数字通信生态。WhatsApp 与 BirdyChat 的互通只是这一变革的起点，未来可能会有更多的 Gatekeeper 和第三方服务加入互操作性网络。对于工程团队而言，理解法律义务的边界、设计合规的技术架构、保障用户隐私与安全，将成为这一变革时代不可或缺的竞争力。 --- **参考资料** - Meta 官方公告：WhatsApp enables third-party chats for users in Europe（2025年11月） - 欧盟委员会：Digital Markets Act - Interoperability Q&A - The Verge：WhatsApp is launching third-party chat integration in Europe（2025年11月） - CEPA：Opening Up — Europe's DMA and the Risks of Interoperability（2025年11月） ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。