關閉 Firefox 的廣告蒐集功能

前陣子有提到 Mozilla 併購了廣告公司後,就在 Firefox 裡面實作廣告投放的蒐集功能:「Firefox 128 實作廣告投放蒐集功能 (Ad measurement)」,然後看到「Make Firefox Private Again (make-firefox-private-again.com)」這篇,網站是 make-firefox-private-again.com

其中的設定就是把 dom.private-attribution.submission.enabled 設為 false,透過 GUI 介面改記得也是類似的效果。

但 Mozilla 已經變成廣告公司了,後續應該只會有更多動作;而廣告公司熟悉的 PR 方法應該都會被拿出來用,至於對 open source community 有沒有用就再看看了...

網站名字的梗... 應該就是 Donald TrumpMake America Great Again 口號。

Firefox 128 實作廣告投放蒐集功能 (Ad measurement)

六月底的時候就有一些消息,然後這幾天熱起來了,先是 Hacker News 上這兩篇,在講 Firefox 128 (現在的 stable 版) 預設開啟了廣告蒐集行為:「Firefox 128 enables "privacy-preserving" ad measurements by default (mstdn.social)」、「"Firefox added [ad tracking] and has already turned it on without asking you" (mastodon.social)」。

這個消息剛好可以跟六月底的時候「併購」了 Anonym 這家廣告公司一起看:「Mozilla acquires ad analytics company, for some reason」。

愈來愈像廣告公司了...

Firefox 的 UI 修正方案

在「Firefox Proton UI userChrome.css fixes. (2021) (github.com/black7375)」這邊看到的,GitHub 上的專案頁面在「Lepton (old name: Proton Fix)」這邊。

作者先前有寫過,我在「Firefox 的 UI/UX 歷史」這篇,同一個 repository 裡面就包含了「修正方案」,補上了一些 icon,並且改了 css 效果。

不過我已經沒什麼在用 Firefox 了,而且目前看起來也不會回去了,看起來只有在交叉找問題的時候會用到...

一個檔案直接跑起大型語言模型的 llamafile

llamafile 是昨天很紅的一個專案,由 Mozilla Internet Ecosystem (MIECO) 弄出來的專案,可以使用一個檔案直接跑起大型語言模型的 HTTP server,讓你可以在瀏覽器裡面直接使用。

直接看官方的 README.md 就可以蠻簡單的跑起來,不過 Simon Willison 也有寫一篇文章介紹一下,可以看看:「llamafile is the new best way to run a LLM on your own computer」。

這邊說的「一個檔案」是指同一個檔案同時可以在 WindowsmacOSLinuxFreeBSDOpenBSD 以及 NetBSD 上面跑,而且這個檔案也把大型語言模型 (LLM) 的 model 檔案包進去,所以檔案會蠻大的,但畢竟就是方便讓人使用:

下載下來直接執行,預設就會在 port 8080 跑起來,可以直接連到 http://127.0.0.1:8080/ 連進去使用。

llamafile 用到的技術是 Cosmopolitan 專案,可以把多個平台的執行檔包在同一個檔案裡面使用。

另外用到的專案是 llama.cpp,這個蠻多人都用過了,可以很方便的用 CPU 或是 GPU 跑 LLM。

我在 Linux 上面跑剛好遇到幾個問題,都是在 README.md 上面有提到的。

第一個是 zsh 無法直接跑 llamafile (Ubuntu 22.04 內建 zsh 的是 5.8.1),這邊官方的建議是用 sh -c ./llamafile 避開:

If you use zsh and have trouble running llamafile, try saying sh -c ./llamafile. This is due to a bug that was fixed in zsh 5.9+. The same is the case for Python subprocess, old versions of Fish, etc.

另外一個對是 GPU 的支援,這邊跟你說加上 --n-gpu-layers 35 就可以用,所以一開始先用 sh -c ./llamafile --n-gpu-layers 35 試著跑:

On Linux, Nvidia cuBLAS GPU support will be compiled on the fly if (1) you have the cc compiler installed, (2) you pass the --n-gpu-layers 35 flag (or whatever value is appropriate) to enable GPU, and (3) the CUDA developer toolkit is installed on your machine and the nvcc compiler is on your path.

但可以看到沒有被 offload 到 GPU 上面:

llm_load_tensors: ggml ctx size =    0.11 MB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  = 4165.47 MB
llm_load_tensors: offloading 0 repeating layers to GPU
llm_load_tensors: offloaded 0/35 layers to GPU
llm_load_tensors: VRAM used: 0.00 MB

嘗試了不同的方法,發現要跑 sh -c "./llamafile --n-gpu-layers 35",也就是把參數一起包進去,這樣就會出現對應的 offload 資訊,而且輸出也快很多:

llm_load_tensors: ggml ctx size =    0.11 MB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  =   70.42 MB
llm_load_tensors: offloading 32 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 35/35 layers to GPU
llm_load_tensors: VRAM used: 4095.05 MB

玩了一下像是這樣:

Firefox 宣布從 Mercurial 換到 Git

Firefox 宣佈從 Mercurial 換到 Git:「Firefox Development Is Moving From Mercurial To Git」。

目前是 Mercurial 與 Git 都支援,理由是不想要維持兩套:

For a long time Firefox Desktop development has supported both Mercurial and
Git users. This dual SCM requirement places a significant burden on teams which
are already stretched thin in parts. We have made the decision to move Firefox
development to Git.

不過不知道決策的過程到底是怎麼產生的,算是 Mozilla 的老問題了...

Firefox 的 :has() 支援度問題

Can I Use... 上面的「:has() CSS relational pseudo-class」裡面可以看到 Firefox 一直都還沒支援,只有在 nightly 版本上面預設有開,這也代表還沒辦法很穩定的用這個 selector... (除非你直接忽略掉 Firefox)。

看到「Prodding Firefox to Update :has() Selection」這篇,Eric Meyer 在抱怨 Firefox 的這個問題,就算是 nightly 的版本也還是有奇怪的 bug,會抓不到 :has() 條件,需要用 contenteditable 的 workaround 觸發 Firefox 的計算。

MozillaBugzilla 上可以看到票還開著:「Implement the :has() pseudo class」,看起來這陣子是一直有在更新,應該是有資源在上面追進度。

等到真的支援,就可以在 querySelectorAll() 裡面直接用 :has() 了,現在 Firefox 的情況讓 Userscript 寫起來有點卡...

Mozilla 推出在本地端直接翻譯的 Firefox Translations

Mozilla 推出了「Firefox Translations」這個 Firefox 上的套件。

主打的就是 offline 這件事情,保有隱私性:

Firefox Translations provides automated translation of web content. Unlike cloud-based alternatives, translation is done locally, on the client-side, so that the text being translated does not leave your machine.

Hacker News 上的討論「Firefox Translations: Translate websites in your browser without using the cloud (addons.mozilla.org)」可以看到有些人有提到效果,雖然沒有像雲端服務的準確,但算是可用:

I've just installed it, and I'm impressed so far. I've only run it against some sample German Wikipedia articles (https://de.wikipedia.org/wiki/Clan_of_Xymox), but it produces surprisingly readable text. I also particularly like the "highlight potential errors" option to flag stuff that even the translation service thinks might be a bit off.

It's not nearly as speedy as Google Translate, but I'll take that happily if it means keeping it local.

從頁面上列出的支援語言可以看出還是以歐美用到的語系為主,然後下方也有說明這個專案是包括其他計畫的贊助累積出來的:

Firefox Translations was developed with The Bergamot Project Consortium, coordinated by the University of Edinburgh with partners Charles University in Prague, the University of Sheffield, University of Tartu, and Mozilla. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 825303.

不過比較好奇的是在頁面上有提到 CPU 需要 SSE4.1 能力... 這樣就有兩個問題了,第一個是 browser extension 可以直接跑 SSE4.1 指令集?另外一個疑問就是,AppleARM 架構就無法支援嗎 (應該也有類似的加速指令集),現在是 x86 限定?

A CPU that supports SSE4.1 extensions is required for this addon to function properly. If it doesn't, an error will be displayed when the translation is being started.

就算現在限制很多,看起來還是個很有前途的計畫,也許有機會移植到其他瀏覽器上?

Mozilla 把對各種規格的態度整理成一個網頁

查資料的時候看到「Mozilla Specification Positions」這個,可以看到 Mozilla 對各種規格的態度,分成幾個不同的類型。

有「under consideration」、「important」、「worth prototyping」這幾個從名字上就大概猜的出來意思,接下來的幾個比較有趣的是「non-harmful」、「defer」與「harmful」。

官方的說明是:

  • under consideration: Mozilla's position on this specification is being discussed.
  • important: This specification is conceptually good and is important to Mozilla.
  • worth prototyping: Mozilla sees this specification as conceptually good, and worth prototyping, getting feedback on its value, and iterating.
  • non-harmful: Mozilla does not see this specification as harmful, but is not convinced that it is a good approach or worth working on.
  • defer: Mozilla does not intend to look at this specification at all in the near future.
  • harmful: Mozilla considers this specification to be harmful in its current state.

所以之後看到一些標準時可以過來這邊看看 Mozilla 的態度...

Firefox 的 RCWN (Race Cache With Network)

前幾天 Hacker News 上看到「When network is faster than browser cache (2020) (simonhearne.com)」這則 2020 的文章,原文在「When Network is Faster than Cache」這邊,講 Firefox 在 2017 年導入了一個特別的設計,除了會在 cache 裡面抓資料以外,也會到網路上拉看看,有機會從網路上抓到的資料會比 cache 先得到,這個功能叫做 RCWN (Race Cache With Network):「Enable RCWN」。

開頭就先提到了有人回報 Firefox 上的 RCWN 似乎沒有明顯效果:「Tune RCWN racing parameters (and make them pref-able)」。

On my OSX box I'm seeing us race more than we probably need to:

Total network request count: 5574
Cache won count 938
Net won count 13

That's racing almost 16% of the time, but only winning 1.3% of the time. We should probably back off on racing a bit in this case, at least.

16% 的 request 決定 RCWN 兩邊打,但裡面只有 1.3% 是 network 比 cache 快。

不過作者決定試著再多找看看有沒有什麼方向可以確認,但測了很多項目都找不到哪個因素跟 cache retrieval time 有直接相關,反而在看看 Chromium 時發現 Chromium 是透過限制連線數量,降低 I/O 造成的問題:

It turns out that Chrome actively throttles requests, including those to cached resources, to reduce I/O contention. This generally improves performance, but will mean that pages with a large number of cached resources will see a slower retrieval time for each resource.

看起來就是個簡單粗暴的 workaround...

Firefox 的 UI/UX 歷史

Hacker News 首頁上看到「Firefox UI/UX History (github.com/black7375)」這篇,整理了 Firefox 的 UI/UX 歷史,裡面也試著分析各個不同版本的優缺點。

話說看到這個最早的版本的 screenshot 讓人懷念 (還叫做 Phoenix 的版本):

裡面也提到了一些 fork,像是「Early (v1 ~ v3)」這個 UI 版本的 fork 還可以在 SeaMonkey 看到。

到了「Classic (v4, 2011.3)」這個版本,目前還有在維護的 fork 則是 Pale Moon,不過核心的部份沒有跟上,很多網站的新功能是沒辦法用的。

接著是「Australis (v29, 2014.04)」這個版本,目前已經沒有在維護的 fork 了,2021 年年底 Basilisk 宣佈停止維護。

然後是「Photon (v57, 2017.11)」這個版本,目前還有在維護的 fork 是 Waterfox 的 G3 系列。

目前最新的一個是「Proton (v89, 2021.06)」這個版本。