12.24 為什麼我們最終拋棄 Chromium 選擇了 Firefox？

瀏覽器是用來顯示在萬維網或局域網等內的文字、圖像及其他信息的軟件，它還可以讓用戶與這些文件進行交互操作。本文中將介紹為什麼我們認為有必要創建自己的瀏覽器，為什麼我們選擇了 Firefox 以及為什麼我們認為這是正確的決定。

譯者 | 彎月

2015年，我們公司發佈了在 Firefox 基礎之上構建的桌面Web瀏覽器。在那之前，我們發行了多個作為 Firefox 插件的搜索和隱私產品。在本文中，我們將介紹為什麼我們認為有必要創建自己的瀏覽器，為什麼我們選擇了 Firefox 以及為什麼我們認為這是正確的決定。

為什麼創建自己的瀏覽器？

搜索是Web瀏覽體驗不可或缺的一部分，幾乎每個瀏覽會話都從搜索開始。所有現代瀏覽器用戶界面都將搜索直接集成到地址欄中。因此，瀏覽器是發行搜索產品的主要方式，2000年的時候，Google 通過創建 Chrome 瀏覽器推動他們的搜索產品時就意識到了這一點。如今我們也意識到了這一點，因此我們希望創建一款瀏覽器，並通過它發行我們的搜索產品，展示我們的願景。

此外，擁有平臺對於維持用戶體驗的控制非常重要。回顧我們的親身經歷也證明了這一點：當初我們的 Firefox 瀏覽器擴展使用的是舊的擴展API，這些 API 擁有很強大的修改瀏覽器UI方面的功能，我們利用這些功能構建了搜索下拉菜單。2017年的時候，由於這些 API 被棄用，我們也無法再通過 Firefox 發行該功能。幸運的是，這一次我們有了自己的瀏覽器。

其次，我們可以通過發行瀏覽器控制更多的用戶體驗。以前，主流瀏覽器對用戶隱私的關注十分有限。根據構建Web搜索的經驗，我們發現用戶的數據被收集，然後再由他人放到“自由市場”上出售。我們希望保護用戶，讓他們免受這種剝削，並在瀏覽器中貫徹應用隱私設計。

我們認為瀏覽器是用戶代理，“用戶代理是代表用戶實際動作的軟件（軟件代理）” 。瀏覽器代表互聯網上的用戶，因此我們有責任保護他們的隱私。我們在 Firefox 插件中實現了反跟蹤和反釣魚技術，這些技術可以直接集成到我們的瀏覽器中。

為什麼從其他瀏覽器上建立分支？

由於上述種種原因，我們決定構建和發行自己的瀏覽器。而且很顯然，我們無需更改現有瀏覽器運行良好的功能，而且在渲染性能和安全性方面，與現有瀏覽器競爭也沒有任何價值。相反，我們想在這些瀏覽器的基礎之上構建新功能。因此，我們不得不以現有的某個引擎為基礎建立分支（fork）。我們的思路是將該瀏覽器作為我們自己的新功能的平臺。

從長遠來看，這項決策可以讓我們的工作更加輕鬆。瀏覽器的發展非常迅速，我們必須經常更新，才能確保及時發行重要的安全補丁。在這種情況下，維護某個分支是非常艱難的工作，而且我們瞭解到，持續做好這項工作的唯一辦法是儘量減少與上游項目的差異。

最後，我們選擇以 Firefox 為基礎建立分支，因為我們的大部分代碼都是 Firefox 擴展，而且為了跟上 Firefox 上游的變動，我們將盡可能多的代碼封裝在擴展中了。

為什麼我們沒有選擇 Chromium ？

如今，以 Chromium 為瀏覽器的基礎已成大勢所趨。Opera、Yandex、Brave以及最近的微軟等眾多公司都朝著這個方向發展。對於我們而言，由於種種原因導致我們不清楚應該做怎樣的選擇：

• 與 Google 相比，我們更認可 Mozilla 的生存信念。我們與 Mozilla 的大部分價值觀都很接近，所以我們認為Mozilla是我們的盟友。在進行分支時，我們需要承擔風險， 比如上游維護者終止或修改我們所依賴的功能。我們認為 Mozilla 比 Google 更值得信賴，Mozilla 終止或修改某個功能的可能性更小；

• 考慮到壟斷的問題，我們認為支持 Firefox 更有意義。Blink / Gecko（Web渲染器）的市場份額並不是一件小事。如果所有瀏覽器最終都使用Blink（Google），則Web將會受到重創，因為開發人員只會優化和測試 Blink 渲染引擎。Web剛剛失去了一個獨立引擎（EdgeHTML），進一步加劇了這個問題。

還有技術上的原因：

• Firefox 提供了瀏覽器方方面面的開放API，大部分 Firefox 的“應用程序”代碼都是用JavaScript編寫的。相反，Chromium 不會暴露某些 Google 業務敏感的區域。最著名的例子就是地址欄。Google 不願意為其他人控制地址欄提供方便；他們只想保護默認

• 維護任何分支都是一場噩夢，因為項目的所有者（對於 Chromium 來說，大多數代碼都來自 Google 員工）可能激進地更改代碼，有時甚至破壞已有的集成，強迫他人跟上他們的步伐；

• Chromium不夠“穩定”。API的更改以及對舊API的支持缺乏持續性和一致性。以 Manifest v3 為例，它的安全、隱私和性能的基礎都不牢靠，因此很有可能會淘汰加強隱私的插件所依賴的一些強大且實用的API，最終會影響到這些插件本身。他們回溯了做出這些更改的初衷，但仍打算將改動繼續到底，對依賴這些API的人來說，這就是一場浩劫；

• Chromium 自帶很多無法輕易刪除的 Google 服務。微軟和 Brave 為了刪除這些服務，投入了大量資源。而一些其他的API，如屏幕閱讀器集成等API都是閉源的。

Chromium 是一款出色瀏覽器，帶有快速的渲染引擎，但維護它的分支需要投入大量資源。我們沒有這些資源，也不願意付出這些代價。事實證明，選擇 Firefox 的決定是正確的，因為隨著時間的流逝，集成我們的功能越來越容易，而 Chromium 已經棄用了對我們的項目至關重要的一些API。

我們的新瀏覽器的功能

我們的新瀏覽器自帶一些自家打造的功能，可以幫助用戶享受安全的私人Web體驗。以下是一些最重要的功能：

• 下拉列表：我們的搜索就在地址欄中。搜索結果會根據用戶類型顯示在下拉列表中，所以可以為你節省搜索結果頁面的時間。顯示的結果由我們的獨立、私有的搜索後端提供；

• 反跟蹤：我們實現了識別並阻止跟蹤器以及反覆嘗試指紋識別的算法，並根據數據不斷更新；

• 廣告攔截：通過高效的廣告攔截，為用戶打造快速、無廣告和煩擾的Web體驗；

• Cookie彈出窗口阻止程序：幫助用戶處理網站上彈出的強制同意窗口，自動處理模稜兩可的UX。我們會阻止數據的收集，而不僅僅是隱藏彈出窗口；

• 自動“忘記窗口”：對於

• 反網絡釣魚：防止用戶陷入釣魚網站，時刻確保用戶的安全；

• 用戶儀表板：顯示隱私狀態，例如阻止了多少廣告以及刪除了多少私人數據點。此外，還提供精選新聞，幷包括一些實用小程序，例如訪問次數最多的網站和書籤。

Firefox是一個偉大的平臺

我們建立 Firefox 分支已有四年多了，我們發現 Firefox 非常適合進行分支。它有一系列對分支非常友好的屬性：

• 該瀏覽器的UI能夠通過CSS定製主題，因此Web開發人員可以輕鬆地設計和調整UI；

• 該瀏覽器是模塊化的，基於 pref 的體系結構非常易於配置；

• 該瀏覽器建立在Web技術之上。開發人員可以更迅速地適應並開展工作。你還可以利用開發者工具調試整個瀏覽器；

• 該瀏覽器對於重新打包發行有著一流的支持，因此很容易在其之上建立其他品牌的遊覽器；

• 該瀏覽器支持非常強大的擴展，尤其是特權上下文，你甚至可以利用它深入瀏覽器的內部；

• 該瀏覽器允許你通過強大的配置腳本進行深度定製。

通用代碼庫

最初，我們利用原始、低級的瀏覽器API 開始構建 Firefox 的擴展。然而，在開始構建瀏覽器後，我們又希望將這些功能發佈到 Android 和 iOS 上的移動瀏覽器中。後來，我們希望在Firefox 57提供的 webextension API 之上運行我們的代碼。對於一個規模很小的團隊而言，確保環境以及代碼庫之間的業務邏輯一致是一項難題。

為了解決這個問題，我們決定利用 JavaScript 來構建我們的一切架構。我們利用同構且通用的 JavaScript 編寫業務邏輯，並在底層添加平臺特定的實現，以處理每個運行時的細節。我們的瀏覽器核心的代碼庫包含跨所有平臺產品的代碼：

• Web擴展、與 Chrome、Firefox 和 Edge的兼容；

• 使用 React-native 的 Android 和 iOS；

• NodeJS，用於測試和 headless 模式。

舉個例子，我們有一個搜索模塊提供給定查詢的結果。這是瀏覽器核心的一個模塊實現的。如前所述，結果的來源之一是瀏覽器的歷史記錄。這是平臺特有的功能，因此臺式機和移動設備上有不同的歷史數據庫。在構建時，綁定了相應的 JavaScript 實現，因此該搜索模塊可以查詢平臺的數據庫。搜索的用戶界面也有所不同：在桌面系統中，結果顯示在URL欄下方的內聯框架中，而在移動設備上，UI是使用 React-Native 實現的。兩種情況都會將查詢推送到同一個搜索實現中，並從中獲取結果。

Android

Cliqz Android：與許多 Android 瀏覽器一樣，Cliqz Android 是基於 Android WebView 的常規應用程序。不同之處在於它運行的是在React-Native運行時中運行的共享 JavaScript 代碼庫。我們的隱私保護功能（例如廣告攔截和反跟蹤功能）在 React-Native 線程中運行，並且還能夠攔截系統 WebView 中發送的網絡請求。我們通過這種獨特的方法提供這些功能，同時又無需派生完整的瀏覽器引擎。

Ghostery Android：在 Ghostery 與 Cliqz 聯合之後，我們決定升級 Ghostery Android 瀏覽器。我們的目標是在手機上提供完整的 Ghostery 體驗，因此我們決定在 Firefox上 構建新版的 Android 瀏覽器（名為Fennec）。在此次構建中，我們充分利用了 Firefox Android 提供的 WebExtension。這基本上是在模仿我們桌面系統的做法。

Fennec是一項偉大的工程項目，基本來說其本質是 Firefox，只不過是面向移動設備。它擁有 Gecko 渲染引擎和 SpiderMonkey JavaScript 引擎。最重要的是，它具有原生的 Android UI，可提供熟悉的外觀。

不幸的是，Fennec 的開發是一個非常複雜的過程。開發人員必須不斷地在不同層面和技術之間來回跳轉，才能實現新功能或修復bug。沒有多少開發人員能夠有效地在 C++、JavaScript和 Java 之間切換。

Mozilla 社區都明白 Fennec 架構的侷限性，因此該瀏覽器於2019年退休。

新一代 Cliqz 瀏覽器：根據 Fennec 的經驗，Mozilla 社區創建了一個全新的體系結構來創建 Android 瀏覽器。它的核心是 GeckoView。這是一款精心封裝的瀏覽器引擎，擁有精心製作的 Java API。任何開發人員都可以藉助 GeckoView，創建 Gecko 支持的瀏覽器，同時又無需編寫 JavaScript 或 C++ 代碼。GeckoView 只是一個“庫”，就像與 Android 一同發佈的 WebView。

但是 GeckoView 能夠運行 WebExtensions，因此，很適合我們公司。我們可以在 GeckoView之上構建漂亮的瀏覽器UI，並以 WebExtensions 的形式發佈共享的 JavaScript 代碼庫。這樣一來，我們就可以藉助我們迅捷的廣告攔截器，在速度方面與 Chromium 競爭，並從隱私保護的各個方面超過 Chromium 。

iOS

蘋果的iOS平臺也大不相同。用戶無法選擇默認瀏覽器，瀏覽器供應商也無法構建自己的渲染或 JavaScript 引擎。所有開發人員都必須使用常規的 iOS WebView（WKWebView）。所有瀏覽器供應商都必須受制於這種限制：Mozilla 甚至 Google 瀏覽器都“只是” iOS應用程序。

從根本上來看，我們的瀏覽器沒有什麼不同。我們利用 Firefox 建立了 iOS分支，為我們的瀏覽器建立了一個穩定的基礎。為什麼選擇 Firefox？因為這是一個開源、非常可靠、久經考驗的項目。但這不是唯一的選擇：DuckDuckGo 也將是一個不錯的選擇。

由於 iOS WebView 不具備運行擴展的功能，因此我們不得不自己動手創建一個。同樣，React Native 提供瞭解決方案：我們創建了一個混合應用程序，該應用程序運行的瀏覽器核心是經過我們大量修改的 Firefox 代碼庫中的 React Native。

值得一提的是，我們已經在 Firefox 之上建立了三個 iOS 分支，我們在建立分支時採用了不同的策略：

1. 與上游的同步很少的“軟”分支：事實證明，我們所做的實質性更改主要圍繞 WebView，因此維護難度非常大。我們選擇修改 Firefox 代碼，並使用雖然有年頭但功能更強大的 UIWebView 來提供隱私功能；

2. 常規同步的“軟”分支：失敗了，因為這限制了我們根據自己的喜好來設計瀏覽器的能力；

3. 使用 cherry-pick 方式選擇性同步的硬分支（當前版本）：這是到目前為止開發人員最喜歡的分支，因為你可以自由修改，同時不必擔心與上游發生衝突。

請注意，iOS 版的 Firefox 並不是一個發展速度非常快的項目。因此手動選擇安全修復程序仍然可行。

原文：https://0x65.dev/blog/2019-12-17/why-we-forked-firefox-and-not-chromium.html

本文為 CSDN 翻譯，轉載請註明來源出處。

閱讀更多 CSDN 的文章

關鍵字: 軟件 拋棄 Mozilla