数字身份的世界可以追溯到多年前，当时只有中心化身份模型。近年来，联合身份模型已扩展到所有领域，从社交网络和教育到企业和政府。最近几年，一些项目已经实现了去中心化身份的新范式，用户拥有数字钱包并控制自己的身份。

这引起了全世界的关注，政府正在为公民设计钱包和去中心化身份，目的是拥有比实体凭证更安全的数字凭证和隐私保护。

鉴于这一创新的范围和规模，数字身份正在对Web产生重大影响，特别是在隐私和用户权益方面，影响着塑造Web生态系统的设想和平衡。考虑到众多利益攸关方（包括政府、实现者、隐私与用户权益倡导者）以及可用技术和相关的标准制定组织，现在是时候分析这些影响和风险了。

因此，我撰写了《Identity & the Web》这篇文章。W3C团队今天发布了这份文档，同时 提出更新W3C联合身份工作组的标准化章程。这篇文章概述了数字身份，重点分析去中心化身份及其对Web和用户的影响，从而了解可能的风险以及如何从技术和治理的角度减轻这些风险。我希望以这篇文章作为切入点，邀请广大社区的审阅并于2024年10月6日前提供反馈，进而帮助我们进一步完善相关内容。

我们希望提供一个用于探讨和管理系统性影响的平台，推动社区在信息生态系统快速演变的进程中规划出一条可靠的路径，强化Web地位与影响力。

[以下内容译自 W3C Web 支付标准活动负责人 Ian Jacobs 的博客文章，参见英文原文]

3月18日，Stripe 向 W3C Web 支付工作组（会议记录）提交了他们为期三个月的SPC（Secure Payment Confirmation，安全支付确认）实验结果。结果非常令人兴奋：转化率提高了8%，认证速度明显加快。接下来我会分享更多细节，大家可以在 Stripe 的演示中获取更多信息。

SPC 的目的是在 Web 支付过程中优化 SCA（strong customer authentication，客户身份强认证）流程。这将改善 Web 端电商体验，增强安全性，并帮助支付行业符合监管的要求（如欧洲的 PSD2）。SPC 尚还没有作为一个 API 或一组完整定义的浏览器行为存在。Stripe 实验尝试实现了 SPC 的一些设想。谷歌工程师通过修改 MacOS Chrome 中的 Web 认证和支付请求 API，使实验成为可能。Web 支付工作组准备开始更系统地阐述 SPC 的特性和范围。

Stripe 实验试图了解用户对认证的偏好，是偏好单次输入密码进行强认证，还是 FIDO 认证。为什么实验选择FIDO？我们通常讲的 FIDO2, 是 FIDO 联盟的 CTAP 协议与 W3C WebAuthn 规范的结合，是 SCA 解决方案的完美基础。所有主流浏览器（桌面和移动端）上都支持 FIDO2,目前几十亿的手机和笔记本电脑都已经预先内置了认证程序。FIDO2 提供了比密码比起来更具安全性和可行性，并切实寻求符合法规的要求（请参阅关于满足 PSD2 SCA 需求的 FIDO 白皮书）。

简单地讲，SPC 实验重点关注使用 EMV® 3DS（3-D Secure，3-D 安全标准）进行初始登记的银行卡支付。正如我在前一篇博客文章中提到的，EMVCo、FIDO 和 W3C 正在讨论可以将 FIDO 与 3DS 结合使用的方法。该实验集中在 3DS 挑战模式(3DS challenge flow)期间使用 FIDO。这个实验将带给我们很多有用的信息，但我们正在进行的一部分工作是确保SPC能够支付过程和系统中被广泛使用。 

为了了解SPC的动机，需要了解3DS在Web上的使用方法。我的解释是一个简化的版本：

* 3DS的一个重要设计目标是使得发行信用卡的银行能够决定将要使用信用卡进行电子商务支付的人是否有权限。然而，当用户购物时，用户是在与商家交互，而不是与他们的银行交互。

* 一种方法是“让用户访问银行”，通过HTTP重定向到银行的网站（在第一方内容中）进行身份验证。考虑到各种便利性，人们会不喜欢这个解决方案。商家也不希望顾客离开他们的网站。

* 另一个解决方案是在商户网站上嵌入来自发卡银行的代码（在第三方内容中）。支付服务提供商（向商户）通常使用采用iframe，但没有Web认证。

我们来分析原因。在 WebAuthn 第一版规范中：

* 依赖方（relying party）必须在第一方（first party）环境中注册验证器。、

* 只有依赖方（relying party）可以对用户进行身份验证。

* 依赖方（relying party）只能在第一方（first party）的环境下这样做。

换言之，在 WebAuthn 第一版规范中，发卡银行（假设它和商户不同源）无法对用户在第三方购买中页使用Web 身份验证。为了克服这一限制，Web 支付工作组要求WebAuthn工作组改进方案。因此，在 WebAuthn 第二版规范中：

* 依赖方（relying party）必须在第一方环境中注册验证器。

* 只有依赖方（relying party）可以对用户进行身份验证。

* 依赖方（relying party）可以在第一方或第三方环境中这样做。 

现在，发卡银行可以在商户页面中使用 WebAuthn 对用户进行身份验证。这已经是一个巨大的成功。但 Stripe寻求进一步的改进。他们指出，在页面中嵌入发卡银行的代码会涉及很多网络请求，可能会出现安全问题。相反，他们希望自己能够触发 Web 身份验证，收集执行的结果，并通过后台渠道将其传达给发卡银行。作为信赖方，发卡银行仍将作为依赖方（relying party）验证该结果。 

首个“超能力”的SPC就是这样产生的。使用SPC：

* 依赖方（relying party）必须在第一方环境中注册验证器。

* 任何一方都可以对用户进行身份验证。

* 任何一方都可以在第一方或第三方环境中这样做。 

这是明显违背 WebAuthn 的行为，因此它仅在“支付情况下”可用。“支付情况下”目前（实验阶段）定义为“在付款请求 API 期间”。

实验阶段的 SPC 融合了支付请求 API 和 WebAuthn。独立使用 API 相比，开发人员通过 SPC 拥有更多超级功能。

SPC 的第二个超级功能是浏览器的“交易确认对话框”，其目标是使用内置浏览器功能，在网站和平台上创建一致的身份验证体验。

这是 SPC 和 WebAuthn 另外一个不同之处。WebAuthn 是在网站新开窗口内执行的。Stripe 询问 Chrome 团队使用当前窗口，而不是新建窗口。权衡结果是使用内置浏览器对话框，效果截图见文章插图。SPC 将身份验证交互操作委托给浏览器。下面描述 SPC 触发交易对话框的流程：

* 注册时（这里我不会详述），用户在第一方环境中向发卡银行注册验证器。发卡银行将用户的卡与该 FIDO 凭证关联。

* 在交易过程中，在任何商户网站上，用户都会选择同一张卡进行支付。Stripe（或任何支付服务提供商）请求发卡银行（通过修改后的 3DS 协议）并询问：这张卡是否存在关联的 FIDO 凭证？发卡银行返回凭证的公钥，以及一个随机数（用于身份验证）。Stripe 调用 SPC，浏览器打开“交易确认”对话框，询问用户：“是否要授权使用此卡向以下商户支付 N 美元？”如果用户继续，平台（以 MacOS 为例）会提示用户授权（本次实验使用 TouchID）。 

Stripe 还希望利用 SPC 来满足 PSD2 的另一个要求：“动态链接”。该要求涉及用户同意交易金额和受益人的加密证据。浏览器的新交易弹框显示 PSD2 所需信息，当用户点击确认时，FIDO 验证器用于确认金额、受益人和卡信息。因此，SPC 的第三个超级功能是内置的对签名交易确认数据的支持。 

总而言之，SPC的初步实验包含了这三种新的浏览器功能：

* 在支付请求API期间对于FIDO凭证，放宽了用户进行身份验证的限制

* 浏览器内置的交易确认对话框

* 签名交易数据

我们已经正在列举这三种功能为 SPC 带来的好处。我想这三个最初的功能未来会在 SPC 中保留，但是人们已经我们添加更多功能，比如标准化注册流程、零摩擦流（zero-friction flows）、作为 FIDO 认证输入的随机性来源，以及在支付 APP 中调用 SPC 的能力。我们将在 Web 支付工作组的远程会议上讨论 SPC 的潜在功能。 

回到实验上来，SPC 与一次性密码相比如何？Stripe 表示，使用 SPC：

* 转换（交易完成）增加了8%。

* 用户验证时间缩短为原来的1/3。

* 欺诈数量低到可以忽略不计。

我预计工作组将把 SPC 作为一项正式提案，这意味着我们将有很多工作要做：

* 更多的实验（包括与银行共同实验）

* 技术规范的初始工作。

* 谷歌将实现扩展到其他平台。

* 与更多浏览器供应商合作。

* 讨论各种支付系统和流程中的业务诉求。如 EMV® SRC（Secure Remote Commerce，安全远程商务）、The Clearing House 的实时支付、欧洲的 Open Banking 等。

* 与 WebAuthn 工作组和 FIDO 联盟沟通，确保 SPC 工作内容的对齐。

* 与 EMVCo 3DS 工作组协调改进 3DS 或 SRC 功能，以支持 SPC。

* 了解SPC与其他认证委托用例的联系；例如，请参阅新的白皮书用于商家和钱包服务的 FIDO SCA 代理。Web 支付安全兴趣小组为 EMVCo、FIDO 和 W3C 提供了讨论使用场景的平台，以及如何确保各种技术能够灵活地互操作。 

我要感谢所有迄今为止为讨论、编码和实验做出贡献的人，特别是 Stripe、Google 和 Coil 的同行们。

W3C理事长 Tim Berners-Lee 发表了W3C博客文章，阐述对HTML5标准中加密媒体扩展（EME）标准工作的观点。文章主要内容翻译如下。英文原文，请参阅博客英文原文。
 

业界广泛讨论的话题焦点在于W3C是否应该开发允许Web页面通过连接现有的底层数字版权管理（Digital Rights Management，以下简称DRM）系统来包含加密内容的加密媒体扩展标准（Encrypted Media Extensions，以下简称EME）。有些声音表示反对，但是我认为实际上合乎逻辑的回答是“是的，W3C应该这样做。”鉴于针对EME的反对浪潮中有很多言辞激烈的抗议，我觉得有必要向公众解释一下开发EME的逻辑所在。这世界上有太多需要去抗议、去深入调查、去跟进的事情，我希望那些用来抗议EME的资源和精力可以另寻渠道去解决真正需要解决的问题。关于EME的争论当中，出现的很多观点我是认同的。要了解为什么会产生分歧，需要直面的首要问题是W3C到底应该不应该开发EME推荐标准。
 

我认为W3C应该开发EME的原因是，通过制定EME标准，我们可以带领从一开始就参与此项标准工作的工业界形成一个简单易用的方法来实现Web页面对加密内容的支持，从而保证浏览器之间的互操作性。这将为广大开发者以及用户带来很多便利。举个例子，很多人喜欢看Netflix提供的内容。他们在每天的工作和生活中有大量的时间用在Web上，他们喜欢把Netflix的内容方便的嵌入到他们的Web页面里面去，他们喜欢就所看见的内容进行在线互动讨论，并将讨论和内容互相链接。
 

那么，大家能不能把内容放到Web上而不用DRM呢？答案是可以的。其实现在Web上大量的视频内容并没有DRM。那些未经加密的付费电影实在太容易被拷贝，并且在现实的乌托邦世界中自愿全价购买一些并没什么用处的内容的人也大有人在。也有人认为整个著作权系统就应该被废止，他们可以通过影响立法活动去尝试修改相关条约，这当然会是一个漫长的斗争历程。无论如何，在当前的现实中，法律是保护著作权的。

既然DRM存在争议...

当一家公司决定分发他们想要保护的内容时，他们有很多选择。记住这一点很重要。
 

如果W3C最初没有开发EME推荐标准，那么浏览器厂商们一定会在W3C之外的某个地方做出类似的东西；如果EME不存在，厂商们一定会开发出新的基于JavaScript的多种版本；如果不使用Web页面来浏览，更多用户就会通过私有应用去看视频内容；如果这些封闭平台禁止应用里的DRM，那么那些大型内容提供商干脆就会去分发自己的机顶盒和游戏机产品作为唯一可以获取他们内容的渠道。
 

即使W3C理事长（W3C Director）决定不做DRM相关的标准，事实上什么也不会改变，因为W3C没有权利去禁止任何事情。W3C不是美国国会，不是国际知识产权组织（WIPO），也不是一个法庭。如果EME反对者意识到这一点，那么关于W3C做EME标准的争议可能就会大大缩短。既然如此，现在我们是不是应该重新将思考和行动回归到真正重要的事情上来呢。
 

那么，W3C可不可以就EME的争论亮明观点呢？可不可以因为DRM对用户来说算不上一件好事情而拒绝那些加入W3C希望从事DRM相关工作的人呢？即便真的如此，再说一次，也不会对现状带来什么改变，因为W3C不是一个法庭，也并非一个执法机构。W3C是什么？W3C是一个Web业界通过沟通和协作打造创新卓越的Web技术的地方。W3C和广大公众要理解在对抗DRM的时候W3C的力量是非常受限的。
 

然而，更为重要一点是，脱离Web做DRM是一个糟糕的想法。对于用户而言，通过Web的加密媒体扩展来实现DRM与其他方式相比是个更好的选择。

1. 如果内容是一个Web页面，那么它就是Web的一部分；

2. EME系统可以将DRM代码沙箱化，从而限制其可能对用户系统带来的安全威胁；

3. EME系统可以将DRM代码沙箱化，从而限制其可能对用户隐私带来的安全威胁；
 

如上所述，当一个内容提供商分发一部电影时，他们有很多选择，这些选择各有优缺点。重要的问题是，内容分发商到底有多了解他们的用户。

• 如果内容分发商选择卖DVD光盘或蓝光光盘来分发内容，他们就永远不会知道用户是不是看了光盘内容，或者有多喜欢看光盘内容；用户则可以尽情观赏内容，不必担心自己的观赏行为是否会被监视；

• 如果内容分发商选择Web作为分发媒介，他们就可以在用户解锁电影内容时第一时间知道这个信息。浏览器通过EME系统，可以根据DRM代码限制电影内容的访问次数，并阻止回传更多细节信息（Web页面也可以监控并报告用户的相关访问行为，但是浏览器的这种行为也可以被监控并报告）；

• 如果内容分发商选择例如IPhone这样的择封闭系统里的应用作为分发媒介，那么他们可以自主制定自己的DRM。他们也可以观察用户对电影观看的方方面面的细节内容。如果他们能够得到用户许可获取更多访问权限，例如获取用户的日程安排，他们就可以对用户做一个完全的侧写，并将其与用户的电影观看习惯进行关联；

• 如果内容分发商选择例如Android或者Mac OS X这样的开放系统总的应用作为分发媒介，他们可以得到与iPhone应用一样的用户信息反馈。但是，鉴于这个系统并不锁定，应用是可以进一步侵犯用户权益的，例如盗取用户机密信息，或者像Sony Rootkit 案件那样在系统上安装间谍软件；

• 如果内容分发商选择使用自己开发的封闭系统，例如游戏机或者机顶盒，用户就可以避免自己的电脑被安装间谍软件。内容发行商对于回传的用户玩游戏或观看行为等信息有绝对的控制权。但是用户却没有办法将这些内容和行为纳入他们互联Web生活的一部分，因为没有链入或链出的方法。
 

总之，实现Web对EME的支持是十分重要的，因为这将提供一个相对安全的在线环境使用户可以获取Web音视频等内容，并便捷的就此进行在线互动。
 

需要提出的是，尽管目前EME在Firefox浏览器Chrome浏览器中的实现中DRM代码已经沙箱化，但是保护用户的DM代码沙箱化程度并不是由EME标准本身定义的。

致媒体朋友

既然电影已经加入了Web内容的阵营，那么接下来我们是否需要担心内容提供商把音乐及图书等其他媒体内容放到Web上面去呢？对于音乐来说，我觉得不需要担心。因为我们看到业界已经有意识的逐渐从基于DRM的模式向一种非加密模式转变了，比如有时买家的邮件地址带有水印，没有DRM。
 

对于图书来说，也许会存在一定的问题，因为现在人们依然在使用大量的不支持Web浏览的封闭阅读设备，图书内容分发商通过这些封闭设备做DRM。并且，这些封闭设备正在逐渐被手机或电脑等通用设备上那些各式具有阅读工程的应用所代替。对于自发向Web模式发展的行业是否会自行放弃DRM，我们可以寄予希望，但前景并不明朗。
 

我们已经讨论了以分发电影为例，各式DRM使用方法的优点。现在，让我们来谈谈大多数DRM系统都存在的问题。

DRM存在的问题

这篇博客大部分的内容是我以W3C理事长的身份从W3C的技术角度去探讨的，但是接下来关于DRM以及DMCA的内容，我表达的是我个人的观点。
 

用户面临的问题

从用户的角度看，DRM的问题还真不少。关于这些问题的记载已经很充分，我在这里列举如下：

•  内容的合理性使用不能保证，例如免除评论、教育目的等

•  阻碍衍生作品的再生成

•  用户不能得到一份备份副本

•  DRM可能对用户的电脑产生安全威胁，攻击用户电脑
 

DRM系统通常会给用户带来的体验并不美好，例如用户只能在某些特定地区使用针对该地区的区域性许可，“购买”和“租赁”概念的不清晰描述，内容提供商消失，以及那些已购买的东西不能够访问等造成的问题。
 

即使有这诸多不便，用户们还是继续购买受DRM保护的内容。
 

开发者面临的问题

DRM阻止独立开发者开发与视频流互动的不同回放系统，例如，增加一个无障碍的特性，加速或减慢回访等。
 

将来可能面临的问题

几十年之后，也许因为当时的加密技术，或者因为没有及时拷贝，我们也许就没有当年那些电影的可用记录资源了。对此，我强力推荐，任何一个获得了一部电影版权并把它以任何加密形式分发的人务必将一份不加密的版本保存在例如大英博物馆、美国国会图书馆以及互联网档案馆等版权库里面。

法律问题

针对EME的大部分反对意见都与DRM有关，其中有些是关于某些法律的具体问题。
 

讨论最多的相关法律是《美国数字千年著作权法案》（Digital Millennium Copyright Act，DMCA）。其他国家的相关法律大多与DMCA内容或多或少的近似。有些其他法律也在讨论范围之列，不过我们并没有一份详尽的清单，也没有做过相关分析。值得一提的是，美国投入了很多精力，通过使用多变或双边协定来劝说其他国家采用《美国数字千年著作权法案》这样的法律。在这里我对其他国家的相关法律不做探讨，但是我想指出的是，并不应该认为这仅是在美国才存在的问题。下面，我们来仔细看一看《美国数字千年著作权法案》。
 

当你想要大刀阔斧的在其他方面从整体上改革现有的著作权系统时，请留意《美国数字千年著作权法案》里面的一些特定部分，例如1201节，会将那些无辜的想弄清楚DRM系统的安全领域研究者置入被惩罚的险境。
 

在W3C的推荐标准开发流程当中，有一段时间我们曾经尝试在所有的EME工作组成员都同意署名保护这个规范技术里面的安全技术研究人员免受相关法律制裁之前，拒绝把EME规范向前推进。长话短说，这个尝试失败了。历史学家可能会指出失败的原因包括EME标准的开发过程不应该如此、EME工作组里面参与该标准的公司和根据《美国数字千年著作权法案》来打官司的公司不是同一伙人等。

安全技术研究人员面临的问题

2017年2月，W3C在鼓励Web业界启动一个“bug bounty”的项目。在这个项目保证参与该项目的发现并报告了系统中所含Bug的安全技术研究人员会被免于起诉。W3C可以鼓励这样的尝试，提供相关指南，但是W3C不能修改法律。我鼓励那些认为这种尝试很重要的人们帮助开发一份业界认同的通用最佳实践指南。一份通用最佳实践指南的初稿以及实施指南已经发布。这份指南的落地、实现以及产业的广泛应用需要大家的支持。
 

修改现行的法律显然是一个更符合逻辑的做法，但是由于技术社区似乎觉得他们对改善问题重重的美国司法体系很难起到积极作用，因为显得积极性不高。
 

这里公众的影响就十分必要了。他们可以促使公司们同意保护那些无辜的从事安全领域研究的人，以及从根本上改变《美国数字千年著作权法案》。W3C非常关注在现行司法体系下遇到麻烦的安全领域研究人员，并愿意跟踪他们的相关进展，寻求解决之道。

Web的未来

只有普世的Web才能发挥其全部作用。Web不仅应该能够可以承载现存的各种疯狂想法，也须要能够保存本世纪那些人类思想成果的精华。Web必须能够符合各种语言和文化的需求，能够包容各类信息及各类媒体。Web的普世性还应该包括对免费事物和收费事物的支持，因为这是当前世界的客观现实。这就意味着，Web能够支持电影等内容是一件好事，那么HTML5包含EME总比不包含要好。

更多内容，请参阅英文原文 W3C Blog: On EME in HTML5。更多W3C博客文章，请参阅W3C官方博客。

W3C宣布已完成了所有的服务器升级，为W3C的所有开放资源提供基于 HTTP 及 HTTPS 的访问方式，全面支持安全加密及认证访问。W3C 在 2015年技术架构组（TAG）的一份报告中倡导在 Web平台中采用安全通信技术（secure communication）。W3C感谢近期Web应用安全工作组（Web Application Security Working Group）的工作，客户端（浏览器）实现的支持，以及W3C系统团队细致的部署升级工作。到目前位置，我们已经能够为所有 W3C的开放资源（包括 W3C的英文网站、各工作组制定的技术规范、文档、各类DTD、词汇表等）提供基于 HTTP 的访问，从而支持对内容的机密性、完整性、认证性保护。

升级具体内容及可能存在的副作用包括：

－支持 Upgrade-Insecure-Requests HTTP 请求头，透明地将 HTTP 请求升级为 HTTPS 请求。这一特性需要浏览器支持。

－支持 Strict-Transport-Security HTTP 请求头（HSTS），通知浏览器对 w3.org 域的访问请求透明地升级为安全请求。目前，所有近期发布的浏览器版本都已提供对这个请求头的支持。 

－为保持兼容性，我们并没有在服务器端将所有 HTTP 请求重定向为对应的 HTTPS 请求。

－升级可能导致在某些代理服务器配置条件下出现重定向的死循环，部分不支持 Strict-Transport-Security 请求头的浏览器版本可能提示“混合内容（Mixed Content）"告警信息。

关于通过 HTTPS 访问这些开放Web资源带来的变化、挑战以及一些可能的副作用，请参阅 W3C的博客文章：W3C 官方网站提供 HTTPS 和 HSTS 协议支持（W3C Blog: Supporting HTTPS and HSTS on w3.org）。 

W3C的安全领域负责人Wendy Seltzer发布博客文章，呼吁加强Web协议和格式的安全设计，保护个人及群组的网络通信及隐私。

2013年秋，全球互联网及Web领域的技术组织联合发布了关于未来互联网合作的蒙得维的亚声明，2014年2月11日，许多Web组织发起了The Day Web Fight Back活动，反对无处不在的网络监控行为。我们呼吁互联网及Web技术社区关注这一问题，并帮助我们建造更加安全、提供隐私保护的Web及互联网基础设施。

在W3C，已经在安全和隐私保护方面开展了相应的努力。

> 欢迎您关注并加入W3C的隐私保护兴趣组（Privacy Interest Group）及Web安全兴趣组（Web Security Interest Group）。 

> W3C致力于开发技术标准，帮助构造安全的Web应用，如跨源资源共享（CORS）、Web加密API（WebCrypto API）等。

> W3C与IAB将于2014年2月28日-3月1日在英国伦敦联合举行主题为“增强互联网　应对网络监控”的研讨会（Workshop on Strengthening the Internet Against Pervasive Monitoring）。

W3C承诺协助建造更加安全的Web，W3C的标准采用开放、多方参与的流程，并给出所有决定的技术依据。 欢迎您加入我们的努力，共同提升Web的安全。

本文的英文原稿，请参阅 W3C Blog: Strengthen Web Security on the Day We Fight Back。

欢迎您使用W3C官方博客及W3C中国网站参与互动讨论。   

W3C的Bernard Gidon 9月20日发表官方文章，欢迎服务器及移动安全解决方案供应商SSL Europa加入W3C。SSL Europa的目标是建立面向移动设备（平板电脑及智能手机等）的数据隐私保护及安全数据传输解决方案。

更多信息，请参阅博客文章 W3C Blog: SSL Europa joins W3C to promote a more secure Web

更多关于W3C官方博客的信息，请参阅W3C官方博客新闻页。

欢迎您使用W3C官方微博及W3C中国网站参与互动讨论。

W3C的追踪保护工作组（Tracking Protection Working Group）后续标准进展文本的决定（Group Decision）。为推动工作组的参与各方在Do Not Track标准的进展，工作组审阅并最终拒绝了Digital Advertising Alliance及其支持者提出的提案。决定重申了追踪保护工作组的使命是“通过定义表达用户对Web追踪（Web Tracking）的用户偏好的机制，提高用户对隐私的控制和保护能力”。

更多信息，请参看W3C Blog：Establishing the Meaning of Do Not Track。 

更多W3C Blog信息，请参阅W3C博客文章、W3C Blog。