2017年3月2日

Firefox <3 Tor Browser

如果你曾用過 Tor,你很可能用過 Tor 瀏覽器;如果你用過 Tor 瀏覽器,你就用過 Firefox。Tor 瀏覽器幾乎就是 Firefox - 雖然有改動和增加一些程式碼,但 Tor 瀏覽器中 95% 左右的程式碼來自 Firefox。Firefox 和 Tor 瀏覽器團隊已經合作了很長一段時間,但在 2016 年,我們開始了前所未有的緊密合作,藉著這些合作,Tor 瀏覽器團隊能更順利的進行他們的工作,為 Firefox 使用者加入更多的隱私性功能,並且讓兩個瀏覽器都更安全。

Tor 瀏覽器團隊利用 Firefox ESR(企業版),再加上一些額外的 patch,來建造 Tor 瀏覽器。這些 patch 提供了 Tor 瀏覽器使用者們重要的隱私功能,但也表示每當 Tor 瀏覽器團隊要使用一版新的 Firefox 時,他們必須修改那些 patch 以符合新版的 Firefox,這樣的工作佔了 Tor 瀏覽器開發大部份的時間。

2016 年,我們開始將 Tor 瀏覽器的 patch 拿來,uplift 到 Firefox。當一個 patch 被 uplift 時,我們把 Tor 瀏覽器的改變加進 Firefox,預設都設為關閉,但可以透過設定開啟。這使 Tor 瀏覽器團隊的工作減少了,因為他們只需要更改設定,而不用更新 patch。這也讓 Firefox 團隊有機會測試 Tor 瀏覽器先進的隱私功能,考慮是否能進一步開放給更多的使用者。

這個 uplift 專案的第一個目標是一個叫 First Party Isolation(譯註:第一方隔離?)的功能,它提供了非常強的反追蹤保護(但可能會使某些網站無法正常顯示)。Mozilla 組成了一個專門的團隊(譯註:有我有我!Fixed bugs 有 12 個是我解的哈哈),使用當初實作 Containers 的技術,將 Tor 瀏覽器中的 First Party Isolation 功能實作到 Firefox 中。這個團隊也透過自動化測試和 QA 的協助來確保 Firefox 的隔離至少和 Tor 瀏覽器一樣強,甚至找到了一些 Tor 瀏覽器可以更加強的地方。這段時間內,Mozilla 的團隊和 Tor 瀏覽器的團隊合作密切,包含每週的視訊會議,以及九月的一次面對面會議。

First Party Isolation 將會被包含在 Firefox 52 中,而 Tor 瀏覽器的下一個版本也會建立在這之上。因此,Tor 瀏覽器團隊將不需要再為這個版本更新 First Party Isolation 的 patch。在 Firefox 中,First Party Isolation 預設是關閉的(因為相容性的問題),但 Firefox 使用者可以透過將 about:config 中的 privacy.firstparty.isolate 設為 true 來打開這個功能。

我們很興奮能在 2017 年持續這份合作。首先我們很快會開始 uplift 一系列的 patch 來防止瀏覽器上的指紋分析 (fingerprinting)。另外對於 sandboxing,我們也會研究如何結合 Yawning Angel 已經在 Tor 瀏覽器上做的,和 Firefox 預計於 2017 年初開始釋出的 sandboxing 功能

最後,我們也不能忘記 Mozilla 和 Tor 專案之間持續合作解決各種安全漏洞。幾週前,我們雙方同時被通知了一個利用 Firefox 中的零時差漏洞針對 Tor 瀏覽器的攻擊。我們合作在 24 小時之內開發、測試、並修復了這兩個瀏覽器。

由 Firefox 和 Tor 瀏覽器團隊的合作,可以看出 Mozilla 的開放、自主參與的原則是如何推動網路的安全和隱私性。我們很自豪在 2016 年和 Tor 瀏覽器完成了這些,我們也期望能持續打造一個更安全且更注重隱私的網路。

原文 / Tor at the Heart: Firefox | The Tor Blog
作者 / Ethan Tseng and Richard Barnes
翻譯 / Po-Hsiang (Jonathan) Hao
授權 / 創用 CC 姓名標示 4.0 國際 授權條款

φ Irvin 編輯

2017年1月2日

Firefox 使用 Adblock Plus 時記憶體更省了

譯註:本文原文發表於 2015 年七月。2015 年 9 月發佈的 Firefox 41 已針對此問題進行更新,縮減了 Adblock 等類似情境下的記憶體用量,本文為問題與解決過程的概述,於 2016 年 5 月完成翻譯。

去(2014)年,我寫了一篇文章,討論 ABP 對 Firefox 的記憶體使用情況的影響,以下是該篇文章的重點。

第一點, 只要啟用 ABP,就會持續佔用大約 60~70 MiB 的資源。[…] 這看起來大概是因為有額外的 JavaScript 記憶體用量,也有部分原因歸咎於額外記憶體用於版面配置。

第二點,每一個 iframe 都會占用約 4 MiB 的資源。這是因為 ABP 會把一個龐大的樣式置入每一個 iframe 中。許多網頁上都會有多個 iframe,因此被占用的記憶體也會快速的增加。 舉例來說,如果我開啟了 TechCrunch,然後捲到每一篇文章中的社群網站按紐 […],在沒有開啟 ABP 的情況下,Firefox 使用了大約 194 MiB 記憶體,開啟了 ABP 後,占用的量變為 417 MiB,先前的兩倍以上。

還有一個更極端的案例是 這個網頁,它包含超過 400 個 iframes。在沒有 ABP 的情況下,Firefox 會使用大約 370 MiB 的資源,開啟了 ABP 後,占用的量就上升到了 1,960 MiB。(譯註:原始連結已消失,[1] [2] 是近似的重製頁面)

(其實這一段敘述不太精確;實際上的資源使用量是以「文件」(Document)數計算,包含了分頁中的最上層文件和 iframe 裡的文件。)

上個禮拜,Mozilla 的開發人員 Cameron McCormack 完成了一些補丁(Patch)修正  bug 77999,這個 bug 已經存在超過 14 年。這個補丁讓 CSS 的關聯資料能被共享(具體來說,這些補丁增加了一個資料結構來共享「使用者代理樣式表」的結果)就此完全解決了第二個問題,兩個問題之中比較重要的部分。

舉例來說,在上面提到的「極端例子」(概稱 Vim Color Scheme Test)裡,每個文件的記憶體用量都減少了 3.62 MiB。該網頁中有 429 個文件,總共減少了大約 1,500 MiB,讓該網頁的記憶體使用量下降到 450 MiB 左右,和沒有開啟 ABP 時相比已經沒有差那麼多了。(這些數據都是在 64 位元的架構下進行測試的。)

我也在多個網站上測試,並且確認當啟用 ABP 時,每個文件均能節省約 3.6 MiB 的記憶體。 不同網頁上的文件數目相差甚大,因此實際效果取決於頁面狀態(我想再針對 TechCrunch 做測試,但是它的首頁已經整個換新了,且不再觸發這麼大量的記憶體。)舉例來說,我在其中一個測試時分別打開了 紐約時報CNNBBC 的首頁和其中的四篇文章,總共有 15 個分頁。在包含了 Cameron 補丁的 Firefox 上啟用 ABP 時,可以少用約 90 MiB 的記憶體,減少了 10%以上。

就算沒有使用 ABP,這個補丁仍然有其他好處。比如說,在 Vim Color Scheme Test 裡,每個文件的實體記憶體用量都下降約 0.09 MiB,總共減少了 40 MiB 左右。

如果您想要自行測試的使用量的變化,您會需要 Nightly 版本的 Firefox 和 ABP 的開發中版本(因為最近出現了一個和 JavaScript 分析有關的錯誤,造成舊的 ABP 無法在 Nightly 上運作)。 在 Firefox 的 about:memory 頁面中,您可以發現「style-sets」的大小變小了。您也會在「layout/rule-processor-cache」下方看到一個新項目,這是新的共享資料的量測數據,它通常只有幾 MiB 而已。

這項改進已經準備放進 Firefox 41 ,並預定於 2015 年 9 月 22 日發佈。而其他釋出頻道的使用者,Firefox 41 Beta 預定將在 8 月 11 日釋出,而 Firefox 41 開發者版本則會於一、兩天內發佈。

原文 / Firefox 41 will use less memory when running AdBlock Plus | Nicholas Nethercote 作者 / Nicholas Nethercote

φ 蒼天炎劍 翻譯 - Kevin-WY、Irvin 編輯