Author: Gea-Suan Lin

CloudFront 宣布支援 JA4 (更多的 fingerprint)

在「Amazon CloudFront launches support for JA4 fingerprinting」這邊看到的，Amazon CloudFront 宣佈支援 JA4。

JA3 是一套取得 TLS client fingerprint 的方式，先前在「CloudFront 支援 JA3 資訊 (SSL/TLS fingerprint)」也剛好有提到。

在 GitHub 專案頁面上面可以看到當初發明 JA3 的 John Althouse 已經離開 Salesforce，成立了 FoxIO：

JA3 was invented at Salesforce in 2017. However, the project is no longer being actively maintained by Salesforce. Its original creator, John Althouse, maintains the latest in TLS client fingerprinting technology at FoxIO-LLC.

而 JA4 則是進一步再改善 TLS fingerprint 的項目，另外有 JA4+ 的計畫，包括了非 TLS 的 fingerprint。

在 JA4+ 裡面有 TCP fingerprint (叫做 JA4TCP)，不過我記得 TCP fingerprint 因為 NAT 以及網路設備會調整 TCP 封包 (以及行為) 的關係，不是很準確...

留個記錄參考，話說 ELB 反而沒有這些功能，可以看出來 AWS 還是偏好你在前面堆個 CloudFront...

AWS 提供 Console-to-Code 功能

這個是在 Reddit 上看到的：「Convert AWS console actions to reusable code with AWS Console-to-Code, now generally available (aws.amazon.com)」，原文在「Convert AWS console actions to reusable code with AWS Console-to-Code, now generally available」。

先前是在 GCP 上用到這個功能，把操作的指令拉出來改，放到 shell script 裡面管理還蠻好用的。

現在 AWS 搞的是可以錄影轉指令，所以就是把操作都轉換成指令的意思，不過兩者骨子裡還是類似的想法。

從文章裡面有提到，現在的版本只支援 Amazon EC2、Amazon VPC 與 Amazon RDS：

At GA, AWS Console-to-Code only records actions in Amazon EC2, Amazon VPC and Amazon RDS consoles.

這樣用途就大打折扣了，在 GCP 上這個功能最好用的地方是在還不熟悉的產品上，可以降低你要查一堆文件才知道 web console 上操作對應到 cli 的指令是哪些...

<button> 與 <input type="button"> 的差異

在追奇怪的問題時發現的，實際上是個當年沒學好 (或是太久沒用忘記了)，現在回頭重新學的東西，在 Stack Overflow 上很久前就有人問過了：「<button> vs. <input type="button"> -- which to use?」。

我遇到的問題是 <button> 預設會觸發 submit 事件 (<input type="button"> 不會，然後我以為 <button> 也不會)。

而這邊又遇到 <button> 上綁定了 click() 事件的後續行為在 Chromium 與 Firefox 不同。

我在 click() 事件裡修改某些 input field 後想要觸發 submit() 事件時透過 document.querySelector('#second_submit_button').click() 觸發第二個 submit 按鈕，但在 Chromium 上會走到第一個 submit，而在 Firefox 上則是會走第二個 submit...

不確定這種複雜的行為是怎麼被定義的 (也蠻有機會是沒定義的)，所以只先查了比較單純的東西。

首先是現代的 HTML 規格中定義 <button> 的行為是在「The button element」這邊，裡面提到：

The type attribute controls the behavior of the button when it is activated. It is an enumerated attribute with the following keywords and states:

中間列了一張表列出 type 可以設定的值，然後說如果沒有指定 type 的話就是 submit：

The attribute's missing value default and invalid value default are both the Submit Button state.

If the type attribute is in the Submit Button state, the element is specifically a submit button.

知道為什麼後就能夠規劃解法了，解法看起來有兩條路：

第一條是用 <input type="button">，這樣就不會觸發瀏覽器的預設 submit 行為，就不會有後續的分支要處理。

第二條是用 event.preventDefault() 躲開問題，就... 會動。

不過這代表小時候沒學好啊... 如果我記得 <button> 預設會 submit 的話，我就會習慣用 <input type="button">，避免常態性中獎 @_@

Google Chrome 的 Canary 版本 (通路) 移除 Manifest V2

在「Manifest v2 is now removed from Chrome canary (chrome.com)」這邊看到的，Google Chrome 的 Canary 版本已經移除 Manifest V2：「Manifest V2 support timeline」。

接下來應該要進入各家瀏覽器自己維護 fork 的時代了，尤其是對 chrome.webRequest 的支援，來看接下來各家 fork 的發展。

.io 網域的後續討論

最近因為「The Disappearance of an Internet Domain」這篇文章的關係，大家在討論 .io 網域後續的存廢問題。

起因是英國放棄了英屬印度洋領地 (British Indian Ocean Territory) 的主權/統治權 (sovereignty)，交還給模里西斯：「UK and Mauritius joint statement, 3 October 2024」。

而這觸發了 ccTLD 的消滅條件，這邊用維基百科的說明：

With the United Kingdom giving up sovereignty of the British Indian Ocean Territory to Mauritius (but maintaining the military base on Diego Garcia via an initial 99 year lease), it is possible under IANA rules, the .io domain will eventually have to be phased out within the following several years, although historically, some exceptions been granted, as was the case for .su.

不過就如同作者提到的，.io 網域實在太多人用了，而且受到許多人的熱愛，或者講的更直接的「是個金雞母」，在金錢的面前，大量的遊說很有可能會使得 IANA 修正現有條款，或是開出例外條款：

The IANA may fudge its own rules and allow .io to continue to exist. Money talks, and there is a lot of it tied up in .io domains.

接下來應該會有會議討論看怎麼玩...

我來猜個可能性... 最後會改 rule，以後這種 ccTLD 通通會變成 gTLD 的模式，拿到商業市場上競標 & 賣給廠商營運？畢竟兩個字實在太香了...

Amazon EC2 讓你可以關閉 vCPU 節省軟體授權費用

在「Amazon EC2 now supports Optimize CPUs post instance launch」這邊看到的：

Amazon EC2 now allows customers to modify an instance’s CPU options after launch. You can now modify the number of vCPUs and/or disable the hyperthreading of a stopped EC2 instance to save on vCPU-based licensing costs.

以往要大量記憶體的會用 r 系列的主機，vCPU:RAM-GB 比率是 1:8，如果要再更高的話有最近推出的 x 系列，可以到 1:16。

對於使用按照 vCPU 收授權費軟體的使用者來說，有可能會希望比率再更大，尤其是應用偏 memory bound + 授權費很貴的情況。

這次 AWS 這次推出讓你關 vCPU 以及 hyperthreading 的選項，雖然機器費用不變，但軟體授權費就可以下降了：

There is no additional or reduced charge for specifying CPU options. You're charged the same as instances that are launched with the default CPU options.

不確定可以關到什麼程度，像是 x8g.48xlarge (192 vCPU + 3TB RAM) 這台機器不知道可不可以關到只有 1 vCPU，我記得實體 CPU 數量與可以控制的記憶體數量有關，虛擬化後的 vCPU 不確定會不會把限制也帶出來。

看起來是個很「有趣」而且「實用」的功能，但這些收授權費的廠商應該不會太開心，不知道會怎麼反應 XDDD

Conventional Commits

查資料的時候翻到的，寫 commit 常有 feat: 或是 fix: 這樣的 prefix，剛剛才突然想到這應該是有人訂規範的，翻了一下應該是「Conventional Commits」這個，裡面也引用了另外一個專案：「commitlint」。

所以 type 的部分可以有很多種類，剛剛前面提到的 feat: 以及 fix: 都在裡面：

build
chore
ci
docs
feat
fix
perf
refactor
revert
style
test

對於有規範用英文寫 commit log 的單位可以直接套用，不算太複雜。

馬上想到的好處大概是這樣對於 junior engineer 可以很自然的把 fix 與 feat 拆開 (其他的也類似)，而且對於 code reviewer 也可以注意變化。

ProductHunt 上面的 bot 問題

在「Bots, so many bots (wakatime.com)」這邊看到的，原文在「Bots, so many Bots」這邊。

作者用釣魚的方式 (對 LLM 的 prompt injection) 以及分析的方式保守估算 ProductHunt 上面至少有 60% 的帳號是 bot，但也提到了一個悲哀的事實，想辦法讓機器人 upvote 以及留言，讓你得到更多正面的回饋，就有機會登上 newsletter 並且得到更多對「真人」的曝光：

Is launching on ProductHunt worth it? Even though most comments and upvotes are bots, there’s probably still some real humans using ProductHunt... maybe. If you pay the bots and get featured in the newsletter, my guess is more real humans will see your product.

yeah，這也是產業鏈...

George Orwell 的 1984 與 Aldous Huxley 的 Brave New World

前幾天看到「Amusing Ourselves to Death (2009) (archive.org)」這則，原文很久前就下架了，所以指到的是 Internet Archive 上的版本：「Amusing Ourselves to Death by Stuart McMillen - cartoon Recombinant Records」。

標題的兩部作品分別是 George Orwell 的 Nineteen Eighty-Four (所以常被簡寫成 1984，中文書名常用《一九八四》來翻譯)，以及 Aldous Huxley 的 Brave New World (中文書名常用《美麗新世界》來翻譯)，都是反烏托邦小說 (Dystopian novel) 的經典作品，需要讀過這兩部作品才比較容易理解這篇漫畫在講的比較。

最後面提到的：

  • In short, Orwell feared that what hate will ruin us.
  • Huxley feared that what we love ruin us.

這個角度的確是之前沒有想過的，有種在指出現在 (2009 年當時) 就已經是 Brave New World 的世界了，以 15 年後 2024 年的角度再回頭看就更明顯了...

uBlock Origin Lite (也就是 MV3 版本) 放棄在 Mozilla Add-ons 平台上繼續上架

整包故事大概都在「uBOL version updates missing in Firefox add-ons store #197」這邊了。

Raymond Hill (uBlock Origin 以及這次提到的 uBlock Origin Lite 的作者) 被 Mozilla 的 Add-ons Team 亂搞以後不爽，決定徹下 Mozilla Add-ons 平台上的 uBlock Origin Lite，改成自己 host。

先是「#issuecomment-2329365796」這邊提到他收到 Mozilla Add-ons Team 兩封信件，開頭就提到這是 manual review：

Your Extension uBlock Origin Lite was manually reviewed by the Mozilla Add-ons team in an assessment performed on our own initiative of content that was submitted to Mozilla Add-ons.

然後 Raymond Hill 提到三個 Mozilla 亂搞的問題，其中第三個我覺得是第一個的延伸，所以我這邊就只講第一個與第二個。

第一個是 Mozilla 指控他傳輸資料但卻沒有取得使用者同意：

Consent, specifically Nonexistent: For add-ons that collect or transmit user data, the user must be informed and provided with a clear and easy way to control this data collection.

這邊 Mozilla 提出來的檔案是 web_accessible_resources/googlesyndication_adsbygoogle.js。

第二個 Mozilla 指控的問題是放了 minified 的檔案但沒有提供 source：

Sources, specifically Sources or instructions missing: Your add-on contains minified, concatenated or otherwise machine-generated code. You need to provide the original sources, together with instructions on how to generate the exact same code used in the add-on.

這邊 Mozilla 提出來的檔案是 web_accessible_resources/fingerprint2.js、web_accessible_resources/google-analytics_analytics.js、web_accessible_resources/google-analytics_ga.js 以及 web_accessible_resources/googletagservices_gpt.js 這四個。

然後這五個檔案打開來看，完全可以同意 Raymond Hill 說明的，完全看不到 Mozilla 指控的東西。

最後是 Mozilla 的處置方法也超級奇怪，將除了最早的版本以外的所有版本都 takedown，但最早的版本也被 flag 上面五個檔案... 這樣就導致用戶會裝到一堆 bug 的版本，逼的 Raymond Hill 也得把最早的這個版本 disable。

最後他已經講的很客氣了：「I am unable to see this as a mistake」，原文大概是「他媽的你 Mozilla 故意搞事」：

@Rob--W I appreciate you trying to build a bridge, but as much as I have tried over and over, I am unable to see this as a mistake, it takes only a few seconds for anyone who has even basic understanding of JavaScript to see the raised issues make no sense, and that the steps taken (disable all but the oldest version instead of all but the most recent) were the worse for both the extension and new users interested in it.