Google Web Store 裡的黑暗交易

標題只寫了 Google Web Store,主要是因為瀏覽器市占率的問題,其實是包含 Firefox 的 Add-Ons。

這是在 Hacker News 首頁上看到的:「Many temptations of an open-source chrome extension developer」,講一直會有人來接觸,可以付費給開發者,想要在這些專案裡面放一些「東西」,可能是蒐集資料,可能是強制導到特定的 search engine,也有可能更邪惡...

另外是老規矩,在 Hacker News 上的討論也可以翻一翻,還蠻有趣的:「Many temptations of an open-source Chrome extension developer (github.com/extesy)」。

先大概看一下 Hover Zoom+ 這個套件在 Google Web Store 的安裝數量,大約 30 萬人:「Hover Zoom+」,作者公佈的信件內容裡面有一些包括價錢與目的...

話說回來,Brave 上的 CRX Viewer 還是沒修好啊:「Stopped working with Brave」,要裝新的套件都得另外再拉 crx 檔下來看,麻煩不少...

Windows 上現成的 KataGo + Lizzie 安裝程式

本來花了一些功夫整理了一下 KataGo + Lizzie 純 CPU 版本在 Windows 上的安裝方式 (在「KataGo/Windows」這邊),後來找了一下發現早就有人做的更簡單了:「BadukMegapack」。

底層的部份除了可以選擇裝 KataGo 外,也可以選擇目前已經停止維護的 Leela Zero,或是 SAIAQRay

而界面的部份除了可以用 Lizzie 外 (而且還是改過的加強版 XD),還可以選其他的界面... 除此之外還連 JVM (Java 8) 都一起拉進來幫你裝。

看起來算是包的好好的... 看起來最困難的應該是弄一張高階顯卡了?

原來 Sentry 有支援 Bash...

Sentry 可以拿來蒐集自己開發軟體的錯誤事件,剛剛突發奇想用搜尋引擎找了一下,發現 Sentry 是有支援 Bash 的:「Sending Sentry Events from Bash」。

文章裡面也直接提到了 hook 的用法,在裝了 sentry-cli 後可以掛進來:

#!/bin/bash
export SENTRY_DSN=
eval "$(sentry-cli bash-hook)"

自己架 Sentry 的步驟我有丟在「Sentry」這邊,或者也可以用雲端的版本。

丟給同事參考看看...

Amazon ECS Anywhere

在去年年底 AWS 的公佈的「re:Invent 2020 – Preannouncements for Tuesday, December 1」裡面提到兩個有趣的產品,一個是 Amazon ECS Anywhere,另外一個是 Amazon EKS Anywhere,現在 Amazon ECS Anywhere 開放了:「Getting Started with Amazon ECS Anywhere – Now Generally Available」。

這兩個服務都是把自家的機器 container 化然後讓 AWS 的服務直接管理,只是一個是 ECS (AWS 自家的規格),另外一個是 EKS (基於 Kubernetes),這次丟出來當然很重要,不過還是會等 EKS Anywhere 出來後一起比較看看。

價錢的部份就是照機器數量算,一台機器大約 USD$7.38/month,以 bare metal 等級的機器來說倒是沒什麼問題:

You pay $0.01025 per hour for each managed ECS Anywhere on-premises instance. An on-premises instance is a customer-managed instance that has been registered with an Amazon ECS cluster and runs the Amazon ECS container agent.

這樣讓地端的機器更容易上雲,不過離台灣本地沒有 region 在網路的 latency 上就有點討厭了,另外一種搞法是找 dedicated hosting 或是自己塞機器進 colocation hosting,然後掛上這類服務?

QUIC 成為標準,從 RFC 8999 到 RFC 9002

前幾天的新聞了,這兩天 FastlyCloudflare 也都發文章出來了,QUIC 成為標準:「QUIC is now RFC 9000」、「QUIC Version 1 is live on Cloudflare」。

主要是這兩家都發稿宣傳他們的平台都支援 QUIC 了,接下來可以等一些測試報告,看看在 web 這種已經有不少複雜的 workaround 機制下,TCP BBR 環境的 HTTP/2 跟 QUIC 環境會有多少差異... 記得 QUIC 也是 BBR-based 的演算法。

在 QUIC 下的 https 協定會走 443/udp,如果防火牆是預設阻擋所有連線,然後逐條開放的話,需要另外開這組設定。

另外就是等 nginx 支援了,在「NGINX QUIC Preview」這邊有些資料,然後「">nginx-quic: log」裡面可以看到東西,裡面不少 commit 只是跟 nginx 本家同步而已,不過還是可以看到一些跟 QUIC 有關的...

USB Type-C 要增加 240W 的規格...

在「USB Type-C Specification 2.1 allows up to 240W Extended Power Range (EPR)」這邊看到這個規格:

Extended Power Range cables have additional requirements to assure that these cables can deliver the full defined voltage and current range for USB PD EPR operation. EPR cables shall functionally support a reported 50 V and 5 A o peration. The minimum functional voltage that a cable shall support is 53.65 V. The electrical components potentially in the path of V BUS in an EPR cable, e.g. bypass capacitors, should be minimally rated for 63 V.

All EPR cables shall be Electronically Marked and include EPR-specific information in the eMarker as defined by the USB PD specification. As defined in the USB PD specification, EPR cables are marked as 50 V and 5 A capable. All EPR cables shall be visibly identified with EPR cable identification icons as defined by the USB-IF. This is required so that end users will be able to confirm visually that the cable supports up to as high of PDP = 240W as defined in the USB PD specification.

也是基於 E-Marker 晶片的關係,除了充電頭支援外,線本身也得支援。這解決了目前很多家桌機都自己搞 >100W 的 dock 來支援高瓦數的充電,推出一個標準來涵蓋收斂...

會不會搞到以後連桌機都可以用 USB-C 界面供電啊...

Freenode 的事情愈演愈烈了,而且看起來一發不可收拾中...

前幾天提到「Freenode 志工團隊決定離開,成立 Libera.Chat」,本來還在猜從 Freenode 搬移的速度可能就一批一批搬,結果這幾天 Andrew Lee 決定做出是一些提油滅火的行為,整個搬移的速度瞬間加快不少...

首先是只要在頻道上提到要轉移到 Libera Chat,頻道就會馬上被 Freenode 封鎖並且由官方「接管」,於是 Gentoo 的頻道就被幹掉了:「Gentoo Freenode channels have been hijacked」。

另外 Andrew Lee 直接在 Freenode 的 blog 上面嗆目前他們還是最大的 IRC network,並且繼續支持 FOSS 社群:「freenode exists for FOSS」,基本上試看不太出來啦...

目前 Libera Chat 已經跑一個禮拜了:「One week of Libera Chat」,陸陸續續看到很多社群都已經轉過去了,看起來應該會是不可擋的趨勢了...

居然在安全性漏洞的 PoC 上面看到拿 Bad Apple!! 當作範例

人在日本的資安專家 Hector Martin 找到了 Apple M1 的安全漏洞,可以不用透過 macOS Big Sur 提供的界面,直接透過 M1 的漏洞跨使用者權限傳輸資料,這可以用在突破 sandbox 的限制。而也如同目前的流行,他取了一個好記的名字:「M1RACLES: M1ssing Register Access Controls Leak EL0 State」,對應的 CVECVE-2021-30747

先講比較特別的點,PoC 的影片放在 YouTube 上,作者拿 Bad Apple!! 當作示範,這很明顯是個雙關的點:

這應該是當年的影繪版本,看了好懷念啊... 當年看到的時候有種「浪費才能」的感覺,但不得不說是個經典。

Hacker News 上有討論可以翻翻:「M1racles: An Apple M1 covert channel vulnerability (m1racles.com)」。

依照作者的說明,Apple A14 因為架構類似,也有類似的問題,不過作者沒有 iPhone,沒辦法實際測試:

Are other Apple CPUs affected?

Maybe, but I don't have an iPhone or a DTK to test it. Feel free to report back if you try it. The A14 has been confirmed as also affected, which is expected, as it is a close relative of the M1.

另外作者覺得這個安全漏洞在 macOS 上還好,主要是你系統都已經被打穿可以操控 s3_5_c15_c10_1 register 了,應該會有更好的方式可以用:

So you're telling me I shouldn't worry?

Yes.

What, really?

Really, nobody's going to actually find a nefarious use for this flaw in practical circumstances. Besides, there are already a million side channels you can use for cooperative cross-process communication (e.g. cache stuff), on every system. Covert channels can't leak data from uncooperative apps or systems.

Actually, that one's worth repeating: Covert channels are completely useless unless your system is already compromised.

比較明顯的問題應該是 iOS 這邊的 privacy issue,不過 iOS 上的 app store 有基本的保護機制:(不過想到作者可以故意寫成 RCE 漏洞...)

What about iOS?

iOS is affected, like all other OSes. There are unique privacy implications to this vulnerability on iOS, as it could be used to bypass some of its stricter privacy protections. For example, keyboard apps are not allowed to access the internet, for privacy reasons. A malicious keyboard app could use this vulnerability to send text that the user types to another malicious app, which could then send it to the internet.

However, since iOS apps distributed through the App Store are not allowed to build code at runtime (JIT), Apple can automatically scan them at submission time and reliably detect any attempts to exploit this vulnerability using static analysis (which they already use). We do not have further information on whether Apple is planning to deploy these checks (or whether they have already done so), but they are aware of the potential issue and it would be reasonable to expect they will. It is even possible that the existing automated analysis already rejects any attempts to use system registers directly.

Freenode 志工團隊決定離開,成立 Libera.Chat

最近 IRC community 吵很兇的一個主題,Freenode 的志工團隊因為 Freenode 後面的公司易主,而且接手後的行為讓志工團隊很不爽,走了二三十個人,決定成立自己的 IRC network Libera.Chat:「freenode now belongs to Andrew Lee, and I'm leaving for a new network.」,其中這邊提到的 Andrew Lee,是 VPN 廠商 Private Internet Access 的老闆。

事情的一些脈絡可以在維基百科「Libera Chat」條目裡看到,另外在維基百科上的「Internet Relay Chat」條目裡面可以看到 Freenode 應該是目前最大的 IRC network,雖然相比全盛時期已經少很多人了。

這次有不少 open source community 的成員響應搬家,搬出來不知道會讓 Freenode 受多少傷,也有可能下面其他的使用者根本不在乎之類的...