幹壞事是進步最大的原動力
前幾天在 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」這邊看起來是明年一月：
寫完上一篇「可以看 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 source viewer」這個套件，來介紹一下...
這個套件可以在尚未安裝前看 Chrome Web Store 裡 extension 的原始程式碼，算是可以在安裝前看一下 extension 在幹什麼。
以前還會遇到會 obfuscated code，導致很難看出來在幹什麼，但在 2018 年以後 Google 公告直接禁止這類行為，就不太會遇到這種情況了 (除非是很舊的 extension)：「Trustworthy Chrome Extensions, by default」。
先前跟 Brave 還會打架，不過後來看起來沒這個問題了...
先前在「修正 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 可以用了...
今天發現 Brave 在視窗最大化時會超出預期的邊界，而非放大到螢幕的邊緣，找了一下發現有人已經在 Brave 的 GitHub 上開了「Incorrect scale if browser is full screen #18964」這張票，後來看到有人說在 Chromium 的 bug system 上已經有人提出來了：「Issue 1257119: Goes under the taskbar when maximized」、「Issue 1260821: maximise gets screen dimension wron」與「Issue 1261797: [User Feedback - Stable] Reports that when Chrome is maximized after being minimized, it launches to beyond the window frame on Linux」。
這次遇到的 bug 看起來是只有用 XFCE 的使用者才會中獎，目前先摸索出一套 workaround 是透過 wmctrl 操作修改瀏覽器的位置與視窗大小。
方法是先用 wmctrl -l -G 列出所有視窗的資訊，包括 geometry 的資料，接著再用 wmctrl -i -r 0x12345678 -e 0,3760,15,1232,1935 這樣的指令去指定瀏覽器的位置與視窗大小。
不知道要撐多久就是了...
在 tab 上放了一陣子的連結，忘記是哪邊看到的，在講 Chromium 系列瀏覽器會針對 Google Search Engine 最佳化：「Google’s unfair performance advantage in Chrome」。
作者發現 Chromium 瀏覽器會預先開 HTTPS 連線連到搜尋引擎，這樣可以大幅降低建立 HTTPS 連線時所需要的時間，包括了 DNS 查詢、TCP handshake 與 TLS handshake：
I was looking for something else when I stumbled upon a feature called
PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.
問題在於這個功能只開給 Google Search 使用：
There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search.
在 search_engine_preconnector.cc (HEAD 版本) 這邊可以看到這段程式碼：
// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
"PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
} // namespace features
作者有提到，的確這個功能會對 search engine 有不小的衝擊，但可以透過擴充 OpenSearch Descriptions 或是 Well-Known URI 的方式提供，現在這樣寫死在程式碼裡面完全就是不公平競爭。
看到「Google revives RSS」這篇，這大概是我在 2021 年最想不到的事情了：Google Chrome 加入 RSS reader 功能 (雖然很陽春)。
Google 的說明文在「An experiment in helping users and web publishers create deeper connections on Chrome」這邊。
目前只有美國的 Google Chrome Canary 用戶才有機會看到這個功能，依照官方的截圖應該是行動版？
把當年的 Google Reader 吐出來啊...
看到「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.
這個方法還蠻暴力的...
Google 打算在 Google Chrome 裡面強推的 FLoC 最近有很多消息，但因為沒看完 spec 就一直丟著了... 可以先參考 iThome 的「繼Brave瀏覽器之後，DuckDuckGo、Vivaldi也要封鎖Google FLoC廣告投放技術」，雖然裡面提的很淺。
目前檯面上除了廣告產業以外，所有看到的人與組織都反對 FLoC。
從 EFF 的「Google’s FLoC Is a Terrible Idea」，之後 DuckDuckGo 也發表了「Use the DuckDuckGo Extension to Block FLoC, Google’s New Tracking Method in Chrome」，再來是 Brave 的「Why Brave Disables FLoC」與 Vivaldi 的「No, Google! Vivaldi users will not get FLoC’ed.」。
最新的進展是 WordPress 決定把 FLoC 當作 security concern 來看，打算直接推出 security hotfix 更新，預設關閉 FLoC：「Proposal: Treat FLoC as a security concern」，在 Hacker News 上也有討論：「Proposal: Treat FLoC as a security concern (make.wordpress.org)」。
主要的原因是正常的 WordPress 版本會在今年七月才出，會跟不上 FLoC 的進度：
Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.
我自己也因為 FLoC 而又再次跳到 Brave，還遇到 imgur Uploader 套件不見 (可以參考「What Happen to the imgur uploader extension?」)，以及有些套件無法運作的問題...
Google Chrome 從 90 版要把 https:// 變成網址輸入時的預設值：「A safer default for navigation: HTTPS」。Hacker News 上的「Chrome’s address bar will use https:// by default (chromium.org)」也可以看一下。
也就是說，沒有輸入 schema 的網址，預設會用 https:// 方式連線，以往這點需要透過 HTTPS Everywhere 這種套件，然後開啟「Encrypt All Sites Eligible」這樣的參數，像是這樣：
這樣會再推一把...