Tag: chrome

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

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

Google 在 Chrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「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 時寫下一套方法，然後拿來擴大套用到整個瀏覽器...

Chromium (Google Chrome) 實做對 Root DNS 的影響

前幾天在 APNIC 上的這篇文章受到社群注意：「Chromium’s impact on root DNS traffic」，在 Hacker News 上也有對應的討論：「Chromium's Impact on Root DNS Traffic (apnic.net)」。

文章作者 Matthew Thomas 是 Verisign 的員工 (Verisign Labs)，可以看出來主力在 DNS 的部份。

Chromium (以及 Google Chrome) 會隨機產生一組 hostname，確認所在的網路是否有 DNS hijack：

這導致了在 Root DNS 上會看到大量不存在網域的 DNS query，這點隨著 Google Chrome 的市占率愈來愈高，在 Root DNS 上這些 DNS query 甚至佔到 40% 以上：

不過 Root Server 有上千台在跑，就目前的效能來說應該是還 OK：

As of 2020-08-27, the root server system consists of 1097 instances operated by the 12 independent root server operators.

把這個問題丟到 bugs.chromium.org 上翻，看起來有三張票在進行中：

瞄了一下裡面的討論，目前的方向有兩類，一種是主張完全關掉，這樣確定可以大幅減少對 Root DNS 的壓力，另外一種是設計 cache，使得 Root DNS 的 loading 降低。

這次有不少新聞都有報導，受到 PR 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

Chrome 85 支援 AVIF

看到「How to Use AVIF: The New Next-Gen Image Compression Format」這篇在推銷用 AVIF 取代 JPEG 與 WebP。

首先是跑去 Can I Use 翻，發現 Google Chrome 85 之後支援了，另外在「Issue 960620: Support AVIF」這邊可以看到對應的 ticket，以及「AVIF Image Decode」這邊有狀態：

Enabled by default (tracking bug) in:
Chrome for desktop release 85

現在的 stabel channel 是 84，所以是下個 release 就會有了。以 Google Chrome 的市占率來說，推出來等於是支援度直接過半... 這點也的確有人批評，不過又是另外一個話題了。

對於不支援 AVIF 的瀏覽器，也有對應的 polyfill 可以上 (用 javascript 去補功能)，不過因為是透過 AV1 codec，能夠向下支援的版本還是不多，除非連 AV1 都透過 polyfill 支援：「AVIF (AV1 Still Image File Format) polyfill for the browser」。

另外在寫「WebP 的檔案大小未必比 JPEG 小...」這篇時有提過 AVIF 其實也不是完美的，畢竟是從 video codec 演化來的演算法，對於演算法判斷不重要的部位會掉比較多細節...

Google Chrome 又要對 URL 搞事了...

上個禮拜鬧的頗兇的話題，Google Chrome 又要對 URL 搞事了：「Google resumes its senseless attack on the URL bar, hides full addresses on Chrome 85」。

這次是打算把整個 path 藏起來：

A few new feature flags have appeared in Chrome's Dev and Canary channels (V85), which modify the appearance and behavior of web addresses in the address bar. The main flag is called "Omnibox UI Hide Steady-State URL Path, Query, and Ref" which hides everything in the current web address except the domain name. For example, "https://www.androidpolice.com/2020/06/07/lenovo-ideapad-flex-5-chromebook-review/" is simply displayed as "androidpolice.com."

來繼續等 3rd-party browser 成熟...

Chrome Extension 的效能分析

在「2020 Chrome Extension Performance Report」這邊看到有人對 Chrome Extension 上前一千名的效能分析，作者有提到是在 GCP 上的虛擬機測試的，跑七次取中位數：

I ran these tests on an n2-standard-2 Google Cloud instance, the numbers in this report show the median of 7 runs.

在「Chrome Extension Performance Lookup」這頁可以直接互動查詢，像是丟入 block 找跟擋廣告有關的關鍵字可以看到：

只看一般性的 blocker (中間還有 VPN 與一些不是一般性的先跳過)，沒什麼意外的 uBlock Origin 的表現很好。

文章內的說明也可以翻一下，看看有沒有哪些 extension 其實不是很必要，但卻榜上有名，可以考慮拔掉省時間與資源...

HTML 轉 SVG

在「html-to-svg」這邊看到的，專案在 GitHub 上的「as-a-service/html-to-svg」這邊。

整個服務的程式碼其實很短 (大約 50 行？)，因為主要的業務是透過 Chrome (headless) 生出 PDF 檔，再用 Inkspace 把 PDF 轉成 SVG：「htmltosvg.js」。

主要是 Inkspace 可以做 PDF 轉 SVG 這件事情算是新知...

幫 2011 年的 Mac Mini 換 SSD

這台 Mac Mini 是我第一個蘋果產品 (退伍後在 PIXNET 的時候買的)，當時本來想在上面寫些東西，不過後來就一直當個終端機在用而已，到這幾年他的定位就是放在客廳當個播放器 (像是開 Twitch 或是 YouTube 在看)。

不過每次用都覺得開 Google Chrome 開的很慢，就興起將硬碟換成 SSD 硬碟的念頭了。至於記憶體，當初在買 Mac Mini 的時候應該是已經升級過，裡面是兩條 4GB 了，網路上是有人提到可以支援兩條 8GB，不過以目前客廳的用法，應該是用不到...

先對價錢做了一些功課，如果是自己處理，打算換成美光的 Crucial MX500，在 24h 是賣 $2,099 (不過後來是剛好有去光華一趟，就在光華買回來)，然後打電話問一下有提供更換服務的店家，500GB SSD 是 $3,500 換到好，1TB SSD 則是 $6,000。

以 500GB 的價錢倒是沒有到不能接受，但也不是能馬上就說 ok 的價位，還是得看一下有多麻煩才能決定要怎麼做。

所以就跑去看了一下 YouTube 上換 SSD 的影片，看起來只要有對應的螺絲起子，應該是可以自己換完。而我之前就有準備六角螺絲起子，應該是可以換下來：

實際拆的時候才發現，不只需要正六角的螺絲起子 (H 系列)，還需要星狀的螺絲起子 (T 系列)，本來想在 24h 下單隔天再來弄，突然想到這種東西在水電五金行應該有，當時才晚上八點，就跑去外面找了一組 (價錢也比 24h 便宜)，回來繼續拆...

有了正確的工具，拆開就簡單不少，反倒是裝回去折騰一陣子... 在裝有 WiFi 天線的那塊板子的四顆螺絲時卡了一個小時 (一直都只鎖的上去三顆)，最後本來是打算少鎖一顆螺絲，結果在準備放棄的時候突然暴力法把四個孔位都卡進去了，就順利把四顆螺絲都鎖上去...

接下來就是先開機進入 macOS Recovery 確認硬碟有被抓到，確認有被抓到以後，就可以準備重裝系統，這時候我拿 MBPR 下載 10.13 (High Sierra，這台 Mac Mini 能支援的最新版)，生出 USB 隨身碟裝機，然後插回 Mac Mini 重開機就可以裝系統了：

裝完後的開機速度很明顯快不少，裝軟體的速度也是，另外再打開一些網站看一看，冷啟動的速度都改善很多。

算是趁連假的時候整理一下硬體，還蠻有趣的...