Category: Safari

最近 AV1 的支援度

HN 上「AV1 video codec gains broader hardware support (fullystacked.net)」這篇在說 AV1 的支援度變得更好了，原文不長，在「The AV1 video codec gains broader hardware support」這邊。

在 Can I Use 上的 AV1 video format 可以看的比較清楚：

不過在瀏覽器上離直接取代掉其他的 video codec 還早，但算是個起頭，至少 iPhone 15 Pro 與 iPhone 15 Pro Max 上的 Safari 支援了，接下來就是看桌機的 Edge 什麼時候才又想到要把 AV1 開回來：

Edge has stopped supporting AV1 completely at some point prior to version 116 (additional information required).

WebKit 要支援 nested CSS 了

從龍哥這邊看到的消息，WebKit 要支援 nested CSS 了：

原文在「Try out CSS Nesting today」這邊，就是這樣的寫法：

.foo {
  color: green;
 .bar {
    font-size: 1.4rem;
  }
}

這個在很多預處理的工具都會支援，然後編譯成展開的形式。

比較特別的是在 nested CSS 中不支援 element 的指定：

main {
 article { ... }
}

他寫的理由我是看不太懂：

That code will fail, because article begins with a letter, and not a symbol. How will it fail? The same way it would fail if you’d misspelled article as atirlce. The nested CSS which depends on that particular selector is simply ignored.

反而要用個奇怪的設計去繞開：

main {
 & article { ... }
}

這邊是真的沒看懂在閃什麼問題...

CSS 的 :has() 有新進展了

在「Using :has() as a CSS Parent Selector and much more」這邊看到 Safari 宣佈對 :has() 的支援，查了一下 Can I use... 上面的資料「:has() CSS relational pseudo-class」，看起來是從 15.4 (2022/05/14) 支援的。

隔壁 Google Chrome 將在下一個版本 105 (目前 stable channel 是 104) 支援 :has()，沒意外的話 Microsoft Edge 應該也會跟上去，看起來只剩下 Firefox 要開了。

先前在「Chromium 的 :has() 實做進展」這邊有翻一下進度，看起來 Chromium 這邊要進入收尾階段了。

等普及後一些延伸套件裡的寫法也可以用 :has() 來處理了，就不用自己在 javascript 裡面檢查半天...

iOS Safari 擋 "Open in App" 的付費套件 Banish

在「New iOS App Blocks Those Annoying 'Open in App' Pop-Ups in Safari」這邊看到 John Gruber 的介紹文章「Banish: New Safari Extension to Block 'Open in App' Dickpanels」，裡面提到的 extension 在「Banish for Safari」這邊，一次性的費用，在台灣是 NT$70。

裡面的 screenshot 給了還蠻清楚的說明：

設定上面因為會牽扯到 privacy 的關係，會有點麻煩，需要開好幾個地方。

順道一提，桌面上的話可以透過 Annoyances 系列的 list 在 uBlock Origin 上擋。

跨瀏覽器追蹤的方式

看到「Exploiting custom protocol handlers for cross-browser tracking in Tor, Safari, Chrome and Firefox」這個方式，跨瀏覽器收集 fingerprint 追蹤。

這次用的方式是透過 handler 追：

The scheme flooding vulnerability allows an attacker to determine which applications you have installed. In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not. On average, the identification process takes a few seconds and works across desktop Windows, Mac and Linux operating systems.

最近大家比較常使用到的應該就是 Zoom 從網頁把應用程式帶起來的方式：

而要怎麼偵測的部份，用到了不同瀏覽器的 side channel。

Chromium 系列的部份對應的 ticket 在「Issue 1096610: External Protocol handler anti-flood protection is ineffective and flaky」這邊有被提出來。主要用到的方法是，在遇到有 handler 時，連打兩次時會被擋下：

被擋下後再打都會失敗，所以需要一個方式重設 flag，而內建的 Chrome PDF Viewer 剛好可以重設 flag：

The built-in Chrome PDF Viewer is an extension, so every time your browser opens a PDF file it resets the scheme flood protection flag. Opening a PDF file before opening a custom URL makes the exploit functional.

在 Firefox 的 side channel 則是可以透過 same-origin policy 測試當作 side channel，對應的 ticket 在「Scheme flooding technique for reliable cross-browser fingerprinting」這邊：

Every time you navigate to an unknown URL scheme, Firefox will show you an internal page with an error. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, a known custom URL scheme will be opened as about:blank, whose origin will be accessible from the current website.

在 Safari 上的問題與 Firefox 一樣，不過沒登入看不到 ticket (也懶的註冊了)：

You are not authorized to access bug #225769. To see this bug, you must first log in to an account with the appropriate permissions.

另外，雖然 Tor Browser 底層是 Firefox，但因為有改變預設值，所以攻擊者也得換方法：

Tor Browser is based on the Firefox source code, so the Same-origin policy trick was used here as well. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.

這個方法還蠻暴力的...

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.

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

Safari 將會禁止長效憑證 (超過 398 天，大約十三個月)

在「Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months」這邊看到的，這次是 Safari 直接發難要幹掉長效憑證。

今年九月前發的憑證是照既有的協議，最長長度是 825 天 (大約 27 個月)，但九月開始發的憑證，如果有效長度超過 398 天就會直接被 Safari 視為無效，所以大約是砍半，其他家瀏覽器不知道會不會跟進...

最早的時候可以直接買五年 (有印像是因為當年的 group.nctu.edu.tw 是我自己買的)，後來好像降到三年，最近是兩年，看起來要變成一年了...

User-Agent 的淘汰提案

看到廢除更新 User-Agent 字串的提案：「Intent to Deprecate and Freeze: The User-Agent string」。

一方面是 User-Agent 裡面太多沒用的假資料 (像是每一家都是 Mozilla)，另外 User-Agent 會帶出一些隱私問題 (辨識資訊)。

目前的提案是希望改用 User-Agent Client Hints (UA-CH) 取代 User-Agent 的功能，把預定義好的東西透過對應的 HTTP header 傳遞。

Chromium 的計畫是在 M81 (stable 版預定在 2020 年三月中釋出) 先 deprecate navigator.userAgent，所以有存取時 web console 上會出現警告。而 M83 (2020 年六月初) 則是不再更動 user agent 字串 (鎖住)。到了 M85 (2020 年九月中) 則是統一 desktop 的 user agent 字串，並且盡可能統一 mobile 上的字串。

另外裡面也有整理了其他瀏覽器的意願：

Edge: Public support

Firefox: Public support for freezing the UA string - “freezing the User Agent string without any client hints—seems worth-prototyping”

Safari: Shipped to some extent. Safari has attempted to completely freeze the UA string in the past, without providing an alternative mechanism. That got a lot of pushback, which resulted in somewhat reverting that decision. Nowadays, their UA string seems frozen, other than updates to the OS version and the browser major version.

雖然不是完全都同意，但看起來應該有機會在今年陸陸續續搞定...