Raspberry Pi 上面直接對 Framebuffer 與觸控介面操作

清 tab,看到這個 2019 年的文章:「Writing GUI applications on the Raspberry Pi without a desktop environment (2019) (avikdas.com)」,原文在 Raspberry Pi 上面希望操作觸控螢幕,但不想要把整包 X.Org 都裝起來,所以直接操作了 Framebuffer,並且自己處理了觸控介面的事件:「Writing GUI applications on the Raspberry Pi without a desktop environment」。

這看起來是作者的成品:

當年作者用 Raylib 實作,不過 2024 年的 Hacker News 倒是提到了不少 library 可以用,之後如果有遇到需求可以當作切入點去研究...

RFC 9512:application/yaml

看到「RFC 9512: YAML Media Type」這個,原來還沒有註冊 application/yaml 啊...

另外在 media type 的文件裡面,意外的給出了安全性的建議:

Code execution in deserializers should be disabled by default and only be enabled explicitly. In the latter case, the implementation should ensure (for example, via specific functions) that the code execution results in strictly bounded time/memory limits.

這邊用的是 should 不是 SHOULD,所以當一般的英文句子在讀,而非具有規範性的敘述。

但還是給了預設關閉 code execution 的建議...

LSAs 與 application password 不同...

前天在「使用 application password 的 Google 服務將在 2024/09/30 停止支援」這邊寫完後,yan12125 在文章留言的地方提到:

看起來這次只有停止支援 Less Secure Apps, application password 還是可以用的。公告中提到:

> If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.

回頭去翻了一下 LSA 是什麼 (出自「Limiting access to less secure apps to protect G Suite accounts」這篇):

A less secure app (LSA) is an app that connects to Google accounts using only username and password verification for access and not OAuth. Generally, you should only allow your users to use external apps that connect to Google accounts via OAuth, as LSAs make user accounts more vulnerable to hijacking.

看起來這邊指的是用原始的 Google 帳號與密碼登入,我一直以為這個方式早就被拔掉了,所以這次的公告以為是拔掉 application password,但看起來不是這樣。

玩了一下 OpenSnitch,Linux 下的 Application Firewall

這是在 Hacker News 上的討論「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」這篇看到的,裡面一開始是提到 Mac 上面的 Little Snitch,可以針對特定應用程式設定防火牆規則,而在 Linux 上對應的解決方案則是 OpenSnitch,但一直沒有嘗試,所以就試著用看看...

套件分成兩個部分,一個是 OpenSnitch 的主程式,另外一個是 GUI 的部分。

而在 Ubuntu 22.04 上裝有點麻煩,因為 Ubuntu 22.04 上預設的 grpc package 似乎是有 bug,需要裝新版解決。

不過我在找 PPA 的時候發現有人包了輔助套件:「OpenSnitch - application firewall (Xenial & newer)」。

這個套件本身是沒有包 OpenSnitch 主程式與 GUI 套件的,他只是要「補充」官方套件安裝的問題,所以需要照他的說明安裝:(我把下面指令提到的 1.5.2 換成目前新版的 1.6.0 裝,目前看起來是會動的)

sudo add-apt-repository ppa:savoury1/opensnitch
sudo apt-get update && sudo apt-get upgrade
sudo dpkg -i opensnitch_1.5.2-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.5.2-1_all.deb
sudo apt-get -f install

這邊用 dpkg -i 裝,而不是用 apt install 的原因是故意讓他不裝 dependency,等到後面的 apt-get -f install 時再裝 PPA 裡面提供的 dependency。

裝好後把跑 opensnitch-gui 起來後就會陸陸續續收到系統內不同的應用程式嘗試的連線,像是官網提供的 screenshot 這樣 (會跳出像左邊這樣的視窗):

這樣可以控的比較細,不過剛開始用會需要花時間把系統內常態性的 request 先設定過一次,還蠻煩的 XD

AWS ALB 支援 TLS 1.3?

AWSALB 宣佈支援 TLS 1.3:「Application Load Balancer now supports TLS 1.3」。

本來以為早就支援了,翻了一下發現應該是太多產品線的關係搞混了:

ALB 則是到了 2023 才支援 TLS 1.3...

「SMS 認證」被電信商 (以及第三方) 拿來套利的市場

Hacker News 上看到「Twitter Lost $60M a Year Because 390 Telcos Used Bot Accounts to Pump A2P SMS (commsrisk.com)」這篇,內文報導是這裡:「Elon Musk Says Twitter Lost $60mn a Year Because 390 Telcos Used Bot Accounts to Pump A2P SMS」。

簡訊的實際成本極低,但利潤超級高,發送方與接收方都有極大的獲利空間。

而這邊提到的 SMS pumping 的方式就是電信商自己做,或是電信商與第三方合作,利用各種發簡訊的方式 (內容不重要),讓 app 端要付出大量的簡訊成本,進而產生出大量的利潤。

Twilio 的「SMS Traffic Pumping Fraud」這頁就有這張圖:

簡訊的特點是很好 scale,你無法同時間接大量的電話,但可以同時間收大量的簡訊。在「SMS Fraud is costing you more than you realize」這邊也有提到這個問題。

這個問題在去年年底在我們自家的服務上就有看到跡象 (東南亞市場頗明顯),當時搜尋有一些討論,而現在看起來 Elon Musk 這次吵應該又會有更多熱度...

話說這樣演化下去,SMS 認證的退場又多了一個理由,除了 SS7 在資安上的安全問題外,看起來成本問題也會跑進來。

DOS 下的 TCP/IP 程式組

Hacker News 上看到「mTCP: TCP/IP applications for DOS PCs (brutman.com)」這個有趣的東西,在 DOS 環境下的 TCP/IP 程式組,原網站在「TCP/IP applications for your PC compatible retro-computers」這邊。

不過我覺得比較神奇的是,他的測試環境是真的包括一堆老機器跟網卡耶 XDDD

裡面提到的 NE1000ISA 界面的卡,這樣聽起來保養的都還不錯...

NLB 接 ALB?

AWS API Changes 上看到這個修改:「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣:

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎,這看起來讓彈性變大不少...