幹壞事是進步最大的原動力
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...
看到「Disable SMS or voice codes for 2-Step Verification for more secure accounts」這邊的說明，G Suite 的管理員可以將 SMS 與 Voice 強制關閉 (也就是不認為這兩個管道是安全的 2FA)。
主要是因為行動網路一直都不怎麼安全，像是 GPRS 與 3G network 使用的 KASUMI，或是 downgrade attack (用 2G network)。
目前 G Suite 登入有提供的 2FA 除了上面這兩個以外，應該還有 TOTP 與 U2F 類的認證方式，這次影響最大的應該是堅持用非智慧型手機的人？這種：
Flickr 在被 SmugMug 收購後就開始在整理架構，其中一塊是把本來綁定 Yahoo! 的登入拿掉，現在官方推出計畫了：「Flickr login freedom is here.」。
不過不是所有人都馬上可以用，而是逐步開放給使用者：
The first page of the login experience has already been updated with a new look, but you will continue to log in to your Flickr account with your Yahoo credentials as you always have until the rollout reaches you.
來繼續等...
在「Android Gets FIDO2 Certification—Now Supports Secure Passwordless Logins」這邊看到 Android 7.0 支援 FIDO2 了：
If you have already installed the latest update of Google Play Services released earlier today, and your Android device is running Android version 7.0 Nougat or above—Congratulations! Your device is now FIDO2 Certified.
所以在 browser 有配合的情況下，可以用手機當作 MFA，而且 anti-phishing...
再弄 WordPress 的 U2F 時發現他也可以共存其他 2FA 機制 (也就是可以挑一種方式當 2FA，像是 TOTP)，就開始重設 OTP...
結果手賤把 FreeOTP 的 ' 改成 ' (因為看起來不順眼 XD)，就遇到「FreeOTP stuck crashing at startup if name contains certain characters · Issue #100 · freeotp/freeotp-ios」這個問題，結果 FreeOTP 直接閃退開不起來，而且沒有 workaround 的方式存取其他的 OTP token...
找了一下替代方案，目前先用「mattrubin/Authenticator: Two-Factor Authentication Client for iOS」這套了，要注意有同名而且界面很像的 app 在上面，要確認作者名稱...
然後接下來就是一連串 reset 2FA token 的步驟了，有些當初沒有留 backup code 超麻煩 @_@
我自己再用的 Trac 本來是走 HTTP 的 Authorization header 登入，但這樣每次重開瀏覽器就要登入一次，覺得麻煩... 就想要找套件改成用 HTML form login。
目前比較有在維護的應該是 AccountManagerPlugin 這套，內建就支援本機密碼，也支援 plugin 掛其他外部服務進去。
但掛進去後發現本來的自動開票機 (i.e. 用 crontab 開票) 就沒辦法登入了，最後找到得用 HttpAuthPlugin 處理。這個套件一開頭就寫了他也是為了 XmlRpcPlugin 而寫的：
This plugin allows you to protect certain paths with HTTP authentication. The AccountManagerPlugin is used to check passwords.
Primarily this is meant to be used with the XmlRpcPlugin, so it will work while using AccountManager's form-based logins.
就是遇到同樣的問題...
最近吵的蠻凶的一個話題... 當你在 Google Chrome 瀏覽器內登入 Google 帳號後 (像是 Gmail)，你的 Google Chrome 就會自動也一起登入了。
官方目前拒絕承認這是個錯誤的設計，所以現在大家都在找 workaround 解。目前看到比較好的方式是這篇，提供了設定方式 (包括 Windows 與 Mac 平台)：「Disable Google Chrome Sign In and Sync」。
裡面有兩個步驟，第一個 SyncDisabled 設為 true 是把同步功能關掉，第二個 RestrictSigninToPattern 設為 .*@example.com 是把同時登入功能限制在 example.com 上，而這個 domain 則是在 RFC 2606 (Reserved Top Level DNS Names) 被保護起來，不開放任何單位註冊，也就是讓 Chrome 不可能找到符合的條件。
另外一個方法是跳到 Firefox，但順暢度應該還是目前最主要的障礙吧...
