Tag: firefox

利用字型來判斷使用者是否有安裝特定軟體

在 Hacker News 上的「TeamViewer installs suspicious font only useful for web fingerprinting (ctrl.blog)」這邊看到的技巧，原文在「TeamViewer installs suspicious font only useful for web fingerprinting」這邊，但文章標題本身可以忽略。

這別提到的方法是，在安裝軟體時額外安裝一個特別的字型，然後網頁就可以透過 javascript 判斷這個字型存不存在，來得知使用者是否有安裝自己的軟體，接下來就可以走到不同的 flow：可以導引使用者下載軟體，或是透過 handler 拉起應用程式。

不過這也透漏出了隱私問題，代表廣告商可以利用這點取得 fingerprint，而不只是軟體自家的網站。

看討論串裡面說 Firefox 上可以用 privacy.resistFingerprinting 擋住：「Firefox's protection against fingerprinting」，但 Firefox 本身也沒有說明的太清楚到底會放行哪些字型：

Not all fonts installed on your computer are available to webpages

在「Security/Fingerprinting」這頁則是：

We only allow specific system fonts to be used, and we ship them to the user using kinto

直接試著找 Bugzilla 與 source code 的資料可以翻到「Restrict CSS font visibility to standard fonts only when privacy.resistFingerprinting is true」這個討論，裡面有提到「https://searchfox.org/mozilla-central/search?path=StandardFonts*.inc」這個，可以看到有 Linux、macOS 與 Windows 10 下的清單。

不過 Chromium-based browser 下目前好像沒看到方案...

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)」這個版本。

從 Mozilla 官網下載的 Firefox 帶有追蹤用的標籤

前天看到「Each Firefox download has a unique identifier」這篇報導，就順手貼到 Hacker News 上面了：「Each Firefox download has a unique identifier (ghacks.net)」。

簡單的說就是 Mozilla 在 Firefox 的 binary 裡面加上 download token，後續就可以追蹤使用者：「[meta] Support download token」。

依照報導所提到的，每次下載 binary 都會有不同的 token：

在「Attached file dltoken_data_review.md — Details」裡面有回答更多細節，像是跟 Google Analytics 綁定：

5) List all proposed measurements and indicate the category of data collection for each measurement, using the [Firefox data collection categories](https://wiki.mozilla.org/Firefox/Data_Collection) found on the Mozilla wiki.   

<table>
  <tr>
    <td>Measurement Description</td>
    <td>Data Collection Category</td>
    <td>Tracking Bug #</td>
  </tr>
  <tr>
    <td>A download token that uniquely corresponds to a Google Analytics ID</td>
    <td>Category 4 "Highly sensitive or clearly identifiable personal data"</td>
    <td>Bug 1677497</td>
  </tr>
</table>

我自己重製不出來 (都是被導去 CloudFront)，但留言區裡面的 Yuliya 透過 Tor 有重製出來：

I have tried some TOR exit nodes:

Name: Firefox Setup 98.0.1_germany.exe
Size: 55528896 bytes (52 MiB)
SHA256: 2d8164d547d8a0b02f2677c05e21a027dc625c0c1375fd34667b7d039746d400
SHA1: 71302acbee6895b84cf0dfae99050926f2db59ef

Name: Firefox Setup 98.0.1_austria.exe
Size: 55528896 bytes (52 MiB)
SHA256: a139a45dd5737ab981068ca2596b7fdfde15e5d4bc8541e0a2f07a65defd3e4e
SHA1: 28630a0aababa162ca9e7cbca51e50b76b9c3cff

I have labeled the file for the corresponding country of the exit node.

如果不願意換到 Chromium-based 的方案，目前在討論裡看到的替代方案是 LibreWolf，昨天裝起來後發現還行，應該也可以測試看看...

curl 的 TLS fingerprint 偽裝專案 curl-impersonate 支援 Chrome 了

先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」這邊提到 curl-impersonate 這個專案，試著修改 curl 的 TLS handshake fingerprint 讓偽裝的更好，本來只支援 Firefox，現在則是支援 Google Chrome 的 fingerprint 了...

作者寫的兩篇說明文章也可以看看：「Making curl impersonate Firefox」、「Impersonating Chrome, too」。

看起來愈來愈完整了，連 LD_PRELOAD 的用法也出現了，然後在 Arch Linux 上也出現 AUR 可以用了...

I have no capslock and I must scream

前幾天看到「I have no capslock and I must scream (marginalia.nu)」這個討論，原文的標題是致敬於「I Have No Mouth, and I Must Scream」這篇小說，所以就決定把原標題留起來好了...

原文在「I have no capslock and I must scream」這邊，在原文的後面提到了 Mozilla 的這張 ticket，應該就是寫這篇文章的「主因」了：「Replace the Text Encoding menu with a single override item Repair Text Encoding」。

這種行為也是為什麼即使 Chrome 愈來愈爛，也不打算跳去 Firefox 的原因...

修正 Curl 的 TLS handshake，避開 bot 偵測機制

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint，就可以知道你是用 Curl，這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare)，而剛剛看到有人投稿自己的 patch，試著將 Curl 修改成 Firefox 的 pattern：「curl-impersonate」，Hacker News 上的討論在這邊可以看到：「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (github.com/lwthiker)」。

作者有提到這次的 patch 偏 hack，不太可能整進上游，但希望未來改的乾淨一點，然後整進上游：

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel，也有人提出來說用 Google Chrome 的更好，不過我覺得有人開始做就已經很棒了 XD

用 Gecko Engine 寫的另外一個瀏覽器 Dot

Hacker News 首頁上看到 Dot 這個瀏覽器，平常看各種標語已經麻木了 (什麼 privacy enhanced 之類的)，讓鄉民看上眼的是，這是一個 Gecko 寫的瀏覽器，也就是 Firefox 的底層，而不是 Blink (就 Google Chrome 那個系列)：「Dot Browser – privacy-conscious web browser (github.com/dothq)」。

抓下來跑了一下，看起來就如同 GitHub 頁面上的警告：

Dot Browser is alpha software, and you will most likely experience bugs and issues!

目前功能也超陽春，還沒支援 extension 之類的東西... 不過是有內建 ad blocking 與 usercss 的能力，算是基本盤吧。

可以放著看看發展的如何...

Firefox 支援 HTTPS RR

在「Firefox 92.0, See All New Features, Updates and Fixes」這邊看到支援 HTTPS RR：

More secure connections: Firefox can now automatically upgrade to HTTPS using HTTPS RR as Alt-Svc headers.

在「Enabling HTTPS RR on release」這邊決定啟用的，使用的標準是「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」這個，可以看到目前還是 draft (draft-ietf-dnsop-svcb-https-07)。

HSTS 是 Trust on first use，也就是在第一次連線時 server side 會送出 HSTS header，之後瀏覽器遇到同一個網站時就會都強制使用 HTTPS。

如果要確保第一次也是強制使用 HTTPS，在這之前必須靠瀏覽器內建的清單 HSTS Preload List 才能確保安全性，這次的 HTTPS RR 算是補上這個缺口。

在使用者環境有 DNS over HTTPS (DoH) 或是 DNS over TLS (DoT)，再加上 DNS resolver 會檢查 DNSSEC 的前提下，整條環境就接起來了。

不過實際讀了 spec 會發現 SVCB RR 與 HTTPS RR 想做的事情太多了，話說愈複雜的東西愈容易出包，先放著觀望看看好了...