Chromium 的 :has() 實做進展

前陣子在「Chromiu 看起來正在實做 CSS4 的 :has()」這邊提到了 Chromium:has() 實做,對應的票在「Issue 669058: CSS selectors Level 4: support :has()」這邊,不過看起來當時沒有實做完整,而且有測出問題:

The following css/selectors  web tests are failing on below platform:

css/selectors/has-basic.html - Failing on chrome/edge/firefox/safari/webkit
css/selectors/parsing/parse-has.html - Failing on chrome/edge/firefox/safari/webkit

昨天又看到新進度了:「Supports all ':has' relative argument cases」。

Supports all ':has' relative argument cases

Currently the relative selector is not supported yet, so this CL
provides the relative argument cases as follows.
 - :has(:scope > <complex-selector>)
 - :has(:scope ~ <complex-selector>)
 - :has(:scope + <complex-selector>)

看起來補上了之前沒實做的部份。更完整的討論過程可以參考 Gerrit 的「Supports all ':has' relative argument cases」這邊。

沒問題的話應該就是時間的問題了,也許三個月到半年左右?

Chromium 看起來正在實做 CSS4 的 :has()

先前一直都有在盯著「Issue 669058: CSS selectors Level 4: support :has()」這個,主要是有這個功能會對於很多應用很方便,無論是對 designer 在設計上,或是對 javascript developer 的操作。

Chromium 上對應的 commit 在「Supports :has() pseudo class matching」這邊,可以看到目前只實做了一部分:

So this CL only supports :has argument selectors starting with
descendant combinator. Argument selectors starting with other
combinators are not supported yet.
 - .a:has(.b)    : Supported
 - .a:has(> .b)  : Not supported yet
 - .a:has(~ .b)  : Not supported yet
 - .a:has(+ .b)  : Not supported yet

但至少是個進展了...

Google Web Store 裡的黑暗交易

標題只寫了 Google Web Store,主要是因為瀏覽器市占率的問題,其實是包含 Firefox 的 Add-Ons。

這是在 Hacker News 首頁上看到的:「Many temptations of an open-source chrome extension developer」,講一直會有人來接觸,可以付費給開發者,想要在這些專案裡面放一些「東西」,可能是蒐集資料,可能是強制導到特定的 search engine,也有可能更邪惡...

另外是老規矩,在 Hacker News 上的討論也可以翻一翻,還蠻有趣的:「Many temptations of an open-source Chrome extension developer (github.com/extesy)」。

先大概看一下 Hover Zoom+ 這個套件在 Google Web Store 的安裝數量,大約 30 萬人:「Hover Zoom+」,作者公佈的信件內容裡面有一些包括價錢與目的...

話說回來,Brave 上的 CRX Viewer 還是沒修好啊:「Stopped working with Brave」,要裝新的套件都得另外再拉 crx 檔下來看,麻煩不少...

這大慨是我在 2021 年最想不到的事情:Google Chrome 加入 RSS 功能

看到「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 Chrome 要推動預設使用 HTTPS 連線

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」這樣的參數,像是這樣:

這樣會再推一把...

Google 釋出網頁版的 Spectre 攻擊 PoC,包括 Apple M1 在內

在大約三年前 (2018 年年初) 的時候,在讀完 Spectre 之後寫下了一些記錄:「讀書時間:Spectre 的攻擊方式」,結果在 Bruce Schneier 這邊看到消息,Google 前幾天把把 PoC 放出來了:「Exploiting Spectre Over the Internet」,在 Hacker News 上也有討論:「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 Apple M1 上都可以跑:

The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度,也還是可以達到 60 bytes/sec 的速度:

While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.

比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨,目前在瀏覽器上只能靠各種 isolation 降低風險,像是將不同站台跑在不同的 process 裡面:

In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.

Apple M1 也中這件事情讓人比較意外一點,看起來是當初開發的時候沒評估?目前傳言的 M1x 與 M2 不知道會怎樣...

Firefox 在 Strict Tracking Protection 模式下閹割 Google Analytics

Twitter 上看到 Firefox 在 Strict Tracking Protection 模式下會閹割掉 Google Analytics

剛好可以跟另外一篇「Google Analytics: Stop feeding the beast」一起看,這篇主要是對網站管理端的說明,你可以使用其他對隱私保護比較好的服務,或是考慮自己架設。

回到使用者端的部份,在 Firefox 裡面 Browser Privacy 預設是 Standard,換成 Strict 後就會觸發這個行為:

不是直接擋掉到 google-analytics.comgoogletagmanager.com 的連線,而是把 javascript 抽換掉,讓呼叫的程式碼完全不會做事。

在 Strict 模式下,除了會閹割 Google Analytics 外,也有其他的 js 會被閹割 (像是 Facebook 的),可以在 GitHub 上的「gecko-dev/browser/extensions/webcompat/shims/」這邊翻到。

這個功能很明顯在 Google Chrome 上不會內建,但很久前就有套件可以用了。目前比較常見的作法是透過 uBlock Origin 做,而且是在內建的「uBlock filters – Privacy」這組定義裡面就有實做,對應到 GitHub 上的 privacy.txt 這邊可以看到:

! Redirect to neutered Google Analytics 
||google-analytics.com/analytics.js$script,redirect=google-analytics.com/analytics.js

! Redirect to neutered Google Analytics Experiments
||google-analytics.com/cx/api.js$script,redirect=google-analytics.com/cx/api.js

不過 Firefox 上的 uBlock Origin 與其他套件也有類似的功能,真的在意的人應該早就使用了...

Google Chrome 88 的 Search Engine Keyword 功能失效恢復的方法

升級到 Google Chrome 88 以後又再次被 Google 姦了,這次是 Search Engine Keyword 的功能預設被關掉:「Chrome 88 disables space bar shortcut for custom search engines, but there's a fix」,在「Google Chrome keyword search is no longer working」這邊也有類似的問題冒出來。

文章裡面有提到解法,在 chrome://flags 裡面挑一個設為 Disabled 就可以了,我是用 #omnibox-keyword-search-button 這組:

設定完成後要重開瀏覽器才會生效。

Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動),後來提供的方法是變成可以設定的選項,但預設是關閉的,這樣一來就可以改善 Root name servers 的壓力:「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出),在繼續觀察幾個月後,上個禮拜 Verisign 的人在 APNIC 這邊更新了消息:「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料,可以看到趨勢往上:

這是後續的資料,從 87 版釋出後開始往下:

另外我覺得比較好玩的是這個,在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明:

看起來沒什麼問題,先 merge 再說... 是這樣玩嗎 XDDD