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.
// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
"PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
} // namespace features
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.
被擋下後再打都會失敗，所以需要一個方式重設 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.
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.
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.
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.
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 不知道會怎樣...
