幹壞事是進步最大的原動力
在「Reserving .INTERNAL for Private-Use Applications」這邊總算是看到通過保留 .internal 的決議了。
整個程序意外的長，大致上有幾個時間區塊，第一個區塊是 2020 年的時候提案以及告知相關單位 (IETF 以及 IAB)，並且得到配合的回覆。
然後就到 2022 年的時候 (2021 年不見了，不確定是不是與 COVID-19 有關) 收取公眾意見，2023 年又再收取一次意見，最後決定選 .internal 保留，然後 2024 年七月決議。
另外文件裡剛好提到「IANA-managed Reserved Domains」，看起來是由 IANA 管理的 reserved domains，可以看到很多 IDN...
前幾天很熱門的「An Anonymous Source Shared Thousands of Leaked Google Search API Documents with Me; Everyone in SEO Should See Them」消息，裡面提到有拿到一份疑似 Google 搜尋引擎的內部 API 文件， 可以證實有很多 Google 搜尋引擎的運作與 Google 對外宣稱的不符。
作者找了業內人士幫忙分析 (他自己說他先前也在碰 SEO 這塊，但是已經離開這個行業六年了)：
Next, I needed help analyzing and deciphering the naming conventions and more technical aspects of the documentation. I’ve worked with APIs a bit, but it’s been 20 years since I wrote code and 6 years since I practiced SEO professionally.
包括作者的一些 Google 朋友，或是 ex-Googler 都確認這份文件符合 Google 內部的文件規範要求，另外裡面的元素編排也都很像是 Google 的文件。
本來以為事情大概就這樣，後續應該就是會有很多人從這份文件分析 Google 有哪些 SEO 的偏好，找出哪些東西與 Google 宣稱的不符。
不過事情突然有個意外的轉折，Google 本來一直是「拒絕評論」的態度，但突然承認這份文件的確是他們內部文件：「Google confirms the leaked Search documents are real」。
"We would caution against making inaccurate assumptions about Search based on out-of-context, outdated, or incomplete information," Google spokesperson Davis Thompson told The Verge in an email. "We’ve shared extensive information about how Search works and the types of factors that our systems weigh, while also working to protect the integrity of our results from manipulation."
反正也沒有人會相信 outdated 了，但可以預想的是 Google 的搜尋結果應該又會變差，因為會有更多 SEO 垃圾開始想辦法衝排名上去...
短短幾天內看到兩個不同的地方用到了 1982 年發現的「Lenstra–Lenstra–Lovász lattice basis reduction algorithm」。
第一個是「Randar: A Minecraft exploit that uses LLL lattice reduction to crack server RNG (github.com/spawnmason)」這篇，作者群利用 LLL 去分析 java.util.Random 的內部狀態，進而得到其他玩家的地點資訊：
Every time a block is broken in Minecraft versions Beta 1.8 through 1.12.2, the precise coordinates of the dropped item can reveal another player's location.
"Randar" is an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused
java.util.Randomin the Minecraft server, then works backwards from that to locate other players currently loaded into the world.
另外一個是在 Hacker News 上面的 id=40080651 提到，前幾天 PuTTY 的 p521 問題在底層也用到了 LLL：
LLL lattice reduction is the same algorithm that can be used for cracking PuTTY keys from biased nonces from the CVE a few days ago. 'tptacek explained a bit about the attack (and links to a cryptopals problem for it, which I can almost pretend to understand if I squint) https://news.ycombinator.com/item?id=40045377
從維基百科的內容也可以看出來 application 非常多，不光是密碼學的領域用到，看起來值得花點力氣來了解...
意外看到「Proposed top-level domain string for private use: ".internal" (icann.org)」這篇，發現 .internal 還沒被 ICANN 列入 reserved top-level domain？原文在 ICANN 的網站上：「Proposed Top-Level Domain String for Private Use」。
這邊有兩個不同的權力組織 (團體)，一邊是掌握著 root name server 規範的非營利組織 ICANN，不過 ICANN 也決定了有哪些 top-level domain 可以賣...；另外一邊是社群與 IETF 在寫下各種建議與制定標準。
現在看起來是在 RFC 6762 (Multicast DNS) 這邊講 Multicast DNS 的地方，意外的在附錄的提到了 .internal 這組 domain：
We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:
然後列出了六個 domain：
.intranet.
.internal.
.private.
.corp.
.home.
.lan.
看起來也不是說這六組要被保留，比較像是講個現象？現在 .internal 要被放進去算是補一些決議？真的有公司想要申請這六組任何一個應該都不會過...
在 Twitter 上看到一個很久前的討論：
— lordlee (@lordlee) December 29, 2021
裡面提到了「Timing Details With cURL」，可以給一個 template 進去輸出內部資訊：
time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_pretransfer: %{time_pretransfer}
time_redirect: %{time_redirect}
time_starttransfer: %{time_starttransfer}
———
time_total: %{time_total}
不過我實際測試發現現在的 curl 版本要加上 \n 才會換行，之後可以拿來 debug 看看...
AWS 放出前幾天 us-east-1 出事的報告了：「Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region」，Hacker News 上的討論「Summary of the AWS Service Event in the Northern Virginia (US-East-1) Region (amazon.com)」也可以看一下，裡面也有人提到儘量閃開 us-east-1。
而爆炸當天的討論「AWS us-east-1 outage (amazon.com)」也可以看一看，裡面還有聊到企業文化的問題...
AWS 的 us-east-1 除了是 AWS 最早的區域以外，也是目前 AWS 內功能最多的區域 (大多數新功能在第一波都會開放 us-east-1 使用)，然後也是最便宜的區域，所以會有很多人都用這個區域提更服務。
也因為這樣，這個區域也是 AWS 內最大的區域，加上 AWS 是目前最大的公有雲，導致了這個區域的很多東西會遇到以前的人都沒遇過的問題，大概每年 (或是每兩年) 就會有一次比較嚴重的 outage，算是為了價錢而選擇 us-east-1 的人要注意的。
說到價錢，如果是為了找價錢比較低的區域，另外一個可以考慮選擇是 us-west-2，出新功能與新產品時也常常會被放進第一波，目前看起來的歷史記錄應該是比 us-east-1 好不少...
這次出問題的主要是內部控制用的網路 (被稱為 internal network) 擁塞，而非客戶在用的網路 (被稱為 main network)：
To explain this event, we need to share a little about the internals of the AWS network. While the majority of AWS services and all customer applications run within the main AWS network, AWS makes use of an internal network to host foundational services including monitoring, internal DNS, authorization services, and parts of the EC2 control plane.
後面也有提到因為壅塞而導致 monitoring 系統受到影響，只能就手上的 log 去分析猜測，然後逐步排除問題，而 deployment 系統也使用內部網路，所以更新的速度也快不起來...
不過基本上可以預期明年或是後年應該還是會再來一波...
Twitter 發了公告請大家改密碼：「Keeping your account secure」。不只是 Twitter 自家的密碼，如果你有重複使用同一組密碼，也建議一起修改：
Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password.
雖然使用 bcrypt，但因為透過 log 記錄下了未加密的密碼，所以就中槍了：
We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
這時候就要再推 Password manager 這種東西了，在每個站台都使用完全不同的密碼，可以降低這類問題帶來的衝擊...
LINE 將內部的座位表由 Excel 管理，改用 Web 界面了：「Excel管理の座席表をLeafletでWeb化した話」，這邊不確定是全球的 LINE，還是只有日本的 LINE...
如果跟日本人有過業務合作的話，就會知道他們對 Excel 的用法只能用
出神入化
來形容啊... 所以看到 LINE 特地寫了一篇來說明他們開發內部系統的事情，覺得還蠻有趣的...
起因是今年四月換辦公室，所以就順便換系統，把本來用 Excel 管理的座位表改用 Web 管理 (然後用了 Leaflet 這個 JavaScript Library)：
人員の増加に対応するために、今年の4月、LINEはJR新宿ミライナタワーに移転しました。移転に伴い、IT支援室ではいくつかの新しい社内システムを導入しましたが、今日はその1つである「座席表」についてお話させていただきます。
這是 Excel 版本的樣子：
這是新版本的樣子，UI 上有更多互動的界面可以操作：
然後文末提到了總務業務量減少，而且因此變更座位變自由了而大受好評 (大概是不會讓總務煩死，所以就可以更自由換來換去 XDDD)：
今回開発した座席表は総務の業務軽減に始まったプロジェクトでした。そして実際に導入後には、座席表の管理にかけていた総務の業務を大幅に削減することに成功しました。また、利用者からもかなり好評で、「これを待っていたんですよ！」といった声もあり、社内コミュニケーションの円滑化に一役買うことができているようです。誰の席でも自由に変更できるという点についても、これまでのところトラブルの報告を受けることなく運用できています。
翻了一下英文版的 blog，好像沒有提到這件事情？XDDD