1

被浏览器厂商公开反对,想让你少看验证码的 WEI API 哪里出了问题?

 1 year ago
source link: https://sspai.com/post/81970
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

被浏览器厂商公开反对,想让你少看验证码的 WEI API 哪里出了问题?

1
被浏览器厂商公开反对,想让你少看验证码的 WEI API 哪里出了问题?
Shiau 等 2 位作者

你在上网的时候,有没有因为网络环境不稳定,连着被问过好几次是不是真人?

从数字到字母、拖动拼图旋转角度、选完所有包含消防栓的图片、按顺序点击了「麻辣香锅」,最后还要手动框选「我不是机器人」,网页加载的图标转了两圈,它邀请你再选一遍所有带公交车的图片。

究其原因,其实和网站保护自己不被机器人的涌入冲垮,以及防止网站内容被机器垃圾灌满有关,背后是一个共同的问题——网站并不能直接知道新来的访客是人是鬼。

2023 年 4 月 25 日,Google 的几位员工在 Github 公开了一份文档,主题是「对网络环境完整性的解释」。这份文档介绍了他们的新设计:网络环境完整性 API(Web Environment Integrity, WEI)。该 API 将允许网站通过第三方检测用户的浏览器是否「可信」,以检测访问网站的是否是机器人,也可以检测浏览器是否被修改过。

和之前 Google 讨论推出的 Topics API、FLoC 一样,WEI API 引发了广泛的讨论,浏览器厂商 Mozilla、Vivaldi、Brave 以及自由软件基金会直接公开反对这个 API,认为它破坏了互联网的开放性和公平性。另一些浏览器插件开发者认为,这个功能可以被用来阻止广告拦截插件。

面相省事又和善的 WEI API 为什么能激起如此激烈的拒绝?它到底做错了什么?

WEI 的目标是什么?可以解决什么问题?

根据 Google 官方的说法,WEI 有 4 个目标:允许网站评估访问者设备、软件和流量的真实性;提供一种兼具对抗性、可持续性的反滥用解决方案;与此同时,无需启用新的跨站用户跟踪技术;并继续允许浏览器在没有证明的情况下正常浏览网络。

可以认为,前 2 个目标是 WEI 的主要业务目标,而后 2 个目标则表达了 Google 针对 WEI 可能导致的新问题,提前表达的立场。

Google 表示 WEI 可以解决很多具体的问题,比如检测社交媒体操纵和虚假参与,即刷票、刷赞;检测广告中的非人类流量,避免广告主的广告曝光给了机器人;检测网络钓鱼;检测批量账户创建和批量账户劫持;检测网络游戏中的大规模作弊行为;检测用户的数据是否因为设备被感染而面临风险;检测通过密码猜测的账户接管尝试,即暴力穷举密码。

一言以蔽之,WEI 最主要的功能,就是可以帮助网站检测用户的设备是否安全、浏览器是否可信、使用浏览器的是否是真人。

WEI 如何工作?

在 2023 年 8 月,Android 版的 Chrome 就已经支持了 WEI。WEI 包含在 Chromium 之中——这是 Google 主导开发的开源浏览器,常见的浏览器比如 Google Chrome、Microsoft Edge,以及上文提到的持反对态度的 Brave,都是基于 Chromium 开发的。

WEI 的工作流程,如下图所示:

1

WEI 的工作流程

假设,用户在 Android 手机上使用 Chrome 浏览器,访问一个已经使用了 WEI API 的网页。那么当浏览器开始加载网页的时候,网页就可以调用 WEI API,向第三方证明者(也就是 Google Play)验证当前环境是否可信,然后根据验证结果来对用户展示不同的网页内容。

从网站开发者的角度,调用 WEI API 需要客户端和服务器的共同参与。先在客户端请求环境完整性证明,将其发送到自己的服务器。然后在服务器上,使用证明者的公钥验证证明信息是否有效,再根据有效的证明信息做出决策。

现在的网站是怎么做验证的?

既然 WEI 解释了自己的目的,要看它是否合理,就要看看它提出的这些问题,现在都是如何处理的,我们就能知道它的诞生能不能带来些实际的改善。

一、设备是否安全?

网页可以通过获取浏览器 User-Agent(UA)的方式,获取宿主设备的操作系统、CPU 架构等有限的信息,比如:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36

网页无法获取浏览器的宿主设备的全部信息,比如无法获取你的设备安装了哪些程序,也无法知道设备是否安全。

但是,以 Android 平台为例,App 可以调用系统 API 做到以上事情,比如获取你的 App 列表,判断你的手机是否由于 Root 而不再安全了。

浏览器通过 WEI API 开放了更大的权限给网站,让网站可以从第三方,也就是其他 App 或服务,比如 Google Play 得知设备是否安全

1

在 Android 平台上,网站判断设备是否安全的信息来源

因此,如果没有 WEI,现在的网站开发人员确实无法单纯通过浏览器来确认设备是否安全。

二、浏览器是否安全?

同样地,现在的浏览器没有相关的 API 来向网站开发人员报告自己是否安全。而网页的开发者,只能利用能获取到的有效信息,来判断用户所使用浏览器的状况,比如通过 User-Agent 知道用户使用的是什么浏览器、版本号是多少。

因此,如果没有 WEI,网站开发人员无法通过浏览器来确认浏览器是否安全。

三、使用浏览器的是否是真人?

前面我们提到了各种验证码。一般来说,简单的验证码有可能是网站自己开发的,比如让用户输入图片中的字符。而复杂的验证码,几乎都是网站使用了第三方的服务,比如选择图片、移动拼图等。

这些第三方服务可能会先分析用户的行为,同时使用第三方 Cookie 等可用于跨站跟踪的信息进行分析,如果觉得用户的行为比较像真人,则给出较为简单的验证码,甚至直接跳过验证码;如果觉得用户的行为比较像机器人,则会展示验证码,如果验证不通过甚至还会增加验证码的难度。

除了验证码之外,还有其他辅助手段可以进行真人检测。比如,一些爬虫会使用无头浏览器比如 Puppteer,而无头浏览器在不进行配置的情况下,User-Agent 内会有明显的 HeadlessChrome 标识。再比如,网站可以获取用户的 IP 地址并做出判断,如果 IP 地址对应着云服务厂商的数据中心或者 IDC 机房,那么用户是真人的概率就会相对较低了。

因此,与上面的 2 个问题不同,如果没有 WEI,网站也有大量的方式可以进行真人检测,只不过需要自己进行检测方案的设计和实现,或者使用第三方的验证码方案。需要注意的是,第三方验证码普遍使用可用于跨站跟踪用户的 Cookie。

WEI 可能会带来什么问题?

好,既然 WEI 看起来确实有用武之地,为什么它会被业界如此旗帜鲜明地抵制呢?

影响用户的浏览体验

WEI 宣称的一些目标,从技术的角度,可能无法对网站开发者形成强有力的约束,更像是建议性质。

网站在浏览器内显示的内容,完全由网站开发者控制,因此网站完全可以做到如果没有获取 WEI 证明,就不向用户展示正常的内容。所以「继续允许浏览器在没有证明的情况下正常浏览网络」这个目标能否实现,完全取决于网站开发者怎么做。因此,用户的浏览体验可能会因为 WEI 而受到损害。

当然,即使没有 WEI,网站依旧可以通过其他办法来影响用户体验:比如检测到用户开启了广告屏蔽插件,就不向用户展示正常的内容,或者展示引导用户关闭广告屏蔽插件的横幅。

产生新的跨站跟踪问题

Google 坦诚地表示,WEI 面临着一些需要解决的挑战和威胁,其中的核心就是用户识别与跨站跟踪问题。

根据 WEI 的机制,第三方负责出具浏览器环境是否可信的证明。第三方为了出具有效、可靠的证明,就必然会收集、分析用户的信息。因此,首要的挑战来自第三方。第三方证明者返回的证明如果包含较高的信息熵,则有可能被用来唯一标识用户,并被用于大规模跟踪用户。

此外,如果不同的网站开发者在站点之间重复使用第三方的证明,那么就和第三方 Cookie 一样,可以对用户进行跨站跟踪。

Google 正在研究相应的对策,来降低发生以上问题的风险。对于浏览器、网站和用户,Google 建议浏览器公开对证明者的资质要求,允许网站评估不同证明者的效用,允许用户选择使用哪些证明者。对于第三方证明者,Google 建议应该公开声明他们所证明的内容。此外,Google 在寻找验证证明是否具备低信息熵的方法,同时尝试对所有第三方证明者的证明强制执行顶级分区,让不同网站无法使用 WEI 来跨站跟踪用户。

(类似的讨论在隐私沙盒引入归因报告 API 时就出现过。)

对其他浏览器或爬虫不公平

浏览器厂商普遍存在这样的担忧,由于「第三方证明者」现在还只有一个 Google Play,未来这个证明者的认证可能也有 Google 的参与,Google 完全可以利用 WEI API 干扰其他浏览器的运行。除了本文开头提到的 Vivaldi,其他持反对意见的浏览器也发表了自己的观点。

Firefox 开发方 Mozilla 在 Github 表示:任何实现通用标准的浏览器都自动成为 Web 的一部分,如果试图限制这些选择,不利于 Web 生态系统的开放性,也不利于用户。与此同时,检测网络欺诈和无效流量是一个棘手的问题,Mozilla 有兴趣帮助解决。然而针对这个问题,Google 提出的 WEI 有明显的缺点,可能会阻碍许多现有的机器人网络访问,比如自动化测试、网页存档、搜索引擎的内容抓取。针对这些场景,WEI 提出的保障措施不太可能有效。

Vivaldi 浏览器在官方 Blog 中表示:如果一个实体有权决定哪些浏览器值得信任,哪些浏览器不值得信任,那么在默认情况下,任何新的浏览器都不会被信任,直到它们以某种方式向证明者证明它们是值得被信任的。最终,任何不支持 WEI API 的浏览器都会被排除在网络之外。

Brave 的 CEO 在社交平台上表示:Brave 浏览器虽然基于 Chromium 开发,但是不会附带 WEI API,就像禁用或取消 Google 放入 Chromium 中的许多其他垃圾一样。Brave 也在官网发布了一篇文章,解释为什么要拒绝 WEI。

1

Google 也在一开始的文章中就指出,以下绝不是 WEI 的目标:在客户端验证签名;干扰浏览器及其插件的正常功能;在不安全的上下文(非 HTTPS 连接)使用 WEI。其中的第 2 条,算是提前回应了浏览器与插件开发者的担忧,但 Google 还是没能给出真正称得上「解决方案」的回答。

2022 年全年,Google 广告业务的营收占总营收的 80% 左右,可以说它就是一家「广告公司」。Google 自然会希望保护广告主的利益,WEI 可以检测访问广告的非人类流量,避免广告主花冤枉钱给机器人看广告的问题。

对用户来说,从隐私保护的角度,Google 希望网站不要自己跟踪、分析用户,交给浏览器去做这件事。但网站和第三方证明者依旧有可能利用新的机制跟踪用户。而如果网站通过 WEI 证明的不同结果来展示不同的内容,用户的浏览体验可能收到损害。更何况即使没有 WEI,这样的事已经在发生了。

其他浏览器厂商则是担心 Google 通过 WEI API,形成自己既是运动员(浏览器)又是裁判员(第三方证明者)的局面,阻碍其他浏览器的正常运作与未来发展。它说自己不会这么干,可谁能保证它会像自己已经逝去的口号一样「不作恶」呢?

手握 Chromium 的 Google,可能还要在探索 Cookie 替代方案的路上再多走几年了。

> 下载少数派 客户端、关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK