Category: GoogleChrome

Google Chrome 將在 115 版之後預設使用 HTTPS 連線

Google Chrome (Chromium) 宣布 115 版後將預設使用 HTTPS 連線：「Towards HTTPS by default」。

查了一下 115.0.5790.98 是 2023/07/18 就出的版本，現在才冒出這篇文章有點晚，但大概就是講一下幹了什麼事情？

We're currently experimenting with this change in Chrome version 115, working to standardize the behavior across the web, and plan to roll out the feature to everyone soon.

主要的差異是在於，即使你輸入或是點擊的連結是 http://，他還是會優先嘗試 HTTPS：

Chrome will automatically upgrade all http:// navigations to https://, even when you click on a link that explicitly declares http://.

只有在 http:// 連結遇到 upgrade 到 HTTPS 失敗時才會回頭用 HTTP：

This works very similarly to HSTS upgrading, but Chrome will detect when these upgrades fail (e.g. due to a site providing an invalid certificate or returning a HTTP 404), and will automatically fallback to http://.

而本來就用 https:// 的連線就完全不會碰 HTTP 了。

講到推動 HTTPS 這點，前陣子剛好也是 Snowden 揭露美國 PRISM (菱鏡計畫) 十年的日子，當年在揭露後也因此加速了各種加密技術的基礎建設，像是 Let's Encrypt，而這也使得 HTTPS 更加普及，也讓 Google Chrome 現在可以預設切 HTTPS。

用 Little Rat 看哪些 extension 在後面亂連線

還在日本的時候在 Hacker News 上看到「Show HN: Little Rat – Chrome extension monitors network calls of all extensions (github.com/dnakov)」這篇，在介紹「little-rat」這個專案，可以看 extension 做了那些連線。

放上 Chrome Web Store 的版本比較陽春，只能擋而不能看，因為 declarativeNetRequest.onRuleMatchedDebug 不能上：

The reason is that the extension uses the declarativeNetRequest.onRuleMatchedDebug API which is not available for publishing in the Chrome Web Store.

比較完整的功能還是需要自己 git clone 下來後裝，缺點就是要每一台自己裝，另外也要自己更新重跑起來。

裝好後跑一陣子讓他記錄，可以看到有些連線是預料中的，像是 uBlock Origin 會需要定時更新 rule，但也意外的看到一些有問題的 extension 了...

透過 WebGPU 跑的 Web LLM

在 Simon Willison 這邊看到的玩法，透過 WebGPU 在瀏覽器上面直接跑 LLM 的 demo：「Web LLM runs the vicuna-7b Large Language Model entirely in your browser, and it’s very impressive」，專案在「Web LLM」這邊，可以直接玩。

不過要注意一下瀏覽器的支援度，如果是 Chrome 的話需要 113+，但目前 stable 還是 112；而 Firefox 的話我試過在 about:config 裡面用 dom.webgpu.enabled 打開 WebGPU 支援，但重開瀏覽器後還是跑不動？(也有可能是 Linux 環境的關係)

Update：應該是 Linux 環境的關係，我在 Linux 下用 dev channel (114) 也不行。

話說有 WebGPU 後是不是開始要擋 GPU 挖礦了...

uBO Lite：另外一個方向的嘗試

兩個禮拜前在 Hacker News 上看到的東西，算是 uBlock Origin 對 Manifest V3 (MV3) 的另外一種嘗試：「uBlock Origin Lite: Description (github.com/gorhill)」，專案的說明在「uBO Lite (uBOL), an experimental permission-less MV3 API-based content blocker.」這邊。

先前在「因應 Manifest V3 而推出的 uBlock Minus (MV3)」這邊提到的 uBlock Minus 是在 MV3 環境下的一個嘗試，但這個版本只是把 MV3 做不到的事情先拔掉，所以缺了很多重要的功能，像是 cosmetic filtering (主要是針對瀏覽器不支援的 css selector，像是最近才剛支援的 :has()，而這些 css selector 對於選擇要幹掉的 html 元素很好用)。

uBO Lite 則是一個妥協，另外讓使用者對特定站台點選授權，而在這些特定授權的站台可以恢復到原來 MV2 時可以過濾的能力 (包含 cosmetic filtering 等等的能力)：

但這個方案也是 Google 所樂見的，只要不方便就會讓使用者慢慢放棄。

目前的公告提到 MV2 只支援到明年一月，大概還有三四個月的時間，接下來 adblock 這塊應該會有很多新的方法陸陸續續冒出來...

因應 Manifest V3 而推出的 uBlock Minus (MV3)

前幾天在 Hacker News 上看到「“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 (github.com/gorhill)」這個，裡面是 uBlock Origin 的作者 Raymond Hill 針對 Manifest V3 的半殘版，取名為 uBO Minus (MV3)：「Add experimental mv3 version」。

在這個版本裡會有不少的功能失效，尤其是用的很多的 cosmetic filtering：

- No cosmetic filtering (##)
- No scriptlet injection (##+js)
- No redirect= filters
- No csp= filters
- No removeparam= filters

這個版本應該是打算要提供給 Manifest V2 被 Google 廢掉後還在用 Google 控制的瀏覽器的人，依照「Manifest V2 support timeline」這邊看起來是明年一月：

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 裡面檢查半天...

在 Ubuntu 20.04/22.04 下使用 18.04 的 chromium-browser

Ubuntu 20.04 之後包的 chromium 都是基於 snap 的方案，是個除了 Canonical 的人以外沒人愛的東西，所以大家都在找方法改回 .deb 的版本。

剛剛因為需要測試東西所以才需要找這個方案，發現有個還蠻有趣的解法，是拿 18.04 的 chromium-browser 的套件來裝，因為官方至少會支援到 2023/04：「Is it still possible to install Chromium as a deb-package on 20.04 LTS using some third-party repository?」。

一個 /etc/apt/sources.list.d/bionic-update.list：

deb http://archive.ubuntu.com/ubuntu/ bionic-updates universe

另外一個 /etc/apt/preferences.d/chromium-deb-bionic-updates：

Package: chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra chromium-codecs-ffmpeg 
Pin: release a=bionic-updates
Pin-Priority: 900

完全還是使用官方套件的解法，唯一的缺點大概就是到明年四月而已，但對要測試來說夠用了...

V7Labs 提供的 Chrome Extension，偵測圖片是否為人工智慧生成的

寫完上一篇「可以看 Chrome Extension 程式碼的 Chrome extension source viewer」後就可以來提「Fake Profile Detector tells you if people are real or fake online」這個了，文章裡面在介紹 V7Labs 所提供的 Chrome Extension：「Fake Profile Detector (Deepfake, GAN)」。

從套件的名字可以看出來他主要是偵測 GAN (Generative adversarial network) 類的類神經網路，這點在套件裡面說明也可以看到：

Right-click on a profile picture, our model will detect if that image contains a GAN generated or real person!

實際上測試時要注意要儘量抓夠大的圖片丟進去測，像是 Generative adversarial network 維基百科這頁裡面「Concerns about malicious applications」這個章節右邊兩張 GAN 生成的圖，如果你用維基百科預設的縮圖大小 (220x220)，上面這張會猜測是真人，下面那張會猜測是假人。

但如果到大一點的圖 (600x600) 的話就都會猜測是假人：「File:Woman 1.jpg」、「File:GAN deepfake white girl.jpg」，原圖 1024x1024 的話也可以偵測出來。

然後 source code 就在那邊可以看 API 怎麼打，大家可以自己研究...

可以看 Chrome Extension 程式碼的 Chrome extension source viewer

好像沒有提過「Chrome extension source viewer」這個套件，來介紹一下...

這個套件可以在尚未安裝前看 Chrome Web Store 裡 extension 的原始程式碼，算是可以在安裝前看一下 extension 在幹什麼。

以前還會遇到會 obfuscated code，導致很難看出來在幹什麼，但在 2018 年以後 Google 公告直接禁止這類行為，就不太會遇到這種情況了 (除非是很舊的 extension)：「Trustworthy Chrome Extensions, by default」。

先前跟 Brave 還會打架，不過後來看起來沒這個問題了...

curl 的 TLS fingerprint 偽裝專案 curl-impersonate 支援 Chrome 了

先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」這邊提到 curl-impersonate 這個專案，試著修改 curl 的 TLS handshake fingerprint 讓偽裝的更好，本來只支援 Firefox，現在則是支援 Google Chrome 的 fingerprint 了...

作者寫的兩篇說明文章也可以看看：「Making curl impersonate Firefox」、「Impersonating Chrome, too」。

看起來愈來愈完整了，連 LD_PRELOAD 的用法也出現了，然後在 Arch Linux 上也出現 AUR 可以用了...