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 是不是也要有稽核機制?

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

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

GitHub 引入 Code Owner 的概念

GitHub 推出了 Code Owner 的概念:「Introducing code owners」。也很直接說這個能是向 Chromium「致敬」出來的:

The code owners feature was inspired by Chromium's use of OWNERS files.

檔案名稱是 CODEOWNERS,可以放在根目錄或是 .github/ 下,可以針對不同的目錄設不同的人:

To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format[.]

這樣一來,在 pull request 的時候就會跳出來:

另外也可以設定需要 code owner 同意才能 merge: