微軟透過 Windows Update 強制安裝新版 Edge

前幾天在虛擬機內的 Windows 突然被裝了新版的 Edge，發現國外也有報導出來了：「With Edge, Microsoft’s forced Windows updates just sank to a new low」。

這次是 Windows Update 推進來的，即使在 Windows 7 上已經 EoL (2020/01/14)，不會有任何安全性更新，微軟也是濫用透過這個方式推進來：

這種方式也都讓大家想到與 antitrust 的關係：

It all immediately made me think: what would the antitrust enforcers of the ‘90s, who punished Microsoft for bundling Internet Explorer with Windows, think about this modern abuse of Microsoft’s platform?

到底會不會觸發呢...

Userscript 內對於 SPA 類的頁面的修改

目前的 userscript 支援這四種啟動時機 (用 @run-at 參數指定)：

  • document-start (一開始就跑)
  • document-body (出現 body 後跑)
  • document-end (DOMContentLoaded 時，或是之後跑)
  • document-idle (DOMContentLoaded 後跑)

但對於 SPA 類的頁面來說，即使用到 document-idle，也不保證執行時頁面已經渲染完成，這時候可能是 framework 才正要開始處理頁面的時候。

如果我們的 userscript 想要「等」這些 framework 處理完後再開始跑，其中一種 workaround 是用 setTimeout() 等，但這樣很容易被 side effect 影響，像是電腦慢一點的時候還是會失敗，而如果 setTimeout() 時間拉太長體驗又不好：

setTimeout(() => {
    // ...
}, 1000);

比較好的方式是用 MutationObserver() 聽事件，在每次有新元素插入時判斷是否達成條件，處理完成後再停止聽事件 (避免持續影響效能)：

let observer = new MutationObserver(() => {
    // ...
    // observer.disconnect();
});

observer.observe(document.documentElement, {
    attributes: false,
    childList: true,
    subtree: true,
});

有些 library 有把這段包起來，但看了使用方式覺得很複雜 (因為要支援比較多的情境)，反而是自己把 MutationObserver() 的概念搞清楚後，用這幾行包起來還比較簡單...

用 Python 刻 GUI 的 guietta

翻 Hacker News Daily 翻到的奇怪工具 guietta，可以在 Python 下用奇怪的方法刻 GUI，範例就很好解釋了調性：

from guietta import _, Gui, Quit

gui = Gui(
    
  [  'Enter numbers:', '__a__'  , '+' , '__b__',  ['Calculate'] ],
  [  'Result:  -->'  , 'result' ,  _  ,    _   ,       _        ],
  [  _               ,    _     ,  _  ,    _   ,      Quit      ]
)

with gui.Calculate:
    gui.result = float(gui.a) + float(gui.b)
    
gui.run()

然後 Ubuntu 下的輸出會是：

在 Hacker News 的討論串「Guietta – Python module to create simple GUIs (github.com)」這邊有人也介紹了其他 Python 下刻 GUI 的方式，翻了一下也還不少有趣的東西。

guietta 看起來拿來刻一些簡單的東西應該還算堪用，尤其是討論裡面有提到在教學授課時可以簡化不少 interface 的問題。

Onion Service 第二版的退場計畫

Tor 這邊給出了 Onion Service v2 的退場計畫：「Onion Service version 2 deprecation timeline」，關於 v2 與 v3 的差異，可以參考之前寫的「下一代的 Tor Hidden Service」，裡面有提到 v3 的 spec。

v2 與 v3 最大的差異就是本來 v2 的 hostname 是 16 個英數字 (大約是 80-bit security)，現在 v3 變成是 56 個英數字 (大約是 280-bit security)，大幅降低 collision 的機會。

目前公佈的時間表是在 2020 年九月先拋警告出來，2021 年七月拔掉 server 支援，2021 年十月拔掉 client 支援：

1. September 15th, 2020
0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6.

2. July 15th, 2021
0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.

3. October 15th, 2021
We will release new Tor client stable versions for all supported series that will disable v2.

差不多是十五個月的計畫...

Amazon SES 開東京區與新加坡區了...

Amazon SES 是 2011 年年初發表的服務，過了九年總算想起來這幾區也是需要 SES 的服務了...：「Amazon Simple Email Service is now available in the US East (Ohio), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Asia Pacific (Seoul) Regions」。

這些年來大家應該都是用 us-west-2 或是 us-east-1 workaround 很久了，現在開這些區域主要還是讓 API 的整合會比較方便，如果本來就是透過 IAM user + username + password 的方式寄信的話就沒什麼差...

另外一種是寄比較大的信件 (產生的流量很大)，這次這樣可以避免降低跨區而被收兩次流量費用，不過這應該是比較少見的情況...

AWS 宣佈提昇 Amazon EFS 的最低效率

AWS 宣佈提昇 Amazon EFS 的最低效率：「Amazon Elastic File System increases file system minimum throughput」。

第一段裡的幾個數字差不多就是重點了：

Amazon Elastic File System (Amazon EFS) file systems using the default bursting throughput mode now have a minimum throughput of 1 MiB/s. All EFS bursting mode file systems (regardless of size) can drive 100 MiB/s of throughput, and file systems with more than 1TiB of Standard class storage can drive 100 MiB/s per TB when burst credits are available. This change increases the minimum throughput from 50KiB/s per GiB of Standard class storage to a fixed minimum of 1 MiB/s for file systems with less than 20 GiB of Standard class storage, when burst credits are exhausted.

本來最低保證效率是每 GB 提供 50KB/sec，也就是要使用到 20GB 才會提供 1MB/sec，現在對於不到 20GB 的使用者，直接拉高到固定 1MB/sec。

這對於剛開始用的使用者會方便一些，不過 EFS 主要還是方便在不同機器上共享，效率上還是本機掛 EBS 好很多 (因為 OS 可以 cache)。

先前在 AWS 上把 /home 丟到 EFS 上面，結果因為 i/o 都需要透過網路的關係，編 pyenv 超慢，後來找一天把東西都丟回 EBS 上，速度快多了...

雞肋功能：AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists，就不需要自己在 security group 裡面針對一堆 IP 設重複的設定：「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了：

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用，主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響，如果沒有開 support ticket 調高限制，預設值是：

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時，需要設定「裡面會包含的最大數量」(可以到 1000)，是一個你不知道為什麼要設定的東西，然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的)，結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule，而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list，改成 15 條後，就可以在 security group 上面掛四次 prefix list (不同的 port)，剛好吃完 60 條規則，第五個設定就完全掛不上去... (無論是用 prefix list，或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用：

  • 一開始就要設計好 prefix list 內的最大筆數，如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則，而是以最大筆數佔用，prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎，因為你可以設計機制，改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量，不會有浪費)，然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到，都已經用 Terraform 這種工具了，加上你又不是只佔一條規則，我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

第四堂：「Data Wrangling」

有陣子沒寫了，來還個債...

這個系列是從『MIT 的「The Missing Semester of Your CS Education」』這邊延伸出來的，這邊講的是「Data Wrangling」這篇。

這篇是在講 pipe 的用法，在講這些工具之前，其實有個很重要的概念應該要說明 (但沒有在這篇文章裡被提到)，也就是 Unix philosophy，這個哲學是指 unix 環境下的工具，都會設計成只做好一件事情。

而要怎麼把這些工具串起來，最常見的就是 pipe，你可以在文章裡看到 grep、sed 與 sort 這些工具的用法，以及怎麼用 pipe 串起來。

這邊剛好也可以提一下，利用 pipe 可以把不同功能打散到不同的 process 上，剛好也可以稍微利用到現在常見的多 CPU 的環境。

另外上面因為提到了 grep，文章內花了不少篇幅在講 Regular expression 這個在 CS 課程裡面也是重要的基礎。

會放這種篇幅長度，一方面是 Regular expression 的實用性很高，另外一方面，學術上與自動機理論中的 DFA 與 NFA 都有關，算是學習計算理論的起點：

然後後面就有提到 AWK 這個工具，這邊要注意的是，雖然可以用 Perl 之類的工具作到類似的事情 (而且更強大)，但 AWK 有被放到 POSIX 標準裡，所以在各種作業系統內幾乎都一定會出現，加上語法算是簡單，學起來還是很有幫助...

然後再最後面的段落冒出一個 gnuplot 畫個圖，以及示範 xargs 這種神器要怎麼用 (這邊會更建議看一下 manpage，可以配合 find 之類的工具用，並且平行化同時處理)。

然後最後示範了 binary data 怎麼處理。

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案，是利用蘋果的 Secure Enclave 機制，把 SSH private key 放進去在裡面進行運算，避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能：

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的：

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機，可以透過有支援 smart card 的硬體掛上去，像是 YubiKey：

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料，看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了，不過要注意純 U2F 的版本沒支援。

RFC 裡面的 MUST/SHOULD/MAY

讀 RFC 文件時常看到會使用這組定義，甚至有些非 RFC 文件也會使用：

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

這邊提到的 RFC 2119 就是 1997 年訂的「Key words for use in RFCs to Indicate Requirement Levels」這篇，以 2020 年的現在來說，這組定義已經被人熟知，用這組定義可以讓閱讀的人很輕鬆的了解條件的強制性。

剛剛在讀新的文件時發現這段文字有更新，往回查發現是針對大小寫的差異提出更新：「Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words」，主要是這兩條：

  • The words have the meanings specified herein only when they are in all capitals.
  • When these words are not capitalized, they have their normal English meanings and are not affected by this document.

然後也更新了引用的部份：

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

不過就算是 2017 年之前應該也是這樣讀就是了...