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 正在研究中)。

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

Google Chrome 對 CPU bug 的 patch

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

先是在 Hacker News 上看到「Speculative fix to crashes from a CPU bug」這個猜測性的修正,這是因為他們發現在 IntelGemini 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 來避開,但看起來手上沒有可以重製的環境,所以只能先把實做丟上來...

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 時可以考慮換過來...

其他用 Chromium 核心的瀏覽器不打算跟進 webRequest 的修改

先前提到的「所以 Google 要對 ad blocker 全面宣戰了...」,現在朝著幾個方向在發展:一個是寄託在反托拉斯法的部份,另外一個是市場的替代方案。

Firefox 算是常被提出來的替代方案,但 Firefox 的流暢度比 Chromium 差了一大截,所以目前主要的替代方案應該還是在各家使用 Chromium 核心的瀏覽器身上。

ZDNet 詢問了這些瀏覽器的人,大多數都表態會維持 webRequest 的原來運作:「Opera, Brave, Vivaldi to ignore Chrome's anti-ad-blocker changes, despite shared codebase」。

目前只剩下剛換到 Chromium 核心的 Microsoft Edge 還沒有回應 ZDNet

先繼續看看吧...

實做 Twitter 同步到 Facebook 的程式

幾個月前 Facebook 把 API 拿掉了,大家都不能用 API 發文,本來想說就放掉這個平台,結果被老人家問怎麼都沒更新,因為老人家都是靠兒子的 Facebook 確認生存,看到沒更新就很擔心... XD

由於 API 沒得用了,所以得自己 hack。這邊先列重點:

  • chromium + VNC 登入後,用 chromium headless + selenium 發文。
  • 對於「網頁的穩定性」來說 (i.e. 常不常改版造成我的程式發文失敗),mbasic(.facebook.com) > m > www。

比較重要的方向就是這些,其他的其實就是磨時間、踩地雷,然後把程式刻出來:「gslin/twitter2facebook」。

把 Google 服務拔乾淨的 Chromium

有人試著把 Chromium 裡的 Google 相關服務都拔乾淨,叫做 ungoogled-chromium

Modifications to Google Chromium for removing Google integration and enhancing privacy, control, and transparency

有提供志願者包好的 pre-built binary,但看了一下版本有點舊,而且不能確定裡面有沒有什麼加料... 要用的人可能還是要考慮自己編一包出來。

在「Add a PPA or APT repo」這邊有人在討論要怎麼包 PPA 出來,不過看起來卡關了...

Android 打算針對 Data Saver + 2G 網路的使用者關閉 JavaScript 功能

在「Chrome for Android may start disabling JavaScript on 2G connections」這邊看到的,引用的文章是 XDA 的「Google Chrome on Android to disable JavaScript automatically on 2G connections」。

在「Disable scripts for Data Saver users on slow connections」這邊可以看到 Android 的計畫,在打開 Data Saver 的情況下,Chrome 會停用 JavaScript,並且提示使用者:

If a Data Saver user is on a 2G-speed or slower network according to the NetInfo API, Chrome disables scripts and sends an intervention header on every resource request. Users are shown a UI at the bottom of the screen indicating the page has been modified to save data. Users can enable scripts on the page by tapping “Show original” in the UI.

在「Enabled NoScript Preview feature by default on Android」這邊可以看到對應的程式修改。

這樣反而可以少收到很多廣告耶,反倒希望是全域打開 XDDD

第一次拿 Headless Chrome (Chromium) 出來玩...

前陣子發現 PChome 24h 的輕小說 Atom feed 掛掉了 (在 gslin/pchome24h-feed 這邊),看了一下頁面發現換 url 了,而且從 BIG5 變成 UTF-8 (賀!!!),但變成大量的 js call 產生資料產生頁面 (還不是 ajax 的 JSON),而且有一堆奇怪的 magic number 在裡面 (感覺會因為改版就產生變化 XD),就懶得再自己組出來了,決定玩看看 Headless Chrome 練個功...

Chrome 從 2017 年七月的 59 版就推出了 Headless 功能 (stable channel 的時間),也因此在去年四月的時候 PhantomJS 就決定停止維護下去:「Google Chrome 的 Headless 模式與 PhantomJS 的歷史」。

官方的文件「Getting Started with Headless Chrome」寫的很完整,而且也可以看到 Headless Chrome 把常見的功能都先實做完了。在不另外裝軟體的情況下就可以做很多事情。像是直接把生成好的 DOM 轉成 HTML 丟出來:

chrome --headless --disable-gpu --dump-dom https://www.chromestatus.com/

或是把頁面輸出成 PDF,或是輸出成圖片 (screenshot.png):

chrome --headless --disable-gpu --print-to-pdf https://www.chromestatus.com/
chrome --headless --disable-gpu --screenshot https://www.chromestatus.com/

也可以直接開 js console 出來互動:

$ chrome --headless --disable-gpu --repl --crash-dumps-dir=./tmp https://www.chromestatus.com/
[0608/112805.245285:INFO:headless_shell.cc(278)] Type a Javascript expression to evaluate or "quit" to exit.
>>> location.href
{"result":{"type":"string","value":"https://www.chromestatus.com/features"}}
>>> quit
$

在文件後面也提供了大量範例,教你怎麼用 Selenium + WebDriver + ChromeDriver 操作,順著用裡面的範例找一下 Python 會怎麼寫就寫好了... 之後也機會來測試 Firefox 好了 :o

CloudFlare 也要提供 Certificate Transparency 的 Log 伺服器了...

看到 CloudFlare 請求加入 Chromium (Google Chrome) 的伺服器列表:「Certificate Transparency - Cloudflare "nimbus2017" Log Server Inclusion Request」。

對照之前的「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」以及「Let's Encrypt 的 Embed SCT 支援」,這樣看起來是瀏覽器內會有一份白名單,只有在這白名單上的 Embed SCT 才會被信任...

但弄到這樣的話,log server 是不是也要有稽核機制?

好像哪邊搞錯了方向啊...