Firefox 也打算淘汰 ESNI,改推 ECH

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。

AWS 推出 CloudShell

AWS 推出了 CloudShell,讓使用者可以繼承 IAM 的權限,在瀏覽器裡面用 command line 操作 AWS 資源:「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單,在 web console 上方的 icon 點下去就可以用了,只是第一次使用的時候會看到需要建立環境的訊息,會等比較久:

連進去後測了一下,看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來,/dev/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器,以這個資訊來查,看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通,但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些,之後應該會陸陸續續再開放:

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份,官方是說不需要另外的費用,只需要付出用到的 AWS 資源,但這邊沒給範例啊,到底是怎麼算的... 看了一圈 EC2ECSEKS 都沒有機器,應該是不會算到這邊?

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是,對於已經習慣跳板機的人來說好像還好,尤其是 command line 已經用熟了,太習慣用 Ctrl-W 刪字串,而在瀏覽器裡面按下去就會直接出事的情況,還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限,所以在 awscli 下的權限是一樣的,另外對於有些 web console 沒支援的操作可以用這個方法補強,而不需要自己弄機器出來跑。

Cloudflare 拔掉使用 Cookie 分析的功能

這兩則應該可以一起看,雖然相差了兩個多月。

首先是今年九月底的時候提供隱私優先的分析系統:「Free, Privacy-First Analytics for a Better Web」,接下來是最近 (十二月) 宣佈要把 __cfduid 這組 cookie 拔掉:「Deprecating the __cfduid cookie」。

文章裡面沒有提到現在是怎麼偵測的,但我猜是瀏覽器的 fingerprint 資料已經足夠辨識了,不需要用到 cookie,這點可以參考 EFF 的「Cover Your Tracks」。

所以 privacy-first 這件事情也只是程度上而已,為了要防禦 bot,還是得正確辨識出不同的使用者,也就是說,現在不用 cookie 不代表 privacy 就高很多。不過這的確是試著在技術上努力降低疑慮就是了...

真的想要在 internet 上隱藏身份的人還是用 Tor 吧,基本上最少應該拿 Tor Browser,更小心一點應該用 Tails 這類軟體。

網頁本身是個合法的 JSON 的展示

Hacker News Daily 上看到「Web Data Render」這個有趣的東西,這個網頁本身是個 JSON,透過一些技巧載入 javascript 後就可以讀取資料 render...

不過網頁本身就不是合法的 HTML 了:「Showing results for https://webdatarender.com/」,只能算是個有趣的作法...

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式,結合了 Golang 的執行效率與 JavaScript 的操作語法,讓使用者可以很簡單的進行壓力測試,在 Hacker News 上也有蠻正向的反應:「K6: Like unit testing, for performance (github.com/loadimpact)」,我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊,看起來「Load Impact」是公司名稱,「LoadImpact」則是產品名稱,然後現在要改名變成「k6」與「k6 Cloud」:

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念,如同字面上的意義,VU 是虛擬的使用者,就技術上來說,每個 VU 都是在獨立的 JavaScript runtime 裡跑:

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了,所以就不需要一堆 callback & promise 架構,用起來就爽很多:

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼,看起來 JavaScript runtime 這部份是用 Golang 寫的 goja

文件裡面給了不少範例,像是在「Running k6」這邊有直接給出怎麼壓測,10 個 VU 跑 30 秒:

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面,「samples」這個目錄下有不少範例,可以直接先看過一次從裡面學到不少功能,之後再回去翻一次 manual,應該就會更熟悉...

隨便測了一下還蠻容易上手的,加上有 apt repository 可以直接納入系統管理,看起來應該會放著跑,之後找機會用看看,也許打 API 之類的...

lighttpd 居然出新版支援 HTTP/2 與 Brotli 了...

從 mailing list 收到 lighttpd 出新版的通知信,本來以為是 security fix,結果看了一下發現雖然版號是從 1.4.55 變到 1.4.56,但這個版本支援了 HTTP/2,以及 Brotli 壓縮:「Release-1 4 56 - Lighttpd - lighty labs」。

lighttpd 應該是我還在學校的時候幫 PIXNET 用的東西?他跑 FastCGI 模式接 PHP 當時效能還不錯... 現在自己架站的習慣是用 nginx 了。

反倒是他當年因為要更方便的支援 FastCGI 而生的 spawn-fcgi 讓 nginx 與其他專案沿用,後來是各家專案自己都原生支援 FastCGI 或是其他協定,所以重要性就淡了一些...

這次的更新推出的 HTTP/2 算是補上蠻重要的功能,不知道會對 lighttpd 社群帶來什麼能量...

Servo 將由 Linux Foundation 提供協助

Servo 是使用 Rust 開發的 web engine,先前是由 Mozilla 在後面支撐,在 Firefox 裡面也有使用 Servo 的 CSS engine,而 Servo 的 JavaScript engine 則是使用了 SpiderMonkey

但在今年 Mozilla 大幅重整組織後,Servo 的未來變得頗不明朗,直到現在公佈會由 Linux Foundation 提供協助:「Servo’s new home」。

The Servo Project is excited to announce that it has found a new home with the Linux Foundation.

這樣看起來暫時解決了一個大問題,開發的能量還得看看要怎麼補上來...

Google Chrome 的 Cache Partition 生效

去年提到的「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」在最近推出的 Chrome 86 預設生效了:「Chrome changes how its cache system works to improve privacy」。

Google 的文章「Gaining security and privacy by partitioning the cache」這邊有提到不同瀏覽器都有打算要支援類似的架構,對應的差異:

Is this standardized? Do other browsers behave differently?

"HTTP cache partitions" is standardized in the fetch spec though browsers behave differently:

  • Chrome: Uses top-level scheme://eTLD+1 and frame scheme://eTLD+1
  • Safari: Uses top-level eTLD+1
  • Firefox: Planning to implement with top-level scheme://eTLD+1 and considering including a second key like Chrome

文章裡面看到了有趣的東西,是他提到了 Fetch 這個標準,然後是在「2.7. HTTP cache partitions」這邊出現了對應的說明:

To determine the HTTP cache partition, given request, run these steps:

Let key be the result of determining the network partition key given request.

If key is null, then return null.

Return the unique HTTP cache associated with key. [HTTP-CACHING]

所以看起來是訂 Fetch 時寫下一套方法,然後拿來擴大套用到整個瀏覽器...

讓瀏覽器直接連 HTTPS 的 SVCB/HTTPS

Cloudflare 的「Speeding up HTTPS and HTTP/3 negotiation with... DNS」這篇裡面提到了一個新的標準 (目前是 draft):「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」。

從文件上可以看到這個標準是由 GoogleAkamai 的人提出來的,想要透過 DNS 的方式告訴瀏覽器這個網站可以直接用 HTTPS 連線 (以及其他資訊)。

這樣有兩個好處,第一個是安全性上的好處,HSTS 只保證了第二次以及之後的連線會強制用 HTTPS,但不能保證第一次連線時是 HTTPS。透過 DNS 查到後可以第一次就用 HTTPS 連線。

第二個是效能上的好處,降低了一個 3xx redirect 的時間,雖然 DNS 多了一些查詢,但 DNS 查詢這邊通常會比 TCP connection 建立連線來說快不少,再加上 HTTP protocol 需要先等瀏覽器端送出 HTTP header 後才有回應,這樣應該是快蠻多的。

文章裡有提到 iOS 14 好像有開始在嘗試,但我好像沒看到其他資料:

We began investigating and found these to be a part of Apple’s iOS14 beta release where they were testing out a new SVCB/HTTPS record type.

先繼續觀望看看標準怎麼發展...

CloudFront 宣佈支援 Brotli

CloudFront 宣佈支援 Brotli:「Amazon CloudFront announces support for Brotli compression」。

官方的說明發現 Gzip 可以好 24%:

CloudFront's Brotli edge compression delivers up to 24% smaller file sizes as compared to Gzip.

Akamai 在「Understanding Brotli's Potential」這邊提到的測試數字稍微做了分類,可以看到在 html 下 Brotli 帶來的改善是最多的。

以前在 CloudFront 上還是可以支援 Brotli,主要是透過後端支援 Brotli 的方式傳回不同的資料,再加上 Vary: Accept-Encoding 的設定讓 CloudFront 針對不同的 Accept-Encoding 分開 cache。

這次的支援等於是讓 CloudFront 理解 Brotli,就可以提昇 hit rate 並且降低後端的壓力:

Prior to today, you could enable Brotli compression at the origin by whitelisting the 'Accept-Encoding' header. Now CloudFront includes 'br' in the normalized 'Accept-Encoding' header before forwarding it to your origin. You no longer need to whitelist the 'Accept-Encoding' header to enable Brotli origin compression, improving your overall cache hit ratio. Additionally, if your origin sends uncompressed content to CloudFront, CloudFront can now automatically compress cacheable responses at the edge using Brotli.

算是補產品線...