safari

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 這個選項？

收斂的過程...

把 Blog 上的 PNG 圖片換成 WebP 格式

WebP 格式的大小比起 JPEG 或是 PNG 都小不少，支援度也都還行，但 Safari 不支援是個大問題，因為在行動裝置裡面 iOS 還是大宗...

目前想到的方法是只對 Imgur 的圖片使用 WebP (.webp)，當遇到不支援的 WebP 的平台時透過 JavaScript 改用 PNG (.png)。

這邊有判斷有沒有支援 WebP 的程式碼出自「Detect WEBP Support with JavaScript」，用 createImageBitmap() 建看看有沒有成功：

(() => {
  let supportsWebP = async () => {
    if (!self.createImageBitmap) return false;
    const webpData = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
    const blob = await fetch(webpData).then(r => r.blob());
    return createImageBitmap(blob).then(() => true, () => false);
  };

  (async () => {
    if (!await supportsWebP()) {
      document.addEventListener('DOMContentLoaded', () => {
        for (let el of document.getElementsByTagName('img')) {
          let src = el.getAttribute('src');
          if (src.match(/\.webp/)) {
            el.setAttribute('src', src.replace(/\.webp/, '.png'));
          }
        }
      });
    }
  })();
})();

這邊比較有趣的是網路上的文件 (MDN 與 CanIuse) 都說 Safari 不支援 createImageBitmap()，但實際上好像沒問題 :o

然後再用 WordPress 的延伸套件「Search Regex」把所有文章理出現 /https:\/\/i\.imgur\.com/(\w+)\.png/ 的字串換成 https://i.imgur.com/$1.webp，接下來就可以拿 Safari 測試了，這樣有點 hack 但看起來還行...

Apple 將移除掉 Safari 的 DNT 功能

在「Apple Removes Useless 'Do Not Track' Feature From Latest Beta Versions of Safari」這邊看到的，看起來包括 iOS 與 macOS 都會移除：

因為沒什麼單位願意遵守，沒必要多送幾個 bytes 還順便讓廣告商可以判斷...

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac，而不是講 app...

這次從高雄回來，在高鐵上想說用手機看看 Trac，發現桌機版的界面是會動，但在手機上不太好用，所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用)，標語是「A responsive, flat, blue theme using Bootstrap」，拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整：

裝好後用手機測了一下，還是有不滿意的地方，不過改善不少了，先這樣撐著...

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+，就要看各網站或是服務的族群了...

WebKit 對 HSTS Super Cookie 提出的改法

Twitter 上看到 WebKit 對 HSTS 所產生的 Super Cookie 提出的改善方案：

How WebKit crumbles the "Super Cookie". https://t.co/iwOpjM8p9f
— WebKit (@webkit) March 16, 2018

拿原文的例子來說明，先指定一個隨機數給 user，像是 8396804 (二進位是 100000000010000000000100)，所以就存取下面的網址：

https://bit02.example.com
https://bit13.example.com
https://bit23.example.com

在存取這些 HTTPS 網址時都會指定 HSTS，所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本，會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)

WebKit 提出的改善方案大概有幾種，主要是就觀察到的現象來限制。

第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計：

https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.example.com
…etc...

https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
...etc...
https://bit64.example.com

所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS：

Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).

但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。

第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」，如果在 HTTPS 頁面上，某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定)，那麼就忽略掉 HSTS 的設計：

We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.

後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走，應該會有些幫助吧...