Firefox 的 UI 修正方案

在「Firefox Proton UI userChrome.css fixes. (2021) (github.com/black7375)」這邊看到的,GitHub 上的專案頁面在「Lepton (old name: Proton Fix)」這邊。

作者先前有寫過,我在「Firefox 的 UI/UX 歷史」這篇,同一個 repository 裡面就包含了「修正方案」,補上了一些 icon,並且改了 css 效果。

不過我已經沒什麼在用 Firefox 了,而且目前看起來也不會回去了,看起來只有在交叉找問題的時候會用到...

PuTTY 使用 ecdsa-sha2-nistp521 的漏洞

看到「PuTTY vulnerability vuln-p521-bias (greenend.org.uk)」這個消息,官網的說明在「PuTTY vulnerability vuln-p521-bias」這邊。

DSA 類的簽名演算法有個得很小心的地方,是 nonce 選擇不當會造成 key recovery,這在原文有提到:

All DSA signature schemes require a random value to be invented during signing, known as the 'nonce' (cryptography jargon for a value used only once), or sometimes by the letter k. It's well known that if an attacker can guess the value of k you used, or find any two signatures you generated with the same k, then they can immediately recover your private key.

維基百科的業面上也有提到這點:

With DSA, the entropy, secrecy, and uniqueness of the random signature value {\displaystyle k} are critical. It is so critical that violating any one of those three requirements can reveal the entire private key to an attacker. Using the same value twice (even while keeping {\displaystyle k} secret), using a predictable value, or leaking even a few bits of {\displaystyle k} in each of several signatures, is enough to reveal the private key {\displaystyle x}.

這次爆炸的起因是 PuTTY 用了 SHA-512 產生 nonce,這邊只會有 512 bits 的輸出,而這對 P-521 需要 521 bits 是不夠的 (於是前 9 個 bit 會是 0):

PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.

In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.

而更糟的是,這不僅僅是將降了 29 的安全性,而是因為 nonce 有 bias,這在 DSA 上已經足以從 60 次的簽出的 signature 中還原出 private key (也就是文章裡提到的 key recovery attack):

This bias is sufficient to allow a key recovery attack. It's less immediate than if an attacker knows all of k, but it turns out that if k has a biased distribution in this way, it's possible to aggregate information from multiple signatures and recover the private key eventually. Apparently the number of signatures required is around 60.

新版會改用 RFC 6979 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)) 實作:

To fix this vulnerability, we've completely abandoned PuTTY's old system for generating k, and switched to the RFC 6979 technique, for all DSA and ECDSA key types. (EdDSA keys such as Ed25519 already used a different system, which has not changed.) However, this doesn't affect the fact that information about existing P521 private keys has already been leaked whenever a signature was generated using the old k generator.

所以這次的 fix 得更新 PuTTY 版本,然後重新產生 private key (會假設已經 leak 了),然後看看系統有什麼要處理的...

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章,原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議,像是第一個建議是把 UUID 裡面的 - 拿掉,這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID,不會是念出來?)。

第二個建議是加上 prefix,這點不一定侷限在 UUID,只要是 token 上面都很適合。這個在不少系統上應該都有看過,像是 GitHub 的 token,或是 AWS 的 token 都算是這類。

文章裡面沒有提到,但這個建議也可以幫助你在 CI 上設定 regex,擋下把 secret token 寫進去的行為。

第三個提到用 base58,一方面是減少長度,另外一方面是想要避免 1IiLl0Oo 的問題,這點我覺得還好... 既然都是 copy & paste 了,我覺得拿 base62 (i.e. 大小寫加上數字) 不錯,這避免特殊字元無法選擇到,也就是文章裡面第一個建議。

第四個建議是建議重新思考 range,因為 UUID 的 128-bit range 很大,但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID,在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西,我就... 跳過了。

Windows 98 安裝的三階段

看到「Why does part of the Windows 98 Setup program look older than the rest? (2020) (retrocomputing.stackexchange.com)」這個,原文是 2020 的討論:「Why does part of the Windows 98 Setup program look older than the rest?」。

問題是 Windows 98 的安裝過程中段可以看出來有 Windows 3.1 介面的感覺,像這樣:

而到了後段又是 Windows 98 的感覺,作者覺得 UI 介面風格不一致的問題...

回答的人則是解釋得很清楚,第一階段是 DOS 階段,會把 Windows 3.1 環境疊出來:

The first, which can run from the setup floppies and/or CD-ROM, uses a DOS program (DOSSETUP.BIN) to set up disk partitions, run various checks etc.:

This phases finishes by copying a minimal version of Windows 3.1 to the target installation drive, in a temporary directory (normally WININST0.400), containing DOSX.EXE, USER.EXE, GDI.EXE, KRNL386.EXE, LZEXPAND.DLL etc. (see MINI.CAB).

第二階段則是 Windows 3.1 環境,把 Windows 98 大多數的東西都複製到硬碟上:

The second uses this minimal Windows 3.1 to run a Windows 3 program, W98SETUP.BIN (specified as the “shell” in SYSTEM.INI):

This starts by copying more files to support all the information-gathering during setup, and various other niceties including the 3D look shown in your screenshot (the contents of the PRECOPY CABs); it ends by copying most of Windows 98, setting the system up so that it will boot Windows 98 from the target drive, and rebooting.

第三階段則是 Windows 98 環境,執行後續的設定程式:

The third runs after the first boot into Windows 98, from Windows 98:

而且也提到了當年可以升級作業系統的情況 (雖然我自己偏好重裝):

It is also possible to initiate the setup process from any of the above environments, which is how Windows 98 handles upgrades (from MS-DOS, or Windows 3, or Windows 95).

是個解釋遺跡的現場 XDDD

把 terminal 軟體從 xfce4-terminal 換成 wezterm

我自從換到 Xubuntu 後一直都是用 xfce4-terminal,直到三月中的時候換成 wezterm 了,記得當時是在 Fediverse 上看到 gugod 說他用這套,測了一下覺得比 xfce4-terminal 好用,可以微調不少 xfce4-terminal 做不到的東西,就換過去了。

前陣子看到「Just How Much Faster Are the GNOME 46 Terminals?」這篇 (via),在 Hacker News 的討論裡面有提到另外一篇文章有測試 terminal latency 的問題:「Terminal Latency」,看了一下 wezterm 的速度不算快,不過 terminal 的速度目前不是我的痛點,所以還好:

(話說 xterm 居然是最快的...)

翻了一下之前在 2021 的時候有提到過 wezterm,不過當時是在講 vttest:「用 vttest 測試 terminal 程式實做的相容性」。

wezterm 是透過一個 Lua 檔案 (~/.wezterm.lua) 在管理設定的,而且預設支援 hot reload,所以不用太擔心會需要一直調整後重啟。

我的設定檔在 config repository 裡面有,不過我是建議自己花些時間調整,如果你是 terminal-heavy user 的話...

Fabrice Bellard 的新作品 TSAC codec

昨天在 Hacker News 上看到「TSAC: Low Bitrate Audio Compression (bellard.org)」這則 Fabrice Bellard 的新作品:「TSAC: Very Low Bitrate Audio Compression」。

Fabrice Bellard 這兩年玩很多 ML 相關的東西,像是 2021 的「LibNC: C Library for Tensor Manipulation」,以及 2023 的「ts_zip: Text Compression using Large Language Models」,這次則是用上了 transformer

tsac is based on a modified version of the Descript Audio Codec extended for stereo and a Transformer model to further increase the compression ratio. Both models are quantized to 8 bits per parameter.

翻了一下 Descript Audio Codec,已經算是很厲害的了,在 44.1KHz mono 的情況下可以做到 8kbps (~1KB/sec):

With Descript Audio Codec, you can compress 44.1 KHz audio into discrete codes at a low 8 kbps bitrate.

TSAC 則是將 mono 的版本做到 5.5kbps,另外 7.5kbps 就能傳雙聲道,也還是低於原來的 8kbps:

TSAC is an audio compression utility reaching very low bitrates such as 5.5 kb/s for mono or 7.5 kb/s for stereo at 44.1 kHz with a good perceptual quality. Hence TSAC compresses a 3.5 minute stereo song to a file of 192 KiB.

聽了一下算蠻厲害的,直接拿音樂來壓還是有不錯的效果?

從技術上的情境可以知道兩端都需要有足夠的算力 (得跑 ML algorithm),然後在頻寬很不足的情況下通訊?商用的情境好像偏少一點,現在連沙漠與深山中都有衛星可以用,也許還是有些情境下用的到,像是 LoRa 的速度就差不多在這個區間。

倒是軍事上面需要考慮不少極端情況,用的機會可能比較高?

Automattic 買下 Beeper

沒想到後續消息居然會是這個,在 Hacker News 上看到 Automattic 買下 Beeper 的消息:「Beeper acquired by Automattic (WordPress) (beeper.com)」,原文在「Beeper is joining Automattic」這邊。

先前因為弄出與 iMessage 相通的工具而知名,當時還追過這個新聞:

看起來之前就有投資的關係了:

Matt, Automattic’s CEO, and I have known each other for years. He was an early user, supporter and investor in Beeper.

不確定買下來能做什麼,新聞稿上講得是很冠冕堂皇... 但對 Beeper 的創辦人這邊大概就是順利脫手?當時 Apple 的態度讓 iMessage 相容性這條路走到 dead end;對 Automattic 這邊大概就是希望這群人做 IM project?

不過當時已經買了 Texts.com (參考當時的新聞「WordPress.com owner buys all-in-one messaging app Texts.com for $50M」),原來這組人是有什麼狀況嗎...?

來分析這次地震的電力系統變化

Facebook 上看到 Wei-Chun HwangArduino.Taipei 上貼的文章:「幾周前剛好這裡有在討論自製地震儀,來給各位看一下資料剛剛發生的地震跟市電電壓還有週期的波形」,裡面剛好有很寶貴的資料,記錄下地震當下台北與彰化的電力資料。

最重要的是這兩張圖:(直接對圖片開新頁可以看到 full size)

這兩張圖記錄下電壓與頻率的變化,可以看到台北與彰化的頻率幾乎是一樣的,畢竟台灣本島大多數的區域是在同一個電網系統裡面。

從氣象署的「第019號 4月3日7時58分 規模 7.2 花蓮縣政府南南東方 25.0 公里 (位於臺灣東部海域)」可以查到地震發生在 07:58:09;另外從第一張圖可以看到電網的頻率有幾個不同的變化:

  • 第一波是 07:58:38 左右開始狂掉,然後到 07:58:48 差不多穩下來。
  • 接著的幾秒 (尤其是 07:58:56 這邊) 可以看到一些波動。
  • 然後是 07:59:00 開始掉,到 07:59:06 到低點 (應該是又有機組解聯?)。
  • 然後是 07:59:13 又一波下探,大約是 07:59:16 第一次觸發到 59.5Hz 的計時點。
  • 但沒過幾秒鐘 07:59:20 可以看到一波回拉。

維基百科有提到「P波」的速度,差不多解釋了第一張圖的一些狀況:

地震中P波速度典型值的範圍是5至8 km/s。精確速度以地球內部區域的不同而變化,範圍從地殼的不到6 km/s至地核的13 km/s。

解聯的機組從「為什麼這次地震沒跳電?綠能、電網發揮關鍵作用!」這邊可以查到,包括了台中電廠 (台中)、通宵通霄電廠 (苗栗)、國光電廠 (桃園)、和平電廠 (花蓮)、海湖電廠 (桃園):

根據台電說明,這次地震造成多座電廠機組跳脫、變電所停電,總共影響 320 萬瓩,受影響的包括台電台中電廠 8 號機、10 號機,通霄電廠 5 號機蒸汽輪機 ST 跳脫,民營電廠也有國光電廠 1 號機、和平電廠 2 號機、海湖電廠 2 部氣渦輪機 GT 跳脫。

計算一下桃園與震央的距離大約 130km (用 Google Maps 粗抓),苗栗大約 110km,台中大約 100km;看起來差不多就是 P 波到的時候就自動觸發降載 & 解聯?

接著應該是第二張圖的範圍了,可以看到 08:00 以後有兩波觸 59.5Hz 的情況,這應該就是在「台電4年電網投資3000億 地震當下維持供電韌性關鍵」這篇報導裡面提到:

台電表示,地震發生瞬間,機組一度跳脫達320萬瓩,也就是6部中型機組的量,電力系統頻率瞬間降至59.46Hz,當下將抽蓄機組解聯3台,減少用電;但同時間電池儲能系統瞬間放電提供約51萬瓩,讓系統頻率回升至59.5Hz,避免用戶因低頻卸載導致限電。

目前查不到 4/3 當天的情況,但從這幾個月的歷史資料可以知道台電電網大約在 30000MW 這個量級左右,掉了 3200MW 差不多是 10% 的量。

馬上可以做的是:電池供應 510MW 補了 1.7% 左右;抽蓄機組是 250MW (不確定當時是多少的負載在跑,假設在 50% 運作,約 125MW),三台解聯大約再空出 375MW,差不多是整體的 1.25%。

這兩個馬上切換可以空出大約 3% 的空間出來。

另外一個關鍵的時間點的資料可以從「日月潭抽蓄水力電廠 全台最大天然儲能電池」這邊讀到:

根據台電指出,這種抽蓄水力發電,特性是起動迅速,只要大約7到8分鐘就可啟動出力,每分鐘單一機組可調整出力約10萬瓩。

以最佳的情況來算 (從第一波地震就馬上開始自動切換,加上最短的七分鐘) 會是 08:05:09 左右才開始加入,會發現這無法解釋第二張圖兩個回拉的行為。

這邊不像是綠能突然加入 (因為太陽不會突然變超亮,同理風力也不會突然刮超大風),比較合理的解釋反而可以從 Ptt 上面看到的文章來解讀:「[問卦] 震到停電回報+1」。

台電雖然沒有承認這件事情,但從時間軸上面來看,08:00:00 到 08:05:00 這邊應該是想辦法減輕負載撐過去,然後其他電廠拉高輸出,加上抽蓄併網進來後再恢復原來負載比較合理,不過這件事情政治不正確,大概就不會有太多討論...

不過目前大方向是好的,現代的新科技 (以及對應的新方法) 建立了更多的緩衝...

Google 推出 Jpegli:JPEG 的 encoder 以及 decoder

Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」,原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小:

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較,大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了,應該是跟 cjpeg 比,如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯,這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品:

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名,比較熟的是 Zopfli 以及 Brotli

IEEE 也宣佈禁用 Lenna 圖了

Lenna (Lena) 是個經典的標準測試圖片,一方面是因為有很多細節可以觀察 image-related algorithm 的情況,另外一方面也是因為這張圖是取自 1972 年的 Playboy 雜誌:

Lenna (or Lena) is a standard test image used in the field of digital image processing starting in 1973, but it is no longer considered appropriate by some authors.

To explain why the image became a standard in the field, David C. Munson, editor-in-chief of IEEE Transactions on Image Processing, stated that it was a good test image because of its detail, flat regions, shading, and texture. He also noted that "the Lena image is a picture of an attractive woman. It is not surprising that the (mostly male) image processing research community gravitated toward an image that they found attractive."

也因為後者的原因,後來也有愈來愈多其他的圖片可以達到類似的效果 (甚至更好),就有替代的聲音出現了。

另外一方面,Lena 本人在 2019 年也提到希望淡出的想法:「How a Nude “Playboy” Photo Became a Fixture in the Tech World」。

But I retired from modeling a long time ago. It’s time I retired from tech, too.

而最新的消息就是 2024/04/01 開始,IEEE 不再接受使用 Lenna 圖的投稿:「Institute bans use of Playboy test image in engineering journals」。

之後大概只會在歷史回顧的時候會引用提到了...