只有 Chromium 的 Web 會是什麼樣子?
本文最初發佈於 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?
- 那些 Go 語言發展歷史上的重大決策
- 從趨勢到挑戰,一站式解讀作業系統運維和可觀測性
- 百萬級 Topic,騰訊雲的 Apache Pulsar 穩定性實踐
- Apache Doris 在思必馳的應用優化實踐:海量語音通話資料下,實時、離線一體的數倉架構設計實踐
- 愛數正式開源認知智慧開發框架 KWeaver
- 運維智慧化的三大關鍵技術
- “抄我的還‘反捅’我一刀”,Gary Marcus 發文駁斥圖靈獎得主 Yann LeCun
- 當出海成為必選項,企業如何構建全場景全生態技術底座?
- 數智底座必備能力三:快速構建創新應用
- Docker 多階段構建實戰 (multi-stage builds)
- 工作筆記之 SELECT 語句在 SAP ABAP 中的用法總結(上)
- 經久不衰的設計定律是不要讓我思考的設計
- 不要指望下一個像 GPT 這樣的大型語言模型會民主化
- Java 近期新聞:Helidon Níma、Spring Framework、MicroProfile、MicroStream、Kotlin 和 Piranha
- 一文入門 jQuery
- C 學習 ---__libc_open 函式的原理
- 監控系統工作原理
- 甲骨文新微服務框架 Helidon Níma:使用虛擬執行緒實現高效能
- 【雲原生 | 從零開始學 Kubernetes】二、使用 kubeadm 搭建 K8S 叢集
- Elasticsearch 聚合學習之四:結果排序