幹壞事是進步最大的原動力
看到「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」這樣的參數，像是這樣：
這樣會再推一把...
在大約三年前 (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 不知道會怎樣...
升級到 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) 實做對 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
這幾天玩 Clubhouse 玩太兇了，來清一下累積在 tab 上的東西...
在「Waterfox G3.1.0 introduces support for installing Chrome and Opera extensions」這邊看到的東西，以 Firefox 為基底的 Waterfox 可以裝 chrome web store 裡的 extension 了。也就是說，現在除了可以裝 Firefox 自家的 Add-Ons 外，現在也可以裝 chrome web store 的套件了，但注意的是，畢竟底層用的 engine 不同 (以及支援的 API 也不同)，不保證 100% 會動。
把自己之前寫過的套件裝起來，在套件頁大概長這樣，不確定自動更新的機制會怎麼跑就是了：
另外一個小問題是，裝完後在 chrome web store 的網站上也不會顯示已經安裝了，這個設計應該是為了隱私，不讓網站有機會偵測到：
加減來測試看看...
看到這則新聞時決定讓子彈飛了一陣子，但好像沒看到什麼新消息：「Feds may target Google’s Chrome browser for breakup」，Hacker News 上也有討論可以翻翻：「Feds may target Google's Chrome browser for breakup (politico.com)」。
Google 在 Chrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站」這樣的事情)，會直接先把 Google Chrome 拆出來的消息不算太意外。
不過大家對反壟斷調查更有興趣的應該是 YouTube 會怎麼被處理。網路上經常會看到「如何逃離 Google」之類的文章，Google 很多服務都有其他平台可以提供，或是 open source 軟體可以使用，但每次一講到 YouTube 時大家都很頭痛，都會提到 YouTube 的難以取代性，因為目前其他平台沒有一個是堪用的...
不知道什麼時候會發動調查...
在「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」。