Firefox 86 預設支援 AVIF 影像格式

在「Firefox 86: AVIF support enabled by default」這邊看到的消息,在 Firefox 86 (目前是 nightly) 預設啟用了 AVIF 影像格式,這是繼「Chrome 85 支援 AVIF」後另外一個主要的瀏覽器也跳下來支援了,大概再幾個月後就會推到 stable channel 上了。

不過想測試的人不用去裝 nightly,77 之後的版本已經支援,只是預設沒有啟用,可以透過 image.avif.enabled 開起來。

另外當初在「WebP 的檔案大小未必比 JPEG 小...」這邊剛好也有帶到 AVIF 的壓縮率不錯,不過演算法判斷非重點部位的細節會被吃掉,這點對於一般的網頁應該還好,但對於希望還是保留細節的網站,也許就不是那麼適合了...

Firefox 也打算淘汰 ESNI,改推 ECH

Firefox 也打算放棄 ESNI,改推 ECH 了:「Encrypted Client Hello: the future of ESNI in Firefox」。

目前的 85 版 (目前的 beta) 支援了 ECH draft-08,想要玩看看的人就可以測試了:

Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming.

另外一個要看的當然就是 Google 家的 Chromium 了,不過這個協定對 Google 的誘因應該是超大,有機會直接穿入中國市場... 只是不知道會不會自己搞一套 protocol。

Internet Archive 的 Flash 收藏

剛剛看到 Internet Archive 的這篇文章:「Flash Animations Live Forever at the Internet Archive」。

Internet Archive 把模擬器掛上去了,所以你可以直接在網站上用這些 Flash 程式:

Great news for everyone concerned about the Flash end of life planned for end of 2020: The Internet Archive is now emulating Flash animations, games and toys in our software collection.

看起來是透過 ruffle + WebAssembly 轉到瀏覽器上面跑:

Utilizing an in-development Flash emulator called Ruffle, we have added Flash support to the Internet Archive’s Emularity system, letting a subset of Flash items play in the browser as if you had a Flash plugin installed. While Ruffle’s compatibility with Flash is less than 100%, it will play a very large portion of historical Flash animation in the browser, at both a smooth and accurate rate.

You will not need to have a flash plugin installed, and the system works in all browsers that support Webassembly.

然後在「Software Library: Flash Showcase」這邊有一些 showcase 可以看,基本上就是測過沒問題的。另外在「Software Library: Flash」看起來就是整包了...

搜了一下以前有在玩的 Zookeeper,好像沒有在裡面...

Servo 將由 Linux Foundation 提供協助

Servo 是使用 Rust 開發的 web engine,先前是由 Mozilla 在後面支撐,在 Firefox 裡面也有使用 Servo 的 CSS engine,而 Servo 的 JavaScript engine 則是使用了 SpiderMonkey

但在今年 Mozilla 大幅重整組織後,Servo 的未來變得頗不明朗,直到現在公佈會由 Linux Foundation 提供協助:「Servo’s new home」。

The Servo Project is excited to announce that it has found a new home with the Linux Foundation.

這樣看起來暫時解決了一個大問題,開發的能量還得看看要怎麼補上來...

Firefox 83 推出 HTTPS-Only Mode

MozillaFirefox 83 推出了 HTTPS-Only Mode:「Firefox 83 introduces HTTPS-Only Mode」。

就如同名稱的說明,這個模式只會允許 HTTPS 的連線,主要的設計方式是把「開 HTTP 連線」當作一種特殊權限,就像 notification 之類的權限一樣:

When you enable HTTPS-Only Mode:

  • Firefox attempts to establish fully secure connections to every website, and
  • Firefox asks for your permission before connecting to a website that doesn’t support secure connections.

使用者會先在設定裡面開啟這個全域設定:

開了以後如果想要連 HTTP 網站,就會遇到阻擋:

這個功能真的不賴,馬上想到 Tor BrowserTails 應該都會改用這個,畢竟 Tor 的 HTTP 出口常常被搞...

我自己類似的保護措施是把 HTTP 頁面執行 JavaScript 的能力全部關掉,像是這樣 (這邊是 Brave 瀏覽器,是個基於 Chromium 的 fork):

然後對於需要 JavaScript 的 HTTP 頁面,我是透過「Simple JavaScript Toggle」暫時授權。

這樣至少在無法確認 integrity 的情況下不會執行 js,減少可被攻擊的面積...

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA,以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄:「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的,沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例,用 SSL Labs 的工具就可以掃出來問題:「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s),所以在 Android 上找不到一條完整的 trust chain:

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain,所以 Windows 上的 Microsoft EdgeGoogle Chrome 是不會有問題的 (這兩個都吃系統的 CA store):

Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料,就是 Android 那包)。

交叉比對中華電信自家的網站,像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組,可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA,但有兩種不同的 SHA256,可以翻到是:「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」,點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽,但卻不是每一個 CA 都有被所有瀏覽器認可,所以在設定的時候就得注意...

話說回來,現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency),的確是有辦法抓出所有的 Intermediate CA 沒錯,但瀏覽器幫使用者預載感覺好像怪怪的?

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料:

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack?

有風聲說司法部會把 Chrome 拆出 Google

看到這則新聞時決定讓子彈飛了一陣子,但好像沒看到什麼新消息:「Feds may target Google’s Chrome browser for breakup」,Hacker News 上也有討論可以翻翻:「Feds may target Google's Chrome browser for breakup (politico.com)」。

GoogleChrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站」這樣的事情),會直接先把 Google Chrome 拆出來的消息不算太意外。

不過大家對反壟斷調查更有興趣的應該是 YouTube 會怎麼被處理。網路上經常會看到「如何逃離 Google」之類的文章,Google 很多服務都有其他平台可以提供,或是 open source 軟體可以使用,但每次一講到 YouTube 時大家都很頭痛,都會提到 YouTube 的難以取代性,因為目前其他平台沒有一個是堪用的...

不知道什麼時候會發動調查...

Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站

在「Chrome exempts Google sites from user site data settings」這邊看到的新聞,引用的網頁是「Chrome exempts Google sites from user site data settings」,然後這篇也有上到 Hacker News Daily 上,所以 Hacker News 上的討論也蠻熱鬧的:「Chrome exempts Google sites from user site data settings (lapcatsoftware.com)」。

作者實際在 macOS 上拿最新版的 Google Chrome (86.0.4240.75) 測試,發現就算你針對 Google 自家的網站選了「Clear cookies and site data when you quit Chrome」,只有 cookie 會清掉,但 database storage、local storage 與 service workers 都不會被清掉:

然後 Brave 那邊前陣子時做完 Sync v2 了,又是個機會看看那邊如何了... 結果發現在 2019 年的時候意外修正了一部分:「"Keep local data only until you quit your browser" only deletes cookies, not local storage #1127」、「Fixes: #870 Replaced logic to clear data with WebKit api. #883」。

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

Google Chrome 的 Cache Partition 生效

去年提到的「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」在最近推出的 Chrome 86 預設生效了:「Chrome changes how its cache system works to improve privacy」。

Google 的文章「Gaining security and privacy by partitioning the cache」這邊有提到不同瀏覽器都有打算要支援類似的架構,對應的差異:

Is this standardized? Do other browsers behave differently?

"HTTP cache partitions" is standardized in the fetch spec though browsers behave differently:

  • Chrome: Uses top-level scheme://eTLD+1 and frame scheme://eTLD+1
  • Safari: Uses top-level eTLD+1
  • Firefox: Planning to implement with top-level scheme://eTLD+1 and considering including a second key like Chrome

文章裡面看到了有趣的東西,是他提到了 Fetch 這個標準,然後是在「2.7. HTTP cache partitions」這邊出現了對應的說明:

To determine the HTTP cache partition, given request, run these steps:

Let key be the result of determining the network partition key given request.

If key is null, then return null.

Return the unique HTTP cache associated with key. [HTTP-CACHING]

所以看起來是訂 Fetch 時寫下一套方法,然後拿來擴大套用到整個瀏覽器...