Tag: mozilla

TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇，這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效，這件事情一開始是在 CA/B Forum 討論，但經過投票後沒有通過：「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同，但有大約 2/3 的憑證發行方都反對：

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (Apple、Google、Mozilla) 在提案被否決後就決定放到自家的規則了：「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始，如果發出來的憑證超過 398 天就當作是無效憑證，也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證，會落在 2022/12/05 失效：

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去，就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft)，這些 CA 一定是在心裡幹爆... XD

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下，WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論：提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好)，然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候，宣稱失真壓縮的部份可以比 JPEG 小 25%～34%：(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%～34% 這個數字，是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg，而如果拿 MozJPEG 相比的話應該得不到這個結果，另外也把 AV1 的 AVIF 拉進來一起測試了：

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite，測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些，但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善)，而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了：

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好，不過要注意演算法會把非重點部位的細節吃掉：

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說，WebP 另外一個痛點是在 Safari 上的支援度，在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了，就剩下 Safari 還不支援，所以目前在 iOS 上得降回 JPEG：

不過這點之後也改變了，在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了：「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...

Firefox 在美國將預設開啟 DNS over HTTPS

看到 Mozilla 在「Firefox continues push to bring DNS over HTTPS by default for US users」這邊的公告，另外也可以參考 Hacker News 上的討論：「Mozilla’s DNS over HTTPs (blog.mozilla.org)」。

這次的改變是將美國的 Firefox 使用者自動啟用 DNS over HTTPS (DoH)，而預設是丟給 Cloudflare：

By default, this change will send your encrypted DNS requests to Cloudflare.

這個作法非常粗暴而且侵犯使用者的隱私。

  • 對於進階而且有在跟重大消息的使用者，他們如果不信任 Cloudflare 的話，會主動關掉 DoH 的選項。
  • 但對於一般使用者，他們不知道這件事情，而他們本來也不會預期他們上網的 hostname 部份會被 Cloudflare 知道。

相較於 Google Chrome 是確認你現在用的 DNS 是不是在有支援 DoH 的清單內，如果是的話就會切過去使用 DoH，但不會因此改變 DNS provider，也就是不會有突然冒出來的第三者知道你瀏覽的網站。

來繼續看...

AWS 上用空間買 IOPS 的故事...

在「A web performance issue」這邊講到 Mozilla 的系統產生效能問題，後續的 trouble shooting 以及解決問題的方案。

這個系統跑在 AWS 上，在一連串確認後發現是 RDS 所使用的 EBS 的 IOPS 滿了：

After reading a lot of documentation about Amazon’s RDS set-up I determined that slow downs in the database were related to IOPS spikes. Amazon gives you 3 IOPS per Gb and with a storage of 1 Terabyte we had 3,000 IOPS as our baseline. The graph below shows that at times we would get above that max baseline.

然後大家對於解法都差不多，因為 Provisioned IOPS 太貴，所以直接加大空間換 IOPS 出來 (因為 General SSD 裡 1 GB 給 3 IOPS)：

To increase the IOPS baseline we could either increase the storage size or switch from General SSD to Provisioned IOPS storage. The cost of the different storage type was much higher so we decided to double our storage, thus, doubling our IOPS baseline. You can see in the graph below that we’re constantly above our previous baseline. This change helped Treeherder’s performance a lot.

然後再設警告機制，下次就可以提前再拉昇：

In order to prevent getting into such a state in the future, I also created a CloudWatch alert. We would get alerted if the combined IOPS is greater than 5,700 IOPS for 6 datapoints within 10 minutes.

不過 General SSD 的 IOPS 是沒有 100% 保證的，只有這樣寫：

AWS designs gp2 volumes to deliver 90% of the provisioned performance 99% of the time.

大多數的情況應該是夠用啦...

Safari 上 uBlock Origin 的情況

uBlock Origin 在 2016 的時候 porting 到 Safari 上，但在 2018 後就沒有再更新了，維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。

主要就是蘋果要廢掉本來的 Extension API，而替代的框架裡沒有對應的 content filtering 能力，所以在新的框架內無法實做 uBlock Origin 的功能...

維護者的建議是換瀏覽器，但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞)，所以維護者的建議就是換成 Firefox。

另外我自己會建議用看看 Brave，因為 Brave 已經決定，如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3)，他們會繼續維持本來的相容性，所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。

Firefox Premium

Firefox 打算要推出 Firefox Premium：「Mozilla will reportedly launch a paid version of Firefox this fall」。

現有的功能仍然會維持免費，所以目前猜測 Firefox Premium 應該是把附加服務包起來變成月費包裝：

So, what we want to clarify is that there is no plan to charge money for things that are now free. So we will roll out a subscription service and offer a premium level. And the plan is to introduce the first one this year, towards fall. We aim for October.

目前有提到的是 VPN，先前 Mozilla 有跟 ProtonVPN 合作，有可能會在接下來的 Firefox Premium 也一起合作...

在 Hacker News 上的討論「Mozilla will reportedly launch a paid version of Firefox this fall (thenextweb.com)」有些值得看一下...

其中一個討論的主題是，既然以 Firefox 當作招牌打包，那麼本來免費時的某些行為大家還可以「忍受」，到了付費版的時候就不是這樣了...

既然目標是十月，先放著吧... 後續應該會有其他的新聞。

在 DOM 操作時的 insertAdjacentElement

看到「Why I'm still using jQuery in 2019」這篇，裡面提到了 jQuery 很多操作上相較於 vanilla javascript 簡單很多，其中一個例子提到了 DOM 操作的 insertAdjacentElement()：

el.insertAdjacentElement('afterend', other) undoubtedly works, but $(el).after(other) is actually palatable.

其實我不知道 insertAdjacentElement() 這個功能，我知道的操作都是透過 parentElement、firstChild 在移動位置，然後用 appendChild() 與 insertBefore() 放進去。

跑去 MDN 上查了「Element.insertAdjacentElement() - Web APIs | MDN」後才發現有這個好用的東西：

targetElement.insertAdjacentElement(position, element);

position 的四個變化減少了以前組積木組多了會頭暈的情況。

接下來是研究支援度的問題，才發現可能是因為 Firefox 一直到 48 才支援 (從「Firefox version history」可以看到 48 是 2016 年八月釋出)，所以網路上大多數的文章都還是用組積木的方式在介紹 DOM 操作，以避免相容性的問題：

Firefox 48 was released on August 2, 2016 for both desktop and Android.

另外還看到 insert​Adjacent​HTML() 與 insert​Adjacent​Text() 可以用，其中讓我注意到 MDN 上面提到 insert​Adjacent​HTML() 居然是 Firefox 8+？本來以為是 48+ 的誤植，但從 Mozilla 的記錄「Implement insertAdjacentHTML」這邊可以看到，應該是在 Firefox 8 的時候實作的，這樣的話可以當作 insertAdjacentElement() 的替代品 (如果考慮到古早的相容性)，只是這邊需要輸入 html string，跟其他操作是是用 element 不太一致...

意外的學到不少歷史故事... @_@

MDN 上的 CSS Layout cookbook

在 MDN 上看到「CSS Layout cookbook」，目前整理了六種情境，包括了設計方式與瀏覽器的支援度。

看到「Center an element」有種苦笑的感覺啊... 以前弄這個都是 workaround，現在都有對應的 CSS 可以處理了。

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

Update：Apple 也宣佈了，時間點跟大家都差不多：「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」，而 Google 也宣佈了「Modernizing Transport Security」，兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除：

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除，換算成時間會從 2020 年一月開始影響到 canary channel，到 release channel 應該跟 Firefox 差不多時間：

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援，但如果伺服器想要只支援 TLS 1.2+ 的話，就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便，替代方案也比較多)，而行動平台看起來需要 Android 4.4+、iOS 7+，就要看各網站或是服務的族群了...

讓 Firefox 連線數變多 (然後加快速度)

最近換到 Firefox 後覺得開很多 tab 時很卡，但 CPU 也沒滿，大概是某種 lock/mutex/semaphore 機制導致硬體資源沒用完但是自己限制住...

找資料研究的時候發現 Firefox 對單一 server 的最大連線數是 6 個，而 Chrome 是 10 個：「Max parallel http connections in a browser?」。這對於網路速度夠的使用者就很卡，像是透過 RSS reader 同時對一個站台狂開分頁時就會卡住。

翻了一下 Firefox 的設定，找到相關的幾個設定，其中上面提到的是 network.http.max-persistent-connections-per-server，預設的確是 6 個，改成 10 個後測了一天好不少，決定改成跟 IE11 一樣的 13 個... (奇怪的數字)

另外一個是 network.http.max-connections，預設是 900 了，應該夠用...