幹壞事是進步最大的原動力
AWS IAM 總算可以掛多個 MFA 到同一個帳號下了：「You can now assign multiple MFA devices in IAM」。
先前的 workaround 是開多個一樣權限的帳號，一個帳號掛 TOTP MFA，另外的每個帳號掛一隻 U2F MFA，但偶而會遇到會認 IAM account 的權限檢查，就會比較麻煩...
先說明一下，目前這個功能看起來還在 rolling update (也有可能是 bug？)，我的公司帳號就成功把本來只有 TOTP MFA 的加掛 U2F MFA 上去，但我自己的 AWS 帳號就怎麼樣都看不到這個新功能。
這是加好的：
這是我自己的 AWS 帳號，沒有像上面那樣可以管理多個 MFA，而點開 Manage 也只會看到移除的選項：
到另外一個掛 U2F MFA 的帳號下一樣也看不到：
另外我在刪除 IAM 帳號時也發現會有無法刪除 MFA 設定的錯誤訊息 (但點進去看 IAM user 可以確認 MFA 已經背山掉了)，這時候再刪一次就會成功，看起來 console bug 還不少... 也許再放個兩天看看？
把先前寫的 twitter2facebook 改寫，從本來固定用 Chromium 65 換成用 Firefox ESR。
當初會用 Chromium 65 這個很舊的版本，是因為這個版本還沒有把 headless 使用的 profile 獨立出來，而我需要 Facebook 登入的 cookie，所以就這樣用了，但畢竟用舊版是個討厭的隱患，還是花了些時間研究出來要怎麼用有 security update 的瀏覽器。
這次換成 Firefox ESR 主要是希望 ESR 版本不會太常改爛東西，不過缺點就是 selenium 4.x 不支援 ESR 版本的 geckodriver (參考「Old geckodriver releases raise an exception (code 64) if started with unsupported --websocket-port argument #1959」這個 issue)，而且關不掉 --websocket-port 這個參數，所以我只好在 requirements.txt 內設定用 3.x 最後一個版本的 selenium==3.141.0 了。
不過預期明年 ESR 更新的時候又要再改了，到時候再看看吧...
另外一個遇到的小問題是，我發現 Facebook 登入第一次後，關掉瀏覽器再打開會被登出，這時候再登入一次後面就正常了，但不知道為什麼...
前幾天社群蠻熱鬧在討論綠界的 *.ecpay.com.tw 憑證被上游 Sectigo 給 revoke，而導致 login.ecpay.com.tw 無法連線的問題 (ba:d3:26:14:db:53:1b:56:49:8d:de:d5:0c:68:b9 這張，另外參考點了 OCSP 檢查的 https://crt.sh/?id=3608838685&opt=ocsp 結果)，可以看 domain 知道這個網域比較偏使用者的用途 (而非 API 類)，會買 EV 主要就是要用在瀏覽器上，所以這邊主要就討論瀏覽器受到影響的部份...
因為 Sectigo 是透過 CRL 與 OCSP 兩個機制把 revoke 資訊送出來，所以各家瀏覽器的處理方式會不太一樣...
首先是市占率最高的 Chrome，因為有自家的機制在處理 revoke，不走 CRL 或是 OCSP，所以大多數的使用者應該都沒有受到影響 (不確定...)，但 Firefox 與 Safari 都吃 OCSP，所以都會炸掉。
這次有看到兩個社群有一些討論，一個是「https://www.facebook.com/groups/rayforum/posts/4417812681632189/」，另外一個是「https://www.facebook.com/groups/616369245163622/posts/2497356027064925/」這邊。
Vincent Liang 有貼了 Sectigo 送 revoke 的原因，在 Mozilla 的 Bugzilla 上面有 Sectigo 的主動通報：「Sectigo: Subject field with unvalidated information included in certificates」，看起來是因為在內部 code review 的時候發現 postOfficeBox (以台灣來說就是郵遞區號郵政信箱) 這個欄位的問題：
Though the postOfficeBox field is permissible for inclusion in OV certificates, any field containing unvalidated information is not permissible. Furthermore, the EV Guidelines prohibit this field at all for EV certificates.
也就是說，在 OV 憑證內可以列入 postOfficeBox，但需要確認後才能列進去；而 EV 憑證則是不允許列 postOfficeBox 的；因為這兩個原因，這些憑證都要 revoke，另外也因為 Baseline Requirements 與 EV SSL Certificate Gudidelines 的要求而需要主動通報。
Sectigo 有列出 453 個受到影響的憑證，不過發文者 Lorex L. Yang 有注意到綠界的這個憑證沒有被列在這 453 個受到影響的憑證內，但是後來也有被 revoke 掉...
所以現在問題就來了，會不會 Sectigo 根本沒通知綠界要換憑證？另外 Sectigo 的通報內容不實也是一個大問題，因為沒有人在 Bugzilla 上提到，所以我就在上面回個 comment 把這個議題拋出來，讓 Mozilla 的人知道後繼續查下去...
當然綠界花了十八個小時解決也是個問題，不過那個就不是我們能管到的了...
在 Hacker News Daily 上看到「Safari tries to fill username」這個 Safari 的 "feature"。
作者發現網站在 Safari 上會出現登入的提示功能，像是這樣：
本來以為是 bug，但實際測過後看起來像是 feature，但抓字串的方法很容易誤判，看起來是抓 welcome back 這組字串：
On further consideration I don't think it's a bug. I think Safari is assuming any page with "Welcome Back" on it is a login page and enabling this behaviour. Therefore I think it's intended.
然後作者也有找到 workaround，用 去閃偵測：
Nice one. I found that using a non-breaking space prevents the behaviour.
>p>welcome back</p>
其他人也有發現其他的字串也會中獎：
It seems the same applies to "Sign In"
"Log in" works too. I tried a couple other languages (Finnish, German, French, Chinese) but the issue/feature seems to only happen with English (although I did use Google Translate, so I can't guarantee I used the right idioms).
目前看起來遇到就只能先 workaround 了...
GitHub 在月初的時候把所有人都 logout，然後前幾天發文解釋了當時的情況：「How we found and fixed a rare race condition in our session handling」。
起因於月初時有使用者回報他在登入後，變成其他人的身份：
On March 2, 2021, we received a report via our support team from a user who, while using GitHub.com logged in as their own user, was suddenly authenticated as another user. They immediately logged out, but reported the issue to us, as it rightfully worried them.
後面其實就是在講他們在改善 github.com 的效能時是在 Rails 架構上疊上許多 threading 的機制，但是沒有處理好 critical section 與 object reuse 而造成後續的問題。
知道是 thread safety 的問題發生點後，其實就大概知道怎麼解決，主要還是 GitHub 在這篇文章裡面透漏了不少有趣的技術。
首先是 github.com 有保留 HTTP header 與 HTTP body，而且有記錄是在哪台機器、哪個 process 處理的，這對於事後找問題時很有幫助：
From reviewing logs, we could gather that the HTTP body in the response to the client we sent was correct and only the cookies in the response to the user were wrong. The affected users from the support reports received a session cookie from a user who very recently had a request handled inside the same process. In one case, the two requests were handled sequentially, one after the other. In the second case, there were two other requests in between.
不確定是不是所有的 HTTP request 都有記錄，以 GitHub 的量來說應該是蠻可觀的，但感覺上現代的硬體好像又可以暴力解...
另外是 github.com 引入了 threading 技術改善效能，不過這邊不確定這邊是用 C/C++ 寫，還是單純用 Ruby 本身提供的 threading 撰寫：
Threads were already used in other places in this application, but the new background thread produced a novel and unforeseen interaction with our exception handling routines. When exceptions were reported from a background thread, such as a query timeout, the error log would contain information from both the background thread and the currently running request, showing that the data was being pulled across threads.
這種最佳化的方式只有在夠大的服務上做才有效益，只能說 GitHub 的人比較無奈，threading 掛上一個已經很複雜的應用程式的確是容易中獎...
在 2017 年的時候 18F 推出了美國政府的 SSO 服務 login.gov：「Government launches login.gov to simplify access to public services」，當時只支援聯邦政府的系統。
這幾天看到了新的公告，宣佈 login.gov 的服務範圍打算擴大到州政府與地方政府的計畫：「Login.gov to provide authentication and identity proofing services to a limited number of federally funded state and local government programs.」。
翻了一下開發網站「Welcome to the login.gov developer guide | login.gov」，可以看到使用的技術應該是 OpenID 與 SAML：
Select between OpenID Connect (OIDC) or SAML protocol implementation protocols. Please note that we recommend OIDC.
難得看到 OpenID 被拿出來用，記起來好了...
Cloudflare 總算是導入 security key 了，之前都得開 app 用 TOTP 認證：「Cloudflare now supports security keys with Web Authentication (WebAuthn)!」。
把 security key 設定好之後，登入就會跳提示要你用 security key 登入：
當你手上沒辦法用 security key 時，還是可以選擇用 TOTP：
這樣方便多了，而且也更安全 (比起六碼數字，以及防 phishing 的能力)。
看到 Twitter 要清沒有在用的帳號的消息：「Twitter will remove inactive accounts and free up usernames in December」，官方的「Inactive account policy」裡面也可以看到。
看起來定義上是六個月沒有動，官方就可以當作 inactive account 處理：
We encourage people to actively log in and use Twitter when they register an account. To keep your account active, be sure to log in and Tweet at least every 6 months. Accounts may be permanently removed due to prolonged inactivity.
讓我想到先前 arashi_5_official 帳號的取名原因 XDDD
另外不知道會怎麼處理權限上的配套措施，像是有不少網站支援 Twitter 帳號登入，如果被其他人拿到後代表有機會取得其他非 Twitter 系統的權限...
這篇是 StackOverflow 在講 cache 的文章，裡面不是什麼新東西，只是看到有趣的項目所以拿出來講：「How Stack Overflow Caches Apps for a Multi-Tenant Architecture」。
在講 cache 前通常都會說明各種儲存空間速度的差異，但裡面混了一個奇怪的東西：
裡面混了一個不是 storage 的東西進去比較，你們是對 Microsoft 的帳號系統有多不爽 XDDD
另外他們列出了目前 Redis 的使用情況：
For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):
- Our Redis physical servers have 256GB of memory, but less than 96GB used.
- 1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)
- Average of 2.01% CPU utilization (3.04% peak) for the entire server (< 1% even for the most active instance)
- 124,415,398 active keys (422,818,481 including replicas)
- Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)
然後更長的版本可以在作者自己的 blog 上讀到，裡面講到的 cache invalidate (purge) 這部份有談到一些他們的作法：「Stack Overflow: How We Do App Caching - 2019 Edition」。
大致上有兩則，一個是 StackOverflow 首頁改版，以前的首頁是各種熱門或是新的問題的列表 (像是下面第一張圖)，而在改版後，沒有登入的使用者將只會看到各種廣告 (可以透過無痕模式測試，像是第二張圖)：
這件事在「New home page makes it seem like SO doesn't allow free use any more」被拿出來討論，而且目前看起來沒打算改回來... 公司大了以後的常態之一。
第二個是有人在瀏覽器的 console 上發現 StackOverflow 上出現 AudioContext 的請求，一路追發現是廣告嘗試透過瀏覽器特性追蹤使用者 (也就是 Fingerprint)：「Why is Stack Overflow trying to start audio?」。
StackOverflow 的官方回應覺得這個廣告不適合，有提出一些方案，不過看了一下這邊方案都還是不可行 (需要瀏覽器實做新功能，或是修正 bug)，目前還是推薦用 uBlock Origin 直接擋掉，節省 CPU resource 與 bandwidth...