Chromium 系列瀏覽器對 Google Search Engine 的不公平最佳化

在 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 的方式提供,現在這樣寫死在程式碼裡面完全就是不公平競爭。

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

但至少是個進展了...

這大慨是我在 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 不知道會怎樣...

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

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

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

GoogleChrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「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」。