幹壞事是進步最大的原動力
升級到 Google Chrome 88 以後又再次被 Google 姦了，這次是 Search Engine Keyword 的功能預設被關掉：「Chrome 88 disables space bar shortcut for custom search engines, but there's a fix」，在「Google Chrome keyword search is no longer working」這邊也有類似的問題冒出來。
文章裡面有提到解法，在 chrome://flags 裡面挑一個設為 Disabled 就可以了，我是用 #omnibox-keyword-search-button 這組：
設定完成後要重開瀏覽器才會生效。
在 Hacker News Daily 上看到「Investigate unusual media traffic pattern for AsterNovi-belgii-flower-1mb.jpg on Commons」這個，維基百科拿來存放各種多媒體檔案的 Wikimedia Commons 發現有大量的印度流量都打進了 https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/AsterNovi-belgii-flower-1mb.jpg/1280px-AsterNovi-belgii-flower-1mb.jpg 這張圖片，而這佔了 EQSIN (新加坡伺服器的代碼) 中 20% 的流量：
由於 User-Agent 與 Referer 都沒有資訊，可以確認這不是瀏覽器造成的流量，但也因為沒有有用的資訊，變得很難查。
接下來有使用者提到時間點可能跟 TikTok 在印度被 ban 有關，因為在被 ban 後有很多使用者會去找替代的服務，而開發者有可能就直接拿這張圖來當啟動畫面或是背景畫面。
所以他們把熱門的替代服務都看了一輪，也都沒看到這張圖。後來他們猜測有可能是抓了但沒顯示在畫面上，所以開始交叉測試：在開 app 後就去 Hive 掃 HTTP log，然後找到一個 app。
後來為了要確認是不是這個 app，他們架了一組 DNS server 記錄查詢的網域名稱，看看 app 會不會觸發查詢 upload.wikimedia.org 這個網域名稱，而不出所料的確認了，而且真的就是在啟動時有抓，但是沒有顯示在畫面上。
接下來就是想辦法聯絡開發團隊，而目前 Wikimedia Commons 這邊先以 User-Agent 擋掉這些需求了。
另外在 Hacker News 上的討論「20% of requests for Wikimedia Commons are for one image of a flower (wikimedia.org)」也很有趣，有其他事件的苦主在當年遇到 MSN 直接用他網站上的圖片導致他的伺服器快掛，而且反應了很多次都沒用，然後他就把圖片換成「Netscape Now」，然後十五分鐘內就被解決了：
At the height of the browser wars I once woke up to Microsoft hotlinking a small button for downloading our software from the MSN homepage. I tried to reach someone there for hours but nobody cared enough to do something about it. The image was small (no more than a few K), but the millions of requests that page got were enough to totally kill our server.
Finally, I replaced the image on there with a 'Netscape Now' button. Within 15 minutes the matter was resolved.
找了一下圖片，看起來應該是類似這種的圖：
要直接反擊讓人會痛... XD
先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。
因為上新聞所以才動了起來 (本來都沒什麼在動)，後來提供的方法是變成可以設定的選項，但預設是關閉的，這樣一來就可以改善 Root name servers 的壓力：「Add multi-state DNS interception policy - functionality piece.」。
而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出)，在繼續觀察幾個月後，上個禮拜 Verisign 的人在 APNIC 這邊更新了消息：「How Chromium reduced Root DNS traffic」。
這是去年八月時丟出來的資料，可以看到趨勢往上：
這是後續的資料，從 87 版釋出後開始往下：
另外我覺得比較好玩的是這個，在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明：
看起來沒什麼問題，先 merge 再說... 是這樣玩嗎 XDDD
剛剛在 Clubhouse 上聽到保哥提到了 RFC 7807 這個東西 (Problem Details for HTTP APIs)，剛剛翻瀏覽器累積的 tab，發現原來先前有看到，而且有打算要出新版的消息：
RFC 7807 "Problem Details for HTTP APIs" has become a widely used standard for representing error messages. work has started on an updated version of the format. if you have any feedback about the spec, now would be a good time to make yourself heard. https://t.co/ERrsf1BbbN pic.twitter.com/dEQnzUMS3M
— Erik Wilde (@dret) January 29, 2021
RFC 7807 裡面這樣定義的方式可以讓 client 端直接判斷 Content-Type 知道這個回傳資料是不是錯誤訊息，不然以前都是 JSON 就得再另外包裝。用 Content-Type 的作法可以讓判斷條件變得清晰不少。
除了 application/problem+json 與 application/problem+xml 以外，在「3.1. Members of a Problem Details Object」裡面則是說明 JSON (或是 XML) 裡面有哪些必要以及可選的資訊要填，然後「3.2. Extension Members」這邊則大概描述一下怎麼擴充。
先有個印象，之後新規劃的東西可以考慮進去...
又是一個以為很久前就已經支援，但實際上沒支援的功能...
ALB 支援使用 cookie 實現 sticky session 功能：「Application Load Balancer now supports Application Cookie Stickiness」。
使用者的 session 通常會使用 cookie 記錄，而如果有多台 server 提供服務時，session 裡的資訊就需要找一個 shared session storage 放，以確保使用者在連到不同的 server 時都還是可以讀到對應的 session，比較傳統的方案就是直接把 session 塞進資料庫，後來發展出 memcached 或是 Redis 可以用。
但有些買來的軟體並沒有考慮到這點 (常常都是內部系統)，導致前面放 load balancer 時，必須想個辦法記錄使用者使用後端的哪台機器，這樣就可以在後端不支援 shared session storage 的情況下，還是可以讓應用正常運作。
透過 cookie 實做的 sticky session 算是蠻常見的作法，只是以為早就有了...
在「Disqus, the dark commenting system」這邊才看到 Disqus 被網路廣告公司買的消息：
Disqus was acquired by an advertising company called Zeta Global in 2017. Obviously, advertising companies do everything to increase their revenue (Ex: the Big G).
引用的報導則是在「Zeta Global acquires commenting service Disqus」這邊可以看到，大約在三年前發生的事情...
基本上已經變成廣告追蹤平台了：
I analyzed the network requests log. Disqus makes HTTP requests to 11 different third-party domains through the browser. All of these websites are trackers/pixels (Even some were detected as malware by my security guard).
而且就算是付費會員也一樣，還是會追蹤：
When you provide a free product, money should come from somewhere. Disqus uses advertising for that. Now, I subscribed to a paid plan trial of Disqus to see if things change or not. No! Even in the paid plans, the same pixels are loaded on the client-side. Looks like there's no way to opt-out from tracking.
後面的推薦可以看看就好，自己架應該還是比較好的選擇... 用「open source comment system」搜有些東西可以參考。
在 Hacker News Daily 上看到「NordVpn disables features when you turn off auto-renew」這個，這也太厲害了：
NordVPN 設計成只要關掉 auto-renewal 就直接拔掉一些功能，一臉 WTF...
在 Hacker News 的「NordVPN disables features when you turn off auto-renew (reddit.com)」看到這段提出來的論點蠻有趣的，當作一個參考觀點：
By now these VPN providers are like toothpaste, diapers or soft drinks: completely undifferentiated between competitors, and so only able to maintain their market share by spending loads on marketing. Of course the company with most egregious dark patterns and aggressive churn dampening wins.
Thankfully a tube of toothpaste doesn't allow implementing dark patterns like this... yet.
這篇「Achieving 11M IOPS & 66 GB/s IO on a Single ThreadRipper Workstation」用了 AMD 平台上的 PCI-e 4.0 硬幹出 4K 隨機讀取 11M IOPS 的速度，另外在大區塊讀取可以到 66GB/sec，後面這個速度應該是可以把 DDR4 記憶體頻寬吃滿...
硬體的部份，作者用了 8*1TB + 2*500GB 的 M.2 SSD 來建這組系統，然後接到卡上：
不過他好像沒提到這組機器的價錢 (雖然每個單品都查的到)，大概算了一下 storage 的部份其實不怎麼貴，Samsung 980 Pro PCIe 4.0 M.2 SSD 的部份，1TB 每一條要 USD$160，500GB 要 USD$120，旁邊那些 CPU 與記憶體反而貴不少... 不過整台機器應該有機會在 USD$10000 搞定？
感覺拿來給剪片的人用很爽？至少在處理讀寫的時候應該是很順...
前陣子因為好玩買了 ZY1280P，主要是可以看充電時使用的 Protocol：
其中 D+ 與 D- 資訊可以拿來判斷現在在跑的 Protocol，網路上有不少資料可以看，就會發現各家廠商在早期出了超多的快充協定。
拿到後把家裡各種可以輸出 USB 電源的東西都測了一輪，才發現有超多東西跟預想的不一樣。
首先是 HA2-50U5Q 這顆 USB 充電器：
最左邊兩個 Port 接上去只顯示了 DCP 5V1.5A + SAMSUNG 2A，接 iPad mini 上去也的確只有 1A 左右的電流。而再往右的兩個 Port 接上去就會顯示 DCP 5V1.5A + APPLE 2.4A，這時候 iPad mini 可以吃到接近 12W 左右，另外 QC 2.0 的 Port 也能提供 APPLE 2.4A。
我之前把 Lightning 的線接在最左邊，難怪充電速度不怎麼樣...
另外一個是行動電源「ASUS行動電源ZenPower 10000mAh(QC3.0)-ABTU018(藍)」：
這台也有類似的情況，QC 3.0 的 Port 可以推 DCP 5V1.5A + APPLE 2.4A 出來，但是另外一個 Port 只能給 DCP 5V1.5A + SAMSUNG 2A，然後我平常也是把 Lightning 的線接在黑色的那條上面...
不過 ZY1280P 這台的 USB Type C 有遇到狀況：有些直接接 Macbook Air 可以充電，但過了 ZY1280P 就不能充 (這邊應該是走 USB PD)，另外在測 Nokia 5.3 也有類似情況 (這台沒有支援 USB PD)，這邊的問題年假期間研究一下，看看有什麼設定要設...
我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2 的 t4g.small 上 (2GB RAM + 20% CPU credit)，跑了一陣子把 CPU usage 拉出來看：
當初估大約要 20% 的 CPU credit，結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB，這個量可以看出來一些沒在用的 process 會被丟到 swap：
total used free shared buff/cache available Mem: 952Mi 380Mi 79Mi 110Mi 492Mi 368Mi Swap: 511Mi 152Mi 359Mi
把條件綜合起來計算，就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。
另外新機種比較不用擔心淘汰速度，就看了一下 Reserved Instances 的價錢，一年 USD$44，三年 USD$84，看起來只要有用兩年就算是 OK，直接買三年解決掉...
