Amazon Translate 可以自動偵測語言了

Amazon Translate 可以將聲音轉成文字,先前都需要自己指定語言,而這幾天發表新的功能,可以自動偵測語言:「Amazon Transcribe Now Supports Automatic Language Identification」。

不過系統要求最少要有 30 秒的資料,跟人類比起來還是有點差距,但比起之前好用不少:

With a minimum of 30 seconds of audio, Amazon Transcribe can efficiently generate transcripts in the spoken language without wasting time and resources on manual tagging.

沒有額外的費用,主要就是照著本來的價錢在走:

There is no additional charge on top of the existing pricing.

翻了一下價錢,好像可以來測一些東西...

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.

算是補產品線...

AWS 推出了 ARM 平台上 T 系列的機器

前幾天發現在 AWS Web Console 上開 EC2 機器時,選 t3a 後本來可以選的「T2/T3 Unlimited」變成只叫「Unlimited」,心裡猜測有東西要推出,然後這幾天看到消息了...

這次 AWS 推出了 t4g 系列的機器,而這邊的 g 如同慣例,指的是 ARM 的 Graviton2:「New EC2 T4g Instances – Burstable Performance Powered by AWS Graviton2 – Try Them for Free」。

目前公司在用的 ap-southeast-1 沒有在支援的地區,只好去 us-east-1 上玩:

T4g instances are available today in US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Tokyo, Mumbai), Europe (Frankfurt, Ireland).

剛好這兩天把 SOP 文件的安裝方法改成 ansible playbook,就順便拿 t4g 的機器測了一下也沒什麼問題。

另外 T 系列機器最重要的 CPU credit 的部份,在官方文件「CPU credits and baseline utilization for burstable performance instances」這邊也已經可以看到 t4g 的相關資料了,基本上跟 t3t3a 是一樣的設計。

而價錢的部份,都以 T 系列裡最大的 2xlarge 來算,Intel 平台的 t3.2xlarge 是 $0.3328/hr,AMD 平台的 t3a.2xlarge 則是 $0.3008/hr,而 t4g.2xlarge 是 $0.2688/hr,大約是 80.7% 與 89.3% 的比率。

另外官方宣稱效能還比 x86 平台上好很多,這點可以打個折看,不過就價位來說是真的不錯:

Using T4g instances you can enjoy a performance benefit of up to 40% at a 20% lower cost in comparison to T3 instances, providing the best price/performance for a broader spectrum of workloads.

不過目前公司的主力還是在新加坡區,而且還有 RI 在跑,等有了 t4g 之後再把一些東西丟上去測看看,然後找時間換過去...

在 Mac 上用鍵盤操作的 Vimac

前幾天在 Hacker News 上看到 Vimac 這個專案,程式碼在 GitHubdexterleng/vimac 上可以看到,而 Hacker News 上的討論則是在「Show HN: Vimac – Productive macOS keyboard-driven navigation (vimacapp.com)」這邊,因為是作者發表的,所以下面也有一些作者的回應。

作者是受到瀏覽器上 Vimium 啟發,利用 macOS 的 Accessibiltiy API 實做類似的想法,讓使用者可以使用鍵盤操作 (所以會需要授權開啟 Accessibility API)。

官方預設啟動 Hint Mode 的快速鍵是 Ctrl-Space,但這對中文使用者來說剛好卡到,所以我把他改成 Option-Space 了,按下去後畫面上會將可以點選的地方都加上快速鍵資訊,像是官方提供的樣式:

另外一個重點是捲動的功能,不過我目前還用的不多,不知道好不好用...

新的 TLS 攻擊:Raccoon Attack

這次看到的是針對 TLS 實做上的問題產生的 Raccoon Attack,反正先取個名字就對了,原圖有點大張,設個 medium size 好了 XDDD:

Why is the attack called "Raccoon"?
Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)

先講影響的產品,首先是經常中槍的 F5,這次連 timing measurement 都不需要太準確就可以打穿:

In particular, several F5 products allow executing a special version of the attack, without the need for precise timing measurements.

OpenSSL 的部份因為從 1.0.2f 之後因為其他的 security issue 所以改善了實做方式,就不會受到這次的攻擊手法影響。

剛剛翻了一下 Ubuntu 上的的資料,看起來 16.04 (xenial) 上的 OpenSSL 就已經是 1.0.2g 了,所以目前只要是有在 Ubuntu 支援的版本應該都不受影響:

OpenSSL assigned the issue CVE-2020-1968. OpenSSL does use fresh DH keys per default since version 1.0.2f (which made SSL_OP_SINGLE_DH_USE default as a response to CVE-2016-0701).

Firefox 直接拔了 DH 與 DHE 相關的 cipher suite,反正在這次攻擊手法出來前本來就已經計畫要拔掉:

Mozilla assigned the issue CVE-2020-12413. It has been solved by disabling DH and DHE cipher suites in Firefox (which was already planned before the Raccoon disclosure).

微軟的部份則是推更新出來:

Microsoft assigned the issue CVE-2020-1596. Please refer to the Microsoft Security Response Center portal.

回到攻擊手法,這次的問題是因為 DH 相關的實做造成的問題。

TLS 要求去掉 premaster secret 裡開頭的 0,造成會因為開頭的 0 數量不同而實做上就不會是 constant time,所以有了一些 side channel information 可以用:

Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server.

然後一層一層堆,能夠知道 premaster secret 開頭是不是 0 之後,接下來因為 server side 會重複使用同一組 premaster secret,所以可以當作一個 oracle,試著去計算出更後面的位數:

This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not.

Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri*ga, which lead to premaster secrets gri*b*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server.

所以針對這個攻擊手法的解法就是用「新鮮的」premaster secret (像是完全不重複使用),然後保留開頭的 0,不需要去掉。而 TLS 1.3 在定義的時候把這兩件事情都做了,所以不會受到影響:

Is TLS 1.3 also affected?
No. In TLS 1.3, the leading zero bytes are preserved for DHE cipher suites (as well as for ECDHE ones) and keys should not be reused.

另外在這邊提到的 Hidden Number Problem (HNP) 也是個不熟悉的詞彙,網站上有提到論文,也就是「Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes」這篇:

Given an oracle Oα(x) that on input x computes the k most significant bits of (α * gx mod p) , find α mod p.

是個離散對數類的問題,之後有空再來翻一翻好了。

自幹 VR 眼鏡

Hacker News Daily 上看到「Relativty‍ an open-source VR headset」這個自幹 VR 眼鏡的專案,專案可以在 GitHub 的「relativty/Relativty」這邊看到。

看起來是使用 3D 印表機生出配件,然後用 ArduinoCore-sam 開發軟硬體的部份,目前的系統可以在 2K 解析度下跑 120fps:

The Relativty firmware, which powers the actual physical device, is based on ArduinoCore-sam. So in addition to the Relativty Motherboard, it is compatible with Arduino Due or any other board equipped with a processor that supports the ArduinoCore.

Relativty headset runs a 2K dual-display at 120FPS. However, because of the open nature of Relativty you can use any display as long as your computer is able to handle it. From more affordable 90Hz 1080p screen to 4K panels.

不過不知道反應延遲有多高,偏高的話會有 3D 暈的問題,在網站裡面沒提到,我猜應該會是痛點... 另外看起來是想要商業化,頁面下面有 hiring 的資訊,先觀望看看好了?

libtorrent 宣佈支援 BitTorrent v2

看到 libtorrent 宣佈支援 BitTorrent v2 (BEP 52) 的消息:「BitTorrent v2」。

BitTorrent v2 這個規格丟出來好久了,但一直都是 draft,而且沒什麼人想要理他,直到 Google 成功產生出 SHA-1 collision 的時候稍微有些音量跑出來,但沒想到居然有人跳下去支援了...

對使用者比較有感覺的差異是從 SHA-1 換成 SHA-2 的 SHA-256 了,這個會影響到整個 torrent file 的結構與 Magnet URI 的部份。

另外一個比較大的改變是 torrent 檔資料結構,有兩個比較大的改變。

第一個是以前用固定的 block size 切割,然後每個 block 產生出 hash,所以 torrent 檔會隨著 block size 選擇的大小 (成反比) 檔案大小 (成正比) 有關,現在會用 Merkle tree,所以只要有 root hash 就可以了。

第二個是以前是把所有檔案包在一起 hash,現在是個別檔案都有自己的 hash (改成 root hash),所以現在變成可以跨 torrent 檔共用檔案。

然後 libtorrent 的文章裡有提到向前相容的方法,不過以產品面上來說沒有什麼太大的誘因,libtorrent 雖然大,但其他幾家的支援度應該也是重點...

Travis CI 支援 Arm64 平台的編譯與測試了

剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了:「Announcing General Availability of Graviton2 CPU Support!」。

架構上是利用 AWS 推出的機器來做,其中支援的 OS image 目前看起來是以 Ubuntu 為主,其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境,而 20.04 (focal) 則除了 LXD container 環境外,也有完整的 VM 環境可以跑:

Following Arm64 distributions of Ubuntu are available for you as LXD containers:

Xenial (16.04)
Bionic (18.04)
Focal (20.04)

Following Arm64 distribution of Ubuntu is available for you as a full VM option:

Focal (20.04)

看起來底層是用 Ubuntu 20.04 為主力,然後提供 container 跑其他版本。

5 Eyes、9 Eyes 與 14 Eyes

{5,9,14} Eyes 是先前在其他地方看到的詞,後來在「Cutting Google out of your life」這邊在講 Google 的替代方案時又有提到,然後也有解釋:「Global Mass Surveillance - The Fourteen Eyes」。

這邊提到的 Eyes 起因是大多數國家對於監視自己公民都有法律限制,所以藉由與國外的情報單位「合作」,取得對自己國家公民的監視資訊 (即使各國之間有簽訂不監視其他國家公民),而這邊列出的 {5,9,14} Eyes 就是互相有簽訂合作的國家:

The UKUSA Agreement is an agreement between the United Kingdom, United States, Australia, Canada, and New Zealand to cooperatively collect, analyze, and share intelligence. Members of this group, known as the Five Eyes, focus on gathering and analyzing intelligence from different parts of the world. While Five Eyes countries have agreed to not spy on each other as adversaries, leaks by Snowden have revealed that some Five Eyes members monitor each other's citizens and share intelligence to avoid breaking domestic laws that prohibit them from spying on their own citizens. The Five Eyes alliance also cooperates with groups of third-party countries to share intelligence (forming the Nine Eyes and Fourteen Eyes); however, Five Eyes and third-party countries can and do spy on each other.

另外還有「Key Disclosure Law」這段,在講有哪些國家有法律可以強制個人交出金鑰。

回到本來提到的 degoogle 列表,裡面列出了很多替代的服務與軟體,其中服務的部份會列出所在地區是否在 {5,9,14} Eyes 的範圍內,以及發生過的爭議事件。

當作替代方案在看,至少可以把一些足跡從 Google 抽出來...

用 picture + source + img 替代本來的 JavaScript 替換

目前我在 blog 上使用 Imgur 的圖檔主要是用 WebP 格式,然後針對不支援 WebP 的瀏覽器 (主要就是蘋果家的 Safari) 是用 JavaScript 換回 JPEG 格式...

昨天早上看到「AVIF has landed」這篇,提醒我有 <picture> 這個原生支援的方式可以用,翻了一下 Can I Use 上面的支援程度,看起來除了 IE11 以外幾乎都支援了 (參考「Picture element」),而且 IE11 應該也會因為語法的關係走到正確的 JPEG fallback,大概是這樣:

<picture>
    <source type="image/webp" srcset="https://i.imgur.com/xxxxxx.webp" />
    <img src="https://i.imgur.com/xxxxxx.jpg" alt="" />
</picture>

換完後來觀察看看...