【AICon】AI 大模型超全落地场景&最佳实践 了解详情
写点什么

只有 Chromium 的 Web 会是什么样子?

  • 2022-08-05
  • 本文字数:3528 字

    阅读完需:约 12 分钟

只有 Chromium 的 Web 会是什么样子?

8 月 16 - 19 日,与零一万物李开复、蔚来李斌、面壁智能李大海,及工商银行、交通银行、华夏银行等 100+ 行业专家相聚 FCon x AICon

本文最初发布于 Mark Nottingham 的个人博客。


网络的大部分复杂性和细微差别都被塞进了浏览器引擎中。尽管开发和维护这些引擎是一项巨大的负担,但幸运的是,世界上有三大浏览器引擎,而且它们都是开源的。


许多人认为,浏览器引擎的多样性是开放网络的基础,不仅保证了互操作性和用户的选择权,而且是保护网络不被集中化的堡垒。


因此,当我最近从一位消息灵通的人士那里听说 “Chromium 社区中的许多人正主张建立一个只有 Chromium 的 Web”时,我的耳朵嗡嗡作响。虽然长期以来,Chrome 团队(及其朋友们)一直在抨击其他浏览器,认为它们实现前沿 Web 扩展的速度太慢,但主张只有一个浏览器引擎的 Web 步子也太大了吧。


更新:请查看下文 Chromium 相关人员的回复。


表面上看,这是有一定道理的。毕竟,一段时间以来,W3C 和 WHATWG(网页超文本应用技术工作小组)的规范都是用算法(而不是声明性的)编写的,为什么不集中在一个现行的代码库上呢?这样一来,像 HTML 解析这样的互操作就完美了,而且人们仍然可以选择提供自己所需功能(如隐私保护)的浏览器。


这也没那么牵强,微软已经为 Chromium 抛弃了自己的引擎,Mozilla 的健康发展和长期(甚至是中期)生存能力令人担心,而距离苹果不得不向其他引擎开放 iOS 只差一步之遥。


毕竟,代码决定了浏览器的能力,因此也就定义了 Web 的形态。Chromium 已经在浏览器引擎中占据了很高的市场份额,为什么不直接将其正式化呢?


抛开人们可能提出的关于多样性、风险管理、创新等方面的诸多观点,我想把重点放在一个潜在变化的方面——治理。


现在,要想使某些东西成为“Web”的一部分,你需要说服一个浏览器引擎来实现它。然而,他们不会立即冲上去悄悄地把活干了,毕竟他们都同意在一个标准制定组织(SDO)中共同定义什么是“Web”,而这个组织通常是 W3C。


我不打算把 Web 标准的制定过程描绘成某种“技术让世界更美好”的理想乐土,其实这个过程混乱、缓慢、令人痛苦,而且结果也不一定总是好的。它有可能被内部人员所控制,有时他们的动机并不纯粹。


尤其是 W3C,它长期以来都存在着治理问题,现在才开始着手解决,例如如何超越 TimBL-as-BDFL 的模式,以及如何超越会员制组织,成为一个真正代表全球公共利益的管理者,此外,它还要平衡浏览器实现者和其他各方出于不同动机而提出的不同需求。


不过,W3C 也有优点:它有明确的决策过程,以及指导决策的文件。决策是透明的,而且允许上诉。领导职位是由社区以民主方式确定并对社区负责,参与的唯一结构性障碍是经济上的,不过,它也为那些有能力做出贡献但无力承担费用的人提供了参与便利。因此,该组织是真正的多利益相关者,不仅有来自大型科技公司的代表,还有来自小型公司的开发者、Web 作家、学术团体、政府部门、民间团队以及安全、隐私和可访问性等方面的倡导者。也有这样一个演变的过程。


所有这些都有助于保证该组织的合法性,也就是说,人们广泛认可它是管理这一领域(在这种情况下,Web 的发展)的权威。


虽然在理论上,这对某些 Web 用户来说可能很重要,但我认为,真正起作用的是政府,他们多年来对互联网采取不闻不问的态度,但现在却对监管互联网(或其某个部分)变得非常感兴趣。


尽管表面上看,他们并不急于这样做。大多数熟悉监管过程的人都痛苦地意识到,它可能带来各种各样的问题,我的“监管政策和实践”课程基本上就是一连串重大监管失败的案例。


也就是说,如果有什么方法能替代严厉的监管,则是值得认真考虑的,特别是当被监管对象是一个全球公共产品时,甚至需要在多个司法辖区之间进行协调。


如此看来,如果 SDO 提供了一种合情合理的治理替代方案,并且与政府的目标相一致,为什么不采用呢?到目前为止,这已经奏效。例如,即使 CMA 非常关注 Chrome 浏览器修改 Cookie 对广告市场造成的影响,但它还是有意识地承担了观察员的角色,观察谷歌在标准制定过程中的表现。


那么,当 Chromium 成为唯一的浏览器引擎时会发生什么?在我看来有两种可能性,其结果大致相同。

首先,在一个只有 Chromium 的未来世界里,Web 治理完全脱离了开放标准,那么 Web 会变得更像 Linux——有些东西基于历史标准,然而现在和未来却被开源实践所牢牢控制。


另一个稍有不同的未来是,Chromium 仍然利用 Web 标准流程进行广泛的评审和社区参与,但由于其权力增加(人们对 W3C 治下的浏览器已经有这样的抱怨),实际掌控浏览器的是实现者,而 SDO 只是随波逐流(甚至比现如今更严重)。


不管是哪一种,Web 发展要么掌握在一个开源项目手中,要么完全由一个项目主导,而这个项目在上面列出的支撑其合法性的许多方面都明显不足。


虽然从任何人都可以浏览源代码(如果他们理解的话)的意义上来说,它是透明的,但从决策方面来说,它并不透明。虽然它是开放的,任何人都可以成为提交者,即使他们不为谷歌工作,但有一个进入的壁垒,那就是你必须编写代码,得到三名现有的提交者提名和确认,而且还得没有其他人反对。问责制和上诉机制是不透明的,据我所知,发生什么事取决于提交者之间的政治行为。


当然,Chrome 团队和其他 Chromium 人员将继续广泛征求意见,以确保人们了解其决定的影响,他们以数据驱动和一丝不苟而闻名。不用质疑他们的意图(至少在我看来),更根本的问题是,我们如何组织社会上的各方,以保证重要决定的做出过程没有任何问题?还有,什么样的 Web 治理才能被视为合情合理?


回到和 Linux 的类比,你可能会说:”那又怎样?Linux 基金会完全有能力管理 Linux,由 Linus 掌舵。这有什么区别?“


关于 Linux 基金会和 Chromium 治理的具体差别,以及 Linus 和 Tim 有什么不同,就留给其他人来比较了。比较重要的一点是,在政府眼中,SDO 已经存在合法性缺陷,把治理降级到一个松散的,由 GOOG 主导的开源项目,方向就走错了。


政府本就已经怀疑大型科技公司影响 SDO,我强烈怀疑,在一个只有 Chromium 的世界里,政府将会认为,对于 Web 这种如此重要的东西进行开源治理是不正当的。虽然目前,在大多数情况下,他们还是愿意听从 SDO 的意见,但开源管理不会得到同样的待遇,浏览器可能会像许多其他产品一样受到监管,由政府主导制定严格的设计标准。我曾经写过一篇文章,探讨这条路上的陷阱。简而言之,预计会出现碎片化和僵化现象。


如果你认为 Cookie 是唯一可能发生干预的地方,请考虑加密、可访问性、浏览器指纹,还有数字版权管理(DRM),当它们都被多国政府或多国政府集团监管时(就像贸易越来越多地被区域贸易协定所监管一样),Web 会变成什么样子?


需要说明一下的是,就其初衷来说,我认为开源治理是很好的——监督一个其他人可以选择的软件项目的设计与实施。但这里的问题是,对于已经成为关键基础设施和全球公共利益的东西,它不能替代精心设计的,涉及多方利益相关者的治理。


我很想知道,Chromium、Chrome 以及谷歌的高层人士对此有何看法,这可能只是一名初级工程师对开放标准流程的困难和缓慢所做的不满情绪的发泄,或许也不是。可以说,将 HTML、DOM 和其他核心 Web 基础设施从 W3C 剥离到 WHATWG,这个非常具有开源色彩的浏览器引擎供应商俱乐部,是朝着这个方向迈出的第一步,而这并没有导致任何明显的负面后果。


更新:Jake Archibald 在 Twitter 上的回复:


不,只有 Chromium 的 Web 不是 Chromium 的目标,也不是社区能够接受的观点。


然后,他又说:


作为一名 IE 时代的开发者,以及一个必须在 iOS 上交付的人,我非常清楚浏览器一元化的危险性。


很高兴听到这样的说法,我真的很欣赏 Jake 的坦率。在我看来,他是一个值得信赖的人,也是一个行事时以 Web 最佳利益为优先考虑的人。


然后,另一位在社区中有着良好声誉的工程师 Sam Sneddon 也插话说:


姑妄听之:我也听到一些人对只有 Chromium 的 Web 持有积极的看法,大多数是在我接触 Chromium 社区还比较多的时候听到的。我不认为这代表了大多数人,但我认为这是一个值得注意的少数。


后来,Jeffrey Yasskin(也是 Chromium 项目的人,在我看来也是一个有道德、有思想的人)新开了一个帖子:


只有 Chromium 的 Web 绝对不是我们的一个目标,但至少,我认为那是相当可能发生的。我认为有四种可能 [...]


所以,随你怎么想。就我个人而言,我的结论是,即使是在一个多引擎的世界里,我们也需要更多的投入并负起责任,而不仅仅是由着一群浏览器供应商就 Web 应该是什么达成一致。SDO 应该努力填补这一空白,不仅仅是制定技术规范,而且还要做对社会有益的事,这样,他们才会被认为是合法的。


这并不是说,他们有民主的权威,有所有的答案甚至总是能把事情做对。他们真正的优势是世所罕有的专业人士的集中,全球性的视野以及其他方法更糟糕的事实。


查看英文原文:


https://www.mnot.net/blog/2022/06/22/chromium-only.html.brotli?

2022-08-05 17:255584

评论

发布
暂无评论
发现更多内容

Linux下TCP网络编程-创建服务器与客户端

DS小龙哥

3月月更

区块链等技术助力北京海关监管

CECBC

开放报名丨《音视频社交新风口》线上峰会,聚焦海外社交生态升级

融云 RongCloud

kubeadm工作原理-kubeadm init原理分析-kubeadm join原理分析

良凯尔

容器 云原生 kubeadm #Kubernetes# Kubernetes 集群

架构实战营-模块一-作业

CityAnimal

架构实战营 #架构实战营 「架构实战营」

java版gRPC实战之四:客户端流

程序员欣宸

gRPC grpc双向流

java版gRPC实战之六:客户端动态获取服务端地址

程序员欣宸

gRPC grpc双向流

基于服务网格的分布式 ESB, 实现应用无关的传统 ESB 转型升级

BoCloud博云

微服务 ESB

“中本聪岛”加密乌托邦

CECBC

数字医疗时代的数据安全如何保障?

CECBC

Flutter 路由及路由拦截跳转404

岛上码农

flutter ios Android开发 移动端 3月月更

黑匣子为什么难成为“云匣子”?

脑极体

面试突击35:如何判断线程池已经执行完所有任务了?

大发导师带赚计划

Java java面试

[Day3]-[快慢指针]解决链表问题

方勇(gopher)

LeetCode 数据结构与算法

在线正则表达式大全测试

入门小站

工具

融云猿桌派:35 岁程序员,正值当打之年,尚有星辰大海

融云 RongCloud

程序员

在线Javascript美化格式化工具

入门小站

工具

java版gRPC实战之五:双向流

程序员欣宸

gRPC grpc双向流

TDengine 助力国产芯片打造“梦芯解算”,监测地质灾害 24 小时无间断

TDengine

数据库 tdengine 物联网

URL的四种形式对比说明

源字节1号

前端开发 后端开发 网站开发

一文带你了解 Python 中的生成器

踏雪痕

Python 生成器 3月程序媛福利 3月月更

超分算法在 WebRTC 高清视频传输弱网优化中的应用

融云 RongCloud

PyTorch

java版gRPC实战之二:服务发布和调用

程序员欣宸

Java gRPC

java版gRPC实战之三:服务端流

程序员欣宸

gRPC

JavaScript数组,看这篇就ok了!

坚果

3月月更

区块链架构下 智慧城市发展加速

CECBC

服务器防渗透--信息收集

喀拉峻

网络安全

Linux之file命令

入门小站

Linux

java版gRPC实战之七:基于eureka的注册发现

程序员欣宸

gRPC 注册中心 eureak

Paxos vs. Raft:我们对共识算法达成共识了吗?

多颗糖

分布式系统 raft PAXOS

小程序电商业务微服务拆分及微服务基础设施选型

Geek_36cc7c

只有 Chromium 的 Web 会是什么样子?_开源_Mark Nottingham_InfoQ精选文章