幹壞事是進步最大的原動力
Firefox 也打算放棄 ESNI，改推 ECH 了：「Encrypted Client Hello: the future of ESNI in Firefox」。
目前的 85 版 (目前的 beta) 支援了 ECH draft-08，想要玩看看的人就可以測試了：
Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming.
另外一個要看的當然就是 Google 家的 Chromium 了，不過這個協定對 Google 的誘因應該是超大，有機會直接穿入中國市場... 只是不知道會不會自己搞一套 protocol。
Cloudflare 本來在推的 ESNI 現在變成 ECH 了：「Good-bye ESNI, hello ECH!」。
上面這張圖是 ESNI，下面這張是 ECH：
可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了，伺服器會先試著解內層的 ClientHelloInner，失敗的時候會用外層的 ClientHelloOuter：
The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.
看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣，這樣就能順便解掉 censorship 的問題...
其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI：
In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.
In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.
不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis)，目前看起來只處理了 ClientHello 本身，現在還是有機會分析 handshake 過程來擋，必須繼續改善 ECH 的協定，讓整個流程看起來都跟一般的 TLS 一樣...
可以等著看，到時候在中國的效果如何了，會不會讓國外的各大服務直接打進去呢...
上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務，而各家 acme client 也都陸陸續續支援了。
Dehydrated 是在 2020/09/15 的時候實做：「EAB + ZeroSSL support」，我就抓了個新版，更新之前自己包的 PPA dehydrated-lite...
Dehydrated 的設定方式還蠻簡單的，在 /etc/dehydrated/config 裡面這樣寫：
CA=zerossl EAB_HMAC_KEY=x EAB_KID=y
其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得，然後其他就照舊跑...
看到「Mutt 2.0 released」這篇，Mutt 推出 2.0 版，官方的 release notes 則是在這：「Mutt 2.0 Release Notes」。
這次版本跳到 2.0 主要是因為有 incompatible changes，實質上的變更其實沒有太多：
This release was bumped to 2.0, not because of the magnitude of features (which is actually smaller than past releases), but because of a few changes that are backward incompatible.
我自己還是保留一個信箱用 Mutt 在看信，主要是有一個信箱是完全控制在自己手上，所以自己架設 mail server 並且在上面看信...
上面主要是透過 procmail 拿來收各種信件 (尤其是 mailing list)，對於純文字的閱讀還是頗方便...
Cloudflare 改善了 Workers 的 cold start 時間：「Eliminating cold starts with Cloudflare Workers」。
傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑：
他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了：
這點利用了 TLS 啟動時的交換時間，把 cold start 的時間疊起來，不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來，不過因為只有 cold start 的部份，應該是還好...
這個連結在瀏覽器的 tab 上好幾天了，要寫這篇的時候試著找了一下當時是從哪個管道看到的來源，翻了一下看起來沒有在 Hacker News Daily 上面列出，但在 Hacker News 上面有找到討論串，不過最近沒有去從那邊翻連結...
Anyway，Zipcall 是使用 WebRTC 實做出來的會議系統，會議相關的流量會直接透過點對點的架構傳輸，不需要透過 server 交換。
由於架構上沒有 server 幫忙重新壓縮再轉給不同的使用者，也就 client 得自己處理，對硬體要求應該會比較高，另外對頻寬的要求也比較大。
另外他提到 latency 比較低這件事情，剛剛用兩隻 webcam 測試，一個掛到 vm guest 裡面，另外一個掛在 vm host 上面，測試下來很明顯可以感覺比起之前用 Zoom 高，可能要再研究到底是什麼原因，不確定跟 vm 有沒有關係，不過還在可以接受的範圍。
安全性與隱私性的實做方式也還得再看看是怎麼弄的，不過目前看起來應該可以先拿來玩玩...
最近剛好跟朋友有聊到 1.1.1.1，然後就有提到我不推薦使用 1.1.1.1 的原因。
主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS)，而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server，讓 DNS server 可以配出更精準的伺服器，而關於 Cloudflare 不支援的這點，可以在「1.1.1.1 supports ECS?」這邊看到一些討論。
這個問題在 Akamai 這種超大 CDN，在同一個地區的各 ISP 都有伺服器的情況下特別明顯。
以我家第四台的 cable 線路來說 (我的備用線路)，是走亞太 (APOL) 的線路出去，如果從自己的 ISP 查 www.akamai.com 的位置，可以查到 23.76.81.151，用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器：
gslin@rpi3p [~] [13:35] host www.akamai.com www.akamai.com is an alias for www.akamai.comv2.edgekey.net. www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net. e1699.dscx.akamaiedge.net has address 23.76.81.151 e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3 e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3 gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151 Start: 2020-04-05T13:35:49+0000 HOST: rpi3p Loss% Snt Last Avg Best Wrst StDev 1.|-- unknown 0.0% 10 0.5 0.5 0.4 0.6 0.0 2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw 0.0% 10 7.8 8.2 6.1 11.9 1.7 3.|-- 10.251.11.6 0.0% 10 19.3 25.6 19.3 33.5 4.7 4.|-- 10.251.231.5 0.0% 10 25.4 23.4 19.8 29.1 3.7 5.|-- 10.251.231.1 0.0% 10 8.0 10.7 5.7 24.0 5.7 6.|-- 10.251.230.34 0.0% 10 26.6 20.6 5.9 110.0 32.1 7.|-- 10.251.230.29 0.0% 10 58.4 35.4 6.6 81.2 30.9 8.|-- 202-178-245-162.cm.static.apol.com.tw 0.0% 10 9.5 18.4 7.4 78.5 21.3 9.|-- 203-79-250-201.static.apol.com.tw 0.0% 10 8.5 8.2 6.4 9.8 1.0 10.|-- 211.76.96.191 0.0% 10 7.2 10.2 6.7 15.6 2.7 11.|-- 203-79-254-10.ebix.net.tw 0.0% 10 2226. 3802. 2226. 6017. 1314.6 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com 0.0% 10 6.4 9.4 6.3 16.4 3.3
但如果從 1.1.1.1 查，會查到在中華電信內的 Akamai 伺服器，於是在尖峰時間反而變得很慢：
gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1 Using domain server: Name: 1.1.1.1 Address: 1.1.1.1#53 Aliases: www.akamai.com is an alias for www.akamai.comv2.edgekey.net. www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net. e1699.dscx.akamaiedge.net has address 23.48.142.132 e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3 e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3 gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132 Start: 2020-04-05T13:39:42+0000 HOST: rpi3p Loss% Snt Last Avg Best Wrst StDev 1.|-- unknown 0.0% 10 0.4 0.5 0.4 0.6 0.1 2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw 0.0% 10 8.7 17.0 6.1 81.2 22.8 3.|-- 10.251.11.6 0.0% 10 26.7 24.6 21.4 29.3 2.8 4.|-- 10.251.231.5 0.0% 10 26.8 29.9 16.8 88.6 21.0 5.|-- 10.251.231.1 0.0% 10 7.2 8.3 6.8 12.7 1.8 6.|-- 10.251.230.34 0.0% 10 10.3 8.9 5.9 11.0 1.6 7.|-- 10.251.230.29 0.0% 10 6.3 10.1 5.4 31.7 7.8 8.|-- 202-178-245-162.cm.static.apol.com.tw 0.0% 10 8.8 9.1 7.3 13.2 1.8 9.|-- 203-79-250-209.static.apol.com.tw 0.0% 10 10.0 8.6 6.3 10.8 1.5 10.|-- 211.76.96.67 0.0% 10 7.9 9.0 4.0 12.4 2.6 11.|-- 109-84-21-113-static.chief.net.tw 0.0% 10 18.3 11.7 7.0 25.1 5.7 12.|-- 21-252-123-103-static.chief.net.tw 0.0% 10 9.4 10.0 7.7 15.0 2.2 13.|-- 203-75-228-5.HINET-IP.hinet.net 0.0% 10 10.1 10.8 7.0 21.2 4.3 14.|-- r4209-s2.hinet.net 0.0% 10 9.4 10.5 6.3 17.9 3.7 15.|-- tpdt-3012.hinet.net 0.0% 10 92.0 61.6 11.1 141.6 53.8 16.|-- tpdt-3301.hinet.net 0.0% 10 42.9 38.8 7.3 100.8 33.6 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com 0.0% 10 8.2 15.5 8.2 46.6 12.4
跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好，但因為沒有 EDNS Client Subnet (ECS) 的資訊，所以只能導去當地 (地理上) 預設的點，latency 應該還是夠低，但頻寬就未必足夠了。
用 8.8.8.8 會好一點，但目前最建議的還是用 ISP 自家的 DNS resolver，當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時，CDN 也還是會正確讀到 ISP 的資訊，配到的伺服器的頻寬就不會太差...
前陣子 Chromium 團隊在研究要移除 User-Agent 字串的事情 (參考「User-Agent 的淘汰提案」)，結果 kiwibrowser 就直接炸下去，Google 很久前就會針對自家網站送出 x-client-data 這個 HTTP header，裡面足以辨識使用者瀏覽器的單一性：「Partial freezing of the User-Agent string#467」。
在 Google 的白皮書裡面是說用在 server 的試驗：
We want to build features that users want, so a subset of users may get a sneak peek at new functionality being tested before it’s launched to the world at large. A list of field trials that are currently active on your installation of Chrome will be included in all requests sent to Google. This Chrome-Variations header (X-Client-Data) will not contain any personally identifiable information, and will only describe the state of the installation of Chrome itself, including active variations, as well as server-side experiments that may affect the installation.
The variations active for a given installation are determined by a seed number which is randomly selected on first run. If usage statistics and crash reports are disabled, this number is chosen between 0 and 7999 (13 bits of entropy). If you would like to reset your variations seed, run Chrome with the command line flag “--reset-variation-state”. Experiments may be further limited by country (determined by your IP address), operating system, Chrome version and other parameters.
但因為這個預設值開啟的關係，就算關掉後也足以把使用者再分類到另外一個區塊，仍然具有高度辨識性，不是你 Google 說無法辨識就算數。
另外如果看 source code 裡的說明：
// Note the criteria for attaching client experiment headers:
// 1. We only transmit to Google owned domains which can evaluate
// experiments.
// 1a. These include hosts which have a standard postfix such as:
// *.doubleclick.net or *.googlesyndication.com or
// exactly www.googleadservices.com or
// international TLD domains *.google. or *.youtube..
// 2. Only transmit for non-Incognito profiles.
// 3. For the X-Client-Data header, only include non-empty variation IDs.
可以看到 *.doubleclick.net、*.googlesyndication.com 與 www.googleadservices.com 全部都是廣告相關，另外 Google 自家搜尋引擎是直接提供廣告 (不透過前面提到的網域)，YouTube 也是一樣的情況，所以完全可以猜測 x-client-data 這個資料就是用在廣告相關的系統上。
The Register 在「Is Chrome really secretly stalking you across Google sites using per-install ID numbers? We reveal the truth」這邊用粗體的 Update 提到了 GDPR 的問題，不確定是不是開始有單位在調查了：
Updated Google is potentially facing a massive privacy and GDPR row over Chrome sending per-installation ID numbers to the mothership.
在這個問題沒修正之前，只能暫時用操作 HTTP header 的 extension 移掉這個欄位。
看到廢除更新 User-Agent 字串的提案：「Intent to Deprecate and Freeze: The User-Agent string」。
一方面是 User-Agent 裡面太多沒用的假資料 (像是每一家都是 Mozilla)，另外 User-Agent 會帶出一些隱私問題 (辨識資訊)。
目前的提案是希望改用 User-Agent Client Hints (UA-CH) 取代 User-Agent 的功能，把預定義好的東西透過對應的 HTTP header 傳遞。
Chromium 的計畫是在 M81 (stable 版預定在 2020 年三月中釋出) 先 deprecate navigator.userAgent，所以有存取時 web console 上會出現警告。而 M83 (2020 年六月初) 則是不再更動 user agent 字串 (鎖住)。到了 M85 (2020 年九月中) 則是統一 desktop 的 user agent 字串，並且盡可能統一 mobile 上的字串。
另外裡面也有整理了其他瀏覽器的意願：
Edge: Public support
Firefox: Public support for freezing the UA string - “freezing the User Agent string without any client hints—seems worth-prototyping”
Safari: Shipped to some extent. Safari has attempted to completely freeze the UA string in the past, without providing an alternative mechanism. That got a lot of pushback, which resulted in somewhat reverting that decision. Nowadays, their UA string seems frozen, other than updates to the OS version and the browser major version.
雖然不是完全都同意，但看起來應該有機會在今年陸陸續續搞定...
Trac 在發 ticket 的通知信時，會定義自己的 Message-ID，另外後續變更的通知信件會增加 References 欄位，讓 mail client 可以配對起來 (變成一個 thread)。
但 Amazon SES 會把原來的 Message-ID 改掉，使用自己的 Message-ID 欄位，可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來，只剩下後續的信件因為有相同的 References，所以 mail client 可以正確的配對起來。
所以我就決定生一個 workaround plugin，只要是沒有 References 的信件 (像是每張 ticket 的第一封信)，就從 Message-ID 複製一份到 References 裡，這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好，所以就不判斷是不是 ticket 的通知信了...
這就是 trac-references-mail-decorator 這個套件的由來...