Tag: chrome

Google 與 Cloudflare 測試 Post-Quantum 演算法的成果

這幾年量子電腦的進展不斷有突破，雖然到對於攻擊現有的密碼學看起來還有一段時間，但總是得先開始研究對量子電腦有抵抗性的演算法...

其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品，兩個團隊合作測試的結果在學界與業界都還蠻重視的：「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。

Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel，有控制組與兩個新的演算法：

Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)

這兩個演算法有優點也有缺點。一個是 key 比較小，但運算起來比較慢 (SIKE，CECPQ2b)；另外一個是 key 比較大，但是運算比較快 (HRSS，CECPQ2)：

For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.

We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.

感覺還是會繼續嘗試，因為這兩個演算法的缺點都還是有點致命...

Google Chrome 要藉由拆開 HTTP Cache 提昇隱私

在「Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache」這邊看到的，Google Chrome 打算要拆開 HTTP Cache 以提昇安全性與隱私性。

有 cache 跟沒有 cache 可以從讀取時間猜測出來，這樣就可以知道瀏覽器是否有這個特定 url 的 cache。

在原文的作者所給的例子沒有這麼明顯，這邊舉個實際一點的例子來說好了... 我想要知道你有沒有看過 zonble 的「返校」這篇文章，我就拿這篇文章裡面特有的資源來判斷。

以這篇文章來說，我可以選擇第一張圖片的網址 https://i0.wp.com/c1.staticflickr.com/1/603/31746363443_3c4f33ab18_n.jpg?resize=320%2C200&ssl=1 這個 url 來判斷讀取時間，藉此我就可以反推你有沒有看過這篇文章，達到攻擊隱私的效果。

解決的方法就是作者文章裡所提到的方法，把 HTTP cache 依照不同的網站而分開 (在 Safari 已經支援這個功能，而 Firefox 正在研究中)。

當然這樣做應該會對流量有些影響，但考慮到這些日子有很多新技術可以增加下載速度，這個功能應該是還能做...

uBlock Origin 的開發版 (Dev) 被 Chrome Web Store 拒絕的事件...

uBlock Origin 是一個在瀏覽器上擋廣告的軟體，以前在推廣的時候都只提到可以過濾掉網站上的廣告，大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD)，但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」，大家接受度意外的爆高，不過這有點扯遠了，回到原來的主題上...

先介紹一下 uBlock Origin 的開發模式，除了一般的 stable 版本外 (「uBlock Origin」這組)，另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組)，這樣讓使用者比較容易安裝與測試，這個方式也可以在 Tampermonkey 上看到。

這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1 版上傳到 CWS 上後收到被拒絕上架的通知：「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。

拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」，也就是不能把目的不同的東西強迫使用者綁在一起使用：

Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose

後續的 1.22.5rc2 也被拒絕，然後他回信詢問了 CWS 官方，得到的仍然是罐頭回應，然後他就決定丟著 (而這個作法還蠻聰明的)，接著這件事情就被丟著變成 PR 事件上了一些媒體，然後昨天就突然解了...

Google 最近的動作愈來愈多了，一方面在嘗試避免觸動反托拉斯法的情況，儘可能打壓這些擋廣告的套件...

Google Chrome 78 又要搞事把 www 開頭拿掉了...

剛剛改回用 beta channel 的 Google Chrome (78 版)，結果發現網址列裡的 www 被拿掉，而且本來可以關掉的方式 (omnibox-ui 系列的設定) 從 chrome://flags 裡面也拔掉了，代表你現在關不掉了...

搜了一下資料，發現在 Reddit 上有人討論過 78 版的這個問題 (當時還在 dev channel)：「Chrome 78 dev hide 'www' again」。

裡面有人提到可以安裝 Suspicious Site Reporter 讓 www 重現，當初看到還半信半疑，結果裝了發現真的會動，WTF...

看了一下 extension 的 source code 發現好大一包，以後應該會有人生一個小的 extension 出來專門做這件事情？

Google Chrome 對 CPU bug 的 patch

既然有方向了，後續應該會有人去找底層的問題...

先是在 Hacker News 上看到「Speculative fix to crashes from a CPU bug」這個猜測性的修正，這是因為他們發現在 Intel 的 Gemini Lake 低功耗晶片組上會發生很詭異的 crash：

For the last few months Chrome has been seeing many "impossible" crashes on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes only happen with 64-bit Chrome and only happen in the prologue of two functions. The crashes come and go across different Chrome versions.

然後依照 crash log 猜測跟 alignment 有關，所以決定用 gcc/clang 都有支援的 __attribute__ 強制設定 alignment 來避開，但看起來手上沒有可以重製的環境，所以只能先把實做丟上來...

Chrome 將不會在 HTTPS 頁面上載入 HTTP 資源...

現在 Google Chrome 的穩定版是 77，到了十二月會推出的 79 的時候，就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施：「No More Mixed Messages About HTTPS」。

首先是 79 的時候會有新的界面，讓使用者可以修改阻擋類的設定。

到了 80 的時候會試著將 HTTP 的影音 <audio> 與 <video> 升級到 HTTPS 連線，如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來，只是安全性上會顯示 Not Secure。

到了 81 就是這系列的最終階段，包括 <img> 也會一使用 80 時影音的邏輯，沒辦法在 HTTPS 上讀到就當作讀取失敗。

Safari 上 uBlock Origin 的情況

uBlock Origin 在 2016 的時候 porting 到 Safari 上，但在 2018 後就沒有再更新了，維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。

主要就是蘋果要廢掉本來的 Extension API，而替代的框架裡沒有對應的 content filtering 能力，所以在新的框架內無法實做 uBlock Origin 的功能...

維護者的建議是換瀏覽器，但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞)，所以維護者的建議就是換成 Firefox。

另外我自己會建議用看看 Brave，因為 Brave 已經決定，如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3)，他們會繼續維持本來的相容性，所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。

Google Chrome 也要打開 DoH

Google Chrome 也要支援 DNS over HTTPS (DoH) 了，不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估？)，會先判斷系統的 DNS 是否在支援 DoH 的清單內，在不改變 DNS 服務商的情況下，從本來的 UDP 查詢變成 DoH 查詢：「Experimenting with same-provider DNS-over-HTTPS upgrade」。

清單可以從「DNS over HTTPS (aka DoH)」這邊看到，除了 Google 自己外，也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。

這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77)：

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.

Brave 試用

目前主力的瀏覽器還是 Google Chrome，會試著用其他的瀏覽器基本上就是「所以 Google 要對 ad blocker 全面宣戰了...」這篇文章提到的事情，然後找看看有什麼方案可以用...

先前測過 Firefox，但目前光是只開著三個 Slack 就會當掉 (三個 tab 都吃滿 100% CPU，所以可以在 top 上看到 300% 的使用率)，另外整理的順暢度還是差了很大一截，實在是找不到什麼好理由換過去...

而這次測的 Brave 是從 Chromium 改出來的，看起來沒有改動太多東西，連 extension 站台都直接吃 Google Chrome 的，基本上都會動。

測了兩天有一些問題：

目前來看轉換成本不算太高，之後 Google Chrome 真的動手搞 ad blocker 時可以考慮換過來...

Chrome 打算要終止支援 FTP 協定

從「Google plans to deprecate FTP URL support in Chrome」這邊看到的，狀態資訊可以在「Deprecate FTP support」這邊看到。

以目前的 timeline 資訊，看起來是 M82 版本會完全拔掉：

M78 (2019Q4)
Finch controlled flag and enterprise policy for controlling overall FTP support.

Support disabled on pre-release channels.

M80 (2020Q1)
Gradual turndown of FTP support on stable.

M82 (2020Q2)
Removal of FTP related code and resources.

不過這樣就沒有方便的 FTP downloader 了 (雖然不常見)，得另外再找軟體下載...