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.

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

AirBnB 送出 Form S-1

Hacker News Daily 上看到 AirBnB 送出 Form S-1 了:「d81668ds1.htm」,在 TechCrunch 上面也有一系列的文章可以看...

印象中差不多試 2018 年就有一些傳言了,結果在 2019 年的時候沒看到,到了 2020 年被 COVID-19 重挫... 但長期來看是個成功的商業模式,所以 2020 年不論是有要上還是沒有要上都不意外,現在丟出 Form S-1 給了個答案。

接下來就是等開張那天的股價了...

Amazon Lightsail 推出 Container 版本

看到 Amazon Lightsail 推出了 Container 版本的消息:「Announcing Amazon Lightsail Containers, an easy way to run containerized applications on the cloud」,另外在「Lightsail Containers: An Easy Way to Run your Containers in the Cloud」這邊也有介紹。

從官方 blog 上的圖可以看到機器規格與價位,比 Lightsail 貴一些:

另外有提到如果之後要轉到 Amazon ECS 或是 Amazon EKS 的話也都可以直接轉,不過我印象中 ELB 的部份還是要設一下,這點看起來 Lightsail 簡化了不少:

If you plan to later deploy your container to Amazon ECS or Amazon Elastic Kubernetes Service, no changes are required. You can pull the container image from your repository, just like you do with Amazon Lightsail.

不過後面實際上是用什麼架構跑啊?如果考慮到安全性的話應該是直接拿 t3.* 的主機直接 1:1 對應,只是包裝成吃 Docker,而不會共用主機?

Firefox 83 推出 HTTPS-Only Mode

MozillaFirefox 83 推出了 HTTPS-Only Mode:「Firefox 83 introduces HTTPS-Only Mode」。

就如同名稱的說明,這個模式只會允許 HTTPS 的連線,主要的設計方式是把「開 HTTP 連線」當作一種特殊權限,就像 notification 之類的權限一樣:

When you enable HTTPS-Only Mode:

  • Firefox attempts to establish fully secure connections to every website, and
  • Firefox asks for your permission before connecting to a website that doesn’t support secure connections.

使用者會先在設定裡面開啟這個全域設定:

開了以後如果想要連 HTTP 網站,就會遇到阻擋:

這個功能真的不賴,馬上想到 Tor BrowserTails 應該都會改用這個,畢竟 Tor 的 HTTP 出口常常被搞...

我自己類似的保護措施是把 HTTP 頁面執行 JavaScript 的能力全部關掉,像是這樣 (這邊是 Brave 瀏覽器,是個基於 Chromium 的 fork):

然後對於需要 JavaScript 的 HTTP 頁面,我是透過「Simple JavaScript Toggle」暫時授權。

這樣至少在無法確認 integrity 的情況下不會執行 js,減少可被攻擊的面積...

CloudFront 新增泰國節點

看到 Amazon CloudFront 新增了泰國曼谷節點的消息:「Amazon CloudFront launches in Thailand」,原來泰國之前沒開啊...

Amazon CloudFront announces its first two edge locations in Thailand.

另外依照網路架構,先前泰國的流量應該是往新加坡或是香港跑 (我覺得新加坡可能比較像?),不過也不是那麼確定... 畢竟地理位置比較近的馬來西亞可以透過陸地就拉過去,不需要走海纜,只是不確定馬來西亞的點有沒有買 transit:

These new edge locations in Bangkok will provide viewers as much as a 30% reduction in p90 latency measures.

然後最近都至少是兩個點在開了,對服務穩定性比較好,維修的影響也比較小...

C++ 版本的 Kafka

Hacker News 首頁上看到的東西,看起來是 C++ 版本的 Apache Kafka 替代品 Redpanda,要注意的是這不是 open source license 軟體:「Redpanda – A Kafka-compatible streaming platform for mission-critical workloads (vectorized.io)」。

目前網站上可以看到,最主要的特點是不需要 Apache ZooKeeper,不過這點在 Kafka 這邊也正在進行了 (之前在「Kafka 拔掉 ZooKeeper 的計畫」這篇有提到),雖然進度有點慢...

另外目前完全沒有 benchmark 資料,只有宣稱 10x 更快,官方在 Hacker News 上的回應是說十二月會有公開的測試報告,這樣我會把 10x 當廣告詞看了,應該會更快,但大概是某種特殊情境下才會達到...

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA,以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄:「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的,沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例,用 SSL Labs 的工具就可以掃出來問題:「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s),所以在 Android 上找不到一條完整的 trust chain:

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain,所以 Windows 上的 Microsoft EdgeGoogle Chrome 是不會有問題的 (這兩個都吃系統的 CA store):

Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料,就是 Android 那包)。

交叉比對中華電信自家的網站,像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組,可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA,但有兩種不同的 SHA256,可以翻到是:「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」,點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽,但卻不是每一個 CA 都有被所有瀏覽器認可,所以在設定的時候就得注意...

話說回來,現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency),的確是有辦法抓出所有的 Intermediate CA 沒錯,但瀏覽器幫使用者預載感覺好像怪怪的?

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料:

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack?

Amazon DocumentDB 推出相容 MongoDB 4.0 的版本

在「Amazon DocumentDB (with MongoDB compatibility) adds support for MongoDB 4.0 and transactions」這邊看到 AWSAmazon DocumentDB 上推出相容 MongoDB 4.0 的版本。

把年初在 Ptt 上寫的「Re: [請益] 選擇mongoDB或是relational database ??」這篇拿出來講一下,MongoDB 4.0 最大的改進就是 multi-document transactions 了。

不過 AWS 先前推出 DocumentDB (MongoDB) 時看到的限制,大家都猜測是用 PostgreSQL 當底層 (「AWS 推出 MongoDB 服務:Amazon DocumentDB」與「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」),雖然目前還是不太清楚,但如果這個猜測屬實的話,要推出各種 transaction 的支援完全不是問題 XDDD

Amazon EBS 的 Cold HDD (sc1) 降價 40%

剛剛看到 Amazon EBS 的 Cold HDD (sc1) 大幅降價 40%:「AWS announces 40% price reduction for Amazon Elastic Block Store (EBS) Cold HDD (sc1) volumes」。

Cold HDD (sc1) 主要是拿來堆資料的,直接掛上來操作比起 Amazon S3 還是方便不少,這次的降價算是懶人的福音?

現在的「Amazon EBS pricing」頁面已經更新了,想要比較的話可以從 archive.is 上面的「Amazon EBS pricing」對比。價錢的部份從十一月九號自動生效:

Amazon EBS customers automatically benefit from this new lower price, which is effective starting November 9th, 2020.

IFTTT 與 n8n

看到「Goodbye IFTTT」這篇在講 IFTTT 收費後的替代方案。

我自己還是繼續用 IFTTT,主要是 Line 的 bot 申請起來太麻煩了,就花錢丟著,其他的大多都有方案可以處理。

但不管怎麼樣,open source 的方案還是可以玩看看... 文章裡其中一個提到的是 n8n,用 Node.js 寫的,裝起來也蠻簡單的 (我是用 nvm + npm 裝起來),而目前支援的項目在「Integrations (Nodes)」這邊可以看到。

跑起來後連上去,這界面看起來更像當年 Yahoo! 家的 Yahoo! Pipes,而不是 IFTTT... 有點唏噓的感覺。

晚點再多花點時間玩玩 n8n...

另外一個是用 Rails 寫的 Huginn,純粹個人偏好,應該暫時不會碰...