Tag: safari

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 上擋。

Apple 對 PNG 解碼的 bug

前幾天的 Hacker News Daily 上看到「PNG Parser Differential」這個，對應的討論在「PNG Parser Differential (vidbuchanan.co.uk)」這邊可以看到。

作者想要利用 threading 加速處理 PNG 格式，結果寫出了 bug，但意外發現 Apple 的 PNG decoder 也犯了一樣的問題：「Ambiguous Decodes #3」。

作者做了一個特別的 PNG 放在網站上，在非 Safari 的情況下會是：

而拿 iPhone 的 Safari 讀的話，可以看到：

應該是 implementation bug，還蠻有趣的 bug...

跨瀏覽器追蹤的方式

看到「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.

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

用 picture + source + img 替代本來的 JavaScript 替換

目前我在 blog 上使用 Imgur 的圖檔主要是用 WebP 格式，然後針對不支援 WebP 的瀏覽器 (主要就是蘋果家的 Safari) 是用 JavaScript 換回 JPEG 格式...

昨天早上看到「AVIF has landed」這篇，提醒我有 <picture> 這個原生支援的方式可以用，翻了一下 Can I Use 上面的支援程度，看起來除了 IE11 以外幾乎都支援了 (參考「Picture element」)，而且 IE11 應該也會因為語法的關係走到正確的 JPEG fallback，大概是這樣：

<picture>
    <source type="image/webp" srcset="https://i.gslin.com/imgur/xxxxxx.webp" />
    <img src="https://i.gslin.com/imgur/xxxxxx.jpg" alt="" />
</picture>

換完後來觀察看看...

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 是我自己買的)，後來好像降到三年，最近是兩年，看起來要變成一年了...

Webkit 的「反追蹤反追蹤」功能...

第一次看到標題的時候的確是 WTF 的感覺，愈來愈感覺到大戰的開始：「Preventing Tracking Prevention Tracking」。

在蘋果的平台上有 Intelligent Tracking Prevention (ITP) 功能，但先前這個功能比較簡單，所以還是有很多地方可以被當作 browser fingerprint 的一部份分析，所以蘋果決定改善，然後在新版的軟體裡引入：

This blog post covers enhancements to Intelligent Tracking Prevention (ITP) included in Safari on iOS and iPadOS 13.3, Safari 13.0.4 on macOS Catalina, Mojave, and High Sierra.

包括了跨站台時 Referer 的省略：

ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains.

然後後面三個改善都跟 3rd-party cookie 有關，其中預設擋掉帶 cookie 的 3rd-party requests 應該會讓一些網站掛掉：

ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.

早期自己做自家 SSO 的奇技淫巧中，會設計出透過 ajax 打多個不同的網域自動登入，看起來應該會需要檢查了...

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 試用」這篇)。

iOS 13 的 Safari 支援 W3C WebDriver

所以之後可以拿 WebDriver 的 library 直接接上去 (不過這個標準好像還沒有什麼人支援啊...)：「WebDriver is Coming to Safari in iOS 13」，看起來是 Remote Automation 這個選項？

收斂的過程...