Tag: mode

Amazon SQS 提高 FIFO throughput 限制

在「Amazon SQS announces increased throughput quota for FIFO High Throughput mode」這邊看到 AWS 提高了 Amazon SQS 中 FIFO throughput 的限制，這本來是個常常有的公告，但讓我意外的是不同區域拉高的數量是不同的：

Amazon Simple Queue Service (SQS) announces an increased quota for a high throughput mode for FIFO queues, allowing you to process up to 9,000 transactions per second, per API action in US East (Ohio), US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt) regions. For Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) regions, the throughput quota has been increased to 4,500 transactions per second, per API action. For all other regions where SQS is generally available today, the quota for high throughput mode quota has been increased to 2,400 transactions per second.

第一梯隊的 (像是 us-east-1、us-west-2 與 eu-west-1) 都是 9000 tps，而第二梯隊是 4500 tps，沒列在上面的區域是 2400 tps。

另外一個比較特別的是 Frankfurt 區居然在第一梯隊...

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的，在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了：

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data，但離職員工爆料加密強度不足的問題：「1606428769731878913.html」，其中這段在講 legacy 版本的加密問題，居然曾經用過 ECB mode：

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的，以 1980 年代的標準就已經知道 ECB mode 的問題了：

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加，從早期的 5000 到現在預設的 100100，這點倒是可以理解。

要避免依賴廠商的資安，一種方式是用目前成熟的開源 Password Manager，並且使用檔案儲存 (像是 KeePassXC 這類工具)，再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式)，但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束，遇到西方的長假，反應都比較慢...

在家裡放光纖的故事 (又是 25Gbps 的 Internet...)

在「Wiring my home with Fiber」這邊看到為了善用 25Gbps 的 internet 頻寬，所以決定在裡直接穿管放光纖...

翻了一下之前寫的「25Gbps 的家用 Internet」，媽的居然是不同人，但都是 Init7 的服務沒錯...

在開頭的地方他先放了架構圖，看起來是多組線路備援的架構？

用的是單模光纖，然後穿現有的牆內管：

然後看起來是自己做插座，而不是直接接設備：

家裡只放了 Cat6 到各房間，可以在短距離裡面跑 10Gbps，或是百米的 2.5Gbps/5Gbps，以這幾年網路升級的速度應該是夠用...

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出 Lockdown Mode

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出了 Lockdown Mode：「Apple expands industry-leading commitment to protect users from highly targeted mercenary spyware」。

Lockdown Mode 主要是透過降低被攻擊的面積以提昇安全性，依照 Apple 的預想，主要是針對被政府單位盯上的族群：

Apple is previewing a groundbreaking security capability that offers specialized additional protection to users who may be at risk of highly targeted cyberattacks from private companies developing state-sponsored mercenary spyware.

在 Lockdown Mode 下目前列出來的限制：

  • Messages: Most message attachment types other than images are blocked. Some features, like link previews, are disabled.
  • Web browsing: Certain complex web technologies, like just-in-time (JIT) JavaScript compilation, are disabled unless the user excludes a trusted site from Lockdown Mode.
  • Apple services: Incoming invitations and service requests, including FaceTime calls, are blocked if the user has not previously sent the initiator a call or request.
  • Wired connections with a computer or accessory are blocked when iPhone is locked.
  • Configuration profiles cannot be installed, and the device cannot enroll into mobile device management (MDM), while Lockdown Mode is turned on.

列出來的這些的確都是之前 0-day 常被拿來打的東西，把攻擊面積縮小的確會有不少幫助。

這應該是業界第一個大咖跳進來做這個 (也就兩個大咖？)，第一次搞未必會完美，但算是個開始，後面應該會有更多的面積被考慮進去...

在非 4K 的螢幕上跑 HiDPI

前幾天看到 BetterDummy 這個專案，作者在 M1 上面外接 24" 1440p 的螢幕，但沒辦法啟用 HiDPI，於是就寫了一個軟體來解：

M1 macs tend to have issues with custom resolutions. Notoriously they don't allow sub-4K resolution displays to have HiDPI ("Retina") resolutions even though (for example) a 24" QHD 1440p display would greatly benefit from having an 1920x1080 HiDPI "Retina" mode.

在這之前的解法都有些麻煩，一種是買個 dummy dongle 去騙 macOS，另外是用 mirror 的方式使用：

To fix this issue, some resort to buying a 4K HDMI dummy dongle to fool macOS into thinking that a 4K display is connected and then mirror the contents of this dummy display to their actual monitor in order to have HiDPI resolutions available. Others use the built in screens of their MacBooks to mirror to the external display. These approaches have obvious drawbacks and cannot solve all problems.

作者提供的軟體可以先建立 Dummy Monitor，然後再透過 mirror 掛到實際螢幕上：

不確定用起來如何，但如果之後有需要的話好像可以測試看看...

Neovim 在選擇檔案名稱時的操作按鍵

在 Neovim 時操作檔案名稱時會是下拉選單，在 insert mode 時的畫面是這樣 (進到 insert mode 後 Ctrl-X + F)：

這時候可以用上下鍵選擇檔案名稱。

在 command mode 下也有類似的功能，像是 :sp 後按 tab 選擇檔案名稱：

問題在於只能用 Ctrl-N 與 Ctrl-P 移動，而不能用上下鍵操作，兩者的 UI 類似但是操作的方式不一樣，於是就翻了翻 manual，找出對應的模式，得到是 command mode，然後用 <expr> + pumvisible() 判斷是否是在 popup menu，接著把上下鍵對應到 Ctrl-N 與 Ctrl-P：

cnoremap <expr> <Down> pumvisible() ? "\<C-n>" : "\<Down>"
cnoremap <expr> <Up> pumvisible() ? "\<C-p>" : "\<Up>"

這樣就搞定了...

Kafka 拔掉 ZooKeeper 的進展已經進到 trunk

差不多一年前提到了 Kafka 打算拔掉 ZooKeeper 的計畫 (在「Kafka 拔掉 ZooKeeper 的計畫」這邊有提到)，昨天 Confluent 發了一篇進展：「Apache Kafka Made Simple: A First Glimpse of a Kafka Without ZooKeeper」。

這件事情可以在「KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum」這邊看到說明，另外在 Jira 上面則是在 KAFKA-9119 這邊追蹤。

目前的好消息就是 KIP-500 的程式碼都已經推進 trunk，目標在 2.8 釋出時就可以用：

So we’re very pleased to say that the early access of the KIP-500 code has been committed to trunk and is expected to be included in the upcoming 2.8 release.

文件裡面會用「Kafka Raft Metadata mode」或是「KRaft」稱呼這種模式：

For the first time, you can run Kafka without ZooKeeper. We call this the Kafka Raft Metadata mode, typically shortened to KRaft (pronounced like craft) mode.

然後有缺一些功能，另外就是常態性宣導這是測試版，建議不要在 production 環境用：

Beware, there are some features that are not available in this early-access release. We do not yet support the use of ACLs and other security features or transactions. Also, both partition reassignment and JBOD are unsupported in KRaft mode (these are anticipated to be available in an Apache Kafka release later in the year). Hence, consider the quorum controller experimental software—we don’t advise subjecting it to production workloads. If you do try out the software, however, you’ll find a host of new advantages: It’s simpler to deploy and operate, you can run Kafka in its entirety as a single process, and it can accommodate significantly more partitions per cluster (see measurements below).

目前丟出來的測試數據可以看到有大幅改善，但仔細看居然是停機與恢復時間：

不知道實際的效能上有多少影響 (正面或是負面)，還是得等了...

GitHub 的 Dark Mode 辨識度太低的問題

GitHub 推出 Dark Mode 後我就馬上切過去，但用了兩天後覺得辨識度太差就換回來了，剛剛在 Hacker News Daily 上看到不只我抱怨這個問題：「GitHub Dark Mode is Too Dark」，在 Hacker News 上的討論也可以翻翻：「 GitHub Dark Mode is too Dark (karenying.com)」。

裡面分析了 Spotify、Facebook、YouTube 以及 GitHub 的配色盤，然後算出對比度，可以看到 GitHub 的配色上的確是差了不少...

目前 GitHub 上的 Theme 功能是掛 beta，應該還是有機會改，看看會不會修的好一點...

Firefox 83 推出 HTTPS-Only Mode

Mozilla 在 Firefox 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 Browser 與 Tails 應該都會改用這個，畢竟 Tor 的 HTTP 出口常常被搞...

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

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

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

重新了解 Amazon EC2 的 T2/T3 Unlimited

剛好跟同事聊到 Amazon EC2 的 T2/T3 Unlimited，因為有些疑惑所以回家查了一下資料，發現以前的理解不夠完整。這是 T2/T3 Unlimited 的說明文件：「Unlimited Mode for Burstable Performance Instances」。

在文件的這塊說明了 T2/T3 Unlimited 模式的計算方式：

When its CPU utilization falls below the baseline, it uses the CPU credits that it earns to pay down the surplus credits that it spent earlier. The ability to earn CPU credits to pay down surplus credits enables Amazon EC2 to average the CPU utilization of an instance over a 24-hour period. If the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a flat additional rate per vCPU-hour.

我本來以為是剩下的 CPU credit 不夠時就會被收費，但依照官方文件的說明，是可以用後面賺到的 CPU credit 支付前面使用的 CPU credit，而可跨越的時間區間是 24 小時。

所以有時候會在 AWS web console 上看到 CPU 沒有在用，但是 CPU credit 卻長回不來的情況，是因為這時候還在還之前的債...